決勝で分散トランザクションの整合性

我々はすべて知っておくべきローカルトランザクションのACIDは、厳密に同じトランザクション内のデータの一貫性を確保するため、ロールバックが失敗し、コミット統一します！広く使用されており、分散トランザクションのプロトタイプは、このようなACIDを達成することはできません、それは2つのだけCAPの原則的に達成することができ、CAPが配布されるトランザクションは、CAP（一貫性、可用性、分割耐性）は、分散型説明しますシステムの3つの主要な側面は、唯一、同時に他の選択を実現することができる。一般的なシステムCP、APシステムがあります。

業界に適用されるCPとAP原則は、いくつかのフレームワークがありました：

CPシステムは、2フェーズ・コミット・プロトコルを持っている（強い整合性）

そこAPシステムTCC（総務補償）

最新の接触aspnetcore.capは満足して、最終的な一貫性、のSQLServerをインストールするには、自分のニーズに応じて、メッセージキューがカフカとRabbitMQの二つのオプションを持つことができるソリューションを提供し、それは、MySQLで非同期メッセージングプログラムの実装、オープンgithubのではなく、対応するバッグNuGetのソースコード！

そのメッセージの種類を確認するために - 分散トランザクションの最終的な一貫性の理解を：

• 1. データを提出するサービス
• 2. メッセージセンターへのメッセージ
• 3. 加入者へのメッセージセンタープッシュメッセージ
• 4. 独自のビジネス・ロジックを処理するために、加入者
• 5. 繰り返しの失敗ではなく、ロールバックなどの強い一貫性よりも、成功するまで再試行に行くために