rpc 呼び出しをリッスンし、それらをどこかにスタックし、処理し、応答する必要があります。問題は、彼らが来るとすぐに実行されないということです。応答は、受信した rpc 呼び出しごとの ACK です。問題は、多くのリッスン サーバーが呼び出しの同じスタックに書き込むことができるように設計したいということです。
私の目標は、できるだけ多くの通話を聞くことです。どうすればこれを達成できますか?
私の主なテクノロジーは Perl と node.js ですが、このタスクにはオープン ソース ソフトウェアを使用します。
どのような種類のジョブ キューでも、必要なことを実行できるようです。私は個人的に、この種の用途にRedisを使用することの大ファンです。Redis リストは挿入順序を維持するため、RPC 呼び出しをリッスンしている任意の数の Web サーバーから、RPC 呼び出し情報をリストの最後に単純にLPUSHできます。 (またはBRPOP ) それらをオフにして処理します。
Node.js は完全に非同期の IO を使用するため、RPC リスナーで多くの処理を行っていないと仮定すると (つまり、リクエストをリッスンし、ACK を送信し、Redis にプッシュするだけです)、私の推測では Node.これは非常に効率的です。
キューに Redis を使用する場合の余談: 壊滅的な障害が発生した場合にジョブが失われないようにする場合は、もう少しロジックを実装する必要があります。RPOPLPUSHドキュメントから:
パターン: 信頼できるキュー
Redis は、バックグラウンド ジョブやその他の種類のメッセージング タスクの処理を実装するためのメッセージング サーバーとしてよく使用されます。プロデューサ側で値をリストにプッシュし、RPOP (ポーリングを使用) を使用してコンシューマ側でこの値を待機する単純な形式のキューが取得されることがよくあります。
ただし、このコンテキストでは、取得したキューは信頼できません。たとえば、ネットワークに問題がある場合や、メッセージを受信した直後にコンシューマーがクラッシュした場合など、メッセージが失われる可能性があるため、まだ処理中です。
RPOPLPUSH (またはブロッキングバリアントの場合は BRPOPLPUSH) は、この問題を回避する方法を提供します: コンシューマーはメッセージを取得し、同時にそれを処理リストにプッシュします。メッセージが処理されると、処理リストからメッセージを削除するために LREM コマンドが使用されます。
追加のクライアントは、処理リストに長時間留まっているアイテムを監視し、必要に応じてタイムアウトしたアイテムをキューに再度プッシュする場合があります。