序文
システムは複雑な分散、サービス及びその他のマイクロアーキテクチャ技術となった後は、システム内のアプリケーションを考慮する必要があります。特に、大量のデータの必要性データベース分割。
以下のような：ユーザーデータの登録、ボリューム、そしてあなたがする必要があるサブライブラリーサブテーブルを考えます
データベースは、その後、分割、頭痛の多くは、いったん取引問題となっている1。その後、我々は見てどのように表示されるようにされた問題に？
シーン
先着順の図、
分割後のデータは、それが上記のスキーマに類似しています
私たちは、たとえば上の図は、ユーザがデータ取ったサブライブラリーのサブテーブルの必要性について数千万いったんユーザのを、データベース上の3点の図は、各ライブラリーは、高可用性を確保します。
このアーキテクチャ設計、トランザクションは、問題が発生します、我々は特定のビジネスシナリオを見て：ユーザBへのユーザー転送100元、このビジネスは比較的簡単ですが、我々はする必要があり、特定の手順を分析します：
1、100元2を差し引くためにユーザAの口座は、ユーザBのアカウントの追加100
ロジックは、擬似コードに簡単です
コードは、私は、問題はないと感じ、比較的明確である我々は、問題の嘘を分析する必要がありますか？
問題
私たちは、二つのステップがあり、移転事業に見るユーザーは、Bプラスお金を操作している、ユーザーAがお金の操作を控除されます
あなたが同じデータベース内にある場合は、同時に、この2段階の操作は、いずれかの成功ていることを確認したり、同じ時間で成功することはできません。データの一貫性の移転というこの保証します。
ただし、クラスタ内のユーザAのクラスタA、B、ユーザBのデータがない場合は？ので、彼らは同じトランザクションではありませんで、成功したが、ユーザーBプラスお金など、ユーザー料金に失敗しました。それは、ピットしまう不完全なデータをアップ。
この問題は、に似ているマイクロサービスアーキテクチャの詳細になり、すべてのサービスであるため、独立したモジュール、すべての長距離通話同じトランザクションで、法律、取引に問題が発生します。
どのようにそれを解決するには？いくつかのオンラインプログラム、などがあります。2フェーズ・コミット、TCCなどは、一般的に存在し、最終的な一貫性方式は。使用方法をご紹介Today'll 解決するためのメッセージング・ミドルウェアを。その後、我々は、外観を調整追加する計画を置くミドルウェアメッセージング、そしてどのように最適化を参照してください。
ミドルウェアソリューションをメッセージング
図は、ミドルウェアの道、メッセージングの使用である非同期トラフィックの控除、およびお金のビジネスを成功充電後、メッセージングミドルウェアに「借方成功メッセージ」を送信し、追加のお金事業は「デビット成功メッセージ」を購読し、お金を追加するには、ユーザB
システムはどのように知っているユーザーBプラスお金？メッセージ本体であるソースアカウントと先口座のIDが含まれている、とお金の量は、
：この時間は、多分少し友人はまた、右、問題である必要があり、要求されますシーンワン：最初の充電後のメッセージ
最初の充電してから障害が発生した場合にメッセージを送信し、メッセージを送信し、そのユーザBは、お金を追加することはできません
その調整のためシーン2：控除後の最初のメッセージ、
デビット成功メッセージが正常に送信されますが、ユーザーAが電荷を失敗した、あなたは、ニュースサービス、ユーザーBプラスお金を購読するためにお金を追加することができます
私たちはされて問題、見るべきであると同時に、デビット、送信メッセージ、および成功または失敗を保証していませんが、一貫性のないデータが得られ。
RocketMQサービスプログラム
なぜなら、上記の問題の、RocketMqメッセージング・ミドルウェア・メッセージは、次の2つの段階に分けられる：準備フェーズ及び検証フェーズ準備段階（予備段階）
ステージはrocketmqにメッセージを送信する主であるが、メッセージが唯一commitlog内に格納され、しかしconsumeQueue見えない、このメッセージを見ることができない消費者側（サブスクリプション終了）です。
コミット/ロールバック相（検証フェーズ）
メインステージは、準備されたメッセージがある中でconsumeQueueに保存されている消費者は、このメッセージの最後に見ることができるように、メッセージを消費できます。
私たちは、次を説明するための図を使用します。
全体のプロセス：
1は、控除する前に、準備ができてメッセージ送信するために
2を、メッセージに成功し、準備を送信した後にローカルデビット取引の実行
3を、控除成功した後、その後、確認メッセージの送信
確認メッセージを見ることができます4、メッセージ終了（プラスマネー事業）を、このメッセージの消費、より多くのお金
確認メッセージの説明
注：上記の確認メッセージがメッセージが加入者を消費することができますコミットすることがあり、また、ロールバックのニュースすることができ、地元のデビット取引のつまり実装はロールバックメッセージを送信するために失敗し、メッセージは準備が削除され、加入者が消費することはできません
さんは分析してみましょう異常なシナリオを：
1異常：あなたは準備が失敗したメッセージを送信する場合は、次の手順では行くことはありません。これは正常である
2異常：あなたは予備的な成功メッセージを送信する場合は、ローカルトランザクションの実装が失敗したが、これは問題ではありません、このメッセージは終わりを消費する準備ができていないためビジネスの消費者の最後まで購読が実行されることはありません。
3異常：あなたは準備が成功したメッセージを送信する場合は、ローカル・トランザクションが成功したが、受信確認メッセージを送信できませんでした。これは問題であり、利用者Aが成功デビットので、お金のビジネスを追加しますが、確認メッセージに加入されていない、あなたはお金を追加することはできません。ここでは一貫性のないデータがありました。
RocketMqはそれを解決する方法であることを？
RocketMQをバックチェック
画像
RocketMqは、上記の問題を解決する方法、核となるアイデアは戻って、[状態]をチェックすることです準備メッセージで定期的にトラバースcommitlog RocketMqです。
メッセージをプロビジョニングすると、最終的になりますので、メッセージのロールバックになったり、メッセージをコミットメッセージがあれば、ローカルビジネスの実施状況を確認するために戻ってトラバースする準備ができているので、ロールバックに成功したローカルビジネスを実行せずに見つかった場合は、実行に成功したメッセージをコミット送信します。
上記異常3、メッセージを送信する準備ができて成功し、ローカルデビットトランザクションが成功したが、受信確認メッセージを送信できませんでした;のでRocketMqがメッセージに予備調査のバックを行います、戻って以降のチェックインの発見事業が成功裏に充電されている、その後、確認をコミットする」再発行メッセージ" ;ので、ビジネスにお金を追加し、このメッセージを購読することができ、最大。
実際には、ローカルトランザクションが存在しないため、このアイデアはまた、異常2の解決が正常に実行され、ビジネスをチェックするRocketMQバックは、全く正常な実行を発見した、ロールバックは確認メッセージが送信されます、メッセージが削除されます。
ビジネスの成功するかどうかを裁判官に戻って確認してください
ビジネスでのチェックバックの小さなパートナーは、ローカル・トランザクションが正常に実行されるかどうかを判断するには？
ローカル・トランザクションは、テーブルの多くを実行した場合、それは私たちが望むことではありません、それらのテーブルが正常にかどうかを判断するために行われるべきですか？これは、あまりにも多くの問題、ビジネスではなく、カップリングされています。
より良い方法はありますか？しているトランザクションテーブルを設計し、ビジネステーブルとトランザクションが同じローカルトランザクション内で結合トランザクションはローカル成功デビットの場合、トランザクションレコードはTransactionIdの状態がされている必要があり、「完了しました。」RocketMqバックがチェックするときは、ちょうど対応するチェックTransactionIdの状況は以下のように「完了」されているかどうか、特定のビジネスデータを心配せずに、。
著者：ロストERの
リンクします。https：//www.jianshu.com/p/286cac4625b6
出典：ジェーンの本は
、著者が著作権を保有しています。著者は認可商業転載してください接触、非商用の転載は、ソースを明記してください。
