0

Rails 4.2 アプリでTwilio を使用してテキストを送受信しています。一度に約 1000 件をまとめて送信し、散発的に受信しています。

現在、テキストを受信すると、それを DB (to、from、body) に保存し、そのレコードを ActiveJob ワーカーに渡して後で処理します。メッセージを送信するために、現在、Twilio パラメータを別の DB に保持し、そのレコードを別の ActiveJob ワーカーに渡しています。私はバッチで行うことが多いので、2 つのワーカーがあります。最初の発信メッセージ ワーカーは、1 つのメッセージを送信します。2 番目のものは DB にクエリを実行し、メッセージを受信する必要があるすべてのユーザーを見つけ、送信する必要がある各メッセージの DB レコードを作成し、そのレコードを最初の送信メッセージ ワーカーに渡します。したがって、2 番目のジョブは基本的に、最初のジョブが処理する一連のジョブを作成するだけです。

現在、ワーカーが処理を終了したらレコードを破棄しています (着信と発信の両方)。サーバー、redis、または resque がダウンした場合に備えて永続化しないことを心配していますが、これが実際に良い設計パターンであるかどうかはわかりません。バニラ ルビー オブジェクトを使用してその ID をワーカーに渡すように提案されましたが、それがデータの信頼性にどのように影響するかはわかりません。では、これらすべての DB を作成するのはやり過ぎですか? バニラ ルビー オブジェクトを作成し、それらのオブジェクトの ID をワーカーに渡すだけでよいのでしょうか?

ありとあらゆる洞察が高く評価され、

ドリュー

4

1 に答える 1

4

最小限のデータをジョブに送信するアプローチが最善のアプローチであるように私には思えます。sidekiq wiki の「ベスト プラクティス」セクションを確認してください: https://github.com/mperham/sidekiq/wiki/Best-Practices

キューがバックアップされ、その間にその見積もりオブジェクトが変更された場合はどうなりますか? 状態を Sidekiq に保存せず、単純な識別子を保存します。perform メソッドで実際にオブジェクトが必要になったら、オブジェクトを検索します。

また、信頼性の面でも、ジョブ キューがダウンすることを心配する必要があります。それは起こります。障害に対してフォールト トレラントになるようにシステムを設計するか、より高い信頼性を保証するジョブ キュー システムを見つけます (ただし、それでも 100% のメッセージ配信率を保証できるキュー システムはありません)。Sidekiq pro は sidekiq (non-pro) よりも優れた信頼性を保証しますが、ジョブを事前に少し考えて設計すれば、クラッシュ後にデータベースをスキャンし、失われた可能性のあるジョブを再キューイングできるジョブを作成できます。 .

フォールトトレラントソリューションの設計にどれだけの労力を費やすかは、情報がポイントAからポイントBに到達することがどれほど重要かによって異なります:)

于 2015-02-08T02:47:34.163 に答える