التكوينات المستحسنة لعملاء Apache Kafka

فيما يلي التكوينات المستحسنة لاستخدام مراكز الأحداث من تطبيقات عميل Apache Kafka.

خصائص تكوين عميل Java

تكوينات المنتج والمستهلك

الخاصية	القيم المستحسنة	النطاق المسموح به	ملاحظات
metadata.max.age.ms	180000 (تقريبي)	< 240000	يمكن تخفيضها لالتقاط تغييرات بيانات التعريف في وقت أقرب.
connections.max.idle.ms	180000	< 240000	يغلق Azure بروتوكول تحكم الإرسال (TCP) الوارد الخامل > 240,000 ملي ثانية، ما قد يؤدي إلى إرسال اتصالات معطلة (تظهر على هيئة دُفعات منتهية الصلاحية بسبب انتهاء مهلة الإرسال).

تكوينات المنتج فقط

يمكن العثور على تكوينات المنتج هنا.

الخاصية	القيم المستحسنة	النطاق المسموح به	ملاحظات
max.request.size	1000000	< 1046528	ستغلق الخدمة الاتصالات إذا تم إرسال طلبات أكبر من 1,046,528 بايت. يجب تغيير هذه القيمة وسوف تسبب مشاكل في سيناريوهات إنتاج معدلات نقل عالية.
retries	> 0		قد تتطلب زيادة قيمة delivery.timeout.ms، راجع الوثائق.
request.timeout.ms	30000 60000	> 20000	سوف تتخلف مراكز الأحداث افتراضياً عن 20,000 ملي ثانية كحد أدنى. بينما يتم قبول الطلبات ذات قيم المهلة المنخفضة، فإن سلوك العميل غير مضمون.. تأكد من أن request.timeout.ms هي على الأقل القيمة الموصى بها 60000 وأن session.timeout.ms هي على الأقل القيمة الموصى بها 30000. قد يتسبب انخفاض هذه الإعدادات في انقضاء مهلة المستهلك، ما يؤدي بعد ذلك إلى إعادة التوازن (مما يؤدي بعد ذلك إلى مزيد من المهلات، ما يؤدي إلى مزيد من إعادة التوازن، وما إلى ذلك).
metadata.max.idle.ms	180000	> 5000	يتحكم في المدة التي سيقوم فيها المنتج بتخزين بيانات التعريف مؤقتاً لموضوع يُعد خاملاً. إذا تجاوز الوقت المنقضي منذ آخر إنتاج لموضوع مدة خمول بيانات التعريف، فسيتم تجاهل بيانات التعريف الخاصة بالموضوع وسيفرض الوصول التالي إليه طلب إحضار بيانات تعريف.
linger.ms	> 0		بالنسبة لسيناريوهات معدل النقل المرتفع، يجب أن تكون قيمة المتبقية مساوية لأعلى قيمة مقبولة للاستفادة من عملية الإرسال في دفعات.
delivery.timeout.ms			تعيين وفقا للصيغة ( request.timeout.ms + linger.ms ) * retries.
compression.type	none		لا يتم دعم الضغط حالياً..

تكوينات المستهلك فقط

يمكن العثور على تكوينات المنتج هنا.

الخاصية	القيم المستحسنة	النطاق المسموح به	ملاحظات
heartbeat.interval.ms	3000		3000 هي القيمة الافتراضية ولا يجب تغييرها.
session.timeout.ms	30000	6000 300000	تبدأ مع 30000، يمكن زيادتها عند حدوث إعادة التوازن المتكرر بسبب رسائل كشف أخطاء الاتصال المفقودة. تأكد من أن request.timeout.ms الخاص بك هي على الأقل القيمة الموصى بها 60000 وأن session.timeout.ms هي على الأقل القيمة الموصى بها 30000. قد يتسبب انخفاض هذه الإعدادات في انقضاء مهلة المستهلك، ما يؤدي بعد ذلك إلى إعادة التوازن (مما يؤدي بعد ذلك إلى مزيد من المهلات، ما يؤدي إلى مزيد من إعادة التوازن، وما إلى ذلك).
max.poll.interval.ms	300000 (افتراضي)	>session.timeout.ms	يستخدم لإعادة توازن المهلة، لذا لا يجب تعيين هذا إلى قيمة منخفضة جدًا. يجب أن يكون أكبر من session.timeout.ms.

خصائص تكوين librdkafka

يحتوي ملف التكوين الرئيسي librdkafka(الارتباط) على أوصاف موسعة للخصائص أدناه.

تكوينات المنتج والمستهلك

الخاصية	القيم المستحسنة	النطاق المسموح به	ملاحظات
socket.keepalive.enable	صحيح		ضروري إذا كان من المتوقع أن يكون الاتصال خاملاً. سيغلق Azure الوارد TCP الخامل > 240,000 ملي ثانية.
metadata.max.age.ms	~ 180000	< 240000	يمكن تخفيضها لالتقاط تغييرات بيانات التعريف في وقت أقرب.

تكوينات المنتج فقط

الخاصية	القيم المستحسنة	النطاق المسموح به	ملاحظات
retries	> 0		الافتراضي هو 2147483647.
request.timeout.ms	30000 60000	> 20000	سوف تتخلف مراكز الأحداث افتراضياً عن 20,000 ملي ثانية كحد أدنى. librdkafka القيمة الافتراضية هي 5000، والتي يمكن أن تكون مسببة للمشاكل. بينما يتم قبول الطلبات ذات قيم المهلة المنخفضة، لا يتم ضمان سلوك العميل.
partitioner	consistent_random	راجع وثائق librdkafka	consistent_random هو الافتراضي والأفضل. يتم التعامل مع مفاتيح فارغة وخالية بشكل مثالي لمعظم الحالات.
compression.codec	none		لا يتم دعم الضغط حالياً.

تكوينات المستهلك فقط

الخاصية	القيم المستحسنة	النطاق المسموح به	ملاحظات
heartbeat.interval.ms	3000		3000 هي القيمة الافتراضية ولا يجب تغييرها.
session.timeout.ms	30000	6000 300000	تبدأ مع 30000، يمكن زيادتها عند حدوث إعادة التوازن المتكرر بسبب رسائل كشف أخطاء الاتصال المفقودة.
max.poll.interval.ms	300000 (افتراضي)	>session.timeout.ms	يستخدم لإعادة توازن المهلة، لذا لا يجب تعيين هذا إلى قيمة منخفضة جدًا. يجب أن يكون أكبر من session.timeout.ms.

ملاحظات أخرى

تحقق من الجدول التالي لسيناريوهات الأخطاء المرتبطة بالتكوين الشائعة.

العلامات	المشكلة	حل
تتسبب الإزاحة في الفشل بسبب إعادة التوازن	ينتظر المستهلك وقتاً طويلاً بين المكالمات للاستقصاء () والخدمة تُخرج المستهلك من المجموعة.	لديك العديد من الخيارات: زيادة مهلة معالجة الاستقصاء (max.poll.interval.ms) إنقاص حجم دفعة الرسالة لتسريع المعالجة تحسين التوازي المعالجة لتجنب حظر consumer.poll() تطبيق مجموعة من الثلاثة هو على الأرجح الاختيار الأمثل.
استثناءات الشبكة عند معدل نقل عالي الإنتاجية	هل تستخدم عميل Java + max.request.size الافتراضي؟ قد تكون طلباتك كبيرة جداً.	راجع تكوينات java أعلاه.

الخطوات التالية

راجع حدود وحصص وقيود الخدمة والاشتراك في Azure للاطلاع على الحصص والحدود الخاصة بجميع خدمات Azure.