分散式事務的挑戰 在多個服務、資料庫和消息代理之間維持數據的一致性的傳統方式是採用分散式事務。分散式的事實標註是XA、XA採用了兩階段提交老保證事務中的所有參與方同時完成提交，或者失敗時同時回滾。應用程式的整個技術棧需要滿足XA標準。 許多新技術，包括NoSQLshujk ,liru MongoDB ...
作者：h-松 鏈接：https://juejin.im/post/5d5569466fb9a06af629a9ab
分散式事務的挑戰
在多個服務、資料庫和消息代理之間維持數據的一致性的傳統方式是採用分散式事務。分散式的事實標註是XA、XA採用了兩階段提交老保證事務中的所有參與方同時完成提交，或者失敗時同時回滾。應用程式的整個技術棧需要滿足XA標準。
許多新技術，包括NoSQLshujk ,liru MongoDB和Cassandra並不支持XA標準的分散式事務。同樣，一些流行的消息代理如RabbitMQ和Apache Kafka也不支持分散式事務。如果你堅持在微服務中使用分散式事務，那麼不得不放棄使用這些流行的資料庫或消息代理。
saga
將跨越多個服務的每個業務事務作為一個SAGA實現。SAGA是一系列本地事務。每個本地事務更新資料庫併發布消息或事件以觸發SAGA中的下一個本地事務。如果本地事務由於違反業務規則而失敗，那麼SAGA將執行一系列補償事務，以撤消前面的本地事務所做的更改。
有兩種協調方式：
- 協同-每個本地事務發佈觸發其他服務中本地事務的域事件
- 編排-編排器（對象）告訴參與者要執行的本地事務
協同式
編排
saga這種模式有以下好處：
它使應用程式能夠跨多個服務維護數據一致性，而無需使用分散式事務 此解決方案有以下缺點：
編程模型更複雜。例如，開發人員必須設計補償事務，以顯式地撤消在SAGA前面所做的更改。 還需要解決以下問題：
為了可靠，服務必須自動更新其資料庫併發布消息/事件。它不能使用跨越資料庫和消息代理的分散式事務的傳統機制。相反，它必須使用下麵列出的模式之一。
