kafka in action

کافکا توی داکیومنت هاش خودش رو پلتفرم دیستربیوت استریم معرفی کرده. اینکه از message broker استفاده کنیم خوبیش loose coupling بین لایه های مختلفه

انواع دلیوری پیام در کافکا

• مدل at most once: یعنی یکبار پیام ارسال میشه و retry نداره و اگه از دست بره برای همیشه از دست میره مثلا برای فرستادن لاگ ویو صفحه خوبه
• مدل at least once: توی این مدل پیام بعد از دریافت توسط consumer کامیت میشه و بعدش پیام پردازش میشه توی این حالت retry داریم برای پیام های که هنوز کامیت نشدن
• مدل exactly once: توی حالت at least once اگه پیام کامیت بشه ولی وسط پردازش کرش کنه اون پیام چون کامیت شده دیگه retry نمیشه ولی توی این حالت بعد از پردازش کامییت میشه پس وقتی کامییت میشه یعنی پردازشش هم تموم شده. یعنی مثلا من یه ایونت میفرستم، پردازشم شروع میشه یه پیام توی یه جایی که برای خوده کافکا است پابلیش میشه بعد اینکه کارم تموم شد کامییت که کردم میره داخل همون جایی که برای کافکا بود میکه کارش تموم شد این ایونت و اگه fail بشه کافکا پاکش میکنه

یادداشت

وقتی پیام پابلیش میشه چه اتفاقاتی میافته؟ وقتی یک پیام در Kafka publish می‌شود، producer اول تصمیم می‌گیرد که پیام باید روی کدام partition برود. این انتخاب یا بر اساس key انجام می‌شود یا اگر key نداشته باشد، با round-robin یا الگوریتم دیگر. بعد از مشخص شدن partition، producer پیام را برای leader broker آن partition می‌فرستد.

broker پیام را به انتهای log مربوط به آن partition اضافه می‌کند. این log یک فایل append-only روی دیسک است که به صورت segment تقسیم شده. داده بلافاصله در حافظه سیستم‌عامل (page cache) ذخیره می‌شود و بعد به صورت پس‌زمینه روی دیسک flush می‌شود، به همین دلیل هم Kafka خیلی سریع عمل می‌کند.

بعد از نوشتن پیام، leader آن را برای replicaهای follower ارسال می‌کند تا کپی‌ها به‌روز شوند. بسته به تنظیمات producer، ممکن است منتظر تأیید همه replicaها بماند یا فقط منتظر تأیید leader باشد. زمانی که شرط acks برآورده شد، leader یک acknowledgment به producer می‌فرستد که شامل offset پیام در log هم هست.

از این لحظه پیام رسماً در Kafka ذخیره شده و آماده مصرف است. consumerها با استفاده از offsetها پیام را از log می‌خوانند. Kafka پیام را تا زمانی که retention policy اجازه دهد نگه می‌دارد، حتی اگر همه consumerها آن را خوانده باشند.

به این ترتیب، publish یک پیام در Kafka زنجیره‌ای از انتخاب partition، append شدن روی log، replication بین brokerها و در نهایت برگرداندن acknowledgment به producer است.

Broker

اBrokerها در واقع سرورهای Kafka هستن که داده‌ها رو نگه می‌دارن و مدیریت می‌کنن. هر broker می‌تونه چند topic و partition رو میزبانی کنه. وقتی من پیام می‌فرستم، broker وظیفه داره پیام رو ذخیره کنه، replicate کنه و در دسترس بقیه consumerها بذاره. وقتی cluster از چند broker تشکیل می‌شه، هر broker با بقیه هماهنگ می‌کنه تا اگه یکی از کار افتاد، داده‌ها همچنان در دسترس باشن. این replication باعث می‌شه Kafka خیلی مقاوم و fault-tolerant باشه.

Topics

تاپیک مثل یه کانال یا دسته‌بنده‌ست که پیام‌ها رو بر اساس موضوع جدا می‌کنه. فرض کن می‌خوای لاگ‌های صفحه، سفارش‌های خرید و هشدارهای سیستم رو جدا ذخیره کنی، هر کدوم یه topic می‌شن. من وقتی پیام می‌فرستم، مشخص می‌کنم به کدوم topic بره. consumerها هم می‌تونن subscribe کنن به topic دلخواه و فقط پیام‌های مربوطه رو بخونن. Topic در واقع یک نام منطقیه که پیام‌ها رو گروه‌بندی می‌کنه، ولی خودش داده رو ذخیره نمی‌کنه—این partitionها هستن که نگهداری می‌کنن.

Partitions

هر topic می‌تونه به چند partition تقسیم بشه تا همزمان پردازش سریع‌تر بشه و مقیاس‌پذیر باشه. Partition مثل یه خط زمانیه، هر پیام که می‌فرستم میره ته این خط و یه offset یکتا می‌گیره. هر partition یه leader داره و followerها اون partition رو replicate می‌کنن. این ساختار باعث می‌شه که حتی وقتی پیام‌ها خیلی زیاد شدن یا brokerها crash کردن، دسترسی به داده‌ها از بین نره. partition همچنین امکان parallelism رو فراهم می‌کنه: چند consumer می‌تونن همزمان روی partitionهای مختلف پیام‌ها رو پردازش کنن.

The Commit Log

کامیت لاگ همون دنباله پیام‌های append-only هست که هر partition داره. وقتی پیام publish می‌شه، میره ته log و offset یکتا می‌گیره. log تضمین می‌کنه که پیام‌ها همیشه پشت سر هم و با ترتیب درست ذخیره می‌شن. Consumerها بر اساس offset می‌تونن پیام‌ها رو بخونن و حتی بعد از چند روز یا هفته دوباره برگردن پیام‌ها رو مرور کنن. Kafka هیچ پیام رو حذف نمی‌کنه تا وقتی که retention policy اجازه بده، حتی اگر همه consumerها پیام رو خونده باشن. این log همچنین پایه‌ایه برای replication، recovery و exactly-once semantics، چون همه داده‌ها مرتب و قابل دسترس باقی می‌مونن.

یادداشت

Retention policy توی Kafka همون قانونی هست که مشخص می‌کنه پیام‌ها تا چه مدت یا تا چه حجمی توی topic نگه داشته بشن. یعنی Kafka خودش به صورت خودکار بعد از یه مدتی یا وقتی حجم log به حد مشخص رسید، پیام‌های قدیمی رو پاک می‌کنه تا حافظه پر نشه.

می‌تونه بر اساس زمان باشه، مثلاً پیام‌ها ۷ روز نگه داشته بشن، یا بر اساس حجم، مثلاً وقتی log یه partition به ۱۰ گیگ رسید، پیام‌های قدیمی شروع به حذف شدن می‌کنن. این سیاست باعث می‌شه حافظه و دیسک broker پر نشه و عملکرد Kafka ثابت بمونه.