分散キューの問題の解決策は何ですか？
分散キューの問題を解決するためのさまざまな方法について、もっと知りたいと思っています。ですから、すでに存在している製品、サービス、実装、研究論文を知りたいのです。
実装は多くの課題に直面し、トレードオフを余儀なくされます。
- 強いまたは緩い順序付けがありますか？
- それはべき等を置いていますか？
- 単一のマシンに収まるキューよりも多くのキューを作成できますか？
- 単一のマシンに収まるよりも多くのデータをキューに入れることができますか？
- データが失われる前に何台のマシンがクラッシュする可能性がありますか？
- ネットスプリットを許容できますか？
- ネットスプリットが修正されたときに、データを自動的に調整できますか？
- クライアントがクラッシュしたときに配信を保証できますか？
- 同じメッセージが2回以上配信されないことを保証できますか？
- ノードが任意の時点でクラッシュし、戻ってきて、ジャンクを送信しないようにすることはできますか？
- ダウンタイムなしで実行中のクラスターにノードを追加またはノードから削除できますか？
- 稼働中のクラスターのノードをダウンタイムなしでアップグレードできますか？
- 異機種サーバーでも問題なく実行できますか？
- キューをサーバーのグループに「固定」できますか？ （例：「これらのキューはヨーロッパのデータセンターでのみ許可されています」）
- 可能であれば、データレプリカを少なくとも2つのデータセンターに配置できますか？
どの実装でもそのすべてに「イエス」と言うことができるという幻想はありません。さまざまな実装について聞くことに興味があるだけです。彼らがどのように働いているか、彼らが作ったトレードオフ、そしておそらく彼らが彼らの特定のトレードオフのセットを決定した理由。
また、上記のリストで見逃したかもしれない課題がある場合。
基本的なキューシステムを作成するのはかなり簡単ですが、すべての課題について前述したように、正しく実行することは別の問題です。私は、ソースコードを記述した自作のシステム、サードパーティのシステム、およびさまざまな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 。
それはべき等のputを持っていますか？いいえ、これが必要な場合にアプリケーション層に実装するのは簡単です。
1台のマシンに収まる数よりも多くのキューを作成できますか？はい。サーバーをクラスター化でき、複数のマシンを異なるキューでセットアップしたい場合は、どちらかからプルすることができます。
単一のマシンに収まるよりも多くのデータをキューに入れることができますか？はい、ほとんどのJMSプロバイダーは、何らかの種類のDB /永続ストレージを使用して、 JMSプロバイダーがダウンしてもメッセージがドロップまたは失われないようにします。
データが失われる前にクラッシュする可能性のあるマシンの数は？これはタイミングに関連しているため、答えるのが少し難しいです。ただし、JMSプロバイダーをクラッシュさせることができ、ディスクが破損していない場合は、ディスクが復旧し、最後のコミットを受け取った場所から開始します。これは、メッセージが2回配信される可能性があることを意味しますが、これを処理するようにアプリをコーディングする場合は問題ありません。各タイプ（プロデューサー、コンシューマー、またはJMSサーバー）が少なくとも1つあれば完了します。また、ディスクが停止した場合の冗長性のために、負荷/バランス/フェイルオーバーを使用することもできます。
ネットスプリットを拡大できますか？「ネットスプリット」の意味は理解できたと思いますが、完全にはわかりません。 JMSサーバーがクラスター化されている場合、サーバーの1つとの接続が失われると、別のサーバーにジャンプし、中断したところからピックアップします。はい。ただし、これらのタイプの状況でも、クライアントが接続を失った時点によっては、メッセージが重複する可能性があります。
ネットスプリットが修正されたときにデータを自動的に調整できますか？トランザクションセッションを使用している場合、コミットが呼び出されたメッセージのみが再配信されます稼働している既存のクライアントに送信します。
クライアントがクラッシュしたときに配信を保証できますか？はい、これはJMSの主な目標の1つです。配信の保証とは、メッセージがキューに入れられている場合、クライアントによる処理が保証されていることを意味します。
同じメッセージが2回以上配信されないことを保証できますか？トランザクションセッションが使用されている場合は、はい。これは、クライアントがメッセージを受け入れ、コミット/ロールバックを呼び出したことを意味します。コミットが呼び出されると、メッセージは再配信されません。
ノードが任意の時点でクラッシュし、復旧し、ジャンクを送信しない可能性はありますか？永続的なクラスター化キューがある場合。はい、クラスタ内の他のノードがメッセージを配信した場合、「ジャンク」を吐き出しません。承認されていないものは引き続き再配信できます。
ダウンタイムなしで実行中のクラスターにノードを追加または削除できますか？はい。
稼働中のクラスターのノードをダウンタイムなしでアップグレードできますか？これは私にとって答えるのが少し難しいですが、そうすることができると思います。
異機種サーバーで問題なく実行できますか？これは正確にどういう意味ですか？ほとんどのJMSプロバイダーは、さまざまなハードウェア、OSなどを使用する環境で非常に簡単に実行できることがわかりました。ただし、パフォーマンスを意味する場合、それはまったく別のことです。分散処理システムはいずれも、遅いノードによって悪影響を受ける可能性があります。キューとコンシューマーを実行している2つの8コアIntelサーバーがありました。これは合計で16コアであり、シングルコアマシンをコンシューマーとして追加したときよりも、これら2つのボックスのみを使用した方がパフォーマンスが向上しました。そのシングルコアマシンは非常に低速だったため、グリッド全体が2倍に遅くなりました。これはJMS自体には関係ありません。
サーバーのグループにキューを「固定」することはできますか？短い答えです。ヨーロッパのデータセンターにのみ存在するクラスターを実行し、そこでキューを構成する方法を考えることができます。次に、Spring構成で、そのキューおよび他のクラスターの他のキューを使用するようにコンシューマーをセットアップします。あなたはドキュメントを参照したいかもしれません：
http://activemq.Apache.org/clustering.html
可能であれば、少なくとも2つのデータセンターにデータレプリカを確実に配置できますか？繰り返しますが、クラスタリングのドキュメントを参照することをお勧めします。
繰り返しになりますが、JMSには、必要に応じて調整できる多くのオプションがあります。トランザクションセッションと永続キューを使用すると、パフォーマンスコストが発生します。私はすべてのベルとホイッスルをオンにするとパフォーマンスが10倍も影響するのを見てきました。これらの機能のいくつかをオフにすると、JBossMQを使用したときに約10,000メッセージ/秒を取得できましたが、オンにすると1000メッセージ/秒に低下しました。大きなドロップ。