基本的なキューイングシステムの作成は非常に簡単ですが、すべての課題について前述したように、正しく実行することは別の問題です。ソースコード、サードパーティシステム、およびさまざまなJMSプロバイダーを記述した自作のシステムを使用しました。JMS（Java Messaging Service）は、これまでに出会った中で最も完全なソリューションです。あなたが求めるものの多くはJMSで利用可能です。私のお気に入りのJMSプロバイダーはActiveMQです。無料で、パフォーマンスが高く、インストールが簡単で、さらに重要なことに、Springを使用してアプリに簡単に組み込むことができます。JMSプロバイダーは、要求されたすべてをすぐに提供するわけではありませんが、アプリケーションで必要になったときに必要なものの多くを処理するためのツールセットを提供します。あなたがリストしたすべてのものを必要とする多くのアプリケーションは見つかりませんでした。順序は重要ではないかもしれません（そうでない場合は最適です）。
http://activemq.apache.org/what-open-source-integration-solution-works-best-with-activemq-.html
それは強いか、順序を失いますか？はい。プログラムのニーズに応じて両方があります。ここでは詳細は以下のとおりです。http://activemq.apache.org/total-ordering.html。
べき等を入れていますか？いいえ。ただし、これが必要な場合、アプリケーション層に実装するのは簡単です。
単一のマシンに収まるものよりも多くのキューを使用できますか？はい。サーバーをクラスター化でき、異なるキューを使用して複数のマシンをセットアップしたい場合は、どちらからでもプルできます。
単一のマシンに収まるデータよりも多くのデータをキューに入れることができますか？はい。ほとんどのJMSプロバイダーは、JMSプロバイダーがダウンした場合にメッセージがドロップまたは失われないように、何らかのDB /永続ストレージを使用する必要があります。
データを失う可能性がある前に、何台のマシンがクラッシュする可能性がありますか？ これはタイミングに関連しているため、答えるのが少し難しくなります。ただし、JMSプロバイダーをクラッシュさせることができ、ディスクが破損していない場合は、ディスクが復旧し、最後のコミットを受け取った場所から開始します。これは、メッセージが2回配信される可能性があることを意味しますが、これを処理するようにアプリをコーディングすれば問題はありません。各タイプ（プロデューサー、コンシューマー、またはJMSサーバー）が少なくとも1つあれば、完了します。ディスクが使用できなくなった場合の冗長性のために、ロード/バランス/フェイルオーバーを使用することもできます。
ネット分割を容認できますか？「ネット分割」の意味は理解できていると思いますが、完全にはわかりません。JMSサーバーがクラスター化されていて、サーバーの1つとの接続が失われた場合、別のサーバーにジャンプし、中断したところからピックアップすることになります。はい。ただし、このような状況でも、クライアントが接続を失った時点に応じて、メッセージが重複する可能性があります。
ネット分割が修正されると、自動的にデータを調整できますか？トランザクションセッションを使用している場合は、コミットされているメッセージのみが、稼働中の既存のクライアントに再配信されます。
クライアントがクラッシュした場合に配信を保証できますか？はい、これはJMSの主要な目標の1つです。配信の保証とは、メッセージがキューに入れられた場合、クライアントによる処理が保証されることを意味します。
同じメッセージが複数回配信されないことを保証できますか？トランザクションセッションが使用されている場合は、はい。これは、クライアントがメッセージを受け入れ、コミット/ロールバックを呼び出したことを意味します。コミットが呼び出されると、メッセージは再配信されません。
ノードは任意の時点でクラッシュし、戻ってきて、ジャンクを送信できませんか？永続的なクラスター化されたキューがある場合。はい、クラスタ内の他のノードがメッセージを配信した場合、「ジャンク」を吐き出しません。まだ承認されていないものはすべて再配信できます。
ダウンタイムなしで実行中のクラスターにノードを追加、またはノードからノードを削除できますか？ はい。
ダウンタイムなしで実行中のクラスターのノードをアップグレードできますか？これは答えるのが少し難しいですが、そうすることができると信じています。
異種サーバーで問題なく実行できますか？これはどういう意味ですか？ほとんどのJMSプロバイダーは、異なるハードウェア、OSなどを使用する環境で実行するのが非常に簡単であることがわかりました。パフォーマンスを意味する場合、それはまったく別のことです。分散処理システムは、遅いノードによって悪影響を受ける可能性があります。キューとコンシューマーを実行している2 8コアIntelサーバーがありました。これは16コアで、これら2つのボックスのみを使用することで、シングルコアマシンをコンシューマとして追加したときよりもパフォーマンスが向上しました。そのシングルコアマシンは非常に低速であったため、グリッド全体の速度が2倍に低下しました。これはJMS自体とは関係ありません。
サーバーのグループにキューを「固定」できますか？短い答えはい。欧州のデータセンターにのみあるクラスターを実行し、そこでキューを構成する方法を考えることができます。次に、spring configで、そのキューと他のクラスターの他のキューを消費するようにコンシューマーをセットアップします。次のドキュメントを参照してください。
http://activemq.apache.org/clustering.html
可能であれば、少なくとも2つのデータセンターにデータレプリカを配置することを確認できますか？繰り返しになりますが、クラスタリングのドキュメントを参照することをお勧めします。
繰り返しますが、JMSには、必要に応じて微調整できる多くのオプションがあります。トランザクションセッションと永続キューを使用すると、パフォーマンスコストが発生します。すべての添え字をオンにすると、パフォーマンスに10倍も影響することがわかりました。JBossMQを使用してこれらの機能の一部をオフにした場合、約10,000メッセージ/秒を取得できましたが、それらをオンにすると1000メッセージ/秒になりました。大きなドロップ。