التكوينات المستحسنة لعملاء 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 | يتم تعيين Event Hubs افتراضيا داخليا إلى 20000 مللي ثانية كحد أدنى.
بينما يتم قبول الطلبات ذات قيم المهلة المنخفضة، لا يتم ضمان سلوك العميل. تأكد من أن 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, gzip |
ضغط gzip فقط مدعوم حاليا. |
تكوينات المستهلك فقط
يمكن العثور على تكوينات المنتج هنا.
| الخاصية | القيم المستحسنة | النطاق المسموح به | ملاحظات |
|---|---|---|---|
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 240,000 مللي ثانية من TCP الخاملة > الواردة. | |
metadata.max.age.ms |
~ 180000 | < 240000 | يمكن تخفيضها لالتقاط تغييرات بيانات التعريف في وقت أقرب. |
تكوينات المنتج فقط
| الخاصية | القيم المستحسنة | النطاق المسموح به | ملاحظات |
|---|---|---|---|
retries |
> 0 | الافتراضي هو 2147483647. | |
request.timeout.ms |
30000 60000 | > 20000 | يتم تعيين Event Hubs افتراضيا داخليا إلى 20000 مللي ثانية كحد أدنى.
librdkafka القيمة الافتراضية هي 5000، والتي يمكن أن تكون مسببة للمشاكل.
بينما يتم قبول الطلبات ذات قيم المهلة المنخفضة، لا يتم ضمان سلوك العميل. |
partitioner |
consistent_random |
راجع وثائق librdkafka |
consistent_random هو الافتراضي والأفضل. يتم التعامل مع مفاتيح فارغة وخالية بشكل مثالي لمعظم الحالات. |
compression.codec |
none, gzip |
ضغط gzip فقط مدعوم حاليا. |
تكوينات المستهلك فقط
| الخاصية | القيم المستحسنة | النطاق المسموح به | ملاحظات |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 هي القيمة الافتراضية ولا يجب تغييرها. | |
session.timeout.ms |
30000 | 6000 300000 | تبدأ مع 30000، يمكن زيادتها عند حدوث إعادة التوازن المتكرر بسبب رسائل كشف أخطاء الاتصال المفقودة. |
max.poll.interval.ms |
300000 (افتراضي) | >session.timeout.ms | تستخدم لإعادة توازن المهلة، لذلك لا ينبغي تعيينها منخفضة جدا. يجب أن يكون أكبر من session.timeout.ms. |
ملاحظات أخرى
تحقق من الجدول التالي لسيناريوهات الأخطاء المرتبطة بالتكوين الشائعة.
| العلامات | المشكلة | حل |
|---|---|---|
| تتسبب الإزاحة في الفشل بسبب إعادة التوازن | ينتظر المستهلك وقتاً طويلاً بين المكالمات للاستقصاء () والخدمة تُخرج المستهلك من المجموعة. | لديك العديد من الخيارات:
|
| استثناءات الشبكة عند معدل نقل عالي الإنتاجية | إذا كنت تستخدم عميل Java + max.request.size الافتراضي، فقد تكون طلباتك كبيرة جدا. | راجع تكوينات Java المذكورة سابقا. |
الخطوات التالية
راجع حدود وحصص وقيود الخدمة والاشتراك في Azure للاطلاع على الحصص والحدود الخاصة بجميع خدمات Azure.