تحسين معالجة Spring Batch الموزعة دون وسيط رسائل
تتطلب معالجة Spring Batch الموزعة عادةً مستودع مهام مشتركًا ودائمًا. يقترح هذا المقال استخدام قاعدة البيانات هذه كمستوى التنسيق بالكامل، مما يلغي وسيط الرسائل. ويركز على تحديد حجم العمل ديناميكيًا وفقًا لعدد العقد النشطة، واستخدام عقدة رئيسية لكل مهمة دون منسق دائم، وتنفيذ طريقة المطالبة بالمقارنة والتبديل (compare-and-set) لمنع التنفيذ المزدوج. بالإضافة إلى ذلك، يوضح آلية تجاوز الفشل عبر نبضات القلب على مرحلتين ويناقش السيناريوهات التي قد يظل فيها الوسيط مفيدًا.
كان Spring Batch إطارًا رائدًا لمعالجة الدفعات على JVM لأكثر من عقد. فهو يسمح ببناء المهام من خطوات، بما في ذلك القارئات والمعالجات والكاتبات الموجهة للقطع (chunk-oriented)، وكلها تُدار بواسطة مستودع بيانات وصفية يتيح إمكانية إعادة التشغيل. هذا الإعداد فعال بشكل خاص لمهام مثل الاستخراج والتحويل والتحميل (ETL) الليلية، والتسوية المالية، والتحقق من البيانات على جهاز واحد.
ومع ذلك، مع نمو أحمال العمل، قد لا يعود جهاز واحد كافيًا. عندما تتجاوز مهمة التسوية نافذة المعالجة الخاصة بها، يكون الرد النموذجي هو توزيع عبء العمل عبر عقد متعددة. تقليديًا، يعالج Spring Batch هذا من خلال التقسيم عن بُعد، حيث تقسم خطوة مدير العمل إلى أقسام وترسلها إلى عقد العاملين عبر وسيط رسائل مثل Apache Kafka أو RabbitMQ.
بينما يعد التقسيم عن بُعد طريقة مجربة، فإنه يقدم طبقة تشغيلية إضافية يفضل العديد من الفرق تجنبها. تدير معظم الفرق بالفعل قاعدة بيانات علائقية، وهي مطلوبة من قبل Spring Batch لمستودع مهامها. وبالتالي، غالبًا ما تكون هناك رغبة قليلة في إنشاء وتأمين وصيانة مجموعة مراسلة فقط لتوزيع أقسام الدفعات.
يقدم هذا المقال نهجًا بديلًا لتنسيق مهمة Spring Batch موزعة وقادرة على تحمل الأخطاء عبر مجموعة صغيرة إلى متوسطة باستخدام قاعدة البيانات المشتركة فقط. وهو لا يجادل ضد استخدام الوسطاء، بل يوضح كيفية إزالتهم من هذه العملية، مع تحديد قيود هذا النهج والسيناريوهات التي يظل فيها الوسطاء الخيار المفضل.
اعتبارات رئيسية لمعالجة الدفعات الموزعة
لإدارة معالجة الدفعات الموزعة بفعالية، يجب معالجة أربعة أسئلة رئيسية:
- كيف يتم تقسيم عبء العمل بين العاملين؟
- من يشرف على تنفيذ المهمة؟
- كيف يطالب عامل بملكية قسم لمنع تلف البيانات؟
- ماذا يحدث إذا فشلت عقدة أثناء التنفيذ؟
عادةً ما يحل وسيط الرسائل هذه المشكلات من خلال ضمان تسليم كل رسالة إلى مستهلك واحد، وفصل الإرسال عن التنفيذ. بدون وسيط، يجب الإجابة على هذه الأسئلة صراحةً باستخدام SQL ضد قاعدة بيانات مصممة للحالة المشتركة الدائمة بدلاً من إرسال الرسائل.
تنفيذ التنسيق القائم على قاعدة البيانات
يستخدم هذا النهج قاعدة البيانات العلائقية المطلوبة من قبل Spring Batch كآلية التنسيق الوحيدة، مما يلغي الحاجة إلى وسيط أو خدمات تنسيق إضافية مثل Apache ZooKeeper. تُخزن جميع معلومات حالة المجموعة في جداول SQL قياسية، مما يجعل المجموعة بأكملها قابلة للفحص من خلال استعلامات SQL بسيطة.
تكمل ثلاثة جداول إضافية مخطط Spring Batch الحالي: جدول `BATCH_NODES`، الذي يسجل العقد مع حالتها وحملها؛ وجدول `BATCH_PARTITIONS`، الذي يتتبع دورة حياة كل قسم؛ وجدول `BATCH_JOB_COORDINATION`، الذي يربط تنفيذات المهام بعقدها الرئيسية المعنية.
بينما يظل مستودع المهام المشترك والدائم ضروريًا، فإن هذا الشرط متأصل في التقسيم الموزع وليس قيدًا على الطريقة المقترحة. يُكتب سياق التنفيذ لكل قسم بواسطة العقدة الرئيسية ويُقرأ بواسطة عقدة العامل التي تنفذه، مما يضمن عدم فقدان أي قسم.
يكون التنسيق لامركزيًا بحكم التصميم، مع عدم وجود عقدة رئيسية دائمة. بدلاً من ذلك، تتحمل العقدة التي تبدأ المهمة دور الرئيسية لتنفيذ تلك المهمة فقط. يقلل هذا التصميم من خطر نقطة فشل واحدة، حيث يؤثر فقدان الرئيسية فقط على تنفيذ تلك المهمة المحددة.
التكامل مع Spring Batch
بالنسبة للمطورين المطلعين على Spring Batch، يتطلب تكامل هذا النهج تغييرات طفيفة في الكود الحالي. يوفر Spring Batch بالفعل واجهة `Partitioner` لتقسيم العمل وواجهة `PartitionHandler` لتنفيذ الأقسام. من خلال تنفيذ `PartitionHandler` مخصص يتفاعل مع قاعدة البيانات، يمكن للمطورين الحفاظ على نموذج البرمجة الحالي.
عند إطلاق مهمة، تسجل العقدة الرئيسية تنفيذ المهمة في جدول `BATCH_JOB_COORDINATION` وتنشئ صفوفًا معلقة لكل قسم في جدول `BATCH_PARTITIONS`. ثم تراقب الرئيسية التنفيذ وتعيد تعيين أي أقسام يتيمة إذا فشلت عقدة.
يتيح هذا التصميم تنفيذًا مباشرًا لمعالجة الدفعات الموزعة دون تعقيد وسيط الرسائل، مما يجعله مناسبًا للسيناريوهات التي تكون فيها بساطة التشغيل والتكلفة أمرًا بالغ الأهمية.
المصدر: InfoQ