著者：陳Guangsheng、ApacheのRocketMQコミッタ、DeFiBusの創設者、Micro Focusの銀行、技術専門家、関連するミドルウェアプラットフォームのプロダクトマネージャーは、IBMや華為のために働いていた、クラウドとビッグデータプラットフォームを担当する事業者。
オリジナルます。https：//mp.weixin.qq.com/s/nfJXGZb402iQnXFcN6TZCg
序文
2019年の終わりには、RocketMQ正式にリリース4.6.0のバージョンは、新機能「要求 - 応答」同期呼び出しを追加します。「要求 - 応答」この新機能では、実用的なマイクロ公共銀行の開発者によって経験、およびコミュニティへのフィードバックの要約です。次の記事意志の詳細新機能。
何を「要求 - 応答」があります
図1.1「要求 - 応答」モード
過去には、ミドルウェア、プロデューサーと消費者の消費量をメッセージングの使用は、メッセージとメッセージを送信するための唯一の責任がある、彼らは互いに通信していません。「要求 - 応答」モードでは、プロデューサーのメッセージが発行可能にした後、同期または非同期の消費消費者の形でRPCコールと同様の効果を達成するように、このメッセージを待ち、応答メッセージを返します。コール（呼RR）中の「要求 - 応答」を通して、プロデューサは、最初のメッセージがブローカを介して取得し、消費者の消費されたメッセージを送信し、このメッセージの消費後、消費者は、さらにメッセージのようなメッセージへの応答であろう最終的に返さプロデューサーを送り出します。説明を容易にするため、この場合にはプロデューサーがパーティーを要求する、メッセージて送信は「要求メッセージ」であると述べ、党と呼ばれる消費者に対するサービス、メッセージは次のように返され、「応答メッセージ。」
「要求 - 応答」モードがRocketMQが同期コールする能力を持っています、RocketMQの利用シナリオを展開し、それがより多くのアプリケーションの可能性を持っています。呼び出しチェーンの追跡および分析を行う情報の収集を容易にするため、原因ブローカーに保存されたメッセージの形で要求に;開発者は、RPCコールフレームワークを実装して、自分のニュース・サービス・バスを構築し、迅速にこの機能を使用することができますマイクロサービス部門、また、アプリケーション・シナリオの広い範囲を持っています。
「要求 - 応答」のロジックの実装
プロデューサー、ブローカー、消費者RR呼び出しの3つの役割に関連します。
実装ロジックのプロデューサー
2.1生産模式図。
1、増加要求メッセージに対応する識別子
要求メッセージを送信すると、RRを増加させる必要性を識別プロデューサーは、キーフィールドがCORRELATION_ID、REPLY_TO_CLIENTを持っているプロパティメッセージを呼び出しました。RR CORRELATION_ID一意このプロパティを介して要求メッセージRRを同じコールと応答メッセージと一致する要求を識別するために使用されます。プロデューサClientIdをある発信元にREPLY_TO_CLIENT識別要求メッセージ。
ちょうどプロデューサがプロデューサメッセージ送信ロジックの元と一致増加に対応するメッセージへのパーティの識別を要求します。
2は、メッセージに応答要求メッセージを待って終了しました。
各リクエスタの要求を行った後、RequestResponseFutureオブジェクトを作成し、CORRELATION_IDの鍵はResponseFutureTableに記録されています。リクエスト実行スレッドを定義してたCountDownLatch RequestResponseFutureによってブロックされて実現します。ときにバックプロデューサインスタンス、RequestResponseFutureに対応ResponseFutureTable CORRELATION_IDから取得した応答メッセージに応じて、活性化されたウェイクたCountDownLatchは、応答メッセージの処理を行うことにより、スレッドがブロックされ、応答メッセージ。
図2.2 RequestResponseFuture構造
ロジックの消費者の実現
2.3消費者の模式図。
消費者の通常の消費量は、唯一の要求メッセージの後、応答メッセージが作成され、に送信されました。応答メッセージを作成するプロパティがCORRELATION_ID失わないように提供されるツール、REPLY_TO_CLIENT他の識別と関連要求RRを作成するために使用されなければなりません。
ブローカーの実装ロジック
2.4ブローカーの模式図。
元の要求メッセージ処理ロジックのブローカ処理は同じであるが、応答メッセージが要求者にアクティブプッシュプッシュメッセージの形態です。消費者サービス側は、ブローカーが応答メッセージがReplyMessageProcessorプロセスと呼ぶことにする受信、Reply_topicに応答メッセージを送信します。プロセッサは、直接にプッシュされた応答メッセージを、対応する見つけるのClientID例とチャンネルプロデューサーでCommitLog応答メッセージ、および得られたClientID応答メッセージREPLY_TO_CLIENTに応じて要求当事者を、分類されます。
すべての応答メッセージは、「クラスタ名_REPLY_TOPIC」形式という名前のブローカーによって、Reply_topicにトピックトピックは自動的に作成され、このシステムが送信されます。メッセージは、要求元のクラスタに対応して送り返すことができるように、経路探索を行うためのトピックを返信、目的は、要求当事者への応答メッセージのバックはブローカーブローカーが接続されていることを確実にするためです。目的に応じて、アクティブプッシュメッセージを使用して、ブローカーは応答メッセージは、要求メッセージの正確なインスタンスに戻すことができるようにすることです。
金融シーンで「要求 - 応答」の練習
金融サービスビジネス要件は、着実に安定してサービスを利用できるの7x24時間を提供し、成功率、高速リカバリを確保するために迅速にノード障害を遮蔽するために十分な強さであることをフォールトトレランスをすることができるようにします。したがって、特定の使用シナリオに基づいて、マイクロ公共銀行は、安全で信頼性の高い金融レベルメッセージバスDeFiBusを構築するために、最寄りのサービス、ヒューズや他の特性を生きたアプリケーションを増大させます。
図3.1バスアーキテクチャ図
示されるように、底部にDeFiBusトップは、バス層、アプリケーション層、DB層です。
バス床2つの非常に重要なサービス、つまりGNSおよびGSLがあります。各顧客のデータの断片化のレベルを達成するために、顧客情報および計画DCNへの重量分布に応じてベース。GNSサービスは、DCNの顧客が存在するかを決定、データレベルで実行アドレッシング断片化されています。あなたはサービスが最初にあなたが現在DCNにアクセスしたいサービスを決定し、スライスのアドレッシングサービスレベルので、GSLサービスを訪問する呼び出すときに、サービスレベルでは、サービスは、さまざまな分野に展開されます。データスライスやサービス2次元から作られた、とGNSアドレッシングGSLスライス、自動ルーティングDCNのためのバスへの最終的な要求を行います。
GNSは、アドレッシングおよびGSLを介して要求し、受信DCN、要求は自動的にアプリケーション処理と呼ば対応するサービス、バスDCN領域にルーティングされる入口からサービスフローを決定します。これだけDCN内の各アプリケーション処理要求内DCN。DBアプリケーションは、DB層は一つの信頼性を向上させるためにコピー以上有していて、同一の予め割り当てられた主DCNにアクセスすることができます。
、様々な態様の最適化と変換を行うために、「要求 - 応答」を使用するためのDeFiBusの開発者サービスの可用性と信頼性を向上させるために。
高速かつ再試行に失敗しました
図急速な失敗と再試行3.2概略図
消費者の観点からは、それは完全なRRタイムアウトコールを通じてタイムアウト事業に相当します。RRは、内部メッセージへの呼び出しを含むことになるブローカがメッセージを表示されることがあり、障害があった場合、2回送信。このように、内部タイムアウトメッセージ送信サービスがタイムアウトに基づいて提供され、自動的に複数の障害リトライが十分な時間を残すために、より小さい値に調整されます。ビジネスタイムアウトが3秒であるような、タイムアウトが1秒にメッセージを送信するように設定されています。タイムアウトメッセージの送信を調整することにより迅速ブローカーのあら探しを。検索は、ブローカーを障害すると、プロデューサーはすぐに別のブローカー、および障害分離ブローカーを再試行します。アイソレーションの終了前に、プロデューサーはもはや孤立ブローカーにメッセージを送信しません。
ヒューズメカニズム
![]()
図の模式ヒューズ3.3
メッセージキューが堆積所定の閾値に達したときに機構手段を融合、キューにメッセージを送信しない、そのサービスインスタンスに対応するキューを一時的ヒューズです。
メカニズムを融合達成するために、キュー「キューの深さ」属性を高めます。メッセージキューの深さは、ブローカーが消費者を引っ張らないキュー上に堆積量を意味します。消費者が失敗したとき、または例外処理は、まずメッセージリクエスト、メッセージブローカ上に堆積され、その後、遅延されます引っ張っていき、その後、クライアントのフロー制御メカニズムをトリガーします。キューMessage Brokerが蓄積量が閾値を超えたことが判明した場合、キューは、ヒューズをマークされています。宛先がブローされている場合、メッセージ・キューを送信するプロデューサは、吹きキューは、応答コードを受信し、すぐにキューがヒューズ分離としてマークされている間、別のキューにメッセージの送信を再試行します。隔離を解除する前に、プロデューサーは、メッセージキューを送信し、さらに分離されません。
分離メカニズム
キューレベルの分離機構は、主機構プロデューサーリトライとサービスを融合するために使用されます。
3.4分離概略図。
ブローカーの障害は、消費者は、トリガメッセージ隔離メカニズムを引くとき。ネイティブRocketMQに実装され、消費者は、PullMessageServiceは、すべてのブローカー要求メッセージを引くために単一のスレッドで送信されます。これらが原因で、一時的なブロッキングのスレッドで、その結果、コネクションブローカーの要求または応答が遅いを確立するために、障害のブローカーノード障害、PullMessageServiceスレッドを持っている場合、それは他の通常のブローカーメッセージタイムアウト時間のかかるプロセスになり、さらには増加しました。したがって、開発者はプルメッセージは、実行時間が閾値を超える要求すると、代替スレッドメッセージを引っ張るために増加され、ブローカが単離される、すべての要求メッセージを引っ張ることをフラグが実行の代替スレッドに転送対応する全てPullMessageServiceを行っていることを確認通常のリクエストブローカー。スレッドによるコンシューマインスタンスブローカー老化プルメッセージには影響しない障害分離部分を確保します。
ダイナミックキューの膨張/収縮能
伸縮動的キュー・オブジェクト・キューとインスタンスの消費者一致数、例えば同じ消費者の各インスタンスのためのキューの数ということを負荷分散の数を収容します。均一なプロデューサー伝送の場合には、消費者のインスタンスが割り当てられていないような、キュー番号が不均衡が発生し、同じ負荷ではありません。
膨張/収縮と動的トピックを調整することによって達成受信ReadQueueNum WriteQueueNum構成。
拡張時には、最初の読み取り可能なキューの数を増やし、最初のリスニング消費者の完了を確認し、[可能な新しいプロデューサーは、メッセージキューを高めるために、このようなことを書き込みキューの数を増やします。
図拡張キュー概略図3.5
代わりに、キューボリュームの削減と拡張プロセスは、キューの書き込み可能回数を減らすために、収縮メッセージキューをオフに行くために、完成したメッセージの消費者の総消費量になるまでキューは、その後、キューの数は、完全な読み削減についてはもはやありません減容手順。
図キュー容量減少概略図3.6
ロードバランシング遷移
変更は新しい結果に古いを更新直接つながる負荷バランス調整RocketMQ消費者の結果は、AからBホッピングにプロセスです。消費者やブローカーは、より多くの時間、消費者のキュー番号の数だけでなく、負荷分散で取得したさまざまな消費者は、一貫性のない結果につながる、一貫性のない表示される場合がありますときにロードバランス。結果が矛盾している場合はリークが耳を傾け、繰り返し問題が発生聞くキュー。同期呼び出しシナリオでは、キューは、漏れにつながるキュー排水処理時間がかかり、高くても残業でメッセージを聞くために耳を傾け、コールをリードに失敗しました。
ロードバランシングロードバランシングの移行は、消費者は、負荷分散サイクルの終了まで結果をロードバランシングに残るし続けるか、新しい所有者がリッスンしている認識される時、結果の変更プロセスは、遷移状態を遷移状態を追加吸い込まときキュー、および古い結果を解放します。
図負荷遷移の概略3.7のバランスをとります
ライブへの応用市
高可用性とディザスタリカバリを実現するために、要件の一部は、サービスは、少なくとも2つのデータセンターに展開されます。データセンターは、すべての障害が利用できないサービスがある場合は、他の通常のデータセンターの例は、自動的に流れのこの部分を引き継ぐことができます。2つのデータセンターでの展開時間、およびサービス・リクエスタ側では2つのセンターが正常な場合、要求者は、最寄りのサービスの原則に従います展開される、要求はIDCが唯一の接続を維持するために心臓を横断し、同じIDCに送られます。同じIDCのサブスクリプション内のパーティサービスのプライオリティキューを聞きます。
図の概略通常3.8
そしてサービスが生存しなかったIDCの別の例がある場合にのみ、サービスはちょうどIDC IDCのキュー間で他を引き継ぐ場合。示すように、実施例2データセンター内の負荷分散におけるIDCとの最初のパーティションのキュー内の実施例1 1、2、3の全てハングデータセンター展開のアプリケーションBは、データセンタ2は、その後のチェックはキューことを発見した場合データセンタは、実施例1のデータセンタ2にキューが割り当てられます。その場合に、アプリケーションBが、無生存の例には、自動的にクロスIDC引き継ぎます。
3.9図を示すアプリケーション障害概略図。
ときブローカーハングのデータセンターでは、すべてのリクエスタがIDCを介して送信されます。示されるように、データセンタ2の後ブローカは、すべての適用例4〜6、失敗し、Aは、要求のこの部分は、実施例1〜3は、アプリケーションBのデータセンタ1によって処理され、近接サービスの原理によれば、データセンタに要求を送信しますブローカを確保に失敗した後に、データセンタ2を介して着信要求も正常に処理することができます。
図の障害概略図3.10ブローカー
IV結論
「要求 - 応答」モード - このホワイトペーパーでは、RocketMQ新機能について説明します。このモードでは、プロデューサメッセージを送信した後、消費者の消費戻るRPCコールと同様の効果に応答メッセージを待ちます。「要求 - 応答」モードでは、RocketMQはこれに基づいて、開発者はより多くの新機能を開発することができ、同期呼び出しに能力を持っていることができます。より良い金融シーンを提供するために、マイクロ公共銀行は、安全で信頼性の高い金融レベルのメッセージバスDeFiBusを構築するために、最寄りのサービス、ヒューズ及びその他の新機能を、ライブの使用を増加しています。マイクロフォーカス銀行は現在、開くフォローアップの断片化に対処するという点で、より一般的な実践の概要と結果の発表があるだろう、注意を理解するためにあなたのすべてを歓迎するためにDeFiBusによる結果のほとんどを持っています！
遂に
これらのデータのコンパイルを収集し、プログラマー群れ：2019一般的なJavaの質問は、私は公共の数の関心を歓迎し、PDF文書はほぼ500ページをまとめたもので直面します！
記事私は、ヨーヨーのような関心のポイントのように支援への感謝を忘れないでください！