ActiveMQの高可用性の実現

1つは、ActiveMQ高可用性アーキテクチャ

ActiveMQの高可用性アーキテクチャは、マスター/スレーブモデルに基づいています。ActiveMQは、HAを構成するための合計4つの構成スキームを提供します。その中で、Shared Nothing Master / Slaveはバージョン5.8以降は使用されなくなり、ActiveMQ5.9バージョンはZookeeperに基づくReplicateLevelDB StoreHAスキームを導入します。

公式ウェブサイトのヒント:

(実際、公式の推奨事項は、activeMQに埋め込まれたKahaDBデータベースを使用することです。)

 

次に、マスター/スレーブアーキテクチャの構成の説明

①共有なしマスター/スレーブ  

このアーキテクチャの最大の機能は次のとおりです。

1)マスターとスレーブはそれぞれ永続メッセージを個別保存し、データを共有しません。

2)マスターが永続的なメッセージを受信した場合、ACK確認をプロデューサーに送信する前に、マスターはスレーブに同期(同期)する必要があります

3)マスターのみがクライアントの要求に責任があり、スレーブはクライアントの要求を受信しません。スレーブはマスターに接続されており、メッセージのバックアップを担当します。

4)マスターに障害が発生した場合、スレーブには2つの方法で対処できます。❶自分でマスターになる;❷閉じる(サービスを停止する)---特定の構成によって異なります。

5)マスターとスレーブの間で「スプリットブレイン」現象が発生する場合があります。たとえば、マスター自体は正常ですが、マスターとスレーブ間のネットワークに障害が発生します。ネットワーク障害により、スレーブはマスター自体になるため、マスターがダウンしていると見なします(構成によるとshutdownOnMasterFailure)。この時点で、クライアントには2つのマスターが存在します。

6)スレーブは、マスターに接続された後にのみメッセージを同期できます。スレーブがマスターに接続される前に、プロデューサーからマスターに送信されるメッセージはスレーブに同期されません。これは構成可能(waitForSlave)パラメーターです。スレーブも開始された場合にのみ、マスターはTransportConnectorの初期化を開始します。クライアントのリクエスト(プロデューサーのリクエスト)を受け入れる

7)マスターまたはスレーブのいずれかがダウンした場合、それらの間の非同期メッセージは自動的に同期できません。現時点では、非同期メッセージは手動でのみ復元できます。つまり、「ActiveMQは、障害回復期間中にマスターとスレーブがデータを自動的に同期できるようにする効果的な手段を提供しません」

8)永続的でないメッセージの場合、それらはスレーブに同期されません。したがって、マスターがダウンすると、永続的でないメッセージは失われます。

 

ShareNothing高可用性構成について少し理解します。

❶上記のステップ2)から、プロデューサーがマスターにメッセージを送信した後、マスターはメッセージをスレーブに同期してから、確認応答ACKをプロデューサーに返す必要があることがわかります。したがって、プロデューサーへの応答には一定の遅延があります。

高速応答を保証するために、つまりプロデューサーがマスターにメッセージを送信した後、マスターはメッセージを受信した直後にプロデューサーに応答し、メッセージをバックグラウンドでスレーブに同期します。これにより、データの不整合の問題が発生します。

なぜなら、マスターがメッセージを受信して​​すぐにプロデューサーに応答した場合、マスターは将来スレーブと同期する前にダウンします。メッセージがまだマスターのメモリにある場合、メッセージはその後失われます。マスターが倒れます マスターがプロデューサーからメッセージを受信し、最初にディスクに書き込み、次にACKをプロデューサーに返し、バックグラウンドでスレーブと同期する場合、マスターは各メッセージが正常に同期されたかどうかをマークする必要があります。スレーブ、メッセージがまだ同期されていない場合、マスターが再起動して回復した後、スレーブはすぐに同期する必要があります。スレーブがマスター上のすべてのメッセージを正常に同期した場合にのみ、スレーブはオンラインになります。これも自動フェイルオーバーを実現できません。

優れた高信頼性ソリューションについて: HadoopHAのQJMメカニズムを参照してくださいコアは次のとおりです。1)ほとんどのマシンの障害しか許容できないクラスターが使用されます。2)データはほとんどのマシンにのみ書き込まれ、クライアントの迅速な応答機能を保証するために確認が返されます。3)データはバックグラウンドマシンのすべてのクラスターに非同期的に同期されるため、高可用性が保証されます。

❷ここのマスタースレーブメカニズムでは、スレーブクラスターではなくスレーブが1つだけあります(上の構造図を参照)。マスターのダウンタイムまたはスレーブのダウンタイムは、サービス全体に大きなリスクを引き起こします。HadoopHAのように「ほとんどのマシンが故障するだけ」、つまり実際の高可用性が達成されないという保証はありません。

❸「デュアルマスター」の問題もあるかもしれません。それが前述の「スプリットブライアン」現象です。

②共有データベースマスター/スレーブ

 これは非常に一般的に使用されるアーキテクチャです。「共有ストレージ」とは、マスターとスレーブの間でデータが共有されることを意味します。

衝突を避ける方法は?データベーステーブルの排他ロックを競合することにより、マスターのみがロックを持ち、ロックを取得していないものが自動的にスレーブになります。

ActiveMQメッセージブローカーはリレーショナルデータベースを使用し、テーブルの排他ロックを取得して、
他のActiveMQブローカーがデータベースに同時にアクセスできないようにします。

 

「共有ストレージ」の場合、永続メッセージのみが「共有」されます。非永続メッセージの場合、それらはメモリに保持されます。構成(forcePersistencyModeBrokerPlugin persistenceFlag)プロパティを使用して、すべてのメッセージを強制的に永続化できます。

マスターがダウンすると、スレーブは自動的にサービスを引き継ぎ、マスターになることができます。データは共有されるため、マスターとスレーブ間でデータをコピーして同期する必要はありません。スレーブは、競争ロックを通じて誰がマスターであるかを決定します。

 

③共有ファイルシステムのマスター/スレーブ

この方法は、基本的に共有データベースストレージの原則と同じであるため(ファイルシステムにもファイルロックがあります)、詳細は説明しません。

 

④最寄りの 複製レベルDBストア

 1)この方法では、Zookeeperを使用してマスターを選出します。選挙を実施するには、「参加者」の過半数が必要です。レプリケートされたLevelDBストアには複数のブローカーがあるため、複数のブローカーの1つがマスターになり、他のブローカーがスレーブになります。マスターのみがクライアントから接続を受信し、スレーブはマスターに接続してマスターで(同期、非同期)データ受信する責任があります 

選択されたマスターブローカーノードが起動し、クライアント接続を受け入れます。
他のノードはスレーブモードになり、マスターを接続して永続状態を同期します。

上記も示しています。各ブローカーはデータを個別に保存しますマスターが新しいデータをスレーブにコピーしたいからです。この観点から:このメソッドを「共有ストレージ」と呼ぶのは少し不適切です。

 

2)クォーラムメカニズムの別のアプリケーション

ブローカーが3人いるとすると、マスターを選出する前に、選挙中に少なくとも2人のブローカーが(ほとんど)同意する必要があります。さらに、新しいメッセージがほとんどのブローカーにコピーされたときにのみ、ACKをプロデューサーに返す必要があります。他のいくつかのブローカーは、バックグラウンドで非同期新しいメッセージ複製できます。

ディスクへの同期を必要とするすべてのメッセージング操作は、更新がノードのクォーラムに複製されるのを待ってから完了します。
したがって、replicas = "3"を使用してストアを構成すると、クォーラムサイズは(3/2 + 1)= 2になります。
マスターは更新をローカルに保存し、他の1つのスレーブが更新を保存するのを待ってから成功を報告します。

例:合計3つのブローカー、1つのマスター、および2つのスレーブがあります。新しいメッセージがマスターに到着すると、マスターは、メッセージが正常に送信されたことを確認するために、プロデューサーにACKを送信する前に、メッセージをスレーブの1つに同期する必要があります

残りのスレーブは、新しいメッセージをバックグラウンドで非同期コピーできます。さらに、スレーブのダウンタイムに耐えることができます。(ほとんどのブローカーのダウンタイムしか許容できません)

この設計要件により、クラスター内のメッセージの信頼性を確保できます。(レプリカ/ 2 + 1)ノードに物理的な障害が発生した場合にのみ、メッセージが失われるリスクがあります。さらに、メッセージをすべてのスレーブに同期する必要はなく、ほとんどのブローカーに同期するだけでよいため、ある程度の応答性も向上します。

 

3)誰がマスターで誰がスレーブであるかを判断するためにどのような基準が使用されますか?

[選択は、「メッセージログ」の「バージョンスタンプ」と「重み」のサイズに応じて決定されます。つまり、「バージョンスタンプ」(最新のデータ)が大きいほど、ブローカーの重みが大きいほどです。最初にマスターになり、他のブローカーがスレーブとして機能し、マスターに従います。

 

ブログリファレンスhttps//blog.csdn.net/weixin_33896069/article/details/85820560

 

 

 

 

 

 

おすすめ

転載: blog.csdn.net/m0_46405589/article/details/115177626