分散トランザクションは、多くの場合、サービス指向の問題点です。多くのシナリオでは、ビジネスを通じて分散トランザクションを回避していますが、分散トランザクションに依存する必要があるシナリオもまだいくつかあります。分散トランザクションの処理方法について話しましょう |
を実装する必要があります。
柔軟な分散トランザクションは、分散システムでトランザクションを処理する方法です。ベストエフォート型のコミット戦略が採用されています。つまり、トランザクションの送信を完了するために最善を尽くしますが、一部の操作の失敗も許容されます。柔軟な分散トランザクションでは、通常、トランザクション管理の実装に TCC (試行-確認-キャンセル) モードが使用されます。 TCC モデルは、トランザクションを試行、確認、キャンセルの 3 つのフェーズに分解します。まず、分散トランザクションの前提条件の保証を解決します。メッセージの繰り返しの送信がビジネスに影響を与えるのを防ぐために、インターフェースは冪等である必要があります。
2 信頼性の高いメッセージ システムの設計 (これは良い感じで比較的シンプルなので共有します)上に示したとおり
実行の開始例: ###試す{### if(prepare()) { //送信前フェーズ
doService(); //ビジネスロジックを実行updateMsgStatus();//ステータスを確認するためにメッセージを更新
}
}
1 メッセージの事前送信、試行フェーズ。メッセージの事前送信が失敗した場合、ビジネスはまだ実行されていないため、システム A と B は依然として一貫性があり、処理は必要ありません。
これはわかりやすいですね
2 現在送信されたメッセージは成功し、ビジネス ロジックの実行が開始されます。実行が成功すると、更新された送信前メッセージのステータスが送信確認に変更されます。このときビジネスロジックの実行に失敗すると、送信済みのメッセージは新たなステータスに更新されず、この時点でメッセージ確認システムが動作し、業務システム1に戻ってメッセージのステータスを確認することになります。業務実行が失敗したことが判明した場合は、送信前ステータスを失敗ステータスに更新します。
###3 この時点でビジネスの実行が成功し、送信を確認するためにメッセージが更新されていれば、問題はありません。メッセージの更新が失敗した場合でも、メッセージ確認システムはステータスをチェックし、メッセージが削除されたか送信が確認されたかを更新します。
を消費し始めます
1> たとえば、消費が失敗して不整合が発生した場合、メッセージ回復システムはメッセージのステータスを検出し、メッセージを再送信します。2>ビジネスの実行が失敗した場合、メッセージは確認されません。メッセージ回復システムは引き続きメッセージのステータスを検出し、メッセージを再送信します
3>アスクが失敗した場合は、上記のロジックで再送しますが、もちろん再送回数には制限があり、毎回送信できるわけではありません。最大回数を超えた場合は再送を行ってください。 、デッドレターキューに入り、手動介入を待ちます。
4> 質問が成功すると、メッセージは正常に消費されます。これは完璧であり、信頼性の高いメッセージ サービスの問題を解決します。
3 頑張って提出してくださいこれは比較的単純です。リアルタイム パフォーマンスが低い一部のシナリオでは、失敗したメッセージを繰り返し送信して、メッセージのプッシュが確実に成功するようにします。
たとえば、トランザクションが完了すると、サードパーティのメッセージがプッシュされます。現時点では、努力の提出
を使用できます。
この記事はオープンソースチャイナコミュニティ[http://www.oschina.net]からの転載です。以上が信頼性の高いメッセージング サービスの実装を検討するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。