ذخیره‌سازی در حالت‌های مختلف: عادی، Idempotency و تراکنش‌ها

Kafka بسته به تنظیمات Producer، داده‌ها را در یکی از سه الگوی ذخیره‌سازی ثبت می‌کند.
تفاوت اصلی میان این حالت‌ها در وجود یا عدم وجود batching، sequence، producerId و نوع کنترل تحویل (idempotent / transactional) است.

🟢 حالت ۱: ارسال ساده (Single Record Produce)

در این حالت هیچ batching، idempotency یا تراکنشی فعال نیست.
هر پیام به‌صورت مستقل و بدون متادیتای اضافی در فایل لاگ ذخیره می‌شود.

📄 نمونه لاگ:

baseOffset: 13 lastOffset: 13 count: 1
producerId: -1 producerEpoch: -1
baseSequence: -1
isTransactional: false
compresscodec: none

📘 ویژگی‌ها:

• هر پیام به‌صورت جداگانه ثبت می‌شود.
• هیچ شناسه تولیدکننده یا sequencing وجود ندارد.
• مناسب برای تست و محیط‌های آموزشی.
• فشرده‌سازی معمولاً غیرفعال است (اما می‌تواند فعال شود).

🟡 حالت ۱: ارسال گروهی (Batching Produce)

در این حالت batching فعال است، اما idempotency و تراکنش غیرفعال‌اند.
Kafka چند پیام را در یک batch ذخیره می‌کند تا کارایی شبکه و دیسک افزایش یابد.

📄 نمونه لاگ:

baseOffset: 47 lastOffset: 51 count: 5
producerId: -1 producerEpoch: -1
baseSequence: -1 lastSequence: -1
isTransactional: false
compresscodec: lz4

📘 ویژگی‌ها:

• چند رکورد در یک batch فشرده ذخیره می‌شوند.
• هیچ شناسه یا sequence وجود ندارد.
• batching از طریق تنظیمات producer فعال می‌شود: linger_ms = 5000 batch_size = 131072 compression_type = 'lz4'
• حتی بدون idempotency، ارسال گروهی کارایی را چند برابر افزایش می‌دهد.

🔎 نکته:
Batching کاملاً مستقل از idempotency است و در هر producer می‌تواند فعال شود.
در محیط واقعی توصیه می‌شود حتماً batching و فشرده‌سازی فعال باشند.

🟠 حالت ۲: Idempotent Producer ) enable.idempotence=True)

Kafka در این حالت برای هر producer یک producerId و sequence تولید می‌کند.
هدف این است که در صورت retry، پیام تکراری در لاگ ثبت نشود.

📄 نمونه لاگ:

baseOffset: 20 lastOffset: 25 count: 6
producerId: 0 producerEpoch: 0
baseSequence: 0 lastSequence: 5
isTransactional: false
compresscodec: lz4

📘 ویژگی‌ها:

• پیام‌ها دارای ترتیب (sequence) هستند.
• اگر producer دوباره پیام را بفرستد، Kafka تکرار را تشخیص می‌دهد.
• batching معمولاً فعال است، ولی الزامی نیست.
• این حالت پایه‌ی پیاده‌سازی exactly-once semantics است.

🔎 نکته:
در هر بار اجرای مجدد producer، مقدار producerId جدیدی تخصیص می‌یابد.

🔵 حالت ۳: Transactional Producer (با transactional.id)

در این حالت پیام‌ها در قالب تراکنش ارسال می‌شوند تا یا همگی Commit شوند یا هیچ‌کدام.
Kafka در این حالت از Transaction Coordinator استفاده می‌کند.

📄 نمونه لاگ (حتی بدون idempotency):

baseOffset: 53 lastOffset: 57 count: 5
producerId: 3 producerEpoch: 0
baseSequence: 0 lastSequence: 4
isTransactional: true isControl: false
compresscodec: lz4
---
offset: 58 isControl: true endTxnMarker: COMMIT

📘 ویژگی‌ها:

• producerId و sequence حتی بدون idempotency فعال‌اند.
• Kafka برای هر تراکنش، رکوردهای کنترل (isControl=true) ثبت می‌کند.
• endTxnMarker نشان‌دهنده‌ی وضعیت Commit یا Abort است.
• producerId ثابت می‌ماند، ولی producerEpoch در اجرای مجدد افزایش می‌یابد.
• batching و compression نیز قابل استفاده هستند.

🔎 نکته مهم:
در حالت تراکنشی، تخصیص sequence و producerId اجباری است،
زیرا Kafka باید بتواند مرز تراکنش‌ها را دقیقاً مشخص کند و از بازپخش ناقص جلوگیری نماید.

⚖️ مقایسه‌ی چهار حالت ذخیره‌سازی

💡 جمع‌بندی تحلیلی

• Batching و Compression ویژگی‌های بهینه‌سازی عملکردند و می‌توانند در همه حالت‌ها فعال باشند.
• Idempotency تضمین می‌کند پیام تکراری در اثر retry در لاگ ثبت نشود.
• Transactions تضمین می‌کنند مجموعه‌ای از پیام‌ها به‌صورت اتمیک ثبت شوند — حتی اگر idempotency غیرفعال باشد، Kafka باز هم برای کنترل تراکنش، producerId و sequence تخصیص می‌دهد.
• بهترین عملکرد در محیط واقعی معمولاً با ترکیب این سه ویژگی حاصل می‌شود:
  batching + compression + idempotency (+ transaction when needed)