ما هي دلالات التسليم في Kafka (at-least-once و exactly-once)؟

Question

Accepted Answer

يدعم Kafka ضمانات تسليم مختلفة — **at-most-once** و **at-least-once** و **exactly-once** — التي تحدد ما إذا كان يمكن فقدان الرسائل أو تكرارها. فهم هذه الضمانات وكيفية تحقيقها مهم لبناء أنظمة موثوقة.

## دلالات التسليم الثلاث

```text
AT-MOST-ONCE → messages may be LOST but never duplicated:
  → commit offset BEFORE processing → if processing fails, the message is skipped (lost)
  → for: when occasional loss is acceptable and duplicates are not (rare)
AT-LEAST-ONCE → messages are never lost but may be DUPLICATED:
  → commit offset AFTER processing → if a crash occurs before commit, the message is
    reprocessed (duplicate) → requires IDEMPOTENT processing
  → the common default; safe (no loss) but handle duplicates
EXACTLY-ONCE → each message is processed exactly once (no loss, no duplicates):
  → the strongest, but hardest; requires Kafka transactions + idempotent producers
```

## تحقيق الضمانات

```text
→ AT-LEAST-ONCE → process then commit; make consumers IDEMPOTENT (handle duplicates safely
  via dedup keys, idempotent operations) — practical and common
→ EXACTLY-ONCE → Kafka's transactional API + idempotent producer (enable.idempotence) →
  produce + commit offsets atomically (exactly-once within Kafka, e.g. Kafka Streams)
  ⚠️ exactly-once is complex and has overhead; often AT-LEAST-ONCE + idempotency is simpler
    and sufficient
```

## التوجيهات العملية

```text
✓ Most systems use AT-LEAST-ONCE + idempotent processing (simple, reliable)
✓ Use EXACTLY-ONCE when duplicates are truly unacceptable AND idempotency is hard
✓ Producer acks (acks=all) → durability (don't lose on the produce side)
→ understand the trade-offs; design for the guarantee your use case needs
```

## السبب في أهميته

فهم دلالات التسليم في Kafka ذو قيمة لأن **ضمانات التسليم تحدد الموثوقية** (ما إذا كان يمكن فقدان الرسائل أو تكرارها)، لذا فإن فهمها مهم لبناء أنظمة موثوقة.

يؤثر اختيار دلالات التسليم بشكل مباشر على الصحة.

فهم **دلالات التسليم الثلاث** — **at-most-once** (قد تُفقد الرسائل لكن لا تُكرر، بالالتزام بالـ offset قبل المعالجة — للحالات التي يكون فيها الفقدان العرضي مقبولاً)، **at-least-once** (الرسائل لا تُفقد أبداً لكن قد تُكرر، بالالتزام بعد المعالجة، مما يتطلب معالجة idempotent — الخيار الافتراضي الآمن الشائع)، و **exactly-once** (معالجة كل رسالة مرة واحدة بالضبط، الأقوى لكن الأصعب، يتطلب المعاملات والمنتجين idempotent) — ضروري لفهم مقايضات الموثوقية.

فهم **كيفية تحقيق الضمانات** — at-least-once بمعالجة ثم الالتزام وجعل المستهلكين **idempotent** (التعامل مع التكرارات عبر مفاتيح إزالة التكرار والعمليات idempotent — عملي وشائع)، و exactly-once عبر Kafka's transactional API والمنتج idempotent (إنتاج والتزام offsets بشكل ذري)، مع التحذير المهم بأن exactly-once معقد مع الحمل الزائد بينما **at-least-once بالإضافة إلى idempotency غالباً ما يكون أبسط وكافياً** — يعكس الأسلوب العملي.

فهم **التوجيهات العملية** — أن معظم الأنظمة تستخدم at-least-once بالإضافة إلى المعالجة idempotent (بسيطة وموثوقة)، باستخدام exactly-once فقط عندما تكون التكرارات غير مقبولة حقاً و idempotency صعبة، واستخدام producer acks لضمان المتانة — يعكس حكماً تصميمياً سليماً.

الرؤية الأساسية هي أن دلالات التسليم تتضمن مقايضات (فقدان مقابل تكرار مقابل التعقيد)، والخيار العملي الشائع هو at-least-once مع idempotency، والذي يرتبط بأهمية idempotency الأوسع في الأنظمة الموزعة.

بما أن ضمانات التسليم تحدد ما إذا كان يمكن فقدان الرسائل أو تكرارها (مما يؤثر بشكل مباشر على الموثوقية) وفهم الدلالات وكيفية تحقيقها (خاصة at-least-once مع idempotency كالافتراضي العملي) والمقايضات مهم لبناء أنظمة موثوقة، فإن فهم دلالات التسليم في Kafka معرفة Kafka ذات قيمة عملية مهمة — محورية للموثوقية، مهمة لتصميم الأنظمة بالضمانات الصحيحة (عادة at-least-once مع idempotency)، وتعكس الفهم المطلوب لبناء أنظمة موثوقة قائمة على Kafka.