Apache Kafka / الأساسي: السجلات والأقسام وتقدم القارئ / الدرس 3

المنتجون والدفعات والإقرارات

تفسير اكتمال المنتج وضبط موازنة محدودة بين التأخر والإنتاجية دون اختراع ضمانات متانة.

وقت القراءة التقريبي: 4 دقيقةتاريخ مراجعة المحتوى 2026-10-28

في هذه الصفحة

أهداف الدرس

التمييز بين الإضافة المحلية وإقرار الوسيط والمعالجة اللاحقة.
شرح الدفعات والضغط ومهل التسليم.

تتبع دورة الإرسال

يسلسل المنتج السجل ويختار قسمه ويخزنه مؤقتاً ثم يرسل الدفعات إلى القادة. إرجاع عملية غير متزامنة لكائن future لا يثبت قبول الوسيط للسجل؛ يجب فحص نتيجة الاكتمال. وحتى نجاح إقرار الوسيط لا يعني أن مستهلكاً أكمل إجراءً تجارياً. أظهر هذه المراحل منفصلة في المقاييس ومعالجة الأخطاء. تسمح إعادة استخدام المنتج بالاستفادة من اتصالاته ودفعاته؛ أما إنشاؤه لكل سجل فيعطل الفكرة. تبقى قواعد أمان الخيوط ودورة الحياة الخاصة بمكتبة العميل المختارة بحاجة إلى مراجعة.

قراءة الإقرارات بوصفها عقداً

يطلب جزء الإعداد إقرار جميع النسخ المتزامنة الحالية ويفعل منع تكرار المنتج. المثال غير كامل عمداً؛ فلا يوفر نقطة اتصال أو بيانات اعتماد أو تطبيق Java قابل التشغيل. يحدد إعداد min.insync.replicas للموضوع وبنية النسخ حالات التدهور التي ترفض الكتابة. تعني all مجموعة النسخ المتزامنة الحالية، لا كل نسخة مهيأة بصرف النظر عن صحتها. إذا تقلصت المجموعة وكان الحد الأدنى صغيراً، تتقلص القدرة العملية على تحمل الأعطال. تعامل مع هذه الخصائص عقداً مشتركاً بين المنتج والموضوع، لا وصفة متانة سحرية.

properties خصائص توضيحية لمنتج Java

acks=all
enable.idempotence=true
linger.ms=5
compression.type=lz4

يحتاج هذا الجزء عميلاً متوافقاً وعقداً مراجعاً للوسيط والموضوع، ولم يشغل.

حساب الانتظار والضغط معاً

تجمع الدفعة سجلات القسم نفسه لتشارك كلفة الشبكة والتخزين. يحدد batch.size هدفاً لحجم الدفعة، ويسمح linger.ms بانتظار سجلات إضافية؛ ولا يعني ذلك وصول كل دفعة إلى الحجم المحدد. يعتمد ضغط الدفعات على تشابه السجلات وكلفة الخوارزمية. تغيرت قيمة linger.ms الافتراضية في Kafka 4.0 من صفر إلى خمس ميلي ثوان، لذا قد تكون افتراضات الإصدارات القديمة خاطئة. حدد ميزانية التأخر أولاً ثم قس التوزيع الفعلي في بيئة مصرح بها. قد يخفي متوسط الإنتاجية تأخراً طويلاً متقطعاً أو قسماً ساخناً.

تحليل ميزانية التسليم

يقسم الحساب المحلي ميزانية تطبيق اصطناعية مقدارها أربعون ميلي ثانية بين انتظار الدفعة ووقت الشبكة والوسيط والهامش المتبقي. لا يتنبأ بزمن وسيط حقيقي؛ بل يكشف ميزانية مستحيلة قبل الضبط. يستهلك تأخير الدفعات من السماح المحدود نفسه الذي تحتاجه المحاولات والجدولة. يحد delivery.timeout.ms الزمن الإجمالي لانتظار نجاح السجل أو فشله، بينما تقيد إعدادات أخرى الطلب الواحد أو انتظار البيانات الوصفية. راجع القيود الموثقة بين الإعدادات. قد تترك المهلة النتيجة التجارية غير مؤكدة، لذلك يحتاج التعافي هوية الحدث ولا يفترض غياب الكتابة.

python حساب محلي لميزانية التأخر

budget_ms = 40
batching_ms = 5
network_broker_ms = 20
slack_ms = budget_ms - batching_ms - network_broker_ms
assert slack_ms == 15
print(slack_ms)

الناتج المتوقع

تبقى خمس عشرة ميلي ثانية وفق الافتراضات؛ وليست قياساً للتأخر.

مراقبة الفشل غير المتزامن والإغلاق

ينبغي أن يسجل معالج callback أو future النتيجة كاملة دون إعاقة تقدم المنتج بأعمال بطيئة غير مرتبطة. قرر هل يرفض الفشل النهائي الطلب الأصلي، أم يحفظ الحدث في مسار إعادة محاولة دائم ومعتمد، أم يطلق إشارة تشغيلية. تسجيل الخطأ ثم تجاهله يغير عقد التسليم بصمت. تنتظر flush الإرسالات المخزنة وفق قواعد العميل، لكنها لا تصلح أخطاء جرى تجاهلها ولا تؤكد المعالجة الخارجية. يحتاج الإغلاق المنضبط مهلة محدودة وحصراً للإرسالات غير المكتملة. لا تنشئ هذه الأمثلة منتجاً حقيقياً ولا تقيس أداءه.

الأخطاء الشائعة وإصلاحها

اعتبار عودة send نجاحاً فورياً للتسليم.

لماذا يحدث؟: الخلط بين الإضافة المحلية واكتمال الإرسال.
كيف تصلحه؟: افحص future أو callback وانقل الفشل النهائي.
كيف تتجنب تكراره؟: تتبع الإضافة والإقرار مرحلتين منفصلتين.

وصف acks=all بأنه حماية من فقدان جميع النسخ.

لماذا يحدث؟: الخلط بين نطاق الإقرار والتعافي المستقل.
كيف تصلحه؟: راجع توزيع النسخ والحد الأدنى للتزامن ونسخ التعافي.
كيف تتجنب تكراره؟: حدد سيناريوهات الأعطال التي يتحملها التصميم فعلاً.

تجاوز الدفعات الكبيرة لهدف تأخر الطلب.

لماذا يحدث؟: إغفال الانتظار والمحاولات عند ضبط الإنتاجية.
كيف تصلحه؟: قس التأخر الكلي واختر إعدادات دفعات محدودة.
كيف تتجنب تكراره؟: راجع التأخر الطرفي إلى جانب متوسط الإنتاجية.

اختبر فهمك

1. هل يثبت إقرار المنتج تحديث لوحة الطرود؟

اعرض الحل المشروح

لا؛ فهو يتعلق بالقبول وفق عقد المنتج والوسيط. للوحة موضع قراءة وزمن معالجة وحالة وجهة مستقلة. إذا احتاج المستخدم تأكيد القراءة بعد الكتابة، فصمم إقراراً تجارياً قابلاً للرصد أو استعلام حالة منفصلاً، دون اعتبار future اكتمالاً لتحديث اللوحة.

2. إذا تغير انتظار الدفعة في نموذج الأربعين ميلي ثانية من خمس إلى عشرين، فما الهامش؟