Kafka عمیق: پارتیشن، Lag و Exactly-Once — طراحی سیستم نرم‌افزاری

فصل ۴ گفت Kafka چیست و چرا؛ این درس می‌گوید چطور واقعاً کار می‌کند — چون ۹۰٪ حادثه‌های production ی Kafka از سه جا می‌آید: انتخاب بد کلید پارتیشن، ندیدن consumer lag، و باور غلط به «exactly-once».

پارتیشن: واحد مقیاس و ترتیب

DIAGRAMیک topic با ۳ پارتیشن و دو گروه مصرف‌کننده

Producers

→

Group A — ۲ consumer

→

Group B — ۳ consumer

داخل هر topic، داده در پارتیشن‌ها (لاگ‌های append-only روی دیسک) تقسیم می‌شود؛ حداکثر موازی‌سازی مصرف = تعداد پارتیشن‌ها. پارتیشن کم = گلوگاه، پارتیشن زیاد = سربار متادیتا و recovery کند — معمولاً ده‌ها تا صدها، نه هزاران بی‌حساب.
ترتیب فقط داخل یک پارتیشن تضمین است؛ کلید پیام تعیین‌کننده پارتیشن است — رویدادهای یک موجودیت (order_id) را با همان کلید بفرست.
کلید داغ، یک پارتیشن را می‌سوزاند و بقیه بیکار می‌مانند (همان Hot Key فصل ۳، این‌بار در لاگ): برای کلید داغ، شکستن کلید با suffix تصادفی + تجمیع بعدی.
Replication factor معمولاً ۳ با min.insync.replicas=2 و acks=all برای داده مهم — پیش‌فرضها برای دوام بهینه نیستند.

Consumer Lag: مهم‌ترین متریک Kafka

Lag = فاصله بین آخرین پیام نوشته‌شده و آخرین پیام خوانده‌شده توسط گروه. lag بالا یعنی مصرف‌کننده عقب است: یا کند است، یا crash می‌کند و retry می‌خورد (پیام سمی)، یا rebalancing مکرر دارد. rebalancing هنگام join/leave مصرف‌کننده‌ها، مصرف را موقتاً متوقف می‌کند — با cooperative rebalancing و ثابت‌ماندن membership کمش کن. هشدار روی lag، نه روی «آیا Kafka بالاست».

تضمین‌ها، صادقانه

Idempotent Producer

هر producer یک PID و شماره ترتیب می‌گیرد؛ retry شبکه پیام را تکراری نمی‌کند — تکرار درون-برکری حذف می‌شود.

Transactions (EOS)

نوشتن اتمی روی چند پارتیشن + commit offset در یک تراکنش: الگوی consume-transform-produce را exactly-once می‌کند.

Log Compaction

برای topic های کلیددار فقط آخرین مقدار هر کلید نگه داشته می‌شود — چنل تکرار state (مثل تنظیمات کاربر) را بدون رشد بی‌نهایت نگه می‌دارد.

حقیقت تلخ

exactly-once فقط داخل مرز Kafka و با sink/source سازگار است؛ به‌محض اینکه پیام به DB/ایمیل برسد، قانون فصل ۴ برمی‌گردد: at-least-once + مصرف‌کننده idempotent.

Kafka در برابر بقیه

ابزار	مدل	کجا می‌درخشد
Kafka	لاگ ماندگار پارتیشنی؛ مصرف‌کننده offset خودش را دارد	رویدادهای عظیم، replay، چند مصرف‌کننده مستقل، stream processing
RabbitMQ	صف کلاسیک با routing هوشمند؛ broker مسئول تحویل است	کاری‌های پس‌زمینه، routing پیچیده، مقیاس متوسط
Pulsar	مانند Kafka + لایه محاسبه/ذخیره جدا و multi-tenancy بومی	تیم‌هایی که geo-replication و multitenancy از جعبه می‌خواهند
SQS/سرویس‌های مدیریت‌شده	صف ابری بدون سرور	صفر عملیات؛ بدون replay و کنترل دقیق

به زبان ساده

Kafka صفی است که پیام‌ها را حذف نمی‌کند؛ هر مصرف‌کننده با offset خودش می‌خواند و «تأخیر مصرف‌کننده» (lag) مهم‌ترین عدد سلامت آن است.

مثال واقعی

مثل نوار خبر دوربین مداربسته: هر ناظر (مصرف‌کننده) با سرعت خودش از همان نوار می‌خواند؛ اگر ناظری عقب بیفتد (lag بالا)، یعنی رویدادها انباشته شده‌اند.