私はまだ遅延ジョブを処理ジョブキューとして使用しているこのプロジェクトを持っています。私は最近、いくつかの疑問を抱かせているエッジケースを見つけました: 私はこの AR (ちなみに MySQL を使用しています) オブジェクトを持っており、更新時に has_many アソシエーションのすべての要素にメッセージを送信します。そのためには、この関連付けのすべての要素をインスタンス化し、それらの要素に対するメッセージを呼び出す必要があります。彼ら一人一人へのこのメッセージの呼び出しを遅らせるのに十分なほど公平に思えました。
現在、関連付けはかなり大きくなりました。エッジケースでは、その関連付けに属する 40000 個のオブジェクトがあります。これによるメッセージ送信には、40000 の遅延ジョブ ジョブの (同期) 作成が含まれます。これらはコミット後ではなく更新後のコールバック内で発生するため、コンテキスト切り替えを利用せずに同じ接続を (ab) 使用しています。短いバージョンでは、同じ接続に 1 つの Update ステートメントと 40000 の挿入のパイプがあります。そのため、この更新は実稼働環境でかなりの時間を飲み込んでいます。
現在、これには多くの方法があります: コールバックをコミット後のものに変更し、40000 ジョブを作成する 1 つの (同期) 遅延ジョブを作成します (1 つのジョブで 40000 (AR) オブジェクトを処理したくありません。今の 40000 は明日 120000 になり、それはメモリアルマゲドンです) など...
しかし、私が本当に考えているのは、遅延処理キューを resque または sidekiq に切り替えることです。redis を使用しているため、書き込みパフォーマンスがはるかに優れています。MySQL ではなく何かを使用しているため、接続が互いにブロックされません。私の唯一の問題は、redis に一度に 40000 の書き込みを行うと、どのくらいの費用がかかるかということです。そして、これらのオプションのいずれかが最初にジョブをメモリに保存し、クライアントへの応答をブロックせず、遅ればせながらそれらを redis に保存しますか? だから、私の本当の質問は、このような極端なケースで、この遅延はどのくらい私を遅らせるのでしょうか?