私は最近、マイクロサービスでのデータの整合性の特性について学び、将来の参照のために、マイクロサービスでのデータの整合性を確保するための現在のいくつかの実装方法を次のようにまとめました。この記事は、マイクロサービスに基づくデータ整合性の実装に関する一般的な紹介を目的としたものであり、詳細には開発されていません。具体的な実装方法については、引き続き学習します。
従来のアプリケーショントランザクション管理
ローカルトランザクションの
マイクロサービスにデータの整合性を導入する前に、トランザクションの背景を簡単に紹介します。従来のスタンドアロンアプリケーションは、データソースとしてRDBMSを使用します。アプリケーションはトランザクションを開始し、CRUDを実行し、トランザクションをコミットまたはロールバックします。すべてローカルトランザクションで発生し、トランザクションサポートはリソースマネージャー（RM）によって直接提供されます。ローカルトランザクションでは、データの一貫性が保証されます。
分散トランザクション
2フェーズコミット（2PC）
アプリケーションが徐々に拡張されると、アプリケーションは複数のデータソースを使用しますが、現時点では、ローカルトランザクションはデータ整合性の要件を満たせなくなります。複数のデータソースへの同時アクセスのため、トランザクションは複数のデータソースにわたって管理する必要があり、分散トランザクションは歴史的な瞬間に発生します。これらの中で最も一般的なのは2フェーズコミット（2PC）で、分散トランザクションはトランザクションマネージャ（TM）によって管理されます。
2フェーズの提出は、準備フェーズと提出フェーズに分かれています。
2フェーズコミット
2フェーズコミットロールバック
ただし、2フェーズコミットはデータの一貫性を完全に保証できず、同期ブロッキングの問題があるため、3フェーズコミット（3PC）の最適化バージョンが発明されました。
三相提出（3PC）
3フェーズ
送信ただし、3PCはほとんどの場合にデータの一貫性しか保証できません。
マイクロサービスでのトランザクション管理
では、分散トランザクション2PCまたは3PCは、マイクロサービスでのトランザクション管理に適していますか？答えはノーです、3つの理由があります：
-
マイクロサービス間に直接データアクセスがないため、マイクロサービスは通常RPC（Dubbo）またはHttp API（Spring Cloud）を介して相互に呼び出し、TMを使用してマイクロサービスのRMを管理することはできなくなりました。
-
マイクロサービスによって使用されるデータソースのタイプは完全に異なる場合があります。マイクロサービスがトランザクションをサポートしないNoSQLなどのデータベースを使用する場合、トランザクションについて話す方法はありません。
-
マイクロサービスが使用するデータソースがすべてトランザクションをサポートしている場合でも、大きなトランザクションを使用して多くのマイクロサービスのトランザクションを管理すると、この大きなトランザクションが維持される時間は、ローカルトランザクションよりも数桁長くなります。このような長期間のトランザクションとクロスサービストランザクションは、多くのロックとデータの利用不可を生成し、システムパフォーマンスに深刻な影響を与えます。
従来の分散トランザクションは、マイクロサービスアーキテクチャではトランザクション管理要件を満たせなくなっていることがわかります。したがって、従来のACIDトランザクションを満たすことは不可能であるため、マイクロサービスでのトランザクション管理は、新しいルールベース理論に従う必要があります。
BASE理論はeBayアーキテクトのDan Pritchettによって提案されました。BASE理論はCAP理論の拡張です。コアとなる考え方は、強い整合性が達成できない場合でも、アプリケーションが適切な方法で最終的な整合性を達成できることです。BASEは、基本的に利用可能な、ソフトステート、および結果整合性を指します。
-
基本的な可用性：障害が発生したときに分散システムがその可用性の一部を失うことが許可されているという事実を指します。つまり、コアは使用可能です。
-
ソフト状態：システムに中間状態を許可します。中間状態はシステムの全体的な可用性に影響しません。一般に、分散ストレージにはデータのコピーが少なくとも3つあり、異なるノード間でコピーの同期を許可する際の遅延がソフト状態の実施形態です。
-
最終的な整合性：最終的な整合性とは、システム内のすべてのデータコピーが、一定期間後に最終的に整合性のある状態になることを意味します。弱い整合性は強い整合性の反対であり、最終的な整合性は弱い整合性の特殊なケースです。
BASEの最終的な整合性は、マイクロサービスでのトランザクション管理の基本的な要件です。マイクロサービスベースのトランザクション管理はどちらも強力な整合性を実現できませんが、最も重い整合性を保証する必要があります。では、マイクロサービスでのトランザクション管理の最終的な一貫性を保証できる方法はどれですか？実装原理によれば、イベント通知タイプと補正タイプの2つの主なタイプがあり、そのイベント通知タイプは、信頼できるイベント通知モードとベストエフォートに分類できます通知モードと補正タイプは、TCCモードとビジネス補正モードに分類できます。これらの4つのモードは、マイクロサービスでデータの最終的な整合性を実現できます。
マイクロサービスでデータの整合性を実現する方法
信頼性の高いイベント通知モード
同期イベントの
信頼性のあるイベント通知モードの設計概念は比較的理解しやすいです。つまり、マスターサービスがイベント（多くの場合、メッセージキュー）を介してスレーブサービスに結果を渡し、スレーブサービスはメッセージを受信してビジネスを完了した後に消費します。 、マスターサービスとスレーブサービス間のメッセージの一貫性を実現するため。最初に考えられる最も簡単なことは、同期イベント通知です。ビジネス処理とメッセージ送信は同期的に実行されます。実装ロジックについては、以下のコードとタイミング図を参照してください。
-
public void trans() { -
try { -
// 1. 操作数据库 -
bool result = dao.update(data);// 操作数据库失败，会抛出异常 -
// 2. 如果数据库操作成功则发送消息 -
if(result){ -
mq.send(data);// 如果方法执行失败，会抛出异常 -
} -
} catch (Exception e) { -
roolback();// 如果发生异常，就回滚 -
} -
}
上記のロジックはシームレスに見えます。データベース操作が失敗した場合、メッセージは送信されずに終了します。メッセージの送信に失敗した場合、データベースはロールバックされます。データベース操作が成功し、メッセージが正常に送信された場合、ビジネスは成功し、メッセージはダウンストリームコンシューマーに送信されます。次に、慎重に検討した結果、同期メッセージ通知には実際には2つの欠点があります。
マイクロサービスのアーキテクチャでは、ネットワークIOの問題やサーバーのダウンタイムの問題が発生する可能性があります。これらの問題がタイミング図のステップ7で発生した場合、メッセージの配信後にメインサービス（ネットワークの問題）に正常に通知されないか、送信を続行できません。トランザクション（ダウンタイム）の場合、マスターサービスはメッセージ配信が失敗したと見なし、マスターサービスビジネスをロールオーバーしますが、実際にはメッセージがスレーブサービスによって消費されているため、マスターサービスとスレーブサービスのデータに不整合が生じます。特定のシーンは、次の2つのタイミング図で確認できます。
イベントサービス（この場合はメッセージサービス）がビジネスに結合されすぎています。メッセージサービスが利用できない場合、ビジネスは利用できません。イベントサービスは、ビジネスから切り離して独立して非同期に実行するか、ビジネスの実行後に最初にメッセージを送信してみてください。メッセージの送信に失敗した場合は、非同期にダウングレードされます。
非同期イベント
ローカルイベントサービス：
上記の同期イベントで説明されている同期イベントの問題を解決するために、非同期イベント通知モデルが開発されました。ビジネスサービスとイベントサービスの両方が分離され、イベントは非同期で実行されます。別個のイベントサービスがイベントの信頼性を保証します投稿。
非同期イベント通知-ローカルイベントサービス
ビジネスが実行されると、イベントは同じローカルトランザクションのローカルイベントテーブルに書き込まれ、イベントは同時に配信されます。イベントが正常に配信されると、イベントはイベントテーブルから削除されます。配信が失敗した場合、イベントサービスを使用して定期的かつ均一に失敗した配信イベントが処理され、イベントが正しく配信されてイベントテーブルからイベントが削除されるまで再配信が実行されます。この方法により、イベント配信の効果が最大限に保証されます。最初の配信が失敗した場合、非同期イベントサービスを使用して、イベントが少なくとも1回配信されるようにすることもできます。
ただし、信頼性のあるイベント通知を確実にするためにローカルイベントサービスを使用するこの方法には欠点もあります。つまり、ビジネスはまだイベントサービスに結合されています（最初の同期配信時）。さらに深刻なことに、ローカルトランザクションにはデータベースに圧力をかける追加のイベントテーブルの操作を担当します。同時実行性の高いシナリオでは、各ビジネスオペレーションが対応するイベントテーブルの操作を生成するため、データベースの使用可能なスループットはほぼ半分になり、これは間違いなく不可能です承諾しました。信頼できるイベント通知モデルがさらに開発されたのはこのためです。外部のイベントサービスが人々の目に表示されます。
外部イベントサービス：
外部イベントサービスは、ローカルイベントサービスをさらに一歩進め、イベントサービスをメインビジネスサービスから分離します。メインビジネスサービスは、イベントサービスに強く依存していません。
非同期イベント通知-外部イベントサービス
ビジネスサービスは、送信前にイベントをイベントサービスに送信します。イベントサービスはイベントを記録するだけで、送信しません。ビジネスサービスは送信またはロールバック後にイベントサービスに通知し、イベントサービスはイベントを送信するか、イベントを削除します。イベントサービスは定期的にすべての送信されていないイベントを取得し、ビジネスシステムにクエリを送信してイベントを送信するか削除するかを決定するため、送信またはロールオーバー後のビジネスシステムのダウンタイムについて心配する必要はありません。イベント。
外部イベントはビジネスシステムとイベントシステムを切り離すことができますが、追加のワークロードももたらします。外部イベントサービスは、ローカルイベントサービスと比較して2倍のネットワーク通信オーバーヘッド（送信前、送信後/ロールバック）を持っています。同時に、ビジネスシステムは、未送信のイベントのステータスを判別するために、イベントシステムに個別のクエリインターフェイスを提供する必要もあります。
高信頼性イベント通知モードに関する注意：
高信頼性イベントモードでは、2つの注意点があります：1.イベントの正しい送信; 2.イベントの繰り返し消費。
非同期メッセージサービスを使用すると、イベントを正しく送信できます。ただし、イベントは繰り返し送信される可能性が高いため、コンシューマーは同じイベントが繰り返し消費されないようにする必要があります。つまり、イベント消費のべき等性を保証する必要があります。
イベント自体が注文ステータスの通知（注文、支払い、発送など）のようなべき等のステータスイベントである場合、イベントの注文を決定する必要があります。通常はタイムスタンプで判断され、新しいメッセージを消費した後、古いメッセージは破棄され、古いメッセージを受信しても消費されません。グローバルなタイムスタンプを提供できない場合は、グローバルに統一されたシリアル番号の使用を検討する必要があります。
べき等性を持たないイベントの場合、それは通常、控除100、デポジット200などのアクション動作イベントです。イベントIDとイベント結果を永続化し、イベントIDをクエリしてからイベントを消費し、実行結果が消費されている場合は直接返します。 ;新規メッセージの場合は実行し、実行結果を格納します。
ベストエフォート通知モード
信頼性の高いイベント通知モードと比較して、ベストエフォート通知モードは理解がはるかに簡単です。ベストエフォートの通知タイプの機能は、トランザクションが送信された後、ビジネスサービスが3つのメッセージの送信など、限られた数のメッセージを送信する（メッセージの最大数を設定する）ことです。3つのメッセージすべての送信に失敗した場合、メッセージは送信されません。そのため、メッセージが失われる可能性があります。同時に、マスタービジネスパーティは、失われたメッセージを回復するために、クエリビジネスインターフェースをスレーブビジネスサービスに提供する必要があります。ベストエフォート通知タイプは、適時性の保証が不十分であるため（つまり、ソフトステートが長時間発生する可能性があります）、データ整合性の適時性要件が高いシステムは使用できません。このモデルは通常、さまざまなビジネスプラットフォームサービスまたはサードパーティビジネスサービスの通知（銀行通知、販売者通知など）で使用され、ここでは展開されません。
ビジネス補正モード
次に、2つの補正モードを紹介します。補正モードとイベント通知モードの最大の違いは、補正モードのアップストリームサービスがダウンストリームサービスの操作結果に依存するのに対し、イベント通知モードのアップストリームサービスはダウンストリームサービスの操作結果に依存しないことです。 。まず、ビジネス補正モードを紹介します。ビジネス補正モードは、純粋な補正モードです。その設計概念は、ビジネスが呼び出されたときにビジネスが正常に送信されることです。サービスが失敗すると、依存するすべての上流サービスがビジネス補正操作を実行します。たとえば、Xiaomingは杭州から出発してアメリカのニューヨークに出張しましたが、今度は彼が杭州から上海への列車のチケットと上海からニューヨークへの飛行機のチケットを予約する必要があります。Xiaomingが正常に列車のチケットを購入し、飛行機のチケットが完売していることがわかった場合、Xiaomingは上海にもう1日滞在する代わりに、上海への列車のチケットをキャンセルし、北京に飛んでからニューヨークに移動することを選択するかもしれないので、Xiaomingはキャンセルしました上海への列車のチケット。この例では、杭州から上海への列車のチケットの購入はサービスaであり、上海からニューヨークへのチケットの購入はサービスbです。ビジネス補償モデルは、サービスbが失敗したときにサービスaを補償することです。この例では、杭州をキャンセルして上海の列車の切符。
補償モデルでは、各サービスが補償の弁解を提供する必要があり、この補償は一般に不完全な補償です。補償操作が実行された場合でも、キャンセルされた列車の切符レコードはデータベースに残っており、追跡できます（一般に、マークとして「キャンセルされました」というステータスフィールド）結局のところ、送信されたオンラインデータは通常、物理的に削除することはできません。
ビジネス補正モードの最大の欠点は、ソフトステートに時間がかかることです。データの整合性の適時性が非常に低く、複数のサービスが一貫性のないデータであることがよくあります。
TCC /確認確認キャンセルモード
TCCモードは、最適化されたビジネス補正モードです。完全に補正できます。補正後、何も起こらなかったかのように、補正の記録が残りません。同時に、TCCは2ステージモデルであるため、TCCのソフトステート時間は非常に短くなります。すべてのサービスの第1ステージ（試行）が成功した場合のみ、第2ステージの確認操作が実行されます。補償（キャンセル）操作を実行しますが、試行フェーズでは、実際のビジネス処理はありません。
TCCモードTCCモード
の特定のプロセスは2つの段階です。
-
ビジネスサービスはすべてのビジネスチェックを完了し、必要なビジネスリソースを予約します
-
すべてのサービスでTryが成功した場合は、確認操作を実行します。確認操作はビジネスチェックを実行せず（試行で行われたため）、ビジネス処理のためにTryフェーズで予約されたビジネスリソースを使用します。それ以外の場合は、キャンセル操作、キャンセルこの操作により、試行フェーズで予約されたビジネスリソースが解放されます。
Xiaoming Onlineは、100万元をChina Merchants BankからGuangfa Bankに送金します。この操作は、サービスaがXiaomingのChina Merchants Bankアカウントから100元を転送するサービスと、サービスbがXiaomingのGuangfa Bankアカウントから100元を転送するサービスの2つと見なすことができます。
サービスa（XiaomingはChina Merchants Bankから100元を送金しました）：
試してください：cmb_accountセットのバランス= balance-100を更新し、freeze =フリーズ+ 100 where acc_id = 1およびバランス> 100;
確認：cmb_accountセットを更新しますfreeze =フリーズ-100 where acc_id = 1;
キャンセル：cmb_accountセットのバランス=バランス+ 100を更新、freeze =フリーズ-100 where acc_id = 1;
サービスb（Xiaomingは100元をGuangfa Bankに転送）：
試行：update cgb_accountセットのフリーズ=フリーズ+ 100 where acc_id = 1 ;
確認：cgb_accountセットのバランス= balance + 100、freeze = freeze-100 where acc_id = 1を
更新; キャンセル：cgb_accountセットのfreeze = freeze-100 where acc_id = 1を更新;
特定の説明：
aのtryフェーズで、サービスは2つのことを行いました事柄：1.ビジネスチェック、Xiaomingのアカウントの金額が100元を超えているかどうかを確認します。2。リソースを予約し、100元を残高から凍結資金に転送します。
aの確認フェーズでは、試用フェーズがすでに実行されているため、および転送が成功したため、ここではビジネスチェックは実行されません。凍結された資金は差し引かれます。
aのキャンセルフェーズでは、予約されたリソースが解放され、両方とも100元が凍結され、残高に戻されます。
bの試行フェーズが実行され、リソースが予約され、100元が凍結されます。
bの確認フェーズでは、tryフェーズで予約されたリソースを使用して、100元の凍結資金を残高に転送します。
bのキャンセルフェーズでは、tryフェーズで予約されたリソースが解放され、凍結された資金から100元が差し引かれます。
上記の簡単な例からわかるように、TCCモデルは純粋なビジネス補償モデルよりも複雑であるため、各サービスは2つのインターフェース、CofirmとCancelを実装に実装する必要があります。次の表
は、
これらの4つの一般的に使用されるモードをまとめたものです。
| タイプ | 名前 | リアルタイムのデータ整合性 | 開発費 | アップストリームサービスがダウンストリームサービスの結果に依存するかどうか |
|---|---|---|---|---|
| お知らせ | ベストエフォート | 低 | 低 | 依存しない |
| お知らせ | 信頼できるイベント | 高い | 高い | 依存しない |
| 補償タイプ | 事業補償 | 低 | 低 | 依存する |
| 補償タイプ | TCC | 高い | 高い | 依存する |
元のリンク：https://www.jianshu.com/p/b264a196b177