レディスとバックグラウンドタスクのためにResqueを使用する点

Question

バックグラウンドタスクやワーカーに外部サービスを呼び出すなどのタスクを実行して、メインアプリケーションから時間のかかるタスクを削除するとなぜRedis To GoでResqueを使うのが良いのか分かりません。 Redis To Goは外部サービスにはなりません。その場合、Redis To Goのキューのキー/値を格納することは予測不可能で時間がかかる可能性がありますので、目的を破ることはありませんか？ To GoはRedisの上Resqueによって

編集は

私は混乱している理由は、私はすべての労働者を設定していなかったし、キューが生成された（そして労働者がなかったので、明らかに操作が待っていた）であります。だから私は最初のRedis To Goの書き込みがメインスレッドによって行われることを意味していると仮定しています。

Answer 1

バックグラウンドワーカーを使用する主な理由は、メインスレッドがタスクの実行に縛られていないためです。 Resqueを使用すると、タスクをメインスレッド外で実行することができます。これは多くの理由から有効です。最大の問題は、低速操作でメインスレッドがハングアップすることがなく、要求が完了するまですべての機能をブロックすることです。

Redis to Goは、リモートのRedisデータベースです。メインスレッドでは、500個のキーを変更する操作を行います。ローカルデータベースでは時間がかかりませんが、マルチコマンドを使用しない限り、各コマンドをサーバーに送信して応答を待つ必要があります。さて、いくつかのコマンドがあれば大したことはありませんが、リモートサーバで500回実行するのにはかなりの時間がかかります。いくつかの例の数字があります。ローカルで操作を実行するには5msかかります。ここでは、ジョブが迅速かつローカルで実行されるため、Resqueを使用する必要はありません。今、Redis to Goを使用して、LANの外に出なければなりません。各操作には5ms（0.005秒）かかります。そして、もし我々がそれらの500を行っていたら、.005 * 500は2.5秒です。今、それはデータベースを照会するために使用されている2.5秒です。主なスレッドは要求が完了するまでロックされます。 （これらの数値は完全にランダムです...より高くても低くてもかまいません）

ここでは、これらの操作はバックグラウンドで行われます。メインスレッドが実行されると、Resqueにジョブが追加されます。メインスレッドが実行されます。 Resqueはコマンドを受け取った順に実行します。現在、実行には2.5秒かかりますが、2.5秒はメインスレッドを保持していません。