httpで複数のサプライヤにメッセージを送信するシステムを再開発しています。オリジナルはperlスクリプトであり、再開発でもperlを使用する可能性があります。フォークするか、フォークしないのですか?
以前のシステムでは、すべてのパールスクリプトがすべて同時に実行されていましたが、各サプライヤには5つあります。メッセージがデータベースに格納されると、ランダムなスレッド番号(1-5)とサプライヤが選択されて、メッセージが2回処理されないようにし、テーブル/行をロックしないようにしました。さらに、大きなメッセージが送信されている間に発生した小さな送信を、大きなメッセージの送信が遅延させないようにするために、データベースに「Fair Queue Position」フィールドがありました。
時には1分あたりわずか数個のメッセージしか存在しませんが、他の時には数十万個のメッセージがダンプされることがあります。私は、すべてのスクリプトを実行してメッセージを常にチェックしているので、それを実行するためのよりよい方法があるか、古い方法が受け入れ可能かどうかを判断しようとしています。
私の考えることは、トラフィックの量に応じて必要なだけ多くの子プロセスを実行してフォークするというアイデアがありますが、実装する方法がわからないフェアキューイングが維持されている間に、各メッセージが1回だけ処理されるようにします。
親スクリプトがDBを更新して、どの子プロセスがそれを処理するかを示していると思いますが、元の方法よりも効率が悪くなることが懸念されます。フォークコードを書く経験はほとんどありません(私が最後にしたのは約15年前でした)。
メッセージキューを最適に処理する方法に関するご意見やガイドへのリンクがありがとうございます。
Gearmanや他のジョブサーバーを見ましたか? – jshy