Resque.enqueue_in(7.days, JobClass)
Resqueおよび resque-scheduler gemを使用して、Rails で長時間保留されているタスク (例: ) に Resque を使用することはどのくらい安全ですか? インスタンスが Heroku で実行されていることに言及してください。キューを失う可能性はどのくらいですか?
1 に答える
半持続性
私のコメントによると、(Resque が使用する) Redis を使用することの欠点は、ダウンタイムの可能性です。
Web アプリの「RAM」として、Redis は半永続的なデータを保存します。これは基本的に、動作中にのみデータを保持することを意味します。ダウンタイムがあると、キューが失われます。
これがあなたの質問の核心です -
キューを失う余裕はありますか?
答えはあなたが答えられる唯一のものです。
ただし、私が検討するいくつかの要因があります。
*Redis は完全なデータベースではありません... JSON
key:value
ペア ストアです。つまり、これは、特定の時間にデータのスニペットを使用するための単純なメカニズムを提供するためにのみ使用する必要があります。例として、Redis を使用してユーザーの ID をシステムの 1 つに保存します。
これは、単純な ID やその他の基本データよりも多くのデータを Redis 内に保存している場合、それを正しく使用していることを意味します。
あなたのキューはどれくらい重要ですか?
他のアプリと同様に、できるだけ多くのユーザー データを保持する必要があります。
ただし、違いは、キューがシステムにとってどれほど重要かということです。
ホテル予約システムの例を挙げました。おそらく、送信する必要がある「ようこそ」メール、ゲストがホテルを見つけるのに役立つ「道順」メールなどがあります。これらは「ミッションクリティカル」ですか?
以前にメール マーケティング システムを設計したことがあります。そのための待ち行列システムは広範でした。しかし、重要なのは「キュー」ではなく、関連するすべての関連データでした。
したがって、データをデータテーブルに保存し、Redis のみを使用して、送信される内容と送信時期の純粋なキューを保存しました。その後、毎分いくつかのスクリプトを実行し (詳細は忘れました)、Redis キューを通過しました。
要するに、適切なデータをテーブルに保存し、必要なときにのみリクエストを処理することを強くお勧めします。
キューの根底にあるのは、キューがダウンした場合にキューを再構築できる必要があるということです。値をredisだけに保存している場合、これが大きなボトルネックになることがわかります。
DB にアクセスすることは、長い目で見れば得られるデータに見合うだけの価値があります。