Celery: الميزة: يجب أن يتجنب الإيقاع الدعوات المتزامنة

يمكن حل هذا باستخدام kombu.pidbox ، وهذه أيضًا هي الطريقة التي يكتشف بها celeryd وجود عقدة بالفعل بنفس الاسم قيد التشغيل. نظرًا لأن celerybeat مركزي ، فيمكنه استخدام اسم عقدة ثابتة.

كأثر جانبي ، سنكون قادرين على التحكم في الكرفس بأوامر التحكم عن بعد (قد يكون هناك أمر لإعادة تحميل الجدول على سبيل المثال ، أو معرفة المهام المستحقة في المستقبل القريب). هذا تأثير جانبي رائع جدًا إذا سألتني.

يحتاج إلى مزيد من التخطيط ، حيث توجد حالة استخدام لتشغيل مثيلات متعددة في نفس المجموعة. على سبيل المثال ، من أجل "تجزئة" الجدول إلى أجزاء متعددة. يجب أن يكون هناك على الأقل إمكانية تحديد اسم عقدة لكل مثيل. التأجيل إلى 2.3.0.

كانت لدينا مشكلة حيث أصبح المربع الذي يشغل celerybeat غير متصل دون الحاجة إلى احتياطي جيد لبدء مثيل celerybeat ليحل محله. ما هي طريقة HA ​​الموصى بها لتشغيل celerybeat ؟

هل سيسمح لنا نهج kombu.pidbox بتشغيل مثيلات متعددة من celerybeat والتي قد تنام فقط إذا اكتشف أن مثيلًا يعمل بالفعل باستخدام اسم العقدة الثابتة والاستقصاء لترقية نفسه إلى الحالة النشطة إذا كان ذلك المثال ينخفض؟

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

+1

+1

هذا شيء يمثل مصدر قلق حقيقي لعمليات النشر الكبيرة حيث أن مرونة الجدولة مهمة.

+9999 ؛)
هل هناك خطأ في استخدام حل kombu.pidbox ؟ حتى بدون تجزئة الميزات الرائعة ، سيكون هذا رائعًا ومفيدًا جدًا. في الوقت الحالي ، أحتاج إلى بدء تشغيل الكرفس يدويًا على مضيف آخر.

يمكن استخدام Pidbox ، لكن المشكلة هي أن الإيقاع ليس مستهلكًا. للرد على رسائل البث مثل "أي حالات إيقاع هنا؟" سيتعين عليه الاستماع باستمرار للرسائل الموجودة في قائمة انتظار البث الخاصة به ، ولا يمكنه حاليًا ذلك لأنه مشغول بجدولة الرسائل.

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

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

يمكن أن يكون لها أيضًا مهلة 2 ثانية على القفل ، وتحديث القفل كل ثانية. ثم هذا يعني أنه سيتعين على مثيل جديد الانتظار لمدة ثانيتين إذا تم تعليق القفل.

يمكن إنشاء قفل في amqp عن طريق التصريح عن قائمة انتظار ، على سبيل المثال `` queue_declare ('celerybeat.lock'، arguments = {'x-expires': 2000} "

+1

أنا أحب أن أرى هذا

+1

+1

+1 كذلك

+1

هل قام أي شخص بالفعل بتطبيق الحل kombu.pidbox أو أي آلية أخرى تحل هذه المشكلة؟ لو كان كذلك انشره من فضلك. لا يزال هناك الكثير من الناس يتساءلون عن أفضل الممارسات.

هل ابتعد أحد عن الكرفس تمامًا بسبب هذا؟ سأكون مهتمًا بمعرفة ذلك أيضًا.

تعديل:

لقد وجدت هذا الجوهر (https://gist.github.com/winhamwr/2719812) من خلال مناقشة google (https://www.google.co.in/search؟q=celerybeat+lock&aq=f&oq=celerybeat+lock&aqs= chrome.0.57j62l3.2125j0 & sourceid = chrome & ie = UTF-8).

أتساءل أيضًا عما إذا كان أي شخص قد استخدم للتو ملف pidfile مشترك لكرفس مباشرة ، ربما مع EBS على AWS أو ربما في دلو S3… celerybeat --pidfile=/path/to/shared/volume .

لقد لاحظت أن المعلم الحالي (3.1 dev) لديه خطوة ثرثرة للمستهلك. سيكون من الممكن الاستفادة من طابور القيل والقال وانتخاب زعيم لتنسيق العمليات ضربات جزءا لا يتجزأ؟ وهذا هو أن كل عامل تشغيل عملية ضربات جزءا لا يتجزأ لكن الزعيم فقط أن يصطف مهمة الدورية. من المحتمل أن يفترض هذا تخزين الجدول الزمني المشترك.

mlavin يمكن أن يعمل هذا ، ولكن فقط لوسائل النقل الوسيطة التي تدعم البث

تكمن مشكلة حل pidbox في أنه يجب إعادة كتابة برنامج celerybeat لاستخدام Async I / O.
لا يمكنه حاليًا استهلاك المهام وإنتاجها ، نظرًا لأن المجدول يحظره.

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

لقد اكتشفت أن الأشخاص المتأثرين بهذه المشكلة غالبًا هم أولئك الذين يستخدمون الخيار -B في عملية التخفي
البرنامج النصي ثم يكرر هذا الإعداد إلى مضيف آخر.

لذا فهمت أنه أمر مزعج ، لكنني لا أعتقد أنه أمر بالغ الأهمية. إذا كان أي شخص يريد حلاً حقًا ، فيمكنه المساهمة فيه ، أو تعييني / التبرع لتنفيذه.

يمكن للمرء استخدام uWSGI لإجراء عملية نبضة واحدة مع الرجوع إلى العقدة (العقد) الأخرى

+1 ، أطلقنا مثيلات Amazon EC2 متطابقة وسيكون من الجيد أن يكون لديك مهام دورية يتم تنفيذها في عقدة واحدة فقط. في غضون ذلك سأحاول استخدام uWSGI شكرًا على الاقتراح.

+1

+1

لقد كنت أقوم بعمل قضية لاستخدام Celerybeat للجدولة ولكن عدم وجود HA خارج الصندوق يجعل الأمر صعبًا للغاية. في الواقع ، يبدو أننا سنسقطها تمامًا بسبب هذا. بكل بساطة ، تشغيل مثيل واحد فقط من Celerybeat يجعل هذا نقطة فشل واحدة وبالتالي ليس الإنتاج جاهزًا لنا.

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

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

شكرا @ 23doors.

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

سأحقق في توصية التصنيف الفرعي. قد يكون هذا نهجًا أنظف.

شكرا على الاقتراحات!

في Lulu ، قمنا بحل هذه المشكلة عن طريق كتابة مدير مجموعة مفرد بسيط (يُسمى BeatCop). يستخدم قفل Redis منتهي الصلاحية لضمان وجود واحد فقط من Celerybeat يعمل في مجموعة قياس تلقائي من عمال الكرفس. إذا حدث أي شيء لذلك Celerybeat (مثل تم تصغير المثيل أو تموت أو تعطل Celerybeat) ، فإن عقدة أخرى تولد تلقائيًا Celerybeat جديدًا. لقد فتحنا BeatCop المصدر .

ingmar كتبنا هذا https://github.com/ybrs/single-beat لنفس الأسباب ، في المرة الأخيرة التي تحققت فيها لم أر تعليقك. لقد أصدرنا أيضًا نظرًا لأن المصدر المفتوح قد يكون مفيدًا للبعض الآخر. أكثر أو أقل يفعل نفس الشيء.

بقدر ما أستطيع أن أرى ، الاختلافات الرئيسية مع beatcop - ، نحن نستخدم pyuv - لذا فإن beatcop أكثر قابلية للنقل وأعتقد أن التبعيات أقل - ، أعد توجيه الطفل stderr و stdout كآباء ، واخرج إذا مات الطفل بنفس الكود ، قم بتكوينه باستخدام المتغيرات. لذلك من الأسهل قليلاً إضافته إلى المشرف.

آمل أن يكون مفيدًا لشخص آخر.

+1

+1

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

ingmar شكرا على هذا! سأقوم بإعطاء هذه اللقطة على مجموعة العمال الخاصة بي.

+10 نظرًا لأن التطبيق الحالي يعني وجود نقطة فشل واحدة تبتعد عن سبب استخدامنا لقائمة انتظار موزعة في المقام الأول

+1

+1

يبدو أن هذا سيكون في الإصدار 5.0.0 https://github.com/celery/celery/milestones/v5.0.0

+1

إغلاق هذا ، كما هو الحال مع الموارد الحالية ، سيستغرق الأمر 10 سنوات حتى يكتمل.

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

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

ظلت المشكلة مفتوحة منذ ستة أعوام حتى الآن ، وعلى الرغم من أنها تُطلب كثيرًا ، وتعتمد عليها شركات لا حصر لها ، لم يعرض أي منها على الإطلاق دفع ثمن تطبيقه.

لقد كانت في الواقع واحدة من القضايا التي اعتقدت أنها ستكون مثيرة للاهتمام للشركات لرعايتها. من المؤكد أنه ليس من الشائع أن تعرض الشركات الدفع مقابل أي ميزة أو إصلاح خطأ أو حتى للمساعدة في حل مشكلة إنتاج. ربما يمكنني الاعتماد عليهم من جهة (أنت رائع) ، لذلك أعرف الآن مدى سذاجة هذه الفكرة تمامًا :)

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

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

شكرًا لك على الوقت الذي قضيته في شرح أسبابك بالتفصيل.

ask كنت أتساءل عما إذا كان من الممكن التحايل على هذه المشكلة عن طريق تحديد موقع ملف celerybeat-schedule (المستخدم بواسطة celery.beat.PersistentScheduler ) داخل وحدة تخزين NFS تتم مشاركتها عبر جميع العقد في الكتلة؟

تستخدم فئة PersistentScheduler shelve كوحدة نمطية لقاعدة البيانات ، لذا يجب منع عمليات الكتابة المتزامنة إلى الملف celerybeat-schedule حسب التصميم. هذا مقتطف من وثائق shelve :

لا تدعم وحدة الأرفف الوصول المتزامن للقراءة / الكتابة للكائنات الموجودة على الرف. (تعتبر عمليات الوصول المتعددة للقراءة المتزامنة آمنة.) عندما يكون لدى البرنامج رف مفتوح للكتابة ، فلا ينبغي أن يفتحه أي برنامج آخر للقراءة أو الكتابة.

بافتراض أننا نبدأ ضربات الكرفس مثل هذا:

celery -A project-name beat -l info -s /nfs_shared_volume/celerybeat-schedule

حيث /nfs_shared_volume هو الحجم المشترك (على سبيل المثال ، يُدار بواسطة AWS Elastic File System) ، هل يمكننا توقع عدم إفساد الجداول الزمنية حتى إذا كانت هناك عملية إيقاع كرفس واحدة تعمل على كل عقدة في المجموعة؟

mikeschaekermann إذا كنت أقرأ المستندات بشكل صحيح ، فإن shelve لا يبذل أي جهد لمنع الوصول المتزامن للكتابة. يخبرك فقط ألا تدع ذلك يحدث. يمضي القسم الذي نقلته ليقول "يمكن استخدام قفل ملفات Unix لحل هذه المشكلة ، لكن هذا يختلف عبر إصدارات Unix ويتطلب معرفة حول تنفيذ قاعدة البيانات المستخدمة."

@ ze-phyr-us أعتقد أنك على حق ، وقد أساءت تفسير مستندات shelve . ومع ذلك ، أتساءل عما إذا كان سيتم حل المشكلة على افتراض أن الواجهة الخلفية Scheduler تضمن العمليات الذرية في الجدول الزمني؟ ask هل تدعم الحزمة django-celery-beat الذرية لحل المشكلة؟ رأيت أنه يستخدم المعاملات للقيام ببعض التحديثات.

لأي شخص آخر ينتهي به الأمر هنا أثناء البحث عن إيقاع ودي من الكرفس موزع / قابل للتحجيم التلقائي ، ويسعده استخدام Redis كخلفية ؛ لقد جربت كلاً من BeatCop والنغمة الفردية المذكورة أعلاه ، لكنني اخترت RedBeat في النهاية.

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

يضمن @ ankur11 النغمة الفردية تشغيل مثيل واحد فقط من ضربات الكرفس ، لكنه لا يزامن حالة الجدول الزمني بين الحالات.

إذا استخدمت برنامج الجدولة الافتراضي مع مهمة دورية تهدف إلى التشغيل كل 15 دقيقة ، وتجاوزت الفشل بضربة واحدة بعد 14 دقيقة من آخر مرة نفذت فيها المهمة ، فلن تعمل المهمة إلا بعد 15 دقيقة من دق الكرفس الجديد بدأ المثيل ، مما أدى إلى فجوة مدتها 29 دقيقة.

لمشاركة حالة الجدول الزمني بين الحالات ، كنت بحاجة إلى استخدام برنامج جدولة بديل . django-celery-beat هو البديل المذكور في مستندات الكرفس ، ولكن كنت أفضّل استخدام Redis كخلفية لمزامنة الجدول الزمني ، نظرًا لأنني كنت أستخدم Redis بالفعل كخلفية للكرفس.

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

في تطبيقنا ، يتم بدء ضربات الكرفس من قبل المشرف في جميع الحالات ، مع Redbeat كمجدول (على سبيل المثال exec celery beat --scheduler=redbeat.RedBeatScheduler --app=myproject.celery:app ). للأسف لا يمكنني مشاركة التعليمات البرمجية المتعلقة بالعمل ، ولكن يسعدني الرد على أي أسئلة إضافية حول التنفيذ بشكل عام.

mikeschaekermann ، يمكنك محاولة لف إيقاع الكرفس باستخدام / use / bin / flock لقفل الوصول ...

flock /nfs/lock.file celery beat ...

بافتراض أنك تثق في تنفيذ قفل NFS الخاص بك :)

هذا من شأنه أن يضمن تشغيل واحد فقط فعليًا والكتلة الأخرى حتى تموت الخزانة.

mikeschaekermann ، يمكنك محاولة لف إيقاع الكرفس باستخدام / use / bin / flock لقفل الوصول ...

قطيع / nfs/lock.file خفق الكرفس ...

بافتراض أنك تثق في تنفيذ قفل NFS الخاص بك :)

هذا من شأنه أن يضمن تشغيل واحد فقط فعليًا والكتلة الأخرى حتى تموت الخزانة.

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

انتهى بي الأمر باستخدام قفل استشاري في Postgres. لقد قمت بعمل أمر إدارة Django يستخدم وحدة django_pglocks ويقوم بتشغيل ضربات الكرفس في عملية فرعية.

انتهى بي الأمر باستخدام قفل استشاري في Postgres. لقد قمت بعمل أمر إدارة Django يستخدم وحدة django_pglocks ويقوم بتشغيل ضربات الكرفس في عملية فرعية.

يبدو أن هذا قد يكون عرضة لنفس المشكلات التي رأيتها باستخدام NFS. ماذا يحدث إذا فقد العميل الذي يحمل القفل الاتصال بخادم Postgres ، أو إذا تمت إعادة تشغيل خادم Postgres؟

@ swt2c Argh ، بالطبع أنت على حق! يجب أن يكون هناك نوع من البقاء على قيد الحياة.

أفعل الآن:

def _pre_exec():
    prctl.set_pdeathsig(signal.SIGTERM)

with advisory_lock(LOCK_ID) as acquired:
            assert acquired
            logging.info("Lock acquired: %s", acquired)
            p = subprocess.Popen(
                celery,
                shell=False,
                close_fds=True,
                preexec_fn=_pre_exec,
            )
            sys.exit(p.wait())

يدعم advisor_lock العودية ، لكنني لا أعرف ما إذا كان يتحقق بالفعل من db:

In [8]:  with advisory_lock('foo') as acquired:
   ...:     print acquired
   ...:     while True:
   ...:        with advisory_lock('foo') as acquired:
   ...:           print acquired
   ...:        time.sleep(1)
   ...:       

# Yes, it does:

True
True
True
<shutdown the instsance>
InterfaceError: cursor already closed

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

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

لقد تغلبت أيضًا على الجدول الزمني في DB ، لكنني لم أختبر ما يفعله الضرب عندما ينخفض ​​db.

ddevlin كنت سعيدًا برؤية تعليقك لأن هذا هو الحل الذي كنت أفكر في تنفيذه أيضًا.

ومع ذلك ، إذا كان بإمكانك مشاركة منطق كيفية بدء المشرف التلقائي redbeat-1 عندما ينخفض redbeat-2 ، فستكون هذه مساعدة رائعة.

قد يكون هذا بسبب عدم فهمي بشأن supervisor ، لكن يبدو أن autorestart=True فعال فقط للبرامج التي تدخل على الأقل في حالة RUNNING مرة واحدة.

مشكلتي هي:

1. لديّ program في صندوق المشرف الخاص بي celery beat redbeat.RedBeatScheduler .
2. المشرف ابتداء، واحدة beat ( beat-1 ) يحصل على القفل ويعمل، في حين أن الآخر ( beat-2 ) يحاول بدء بضع مرات، ويدخل في FATAL state (مع ظهور الخطأ Seems we're already running? ).
3. من الناحية المثالية ، إذا توقف beat-1 ، فأنا أريد أن يبدأ المشرف beat-2 .
4. ومع ذلك ، هذا لا يحدث لأنه لم يكن في حالة RUNNING لتبدأ بها. مما يعني أنه إذا أوقفت beat-1 ، فعندئذ يتوقف ولن يحدث شيء.

بعيدًا عن رأسي ، سيكون الحل هو الحصول على cron الذي يستمر في عمل supervisorctl restart all كل 5 ثوانٍ أو نحو ذلك ، ولكن أردت فقط الحصول على أفكارك حول كيف تمكنت من تحقيق هذا التكرار مع المشرف.

مرحبًا harisibrahimkv ، مشكلتك هي أنك تبدأ حالتين متطابقتين من ضرب الكرفس على نفس المضيف ؛ أتوقع أنك ترى ERROR: Pidfile (celerybeat.pid) already exists. في سجلاتك مقابل beat-2 ؟ أستطيع أن أرى أن وجود حالتين من ضربات الكرفس تعمل على نفس المضيف سيكون مفيدًا لاختبار تجاوز الفشل بينهما ، ولكن من أجل التكرار الحقيقي ، ربما تريد تشغيل ضربات الكرفس على مضيفين متعددين.

لتشغيل مثيلات متعددة على نفس المضيف ، اطلب من المشرف بدء تشغيلها باستخدام الوسيطة --pidfile ومنحهم ملفات pidfiles منفصلة: على سبيل المثال

# beat-1 
celery beat --scheduler=redbeat.RedBeatScheduler --pidfile="beat-1.pid" ...
# beat-2
celery beat --scheduler=redbeat.RedBeatScheduler --pidfile="beat-2.pid" ...

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

كان هدفنا هو الحصول على مجموعة متدرجة تلقائيًا من المضيفين المتطابقين الذين يديرون عمال الكرفس ويضرب الكرفس تحت إشراف المشرف. كل مضيف لديه مثيل واحد من ضربات الكرفس. في هذا التكوين ، يجب أن تبدأ ضربات الكرفس بنجاح على جميع المضيفين ، ولكن أي حالات لضرب الكرفس لا تحصل على القفل ستكون فعالة في وضع الاستعداد ولن تقوم بجدولة المهام (على الرغم من أن جميع المضيفين في البركة سيعالجون المهام). إذا تم إيقاف المثيل الذي يحتوي على القفل (على سبيل المثال عندما يتم تصغير حجم التجمع ، أو عندما نقوم بترقية متجددة للمضيفين في التجمع) ، فستحصل إحدى مثيلات الاستعداد على القفل وتتولى مهام الجدولة.

ddevlin شكرًا جزيلاً لك على العودة إليّ وجعل الإنترنت مكانًا رائعًا! نقدر بصدق ذلك! (كان يركض ليخبر عائلتي بأكملها عن ردك: د)

1. نجح pidfile bit وكنت سعيدًا جدًا برؤية beat-2 يتولى المهام عندما يتوقف الآخر. يمكن تكوين وقت الإيقاع بـ CELERYBEAT_MAX_LOOP_INTERVAL = 25 (على الكرفس 3.x).

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

شكرا جزيلا ،
من قرية صغيرة في أقصى جنوب شبه القارة الهندية. :)