Celery: 機能：Beatは同時呼び出しを回避する必要があります

これは、 kombu.pidboxを使用することで解決できます。これは、同じ名前のノードがすでに実行されていることをceleryd検出する方法でもあります。 celerybeatは一元化されているため、固定ノード名を使用できます。

副作用として、リモートコントロールコマンドでcelerybeatを制御できるようになります（たとえば、スケジュールをリロードしたり、近い将来に予定されているタスクを確認したりするコマンドがある可能性があります）。 あなたが私に尋ねれば、それはかなり素晴らしい副作用です。

同じクラスターで複数のインスタンスを実行するユースケースがあるため、さらに計画が必要です。 たとえば、スケジュールを複数の部分に「シャーディング」する場合。 少なくとも、インスタンスごとにノード名を選択できる可能性が必要です。 2.3.0に延期します。

celerybeat実行しているボックスがオフラインになり、新しいcelerybeatインスタンスを開始するための適切なフォールバックが行われずにオフラインになるという問題がありました。 celerybeatを実行するための推奨されるHAの方法は何ですか？

kombu.pidboxアプローチでは、 celerybeat複数のインスタンスを実行できますか？インスタンスが固定ノード名ですでに実行されていることを検出した場合はスリープ状態になり、ポーリングしてアクティブに昇格します。インスタンスがダウンしますか？

複数のアクティブなインスタンスを実行することは興味深いように思えます-スケジュールを共有することに加えて、他にどのような利点がありますか？

+1

+1

これは、スケジューリングの復元力が重要である大規模なデプロイにとって真の懸念事項です。

+9999;）
kombu.pidboxソリューションの使用に何か問題がありますか？ シャーディングと派手な機能がなくても、これは素晴らしく、非常に便利です。 今、別のホストでcelerybeatを手動で開始する必要があります。

Pidboxを使用することもできますが、問題はビートがコンシューマーではないことです。 「ここにビートインスタンスはありますか？」のようなブロードキャストメッセージに応答するにはブロードキャストキューでメッセージを常にリッスンする必要がありますが、メッセージのスケジュールが忙しいため、現在はリッスンできません。

技術的には、2番目のスレッドを使用している可能性がありますが、パフォーマンスが低下する可能性があり、この機能のためだけに多くのオーバーヘッドが発生します。

2番目の解決策は、ロックを使用することですが、ロックを解除する必要があるという欠点があります。 つまり、ビートプロセスが強制終了された場合、古いロックでは、新しいインスタンスを開始するために手動で介入する必要があります。

また、ロックに2秒のタイムアウトがあり、1秒ごとにロックを更新することもできます。 つまり、ロックが保持されている場合、新しいインスタンスは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）。

また、誰かがcelerybeatに共有pidfileを直接使用したことがあるのではないかと思います。おそらく、AWSのEBSで、またはS3バケットで… celerybeat --pidfile=/path/to/shared/volume 。

現在のマスター（3.1 dev）には、コンシューマー向けのゴシップステップがあることに気づきました。 ゴシップキューとリーダー選出を活用して、埋め込まれたビートプロセスを調整することは可能でしょうか？ つまり、各ワーカーは埋め込みビートプロセスを実行しますが、リーダーのみが定期的なタスクをキューに入れます。 これは、共有スケジュールストレージを想定している可能性があります。

@mlavinこれは機能する可能性がありますが、ブロードキャストをサポートするブローカートランスポートの場合のみです

pidboxソリューションの問題は、非同期I / Oを使用するようにcelerybeatプログラムを書き直す必要があることです。
スケジューラーがブロックしているため、現在、タスクの消費と生成の両方を行うことはできません。

ほとんどの場合、これは必要な機能ではありません。ほとんどの本番環境にはビートプロセス専用のホストがあり、複数のインスタンスを開始しないようにするには、 --pidfileを使用するだけで十分です。

この問題の影響を受けるのは、デーモン化で-Bオプションを使用する人であることがよくあります。
スクリプトを作成し、その設定を別のホストに複製します。

だから私はそれが迷惑だと思いますが、それは重要ではないと思います。 誰かが本当に解決策を望んでいるなら、彼らはそれを貢献するか、私を雇う/寄付してそれを実装することができます。

uWSGIを使用して、他のノードへのフォールバックを伴うシングルビートプロセスを実行できます。

+1、同一のAmazon EC2インスタンスを起動し、1つのノードでのみ実行される定期的なタスクがあると便利です。 その間、私は提案に感謝してuWSGIを使用しようとします。

+1

+1

私は仕事でCelerybeatをスケジュールに使用することを主張してきましたが、HAをすぐに使用できないため、非常に困難になっています。 実際、これが原因で完全に削除されるようです。 非常に簡単に言えば、1つのCelerybeatインスタンスのみを実行すると、これが単一障害点になるため、本番環境に対応できなくなります。

@junaidchこれでセロリを落とすべきではないと思います。 いつでもすべてのサーバーでスケジューラーを実行できます。定期的なタスクの場合は、何らかのロックメカニズムを使用して、重複しないようにし、頻繁に実行しないようにします。 さらに、スケジューラーをサブクラス化してそこでロックを実行することも、タスクレベルのロックをスキップしてスケジューラーですべてを実行することもできます。

これは一種の回避策であるため、セロリにいくつかの組み込み機能があると便利ですが、それでも本番環境で問題なく使用できます。

@ 23doorsに感謝します。

私のタスクは、タスクの別のインスタンスが実行されないように、すでにRedisロックを維持しています。 2つの異なるマシンで2ビートを実行し、タスクが5分間隔でスケジュールされている場合、両方のビートがタスクをキューにプッシュしていても、それは機能すると思います。 コア機能の回避策を実装する必要がある場合、採用のケースを作成するのはさらに難しくなります。

サブクラスの推奨事項を調査します。 それはよりクリーンなアプローチかもしれません。

提案をありがとう！

Luluでは、単純なクラスターシングルトンマネージャー（BeatCopという名前）を作成することでこれを解決しました。 期限切れのRedisロックを使用して、Celeryワーカーの自動スケーリングプールで実行されているCelerybeatが1つだけであることを確認します。 そのCelerybeatに何かが起こった場合（インスタンスがスケールアウトされたり、停止したり、Celerybeatがクラッシュしたりするなど）、別のノードが自動的に新しいCelerybeatを生成します。 BeatCopを

@ingmar同じ理由でこのhttps://github.com/ybrs/single-beatを作成しましたが、前回チェックしたときにコメントが表示されませんでした。 オープンソースが他の人にも役立つかもしれないので、私たちはまたリリースしました。 多かれ少なかれ同じことをします。

私が見る限り、beatcopとの主な違い-、pyuvを使用しています-したがって、beatcopはより移植性が高く、依存関係が少ないと思います-、子のstderrとstdoutを親としてリダイレクトし、子が同じコードで死亡した場合は終了し、次のように構成します環境変数。 そのため、スーパーバイザーに追加するのは少し簡単です。

それが他の誰かに役立つかもしれないことを願っています。

+1

+1

領事のキー値をロックコントローラーとして使用することを検討していますが、誰かがこのアプローチを試しましたか？ したがって、1つのインスタンスが機能している間、他のインスタンスはロックが更新されなくなるまで「スリープ」し、その後、領事選挙メカニズムがタイムスタンプ付きのキー値を更新するのは誰かを決定します。 ロックを更新する人は誰でも機能します。

@ingmarありがとうございます！ これをワーカークラスターで試してみます。

現在の実装としての+10は、最初に分散キューを使用する理由から離れた単一障害点を意味します

+1

+1

これはv5.0.0に含まれるようですhttps://github.com/celery/celery/milestones/v5.0.0

+1

これを閉じると、現在のリソースと同様に、完了するまでに10年かかります。

申し訳ありませんが、これはいわゆる「分散」キューにとって深刻な問題です。 これを実装するのにどれだけ時間がかかるとしても、最終的には修正する必要があります。 _現在_リソースがないため、完全に有効な問題を解決することは正しくないようです。 もう一度開いて、現時点で優先度が低いことを示すラベルを貼っていただけませんか。

私の閉鎖の理由がばかげて突然だったのは知っているので、ソフトウェアのユーザーとして私はあなたの感情を理解することができますが、技術的にはBeatはアドオン機能のようなものです。 これはCeleryの他の部分から完全に切り離されており、実装を単純に保つために、意図的に非分散になるように設計されています。 これは、PythonからのcronジョブをすでにCeleryを使用しているユーザーへのボーナスとして定義するための巧妙な方法として始まり、その後、ますます多くの人々がCeleryをcronの代替として使用しました。

この問題は6年間開かれており、頻繁に要求され、無数の企業がそれに依存していますが、実装にお金を払うことを申し出た企業はありません。

それは実際、企業が後援するのに興味深いと私が考えた問題の1つでした。 確かに、企業が機能やバグ修正、さらには本番環境の問題の解決を支援するためにお金を払うことを申し出るのは一般的ではありません。 私はおそらく一方でそれらを数えることができます（あなたは素晴らしいです）ので、今私はそのアイデアがどれほど素朴であったかを知っています:)

今日もこの問題の複製を閉じました。＃1495を参照してください。 この問題を解決しようとするプルリクエストがあり、いくつかは有望ですが、特定の実装が機能することを証明するために必要な献身を考えると、私はまだそれらを適切にレビューする時間がありませんでした。 たぶん、これは誰かを行動に移すでしょう、たとえそうでなくても、誰もそれに取り組んでいないときに機能リクエストを6年間開いたままにしておくよりはましだと思います。 これは、これが修正されることを望んでいるユーザーにとっても一種の不利益です。

@askまあまあ。 他のスレッドで言うように、分散cronが非常に複雑な問題であることは事実です。 そして、それはセロリの外に住むべきもののように聞こえます。

時間を割いて、理由を詳しく説明していただきありがとうございます。

@askクラスター内のすべてのノードで共有されているNFSボリューム内にcelerybeat-scheduleファイル（ celery.beat.PersistentScheduler ）を配置することで、この問題を回避できるかどうか疑問に思っていましたか？

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によって管理されるなど）である場合、クラスター内のすべてのノードで1つのセロリビートプロセスが実行されていても、スケジュールが台無しにならないことを期待できますか？

@mikeschaekermannドキュメントを正しく読んでいる場合、 shelveは同時書き込みアクセスを防ぐための努力をしていません。 それはあなたにそれを起こさせないように言うだけです。 あなたが引用したセクションでは、「Unixファイルロックを使用してこれを解決できますが、これはUnixバージョンによって異なり、使用するデータベース実装に関する知識が必要です」と続けています。

@ ze-phyr-usあなたが正しいと思います、そして私はshelveドキュメントを誤解しました。 それでも、 Schedulerバックエンドがスケジュールどおりの不可分操作を保証すると仮定して、問題が解決されるかどうか疑問に思っていますか？ @ask django-celery-beatパッケージは、問題を解決するためにアトミック性をサポートしていますか？ いくつかの更新を行うためにトランザクションを使用していることがわかりました。

分散型/自動スケーリングに適したセロリビートを検索しているときにここに行き着き、Redisをバックエンドとして使用して満足している他の人のために。 上記のBeatCopとシングルビートの両方を試しましたが、最終的にはRedBeatを選び

こんにちは@ddevlin
私も同様の問題を抱えていますが、シングルビートを使用しているときにどのような問題に直面しましたか？ また、多すぎない場合は、複数のサーバーに対してredbeatを構成した方法の実装サンプルを共有してください。

@ ankur11シングルビートは、セロリビートのインスタンスが1つだけ実行されていることを保証しますが、インスタンス間でスケジュール状態を同期しません。

15分ごとに実行することを目的とした定期的なタスクでデフォルトのスケジューラーを使用し、タスクが最後に実行されてから14分後にシングルビートでフェイルオーバーした場合、タスクは新しいセロリビートの15分後まで実行されませんでした。インスタンスが開始され、29分のギャップが発生しました。

インスタンス間でスケジュール状態を共有するには、別のスケジューラーを使用する必要がありました。 django-celery-beatはCeleryのドキュメントに記載されている代替手段ですが、すでにRedisをCeleryバックエンドとして使用していたため、スケジュール同期のバックエンドとしてRedisを使用することを好みました。

Redbeatには、Redisがサポートする共有スケジュール状態と、1つのインスタンスのみがタスクをスケジュールしていることを確認するためのロックの両方が含まれているため、使用を開始した後はシングルビートやBeatCopは必要ありませんでした。

私たちの実装では、セロリビートは、スケジューラーとしてRedbeatを使用して、すべてのインスタンスでスーパーバイザーによって開始されます（例： exec celery beat --scheduler=redbeat.RedBeatScheduler --app=myproject.celery:app ）。 残念ながら、仕事関連のコードを共有することはできませんが、実装全般に関する追加の質問には喜んでお答えします。

@mikeschaekermannセロリのビートを/ use / bin / flockでラップしてアクセスをロックしてみてください...

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

NFSロックの実装を信頼していると仮定します:)

これにより、1つだけが実際に実行され、他の1つはロッカーが死ぬまでブロックされます。

@mikeschaekermannセロリのビートを/ use / bin / flockでラップしてアクセスをロックしてみてください...

群れ/nfs/lock.fileセロリビート..。

NFSロックの実装を信頼していると仮定します:)

これにより、1つだけが実際に実行され、他の1つはロッカーが死ぬまでブロックされます。

私はこの方法を試しました。 残念ながら、NFSロックを保持しているクライアントがNFSサーバーへの接続を失った場合、ロックはNFSサーバーによって取り消され、別のクライアントに渡される可能性があります。 元のロックホルダーが接続を回復すると、群れはロックが取り消されたことを認識しないため、2つのノードが「リーダー」であると信じています。

私はPostgresでアドバイザリロックを使用することになりました。 django_pglocksモジュールを使用し、サブプロセスでセロリビートを実行するDjango管理コマンドを作成しました。

私はPostgresでアドバイザリロックを使用することになりました。 django_pglocksモジュールを使用し、サブプロセスでセロリビートを実行するDjango管理コマンドを作成しました。

それは私がNFSを使用して見たのと同じ問題の影響を受けやすい可能性のようにこれがそうです。 ロックを保持しているクライアントがPostgresサーバーとの接続を失った場合、またはPostgresサーバーが再起動された場合はどうなりますか？

@ swt2cああ、もちろんあなたは正しいです！ ある種の生き続ける必要があります。

今私はやっています：

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は再帰をサポートしていますが、実際にデータベースをチェックしているかどうかはわかりません。

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-2がダウンしたときにスーパーバイザーがredbeat-1自動再起動する方法のロジックを共有できれば、それは大きな助けになります。

これは、 supervisorに関する理解が不足していることが原因である可能性がありますが、 autorestart=Trueは、少なくとも1回はRUNNING状態になるプログラムに対してのみ有効であるようです。

私の問題は：

1. celery beatとredbeat.RedBeatScheduler supervisor.confに2つのprogramがあります。
2. スーパーバイザーを開始すると、一方のbeat （ beat-1 ）がロックを取得して実行され、もう一方（ beat-2 ）が数回開始を試みてFATAL状態（ Seems we're already running?エラーあり）。
3. 理想的には、 beat-1が停止した場合、スーパーバイザーにbeat-2を開始してもらいます。
4. ただし、そもそもRUNNING状態ではなかったため、これは発生しません。 つまり、 beat-1停止すると、停止して何も起こりません。

私の頭から離れて、解決策は、5秒ごとにsupervisorctl restart allを実行し続けるcronを持つことですが、どのように達成できたかについてあなたの考えを知りたいだけですスーパーバイザーとの冗長性。

こんにちは@harisibrahimkv 、あなたの問題は、同じホストでセロリビートの2つの同一のインスタンスを開始していることです。 beat-2ログにERROR: Pidfile (celerybeat.pid) already exists.れていると思いますか？ 同じホストでセロリビートの2つのインスタンスを実行すると、それらの間のフェイルオーバーをテストするのに役立ちますが、実際の冗長性を得るには、複数のホストでセロリビートを実行する必要があります。

同じホストで複数のインスタンスを実行するには、スーパーバイザーに--pidfile引数でインスタンスを開始させ、個別のpidfileを指定します。

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

両方のインスタンスはスーパーバイザーの下で正常に起動するはずですが、ログファイルを確認する場合は、そのうちの1つだけがタスクをスケジュールしているはずです。 そのインスタンスを停止すると、他のインスタンスがタスクのスケジューリングを引き継ぐのがわかります。

私たちの目標は、セロリワーカーを実行している同一のホストの自動スケーリングプールと、スーパーバイザーの下でのセロリビートを作成することでした。 各ホストには、単一のセロリビートインスタンスがあります。 この構成では、セロリビートはすべてのホストで正常に開始されますが、ロックを取得しないセロリビートのインスタンスは事実上ホットスタンバイになり、タスクをスケジュールしません（ただし、プール内のすべてのホストがタスクを処理します）。 ロックのあるインスタンスが停止した場合（たとえば、プールが縮小された場合、またはプール内のホストのローリングアップグレードを実行している場合）、スタンバイインスタンスの1つがロックを取得し、スケジューリングタスクを引き継ぎます。

@ddevlin私に戻ってきて、インターネットをこのような素晴らしい場所にしてくれてありがとう！ 心から感謝します！ （私の家族全員にあなたの返事について話していました：D）

1. pidfileビットは機能し、もう一方が停止したときにbeat-2がタスクを引き受けるのを見てとてもうれしかったです。 CELERYBEAT_MAX_LOOP_INTERVAL = 25 （セロリ3.x）でビートの時間を設定できます。

2. はい、実際の冗長性のために、この設定をさまざまなインスタンスにまとめて行う予定です。 使用していたセットアップについて説明していただきありがとうございます。 今それに取り組むつもりです。 「同じインスタンス上の複数のホスト」のセットアップは、正しく理解されているように、フェイルオーバーの概念がこのスーパーバイザーのセットアップで機能するかどうかを最初に検証することでした。

温かい感謝、
インド亜大陸の最南端にある小さな村から。 :)