أفضل الممارسات لتوسيع أعباء العمل القائمة على كافكا

أباتشي كافكا معروف بقدرته على معالجة كمية هائلة من الأحداث في الوقت الحقيقي. ومع ذلك، للتعامل مع ملايين الأحداث، نحتاج إلى اتباع بعض الممارسات المثلى أثناء تنفيذ خدمات منتج كافكا وخدمات المستهلك.

قبل البدءفي استخدام كافكافي مشاريعك، دعنا نفهم متى يجب استخدام كافكا:

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

الاختلافات الرئيسية عن أنظمة الانتظار الأخرى 

أدناه توضح الفروقات بين أباتشي كافكا وأنظمة مثل أكتيف إم كيو، زيرو إم كيو، وفيرن إم كيو:

تخزين دائم

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

التقسيم

تقسم البيانات عبر السماسر/المواضيع، مما يمكن من معالجة متوازية لتيارات البيانات الكبيرة وزيادة معدل الإنتاجية. يساعد هذا الأمر خيوط الاستهلاك على الاتصال بالتقسيم الفردي، مع تعزيز التوسع الأفقي.

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

يمكن للعديد من المستهلكين الاشتراك في نفس الموضوع وقراءة من مواقع بداية مختلفة ضمن تقسيم واحد، مما يسمح بأنماط استهلاك مكررة لفرق مختلفة لاستهلاك ومعالجة نفس البيانات لأغراض مختلفة. بعض الأمثلة هي:

• نشاط المستخدم الذي يستهلكه فرق تعلم الآلة لاكتشاف الأنشطة المشبوهة
• فريق التوصيات لبناء التوصيات
• فريق الإعلانات لإنشاء إعلانات ذات صلة

ممارسات منتج كافكا المثلى

حجم الدفعة ووقت الانتظار

من خلال تكوين batch.size و linger.ms، يمكنك زيادة كفاءة منتج كافكا. batch.size هو الحد الأقصى لحجم الدفعة بالبايت. سيحاول كافكا تجميعها قبل إرسالها إلى المنتجين. 

Linger.ms يحدد الوقت الأقصى بالمللي ثانية الذي سينتظره المنتج لإضافة رسائل إضافية إلى الدفعة لمعالجتها. 

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

الضغط

طريقة أخرى لزيادة الناتج هي تمكين ضغط البيانات من خلال تكوين compression.type. يمكن للمُنتج ضغط البيانات باستخدام gzip, snappy, أو lz4 قبل إرسالها إلى الوسطاء. بالنسبة لحجم البيانات الكبير، يساعد هذا التكوين في تقليل التكلفة الزائدة للضغط مع كفاءة الشبكة. كما يوفر عرض النطاق الترددي ويزيد من الناتج للنظام. بالإضافة إلى ذلك، من خلال ضبط مُسلسل البيانات ومفتاح المُسلسل بشكل مناسب، يمكننا التأكد من تسلسل البيانات بتنسيق متوافق مع مستهلكيك.

إعادة المحاولات والموثوقية

لضمان موثوقية منتج Kafka، يجب تمكين إعادة المحاولات والموثوقية. من خلال تكوين retries, يمكن للمُنتج إعادة إرسال أي دُفعة من البيانات التي لم تحصل على ack من الوسيط في عدد محدد من المحاولات.

التأكيدات

يتحكم هذا التكوين في مستوى التأكيد المطلوب من الوسيط قبل اعتبار الرسالة تم إرسالها بنجاح. من خلال اختيار مستوى acks المناسب، يمكنك التحكم في موثوقية تطبيقك. فيما يلي القيم المقبولة لهذا التكوين.

• 0– الأسرع، لكن دون ضمان تسليم الرسالة.
• 1 – تأكيد الرسالة بمجرد كتابتها على وسيط الرئيس، مما يوفر الموثوقية الأساسية.
• all – تعتبر الرسالة تم تسليمها فقط عندما يؤكد جميع النسخ عليها، مما يضمن المتانة العالية.

ضبط التكوين استنادًا إلى العبء العملي

يجب عليك البدء في تتبع المقاييس مثل معدل إرسال الرسائل، حجم الدفعة، ومعدلات الأخطاء لتحديد نقاط الضعف في الأداء. تحقق بانتظام وقم بضبط إعدادات المنتج بناءً على التعديلات أو التحديثات في الميزات / البيانات.

أفضل الممارسات لمستهلكي Kafka

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

يجب أن ينتمي كل مستهلك Kafka إلى مجموعة مستهلكين؛ يمكن أن تحتوي مجموعة مستهلكين على مستهلك واحد أو أكثر. من خلال إنشاء مزيد من المستهلكين في المجموعة، يمكنك زيادة القدرة على قراءة من جميع الأقسام، مما يتيح لك معالجة حجم كبير من البيانات. تساعد إعدادات group.id  في تحديد مجموعة المستهلك التي ينتمي إليها المستهلك، مما يسمح بتوازن الحمل عبر عدة مستهلكين يستهلكون من نفس الموضوع. الممارسة الجيدة هي استخدام معرفات المجموعات ذات المعنى لتحديد مجموعات المستهلكين بسهولة داخل تطبيقك. 

التعهد بالإزاحة

يمكنك التحكم في وقت التزام تطبيقك بالإزاحات، مما يمكن أن يساعد في تجنب فقدان البيانات. هناك طريقتان للتزام الإزاحات: تلقائيًا ويدويًا. بالنسبة لتطبيقات عالية الإنتاجية، يجب عليك النظر في التزام يدوي للتحكم الأفضل.

• تعيين تلقائي للإزاحةإعادة تعيين – يحدد ما يجب فعله عندما يبدأ المستهلك في استهلاك موضوع بدون إزاحات مؤكدة (على سبيل المثال، موضوع جديد أو مستهلك ينضم إلى مجموعة للمرة الأولى). الخيارات تشمل earliest (قراءة من البداية)، latest (قراءة من النهاية)، أو none (رمي خطأ). اختر “earliest” في معظم الحالات لتجنب فقدان البيانات عندما ينضم مستهلك جديد إلى مجموعة. يتحكم في كيفية بدء المستهلك في استهلاك البيانات، مضمناً سلوكًا صحيحًا عند إعادة تشغيل المستهلك أو إضافته إلى مجموعة.
• تمكين التأكيد التلقائي – يساعد في تكوين لتأكيد الإزاحات تلقائيا بانتظام. عادة ما نقوم بتعيين القيمة على false في معظم السيناريوهات الإنتاجية حيث لا نحتاج إلى موثوقية عالية ونقوم بتأكيد الإزاحات يدويًا داخل منطق التطبيق الخاص بك لضمان معالجة مرة واحدة بالضبط. يوفر التحكم لإدارة تأكيد الإزاحات، مما يسمح بالمزيد من التحكم في معالجة البيانات.
• auto.commit.interval.ms – فترة زمنية بالمللي ثانية يتم فيها الالتزام بالتحويلات تلقائيًا إذا كانت enable.auto.commit مُعينة على true. قم بتعديلها استنادًا إلى وقت معالجة تطبيقك لتجنب فقدان البيانات بسبب الفشل غير المتوقع.

حجم الاسترجاع وأقصى عدد سجلات للتصويت

تساعد هذه الإعدادات في التحكم بعدد السجلات المسترجعة في كل طلب، قم بتكوين fetch.min.bytes و max.poll.records. زيادة هذه القيمة يمكن أن يساعد في تحسين إنتاجية تطبيقاتك مع تقليل استخدام وحدة المعالجة المركزية وتقليل عدد المكالمات التي يتم إجراؤها إلى الوسطاء.

• fetch.min.bytes – الحد الأدنى لعدد البايتات التي يجب استرجاعها من الوسيط في طلب تصويت واحد. قم بتعيين قيمة صغيرة لتجنب المكالمات الشبكية غير الضرورية، ولكن ليست صغيرة جدًا لتجنب التصويت المفرط. يساعد ذلك في تحسين كفاءة الشبكة من خلال منع الطلبات الصغيرة والمتكررة.
• fetch.max.bytes – الحد الأقصى عدد البايتات التي يمكن سحبها من وسيط في طلب استقصاء واحد. قم بضبطه بناءً على الذاكرة المتاحة لتجنب تحميل عمال المستهلكين بشكل زائد. هذا يقلل كمية البيانات المسترجعة في استقصاء واحد، مما يتجنب مشاكل الذاكرة.
• max.poll.interval.ms – الحد الأقصى للوقت الذي ينتظر فيه طلب الاستقصاء لإرجاع البيانات قبل أن ينتهي الوقت.  حدد مهلة جيدة لتجنب توقف/تأخر المستهلكين إذا لم تكن البيانات متاحة. يساعد ذلك في منع المستهلكين من التوقف انتظارًا للرسائل لفترة طويلة جدًا. (في بعض الأحيان، قد يتم إعادة تشغيل حاويات k8s إذا تأثرت اختبارات الحية).

تعيين الأقسام

هذه هي الاستراتيجية المستخدمة لتعيين الأقسام (partition.assignment.strategy) للمستهلكين داخل مجموعة (مثل range، roundrobin). استخدم range لمعظم السيناريوهات لتوزيع الأقسام بشكل متساوٍ عبر المستهلكين. هذا يمكن أن يتيح توزيع حمل متوازن بين المستهلكين في مجموعة.

إليك بعض الاعتبارات المهمة قبل استخدام كافكا:

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

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