بناء تطبيق نشط مدفوع بالأحداث مع طابور رسائل الفشل

تسهل بنية المعمارية المعتمدة على الأحداث الأنظمة في الرد على الأحداث الحقيقية، مثل عندما يتم تحديث ملف تعريف المستخدم. يوضح هذا المنشور كيفية بناء تطبيقات تفاعلية تعتمد على الأحداث تتعامل مع فقدان البيانات من خلال دمج Spring WebFlux وApache Kafka وDead Letter Queue. عند استخدامها معًا، توفر هذه الأدوات إطار عمل لإنشاء أنظمة مقاومة للأخطاء، مرنة، وعالية الأداء، وهو أمر مهم للتطبيقات الكبيرة التي تحتاج إلى التعامل مع كميات ضخمة من البيانات بكفاءة.

الميزات المستخدمة في هذا المقال

• Spring Webflux: يوفر نموذجًا تفاعليًا يعتمد على ضغط خلفي غير متقطع لمعالجة الأحداث بشكل متزامن.
• Apache Kafka: تساعد منتجي ومستهلكي Kafka التفاعليين في بناء خطوط معالجة كفؤة وقابلة للتكيف.
• تدفقات تفاعلية: لا تعيق تنفيذ تدفقات منتجي ومستهلكي Kafka.
• طابور الرسائل الميتة (DLQ): يقوم DLQ بتخزين الرسائل مؤقتًا التي لم يمكن معالجتها لأسباب مختلفة. يمكن استخدام رسائل DLQ لاحقًا لإعادة معالجة الرسائل لمنع فقدان البيانات وجعل معالجة الأحداث مرنة.

منتج Kafka التفاعلي

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

يمكن العثور على منتج كافكا التفاعلي الموضح أعلاه على GitHub.

مستهلك كافكا التفاعلي

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

يمكن العثور على مستهلك كافكا التفاعلي الموضح أعلاه على GitHub.

طابور الرسائل الميتة (DLQ)

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

فوائد دمج قائمة الرسائل الميتة

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

يمكن دفع الرسائل الفاشلة إلى DLQ من كود المنتج كما هو موضح أدناه:

يجب إنشاء معالج DLQ في المستهلك التفاعلي كما هو موضح أدناه:

الخاتمة

يساعد دمج DLQ مع منتج ومستهلك تفاعليين في بناء تطبيقات مدفوعة بالأحداث resilient و fault-tolerant و efficient. يضمن المنتجون التفاعليون نشر الرسائل بشكل غير محجوز؛ من ناحية أخرى، يعالج المستهلكون التفاعليون الرسائل مع ضغط عكسي، مما يحسن الاستجابة. يوفر DLQ آلية احتياطية تمنع الانقطاعات وتمنع فقدان البيانات.

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

يمكن العثور على كود المرجع أعلاه في منتج GitHub و مستهلك GitHub.

يمكن العثور على مزيد من التفاصيل حول المنتج والمستهلك التفاعليين في ReactiveEventDriven. تقدم مستندات Spring Apache Kafka مزيدًا من المعلومات بشأن DLQ.