どのメッセージキューを選択する必要がありますか（Linuxで実行する必要があります）
Linux用のオープンソースのメッセージキューはたくさんありますが、何をすべきかを決めるのに助けが必要です。
私の問題は単純です-処理する必要のあるファイルのリストが送信されます。各ジョブを分割することはできませんが、それらは自己完結型であり、複数のコンピューターに分散させることができます。
メッセージキューを使ってこれを解決しようと思っています。複数のクライアントが中央キューにメッセージを送信します。各キューには、現在のジョブの処理が終了したときにそのキューからジョブを取得する多数のサブスクライバーがあります。
理想的には、次の品質が必要です
- メッセージキューは、シャットダウン/再起動の場合に未処理のメッセージを保存できる必要があります
- ジョブは単一のサブスクライバーのみが処理できます（重複するジョブは必要ありません）
- サブスクライバーは、別のサブスクライバーのセットによって処理される独自のジョブを送信できる必要があります。
誰もが使いやすいメッセージキューを提案できますか？
RabbitMQとZeroMQがありますが、afaik ZeroMQは、クラッシュした場合に未処理のメッセージを保存しません。どちらもオープンソースであり、オープンメッセージングプロトコルであるAMQPを使用しています。
私は最近のアーキテクチャ計画でこれを経験しました。
基本的に..「メッセージキュー」..すべてに、次の両方の特性を同時に保証するものがないという問題があります。
メッセージの受信を保証
重複するメッセージがないことを保証します
したがって、現在オープンソースソリューションとして提供されているものは、これら2つの必須タスクを同時に実行することはできません。（IBMで50Kを費やしたい場合を除く）
cassandraはクォーラムの読み取り/書き込みでこれを処理できるが、大規模な同時実行性を考慮していないことを示唆する素晴らしいビデオが1つあります：/
結局、私は[〜＃〜] redis [〜＃〜]に落ち着きました（私はクラスター化されたソリューションを避けました）
シンプルかつ効果的にシングルスレッド..（重複を避けるため）キューワーカーにアトミックBlockonPopまたはマルチキャストpubsubhubbub機能を提供します。
到着しなかった「失われた仕事」を管理するために、自家製のソリューションが開発されました。（信頼性）
実はとてもシンプルなモデルです。メンテナンスも簡単そうです。
お役に立てれば..
Beanstalkd は、基本的なニーズに一致する単純なジョブキューシステムです。キュー自体に障害が発生した場合、バイナリログを使用して永続性を提供でき、一度に1人のワーカーのみがジョブを持つことができますが、ジョブもタイムアウトで設定されるため、削除されない場合、またはその前にキューに戻される場合、それらは再び利用可能になります（労働者の問題の場合）。
ローカルユーザーグループに対して beanstalkdでのプレゼンテーション を実行しました。これには、さらに情報があります。
非常に簡単に使用できるのはmemcacheqです。これは、memcachedと同じAPIを使用するため、同じライブラリを使用できます。 BDBバックエンドを使用するため、RAMではなくmemcachedのようになります
私はこのタイプのタスクにBeanstalkdを使用しました。再起動の間にジョブをディスクに永続化するように構成できます。重複を削除しやすくするために、ジョブ識別子をmemcachedにプッシュしました。ジョブがすでにmemcacheにある場合は、Beanstalkdでキューに入れるのではなく、削除してください。