Celery: اقتراح لإيقاف Redis كوسيط دعم. [مرفوض]

توجد في الوقت الحاضر بدائل للكرفس ، على سبيل المثال huey و rq والتي تركز صراحة على دعم redis كوسيط. عندما أطلق الكرفس ، لم يكن هناك شيء.

ask ما رأيك في إسقاط دعم وسيط SQL أيضًا؟ أشك في أن هناك العديد من الأشخاص الذين يستخدمون قاعدة بيانات SQL في الإنتاج. حتى لو فعلوا ذلك ، فلا ينبغي عليهم فعل ذلك.
لدينا أيضًا عامل إرساء مما يعني أن نشر rabbitmq هو حرفياً أمر واحد بعيدًا. لم يعد الأمر صعبًا بعد الآن.

لقد أسقطت للتو دعم SQL كوسيط ، بما في ذلك جميع الوسطاء الآخرين بخلاف RabbitMQ / Redis / SQS / Qpid :)

(مكرر)

أنا لست مرتبطًا بمجتمع الكرفس ؛ بغض النظر عن 0.02 دولار:

• Redis مشهور حقًا - يتمتع بشعبية مثل جميع الوسطاء المدعومين الآخرين _combined_ ، إذا كنت تعتقد أن Google Trends تمثل
• إنه قادر على أن يكون وسيطًا جيدًا حقًا _و الخلفية (RabbitMQ أيضًا)
• يتم تقديمه بشكل فريد من قبل بائعي السحابة الكبار كخدمة مُدارة بالكامل
• نحن نستخدم Redis كثيرًا!

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

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

MaximilianR أتحدث فقط عن نفسي:

1. هذه قاعدة بيانات كبيرة يمكن السير فيها
2. خاصة إذا لم تكن خبيرًا في kombu و ayncio
3. وليس لديك أي حدس حول عمق المشكلات المبلغ عنها

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

MaximilianR ، كان هناك العديد من المساهمين ، لكنني بالتأكيد قمت بالكثير من العمل. نما المشروع بسرعة كبيرة ، وفي وقت ما كان لدي الاختيار بين إصلاح الأخطاء أو دعم المستخدمين على IRC / email / StackOverflow وما إلى ذلك ، خاصة أشياء مثل مشكلة الجمود في تجمع المعالجات المتعددة التي استغرقت أكثر من 6 أشهر من الترميز المركّز ، عندما كان يجب أن أكون إرشاد الناس. كنا في تلك المرحلة بحجم RabbitMQ تقريبًا في التنزيلات ، ولكن حيث كان لديهم 8 أشخاص يعملون بدوام كامل ، كنت أنا الوحيد.

من المحتمل أن تكون هناك أشياء أخرى يجب بترها ، لكنني لا أعتقد أن أي شيء يستغرق وقتًا طويلاً مثل Redis.

كان عمل نقل amqp / kombu إلى حالة عدم التزام كاملة أيضًا مصدرًا رئيسيًا للوقت ، ولكنه ضروري لحل عدد من المشكلات. لم يكتمل على الرغم من ذلك.

ask هل تعني رسالتك أعلاه أنك ما زلت مهتمًا ببذل الجهد في SQS؟ لقد لاحظت وجود تذكرة SQS واحدة مفتوحة هنا ، لكنني ما زلت أرى التحذير "التجريبي" في المستندات. هل يمكنك تقديم المشورة بشأن الوضع الحالي والاحتياجات المستقبلية لـ SQS؟

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

اسال شكرا لتقاسم ذلك أعلاه. يمكنني أن أقدر من أين أتيت. آمل من خلال هذا النهج / طرق أخرى أن يكون من الأسهل الحفاظ على الكرفس ومواصلة نجاحه ...

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

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

تم إدراجnicksloan SQS الآن كوسيلة نقل مدعومة في المستندات الرئيسية: http://docs.celeryproject.org/en/master/getting-started/brokers/index.html

تمت رعاية العمل لإعادة كتابة نقل SQS إلى استخدام I / O غير المتزامن بمبلغ يزيد قليلاً عن 1000 دولار.

scoates إن نقل

أريد أن أدعم Redis ، أنا أفعل ذلك حقًا. كنت أقاتل من أجل ذلك عندما عملت في RabbitMQ / Pivotal حيث شعرت أننا بحاجة إلى حل مشترك في Python للأنماط التي يطبقها الكرفس. ولكن إذا لم يتم استثمار المجتمع والشركات التي تستخدمه في استمرار عمله ، فسأترك في مكافحة الحرائق وفي أسوأ الأحوال مثل الآن غير قادر على إصلاح المشاكل الخطيرة في النقل التي تؤدي إلى انتقاد الناس للمشروع. هذا يجعل حياتي أكثر بؤسًا ويقلل من معنوياتي.

قد يكون هذا جذريًا جدًا نظرًا لتاريخ الكرفس ، لكن هل فكرت في الاحتفاظ فقط بـ Redis على RabbitMQ؟

MaximilianR لقد فكرت في الأمر ، لكن شغفي هو تمرير الرسائل وبناء أنظمة موزعة صحيحة. لم يزودنا Redis بعد بتنفيذ BRPOPLPUSH الذي يعمل على تنفيذ إقرارات الرسائل ، ومع الكشف عن عدم القدرة على قبول أنه من المستحيل الاعتماد على وقت ساعة الحائط في الأنظمة الموزعة ، حقيقة أساسية ، أنا أكثر حذرًا. يهاجم RabbitMQ مساحة المشكلة بجدية على الأقل ، وهناك لاعبون آخرون مثل كافكا و NSQ. تتعامل الكثير من المكتبات مع قوائم انتظار المهام كعملية قائمة بسيطة ، لكني أرفض أن يصبح الكرفس واحدًا منهم :)

scoates : لم أكن أتحدث عن كيف

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

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

نظرًا لأن بروتوكول Redis بسيط جدًا ، فإن إعادة كتابة النقل ليكون غير متزامن تمامًا لا يجب أن يكون بهذه الصعوبة. لقد صنعت طبقة تمكن الكرفس من دعم أي مكتبة من مكتبات Tornado ، ويمكن صنع نفس الشيء مع Asyncio و Twisted ، لذلك قد يكون لدينا عملاء هناك يمكننا إعادة استخدامها.

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

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

ask كان جعل الشركات تحافظ على
الشيء نفسه بالنسبة لـ MongoDB والخدمات الأخرى.
بالنسبة إلى وسطاء SQL ، أعتقد أنهم ليسوا فكرة جيدة جدًا ولا ينبغي لنا دعمهم.
يمكننا استخراج الكود بدلاً من إزالته والبحث عن شخص ما للحفاظ عليه. إذا لم يكن هناك اهتمام كافٍ ، فلا داعي لهم.
قاعدة بيانات SQL الوحيدة التي يمكن أن تكون وسيطًا هي Postgres نظرًا لاحتوائها على إمكانات Pub / Sub ولكن لم يتم تنفيذها حاليًا على أي حال.

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

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

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

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

مثل dvirsky ، تتم رعاية عملي في سأشارك في المساعدة في العثور على أفضل الحلول في جانب Redis ، وربما حتى تمديد دعم رسائل Redis من أجل تسهيل أشياء معينة في التنفيذ. يمكننا أيضًا التأكيد على قدرة الواجهة الخلفية على استخدام Sentinel / Redis Cluster في مرحلة ما من أجل الحصول على تجربة جاهزة لـ HA. آمل أن نحصل على أخبار جيدة في أسرع وقت ممكن ، حيث نقوم حاليًا بتقييم الجهد المطلوب.

هذه حقا أخبار جيدة! أفهم تمامًا أنك ترغب في معرفة العمل المطلوب قبل الالتزام به :)

الساعة 3 صباحًا هنا الآن ، ولم أقم بتجميع قائمة بالمشكلات ولكن فيما يلي بعض الملاحظات القصيرة:

لا يعرّف الكرفس مجموعة من الميزات التي يتم تنفيذها بواجهة Redis بدلاً من ذلك
يستخدم AMQP API لاستخدام المراسلة بطريقة عامة. مراسلة من الاسم إلى قائمة الانتظار وتوجيه عام / فرعي وموضوع. لا يعد توجيه الموضوع مطلبًا صارمًا ، لكن الباقي مهم لميزات Celery الرئيسية المتمثلة في 1) التعامل مع رسائل المهام ، و 2) إرسال / استقبال أحداث المراقبة ، و 3) إرسال رسائل البث إلى العمال لإدارتها (مثل إيقاف التشغيل / زيادة التزامن / إلخ. ).

1) يجب أن يكون غير متزامن حتى لا يحجب العامل عن أي عملية

يستخدم الإصدار الحالي مكتبة redis-py ، وهي متزامنة. لقد اخترقت هذا لأجعله
إنه يستهلك الرسائل بطريقة غير متزامنة ، لكنني أظن أنه لا تزال هناك أخطاء لأننا لا نعرف بالضبط ما يحدث في العميل. قد يكون هناك بالفعل عملاء redis غير متزامن متاحين لـ
قد لا نستخدم Tornado / asyncio الذي يمكننا استخدامه ، أو أسوأ حالة نظرًا لأننا لا نحتاج إلى الكثير للقيام بذلك بشكل خام
كن صعبًا جدًا.

2) إدارة الاتصال

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

3) رسالة إقرار

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

شكرًا ask ، بخصوص النقطة "1" ، قد يكون من المنطقي تنفيذ الحد الأدنى من دعم Redis غير المتزامن الذي نحتاجه للأوامر القليلة التي نرسلها مباشرةً داخل الوسيط بدلاً من الاعتماد على lib خارجي.

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

1) يجب أن يكون غير متزامن حتى لا يحجب العامل عن أي عملية

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

تحرير: لم أعمل مع أسينسيو بيثون بشكل مباشر حتى الآن ، ولكن مما رأيته يشبه إلى حد كبير الإعصار ، لذا من المحتمل أن يكون هذا النمط سهلاً.

dvirsky غير مسموح لنا باستخدام fork . لا تدعم Python هذه الحالة ، وحتى إذا تم إنتاج تصحيح لـ cpython ، فسيتعين علينا تصحيح مكتبات Python الموجودة بعناية ، على الأقل امتدادات C ، لتكون آمنة بهذه الطريقة. تم تحقيق ذلك في متتبع أخطاء Python منذ بعض الوقت ، ولهذا السبب كنا نقوم بالترحيل إلى I / O غير المتزامن. نحتاج أيضًا إلى الانتقال إلى هناك بشكل عام ، نظرًا لأن هذا في مستقبل Python الآن مع دعم I / O الأساسي غير المتزامن.

antirez إعادة:

حول النقطة "1" قد يكون من المنطقي تنفيذ الحد الأدنى من دعم Redis غير المتزامن الذي نحتاجه للأوامر القليلة التي نرسلها مباشرة داخل الوسيط بدلاً من الاعتماد على lib خارجي.

لن أفعل ذلك. تدور معظم أكواد redis-py حول إدارة الشبكات والاتصال ، وليس حول تنفيذ الأوامر ...

dvirsky لدينا ضيعة للوقت. ليس لدينا الكثير من الشبكات ، لكنني أعتقد أن معظمها يقوم بتحليل البروتوكول ونحن نفعل ذلك بالفعل بالقرب من يدوياً أو بالتثبيت في فئات redis الحالية.

ask نعم هناك hiredis وهو امتداد C مخصص لتحليل بروتوكول redis ، ويمكن أن يعمل مع عميل غير متزامن أيضًا. ما هي الإستراتيجية التي اخترتها حتى الآن لجعل redis غير متزامن؟

على أي حال ، أحتاج إلى إلقاء نظرة على ما يحدث مع العملاء غير المتزامنين مؤخرًا ، لم أقم بالكثير من أعمال البايثون في العام ونصف العام الماضيين. أرى أن https://github.com/leporo/tornado-redis لم يكن نشطًا للغاية.

ليس هناك الكثير من الإستراتيجية ، فنحن نضيف المقبس إلى حلقة الحدث ونرسل على سبيل المثال BRPOP بشكل متزامن ، ثم ننتظر حتى يكون المقبس قابلاً للقراءة ونقرأ الاستجابة بشكل متزامن ؛)

نظرًا لعدم وجود طريقة لإعادة التشغيل في منتصف تحليل الاستجابة

dvirsky إذا استخدمنا hiredis لأي شيء بخلاف تحليل البروتوكول ، فسنواجه مشكلات توافق مع gevent / eventlet (عند استخدامه بدلاً من المعالجة المتعددة) ، كما أنه سيجعل hiredis إلزاميًا أي مشكلات قابلية النقل إذا تم تشغيل الكرفس على PyPy.

dvirsky أيضًا لا يعرض py-hiredis أي وظيفة بخلاف تحليل البروتوكول في الوقت الحالي.

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

أنت تستخدم gevent الآن؟

dvirsky نحن ندعم gevent و eventlet والمعالجة المتعددة (prefork) مع I / O غير المتزامن. ولكن إذا كنت تدعم أحدهم ، فعادة ما يكون لديك الآخرون.

نعم ، هناك أوقات يكون فيها gevent أكثر ملاءمة للمهام. على سبيل المثال ، عند كتابة المهام إلى قاعدة البيانات أو تنفيذ طلب HTTP.
من السهل بما فيه الكفاية فضح وتسجيل FDs في gevent ولكن هذا يتطلب مزيدًا من العمل في py-hiredis.

dvirsky هنا مثال على كيفية القيام بذلك باستخدام PyCurl. https://gist.github.com/GuoJing/5875326
تحتاج إلى فضح FD من أجل التعاون مع gevent.

لقد تعرفت مؤخرًا على المشكلة المتعلقة بدعم الكرفس لـ Redis وعلى الرغم من أنني لم أكمل تحليلًا شاملاً ، يمكنني القول إن كتابة / ترقية عميل python redis باستخدام asyncio تبدو فكرة جيدة ، ولكن من المعايير الحديثة ، سيكون ذلك أفضل تم تنفيذه فوق asyncio + libuv للضغط على أكبر قدر ممكن من الأداء.

للاطلاع على المراجع انظر

• https://github.com/MagicStack/uvloop
• https://github.com/saghul/pyuv
• http://magic.io/blog/uvloop-blazing-fast-python-networking/

ضد هذا الموقف - أو لتعقيد الأمور ، أود أن أشير إلى أنه من تجربتي الخاصة مع عملاء Redis ، كمطور ومستخدم ، فإن الاعتماد كليًا على libuv سيمنع العميل فعليًا من تحقيق أقصى أداء ، وهذا أمر لا بد منه. هناك الكثير من الأشياء التي تحدث تحت غطاء محرك السيارة في libuv والتي تؤدي في الواقع إلى إبطاء io في بعض الحالات ، ويقوم ioredis بذلك من خلال Node وهو ليس مؤديًا حقًا.

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

@ merl-dev لا تزال المشكلة هي PyPy حيث يكون hiredis + cffi أبطأ في تحليل بروتوكول redis من تنفيذ محلل بروتوكول python الخالص.
على الأقل ، يحتوي الإصدار الخاص بي أيضًا على بعض الإخفاقات في الاختبار مع redis-py. انظر https://github.com/redis/hiredis-py/pull/46

من الممكن تمامًا كتابة عميل hiredis كملحق CPython. ما زلت غير متأكد بنسبة 100٪ بشأن CFFI.

لنحصل عليه

thedrow هذا يذكرني - هل نظرت إلى ميزة redis Streams الجديدة؟ يمكن استخدامه كوسيط رسائل أكثر قوة من الأشياء الحالية. ستكون GA قريبًا جدًا.

ليس لدينا. ليس لدينا القدرة على إعادة بناء وسيط redis في الوقت الحالي.
كنا نأمل أن تكون لديكم بعض الأيدي الاحتياطية للقيام بذلك.

thedrow قد لا نعد بأي شيء ولكن قد نخصص بعض الموارد الإضافية لدعم النظام البيئي redis بشكل استباقي.

dvirsky تقصد هذا الاقتراح ، أليس كذلك؟ لذا يمكنك استخدام TAPPEND للإدراج في قائمة الانتظار ، و TREAD + TACK لإلغاء الصف ، والمعالجة والإقرار.

georgepsarakis لم يعد اقتراحًا ، إنه يعمل ، والبادئة هي X ، أي XADD. راجع https://www.youtube.com/watch؟v=ELDzy9lCFHQ

إذن ما هو القرار الأخير بشأن دعم وسيط redis؟ هل سيتم إهماله في أي وقت قريبًا؟

ليس الان.

لم أستطع تحديد الطريقة التي يميل بها المجتمع ولكننا بدأنا مشروعًا جديدًا وأنا متردد في الذهاب مع Redis كوسيط بسبب التفكير في إهماله. أفكار؟

من الآمن افتراض أن وسيط redis سيبقى في المستقبل المنظور. الكثير من الناس يعتمدون عليه.

كل الوقت # 301/601 أصبح قديمًا.

حاول ermik المساعدة في الحصول على ذلك بشأن المشكلة ذات الصلة.