Celery: ブローカーサポートとしてRedisを非推奨にする提案。 [拒否]

現在、セロリの代替品が存在します。たとえば、 hueyやrq 、ブローカーとしてのredisのサポートに明示的に焦点を当てています。 セロリがリリースされたとき、何もありませんでした。

@ask SQLブローカーのサポートも
また、dockerもあります。これは、rabbitmqのデプロイが文字通り1つのコマンドで済むことを意味します。 もう難しいことではありません。

RabbitMQ / Redis / SQS / Qpid以外の他のすべてのブローカーを含む、ブローカーとしてのSQLのサポートを終了しました:)

（複製）

私はセロリコミュニティにそれほど縛られていません。 私の0.02ドルに関係なく：

• Redisは本当に人気があります-Googleトレンドが代表的だと思うなら、
• それは本当に良いブローカーとバックエンドになることができます（RabbitMQも）
• 大手クラウドベンダーがフルマネージドサービスとして独自に提供しています
• Redisを多用しています！

メンテナンスの問題についてのあなたの気持ちに共感することができます、そしてこの種の行動は持続可能性への一歩です。 しかし、あなたが作ることができる他の「切断」はありますか？

方程式の「供給」側で、コミュニティからのセロリへの貢献がこれ以上ない理由について何か考えがありますか？
コミットとPRをざっと見てみると、私が貢献しているいくつかのオープンソースライブラリと比較して、セロリは主に1人の作業であることがわかります。

@MaximilianR自分のためだけに話す：

1. これは、ウォークインするためのかなりのコードベースです
2. 特に昆布やアインシオの専門家でない方は
3. そして、あなたは報告された問題の深さについての直感を持っていません

とはいえ、私はセロリを使っているので、役に立つ方法があれば喜んでお手伝いします。

@MaximilianR 、たくさんの貢献者がいますが、間違いなく私はたくさんの仕事をしました。 プロジェクトの成長が速すぎたため、ある時点で、バグを修正するか、IRC / email / StackOverflowなどでユーザーをサポートするかを選択できました。特にマルチプロセッシングプールのデッドロックの問題などは、6か月以上の集中的なコーディングが必要でした。人々を指導する。 その時点では、ダウンロードでRabbitMQとほぼ同じサイズでしたが、8人がフルタイムで働いていたので、私だけでした。

切断するものはおそらく他にもありますが、Redisほど時間のかかるものはないと思います。

amqp / kombuを完全な非同期に移植する作業も大きな時間の浪費でしたが、多くの問題を解決するために必要でした。 しかし、それは決して完了しませんでした。

@ask上記のメッセージは、SQSに力を入れることにまだ興味があることを意味しますか？ ここに開いているSQSチケットが1つしかないことに気付きましたが、ドキュメントに「実験的」警告が表示されます。 SQSの現在の状況と将来のニーズについてアドバイスできますか？

本番環境ではCelery + SQSを使用するので、それに向けていくらかの努力を払うことができるかもしれませんが、SQSがプロジェクトの長期計画の一部でない場合は、そのような状況に陥りたくありません。

@ask上記を共有してございます。 私はあなたがどこから来ているのか理解できます。 私はこれ/他のアプローチを通してセロリがその成功を維持しそして継続するのがより簡単になることを願っています...

間違いなくあなたのプロジェクトに最善を尽くしますが、Redisのサポートが終了した場合、私は確かに内部的にCeleryを取り除くようにプッシュします。 RabbitMQを使用しない理由を本当に知りたい場合は、非公開で詳しく説明しますが、公開されている他のプロジェクトを非難したくはありません。

関連：Dockerでの開発方法が機能する可能性があるため、これが1つのコマンドであることを提案しますが、それは必ずしも他のユーザーが展開する方法ではありません。

@nicksloan SQSは、マスタードキュメントでサポートされているトランスポートとしてリストされています： //docs.celeryproject.org/en/master/getting-started/brokers/index.html

SQSトランスポートを非同期I / Oを使用するように書き直す作業は、1000ドルを少し超える金額で後援されました。

@scoates Redisトランスポートは、メッセージの読み取りに非同期I / Oを使用するために実際にハッキングされているため、状況はさらに悪化していますが、公開は依然として同期しています。 Python redisライブラリは同期しているため、メッセージを読む場合でもまだ複数の課題があり、それがどのように機能するかについては多くの不確実性があります。 バグは簡単にそこに隠れている可能性があり、redis-pyライブラリに変更を加えると、非正統的な方法で使用している場合に劇的な影響を与える可能性があります。

Redisをサポートしたいのですが、本当にそうです。 私がRabbitMQ / Pivotalで働いていたとき、Celeryが実装するパターンには、Pythonで共通のソリューションが必要だと感じたので、私はそれのために戦っていました。 しかし、コミュニティとそれを使用している企業がそれを機能させるために投資されていない場合、私は消火活動に取り残され、最悪の場合、プロジェクトを批判する人々につながる輸送の深刻な問題を解決できなくなります。 これは私の人生をより悲惨にし、士気を低下させます。

セロリの歴史を考えると、これは過激すぎるかもしれませんが、RabbitMQよりもRedisだけを維持することを考えましたか？

@MaximilianR私はそれを検討しましたが、私の情熱はメッセージの受け渡しと正しい分散システムの構築にあります。 Redisは、メッセージ確認応答を実装するために機能するBRPOPLPUSHの実装をまだ提供しておらず、分散システムでは実時間に依存することが不可能であることを受け入れることができないことが明らかになりました。基本的な事実ですが、私はもっと警戒しています。 RabbitMQは少なくとも問題領域を真剣に攻撃しており、KafkaやNSQのような他のプレイヤーもいます。 多くのライブラリがタスクキューを単純なリスト操作として扱っていますが、Celeryがそれらの1つになることを拒否します:)

@scoates ：私は自分がどのように開発しているのかなどについて話していませんでした。 2016年に「rabbitmqをデプロイするのは難しい」と言うのはナンセンスだと言っていました。 どこかに何かをデプロイすることについて何も知らなくても、本当に役立つdockerがあります。 間違った仮定をしないでください。

おかげで私たちでチェックするため@ask。 セロリは素晴らしい製品であり、あなた（そしてコミュニティ）が持っている限られたリソースを考えると、コア製品に焦点を当てることが最善の決断だと思います。 多くの異なる互換性のないシステムを使用して同じ優れた機能を提供しようとすることはどれほど難しいか想像できます。 消費者の観点からすると、非常に多くのオプションがあると、製品が複雑になると思います。 これはおそらくあなたのユーザーの何人かを混乱させるだろうと私は確信していますが、ブローカーを減らすことに固執することは製品のために正しいことだと思います。 AMQPは標準的で広く受け入れられているプロトコルであり、rabbitmqは非常に優れた実装であるため、AMQPに焦点を当てたいと思います。

やらなければならない作業がそれほど多くないのは悲しいことですが、すべてのトランスポートと機能をすべて合計すると、週に数時間だけでは持続可能ではありません。

Redisプロトコルは非常に単純なので、トランスポートを完全に非同期に書き換えるのはそれほど難しいことではありません。 Celeryが任意のTornadoライブラリをサポートできるようにするレイヤーを作成しました。これは、asyncioやTwistedでも同じように作成できるため、再利用できるクライアントが存在する場合もあります。

Pythonはstdlibのasyncioで劇的に変化しています。 新しいWebフレームワーク、新しいネットワークライブラリが必要であり、エコシステム全体を適応させる必要があります。 独自のイベントループを維持し続ける必要がなくなるため、作業が少し簡単になりますが、移行にはいくつかの作業が必要になります。

また、複数の言語をサポートする新しいメッセージプロトコルができたので、Goなどで新しいワーカーを作成したいと思います。 Redisは、メッセージヘッダー、プロパティなどを実装していないため、メッセージングの相互運用性に最適ではありません。AMQPプロトコルは、元のユースケースの1つであったため、間違いなく優位に立っています。

@ask私のアプローチは、企業にブローカーを維持させることでした。 それでは、Redisラボの誰かと話をして、牽引力が得られるかどうかを確認してみましょう。
MongoDBやその他のサービスについても同じです。
SQLブローカーに関しては、あまり良い考えではなく、サポートすべきではないと思います。
コードを削除する代わりに抽出して、維持してくれる人を探すことができます。 十分な関心がない場合は、それらの必要はありません。
ブローカーになることができる唯一のSQLデータベースはPostgresです。これは、Pub / Sub機能を備えているためですが、現在は実装されていません。

私たちはそれを非推奨にして、何が起こるかを見ることができると思います。 たぶん誰かがメンテナンスを引き継ぐか、後援によってそれのためにステップアップします。 そうでなければ、人々が必要としているが、誰もサポートしたくない製品があります。これは、現時点で合計18票になる可能性があります。 それがRedisLabsだけを揺るがすとは思わない:)

しかし、コミュニティとそれを使用している企業がそれを機能させるために投資されていない場合、私は消火活動に取り残され、最悪の場合、プロジェクトを批判する人々につながる輸送の深刻な問題を解決できなくなります。 これは私の人生をより悲惨にし、士気を低下させます。

私たちは複数のプロジェクトでredisブローカーと一緒にセロリを使用しており、それに依存していますが、私はその感情に強く同意します。 あなたがそれを高レベルの品質に保つことができないならば、それはセロリに悪い名前を与えるだけで、みんなを不幸にします–あなたとユーザー。

やあ。 私はRedisLabsで働いており、最近までセロリのユーザーでした。 @thedrowはこれを私の注意を引きました、そして私達はこれを内部で議論しました。 私たちは皆さんを喜んでお手伝いします。セロリの一部としてredisを維持することが重要だと考えています。 個人的にやるのか、他の人にやるのかはまだわかりませんが、何をする必要があるのか​​を話し合いましょう。

@dvirskyのように、Redisへの私の作業はRedis Labsによって完全に後援されており、このバックエンドを支援できる場合（できればそうです）、Redis側で最適なソリューションを見つけるのを支援することに関与します。実装の特定のことを容易にするために、Redisメッセージングサポートを拡張します。 また、HA対応のエクスペリエンスを実現するために、ある時点でSentinel / Redisクラスターを使用するバックエンドの機能を強調することもできます。 現在必要な努力を評価している良いニュースができるだけ早くあることを願っています。

これは本当に良いニュースです！ 私はあなたがそれにコミットする前に関係する仕事を知りたいと思っていることを完全に理解しています:)

今は午前3時です。問題のリストは収集していませんが、短いメモをいくつか示します。

Celeryは、Redisへのインターフェースで実装される一連の機能を定義していません。
AMQP APIを使用して、一般的な方法でメッセージングを使用します。 名前からキューへのメッセージング、pub / subおよびトピックルーティング。 トピックルーティングは厳密な要件ではありませんが、残りは1）タスクメッセージの処理、2）監視イベントの送受信、3）ワーカーへのメッセージのブロードキャスト（シャットダウン/同時実行性の向上など）のCeleryの主な機能にとって重要です。 ）。

1）ワーカーが操作をブロックしないように、非同期である必要があります

現在のバージョンでは、同期型のredis-pyライブラリを使用しています。 私はこれをハックして作りました
非同期でメッセージを消費しますが、クライアントで何が起こっているのか正確にはわからないため、まだバグがあると思います。 利用可能な非同期Redisクライアントがすでに存在する可能性があります
私たちが使用できる竜巻/非同期、または生でそれを行う必要がないため最悪の場合はそうではないかもしれません
とてもトリッキーになります。

2）接続管理

タスクを消費する接続が1つあり、pubsubを実行する接続が1つあり、次にプールがあります。
メッセージの確認や未確認メッセージの復元など、帯域外操作を実行するための接続の数。 ここではエラー処理に関して混乱があり、使用後にすべての接続を閉じるとは限りません。

3）メッセージの確認

メッセージは、確認された後にのみサーバーから削除され、すべてのメッセージコンシューマーがメッセージを復元しようとする可視性タイムアウトがあります。 まあそれは混乱です、
これについては後で詳しく説明します。

@askに感謝し外部ライブラリに依存するのではなく、ブローカー内で直接送信するいくつかのコマンドに必要な最小限の非同期Redisサポートを直接実装することが理にかなっている場合があります。

2つだけ、そしておそらく他のいくつかの小さな問題がすぐに解決を必要とすることに注意してください。 これはおおむね機能していますが、メッセージの確認応答によってメッセージが失われる場合がありますが、ackエミュレーションの前は状況がはるかに悪かったため、これはウィッシュリスト項目です。 同期Redisクライアントによってワーカーがブロックされる可能性があります。これにより、パフォーマンスが低下し、まれにワーカーがハングします。

1）ワーカーが操作をブロックしないように、非同期である必要があります

最後に確認したところ、非同期Redisクライアントは完全ではありませんでした（竜巻の場合はいくつかあります）。 このような状況で私が何度も行ったことは、スレッドプールエグゼキューターとfuturesを使用して、redis-pyを非同期クライアントのように動作させることでした。 並行タスクが多すぎず、いくつかのスレッドで実行できる限り、非同期クライアントよりもうまく機能します。

編集：私はまだPythonのasyncioを直接操作していませんが、私が見たところ、竜巻にかなり似ているので、このパターンはおそらく簡単に実行できます。

@dvirsky forkも使用しているため、スレッドの使用は許可されていません。 Pythonはこのケースをサポートしていません。また、cpythonのパッチが作成された場合でも、この方法で安全を確保するには、既存のpythonライブラリ（少なくともC拡張機能）に注意深くパッチを適用する必要があります。 これは、Pythonバグトラッカーで少し前に実現されたため、非同期I / Oへの移行を行っています。 また、一般的にそこに移動する必要があります。これは、Pythonの将来であり、コア非同期I / Oがサポートされるようになったためです。

@antirez re：

ポイント「1」については、外部ライブラリに依存するのではなく、ブローカー内で直接送信するいくつかのコマンドに必要な最小限の非同期Redisサポートを直接実装することが理にかなっている場合があります。

私はそれをしません。 redis-pyのコードのほとんどは、コマンドの実装ではなく、ネットワークと接続の管理を中心に展開しています...

@dvirskyそのために完全に機能する接続管理ジェネリックがありますので、時間の

@askはい、redisプロトコルを解析するための専用のC拡張機能であるhiredisがあります。IIRCは非同期クライアントでも機能します。 redisを非同期にするためにこれまでどのような戦略を選択しましたか？

とにかく、私は最近非同期クライアントで何が起こっているのかを見る必要があります、私は過去1年半の間多くのPythonの仕事をしていません。 https://github.com/leporo/tornado-redisはあまり活発ではなかったようです。

戦略はあまりありません。ソケットをイベントループに追加して、たとえばBRPOPを同期的に送信し、ソケットが読み取り可能になるのを待って、応答を同期的に読み取ります;）

応答の解析中に再起動する方法がないため

@dvirskyプロトコル解析以外の目的でhiredisを使用すると、gevent / eventletとの互換性の問題が発生し（マルチプロセッシングの代わりに使用した場合）、CeleryがPyPyで実行されている場合の移植性の問題であるhiredisが必須になります。

@dvirskyまた、py-hiredisは、現時点ではプロトコル解析以外の機能を公開していません。

Pythonは、私が信じるある時点でまともな非同期redisクライアントを必要とするので、適切なものを開始することは悪い考えではありません。 たとえば、redis-pyでプロトコル解析コードの一部をリファクタリングします。

あなたは今geventを使っていますか？

@dvirsky非同期I / Oを使用して、gevent、eventlet、およびマルチプロセッシング（prefork）をサポートします。 しかし、あなたが1つをサポートするなら、あなたは通常他のものを持っています。

はい、geventがタスクにより適している場合があります。 たとえば、タスクがデータベースに書き込むか、HTTPリクエストを実行する場合などです。
FDをgeventに公開して登録するのは簡単ですが、py-hiredisでさらに作業する必要があります。

@dvirskyこれは、PyCurlでどのように行われるかの例です。 https://gist.github.com/GuoJing/5875326
geventとコラボレーションするには、FDを公開する必要があります。

私は最近、Redisのセロリサポートを取り巻く問題を紹介されました。徹底的な分析は完了していませんが、asyncioを使用してpython redisクライアントを作成/アップグレードすることは良い考えのように思えますが、最近のベンチマークからは、それが最善でしょう。 asyncio + libuvの上に実装され、可能な限り多くのパフォーマンスを絞り込みます。

参考のために参照してください

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

この立場に対して、または問題を複雑にするために、開発者およびユーザーとしてのRedisクライアントでの私自身の経験から、libuvに完全に依存すると、実際にはクライアントが最大のパフォーマンスを達成できなくなります。そのためには、hiredisが必須です。 libuvの内部では、実際にioが遅くなることがありますが、ioredisはNodeを介してそれを実行しますが、実際にはパフォーマンスが高くありません。

したがって、私が想定するソリューションには、混合されたhiredis-async実装があります。 （別の言い方をすれば、たくさんの選択肢を試して、たくさんのチェリーピッキングとベンチマークを試す必要があります）

@ merl-dev問題は依然としてPyPyであり、hiredis + cffiは純粋なPythonプロトコルパーサーの実装よりもredisプロトコルの解析に時間がかかります。
少なくとも私のバージョンでは、redis-pyでいくつかのテストに失敗しています。 https://github.com/redis/hiredis-py/pull/46を参照して

CPython拡張機能としてhiredisクライアントを作成することは完全に可能です。 CFFIについてはまだ100％確信がありません。

取得しましょう

@thedrowこれは私に思い出させます-新しいredisストリーム機能を見ましたか？ これは、現在のものよりも堅牢なメッセージブローカーとして使用できます。 間もなくGAになります。

私たちはしていません。 現在、redisブローカーをリファクタリングする機能はありません。
私たちはあなたたちがそうするためにいくつかの予備の手を持っていることを望んでいました。

@thedrow私たちは...何も約束しないかもしれませんが、redisエコシステムを積極的にサポートするためにさらにいくつかのリソースを捧げるかもしれません。

@dvirskyあなたはこの提案を意味しますよね？ したがって、 TAPPENDを使用してエンキューし、 TREAD + TACKを使用してデキュー、処理、および確認応答を行うことができます。

@georgepsarakisこれはもはや提案ではなく、機能しており、プレフィックスはX、つまりXADDです。 https://www.youtube.com/watch?v=ELDzy9lCFHQを参照して

では、redisブローカーをサポートするための最後の呼びかけは何ですか？ 近いうちに非推奨になる予定ですか？

現時点ではない。

コミュニティがどちらの方向に傾いているのかわかりませんでしたが、新しいプロジェクトを開始しており、廃止することを考えているため、ブローカーとしてRedisを使用することを躊躇しています。 考え？

redisブローカーが当面の間とどまると想定するのは安全です。 あまりにも多くの人がそれを中継します。

その間ずっと＃301 / 601は古くなっています。

@ermikは、関連する問題についてそれを理解するのを