分佈式設計模式-分佈式事務

分佈式事務的挑戰

在多個服務、數據庫和消息代理之間維持數據的一致性的傳統方式是採用分佈式事務。分佈式的事實標註是XA、XA採用了兩階段提交老保證事務中的全部參與方同時完成提交，或者失敗時同時回滾。應用程序的整個技術棧須要知足XA標準。

許多新技術，包括NoSQLshujk ,liru MongoDB和Cassandra並不支持XA標準的分佈式事務。一樣，一些流行的消息代理如RabbitMQ和Apache Kafka也不支持分佈式事務。若是你堅持在微服務中使用分佈式事務，那麼不得不放棄使用這些流行的數據庫或消息代理。

saga

將跨越多個服務的每一個業務事務做爲一個SAGA實現。SAGA是一系列本地事務。每一個本地事務更新數據庫併發布消息或事件以觸發SAGA中的下一個本地事務。若是本地事務因爲違反業務規則而失敗，那麼SAGA將執行一系列補償事務，以撤消前面的本地事務所作的更改。

有兩種協調方式：

• 協同-每一個本地事務發佈觸發其餘服務中本地事務的域事件
• 編排-編排器（對象）告訴參與者要執行的本地事務

協同式

編排

saga這種模式有如下好處：

它使應用程序可以跨多個服務維護數據一致性，而無需使用分佈式事務 此解決方案有如下缺點：

編程模型更復雜。例如，開發人員必須設計補償事務，以顯式地撤消在SAGA前面所作的更改。 還須要解決如下問題：

爲了可靠，服務必須自動更新其數據庫併發布消息/事件。它不能使用跨越數據庫和消息代理的分佈式事務的傳統機制。相反，它必須使用下面列出的模式之一。