【分布式事務】微服務架構下的分布式事務問題

阿新 • • 發佈：2018-10-02

queue spring 回滾事務提交 relative 社區 confirm 模型功能

一、基本概念

ACID理論：關系型數據庫的事務滿足 ACID 的特性，具有 ACID 特性的數據庫支持數據的強一致性，保證了數據本身不會出現不一致。適用於傳統的單體架構。
CAP理論：在分布式系統下，包含三個要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分區容錯性），並且三者不可兼得。分布式系統要求保證分區容錯性，只能在數據強一致性（C）和可用性（A）之間做平衡，即選擇CP或者AP。比如Zookeeper為CP系統保證強一致性犧牲一定的可用性；Eureka為AP系統保證較高可用性犧牲一定的一致性。另外，CAP理論中是忽略網絡延遲，也就是當事務提交時，從節點A復制到節點B，但是在現實中這個是明顯不可能的，所以總會有一定的時間是不一致。所以CAP一般適用於局域網系統的理論基礎。
BASE理論：解決 CAP 理論中分布式系統的可用性和一致性不可兼得的問題，提出最終一致性。即，最終數據是一致的就可以了，而不是實時保持強一致。例如，支付成功，訂單也成功，但增加積分失敗，此時，不應回滾支付和訂單，而應通過一些補償方法來讓積分得以正確地增加。

二、解決方案

方案	解決思路	適用場景	說明
本地事務	基於數據庫的ACID理論基於undo、redo日誌記錄 undo日誌實現回滾、redo日誌實現commit場景異常的恢復	傳統單體架構分布式事務要求不高的場景	分布式系統場景出現問題怎麽辦？日誌記錄--監控告警–人工幹預修復問題溯源，例如：維修工單可以創建，但是維修費用調用失敗導致整個事務回滾可能維修費用自身問題，如性能壓力過大導致請求時，觸發調用失敗回滾可能維修費用操作依據成功了，但是返回
兩階段提交	基於XA協議，依賴TM、RM的交互，依賴數據庫的能力 TM存在單點故障，鎖資源占用時間較長	面向多數據源或者分布式數據庫設計（XA本質是TM與RM之間的規範）適用於多數據源的架構 Mycat也實現了XA協議，一些公司的分布式事務使用該方案，但是應用層非微服務架構適用於並發量不大，處理時間較短的核心交易業務場景	XA協議：
三階段提交	基於TCC協議在數據庫外部實現事務機制達到最終一致性犧牲了應用的靈活性，需要提供Try、Confirm、Cancel的具體實現，且需要小心保證冪等操作	跨應用，但需要實現TCC接口，對已有系統侵入較大，適用於新系統不強依賴數據庫特性，TCC是一個通用的模型參考實現：https://github.com/liuyangming/ByteTCC/	TCC協議：
可靠消息模式	大事務轉變為小事務，小事物之間的不一致通過額外的輪訓任務進行補償該思路最初由Ebay提出：https://queue.acm.org/detail.cfm?id=1394128 可分為基於本地事件、基於外部事件兩種模式業務邏輯需要保證冪等性	適用於核心模塊的改造，或者完全基於消息驅動的架構，否則對已有系統入侵較大另外，如果需要回滾，超過兩個實務操作的場景比較復雜，所以這種場景需要遵守最終一致性原則，失敗不會滾，直到補償成功依賴具備事務功能的消息系統或者數據庫，如：RabbitMQ、Kafka、RocketMQ等	基於本地事件：基於外部事件：
可靠消息變種	不依賴消息隊列通信，將消息隊列的功能包裝為Rest服務，屏蔽消息隊列的接口將基於可靠消息模式對架構和應用入侵的缺點降低	最大努力通知型如支付寶的回調機制，可以設置指數時間重試，參考阿裏實現：https://zhuanlan.zhihu.com/p/26114119
可靠消息變種		下遊應用輪詢如微信的輪詢機制，由下遊應用自己保證一致性
SAGA方案	基於工作流的思路，原理：https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf 定義順序操作、回滾操作的流程，交給事務協調器統一管理一些應用框架實現了該方案，如CQRS框架Axonframework：https://github.com/AxonFramework/AxonFramework，又如華為servicecomb：https://github.com/apache/incubator-servicecomb-saga	應用方定義工作流，交給SAGA進行管理，雖然這種方案不火熱，但是對應用入侵較小，且符合分層的設計原則，添加一個composite層單獨實現需要分布式事務的流程即可	SAGA工作流：
阿裏GTS	優化XA架構的路線，使用上與XA類似，業務入侵較小，添加註解 GTS參考：https://zhuanlan.zhihu.com/p/32684212 仿GTS實現：https://github.com/wxbty/meepo https://github.com/chenjy16/gts 與GTS類似的：https://github.com/codingapi/tx-lcn 看起來最成熟的開源方案	適用於阿裏雲方案，專線也可以接入使用，第三方系統遵循TCC的也可以接入
總結建議	如果非必要，不引入分布式事務，每個微服務保證自身的高可用，基本能夠保證數據的一致性，極端的情況除外。--事實上微服務的架構BAT十年前就在使用，沒有分布式事務也一樣，因為基礎設施、每個微服務自身可用性比較高，所以不需要引入更大的復雜性如果必要，首先保證核心業務的數據一致性，比如交易業務，可以采用消息機制、最大努力通知、輪詢機制的方案，他們的本質都是記賬，即使出了問題也有據可查--這部分一般借助第三方支付系統的能力即可滿足如果只是較少量的業務需要分布式事務特性，可以局部使用基於可靠消息的方案，參考：https://github.com/vvsuperman/coolmq，這種方案需要註意很多細節，理論上每個環節都可能出現網絡異常，都需要有相應的措施保障，比如：如果建立指數時間重試機制，下遊服務接口需要保證冪等，該方案相當於業務自己負責維護一致性如果大量業務需要分布式事務，也可以引入類似DelayMq的服務做解耦，利用該服務提供回調服務將服務鏈串聯起來（消息中包含回調的Url、參數），但是下遊的服務接口需要保證冪等性--PaaS平臺可以提供類似的服務，參考：https://zhuanlan.zhihu.com/p/26114119。該方案需要能夠接受部分代碼的重構如果大量業務需要分布式事務，可以引入類似GTS對業務入侵較小的框架，避免更新架構和代碼，代碼添加必要的註解即可，如：https://github.com/codingapi/tx-lcn --開源方案，建議經過測試之後謹慎上線，這個能力也可以研究下看看能不能做到PaaS平臺數據一致性是一個系統工程，僅僅在事務框架層面解決是不夠的，還需要配套的規範措施--如請求RequestID、鏈路追蹤、接口冪等、日誌輸出規範、關鍵日誌記錄規範等，出現問題可以快速定位，這部分的數據可以讓PaaS接管，提供鏈路服務、監控告警服務等完善基礎設施，降低網絡問題的影響是重要前提。對於實際調用已經成功，返回時網絡異常的問題，需要補償機制--PaaS可以提供類似DelayMq的服務完善應用的監控告警設施，如應用的API、訪問次數、失敗次數等監控，及時告警--PaaS可以提供應用的實時監控告警能力

三、參考資料

再有人問你分布式事務，把這篇扔給他：https://mp.weixin.qq.com/s/W7XeNKIwB-JxnyStq0xD6g
GTSDemo介紹：https://help.aliyun.com/document_detail/57267.html?spm=a2c4g.11174283.3.5.6eea735d9NoIS6
ByteTCC：https://github.com/liuyangming/ByteTCC/
GTS解密--GTS的原理、架構與特點：https://zhuanlan.zhihu.com/p/32684212
分布式事務系列：https://blog.csdn.net/qq_27384769/article/details/79305402

四、GitHub相關項目

https://github.com/HasonHuang/distributed-transaction-process
https://github.com/QNJR-GROUP/EasyTransaction
https://github.com/vvsuperman/coolmq
https://github.com/yu199195/myth
https://github.com/yu199195/hmily
https://github.com/1991wangliang/tx-lcn
https://github.com/codingapi/tx-lcn
https://github.com/prontera/spring-cloud-rest-tcc
https://github.com/QNJR-GROUP/EasyTransaction

【分布式事務】微服務架構下的分布式事務問題

queue spring 回滾事務提交 relative 社區 confirm 模型功能一、基本概念 ACID理論：關系型數據庫的事務滿足 ACID 的特性，具有 ACID 特性的數據庫支持數據的強一致性，保證了數據本身不會出現不一致。適用於傳統的單體架構。 CAP

【分散式事務】微服務架構下的分散式事務問題

ACID理論：關係型資料庫的事務滿足 ACID 的特性，具有 ACID 特性的資料庫支援資料的強一致性，保證了資料本身不會出現不一致。適用於傳統的單體架構。 CAP理論：在分散式系統下，包含三個要素：Consistency（一致性）、Availability（可用性）、Partition toleranc

阿裏微服務架構下分布式事務解決方案－GTS

tor HERE 優秀使用 where 支持討論物流可用性雖然微服務現在如火如荼，但對其實踐其實仍處於初級階段。即使互聯網巨頭的實踐也大多是試驗層面，鮮有核心業務系統微服務化的案例。GTS是目前業界第一款，也是唯一的一款通用的解決微服務分布式事務問題的中間件，而且

使用nhmicro提供的micro-datasource嵌入式的解決微服務架構中分布式事務問題

微服務 nhmicro 分布式應用原理：使用micro-datasource數據源使事務與線程解耦，通過groupid在其他線程進行事務提交或回滾。多個系統需要統一提交時，通過activemq發送提交消息（含有groupid），各系統收到消息後進行統一提交或回滾。micro-datasource

微服務架構及分布式事務解決方案

路由 ons city nic net 原則分享圖片成功 ket 分布式事務分布式事務場景如何設計系統架構及解決數據一致性問題，個人理解最終方案把握以下原則就可以了，那就是：大事務=小事務（原子事務）+異步（消息通知），解決分布式事務的最好辦法其實就是不考慮

玩轉KafkaIO與Flink微服務架構的分布式事務

http 就是 req 網上購物恢復其它本質強一致上鎖一、盡量在業務上和技術上避免分布式事務顯而易見，微服務架構十分的流行，特別是對於電商領域來說。他的優點就不多說了，但是隨著集群機器的增加，集群的規模也越來越大，隨著集群搭載的服務規模也越來越大，導致事務的

微服務架構下處理分布式事務，你必須知道的事兒

時機一致性 cloud 困難都是 upd 數據庫 dynamo 應用根據微服務架構的鼻祖 Martin Fowler 的忠告，微服務架構中應當盡量避免分布式事務。然而，在某些領域，分布式事務如同宿命中的對手無法避免。在工程領域，分布式事務的討論主要聚焦於強一致性和

微服務架構下的分布式數據管理

數據庫更新 event 可擴展存儲展現文檔數據庫 and 持久化 class 1.1 分布式數據管理之痛點為了確保微服務之間松耦合，每個服務都有自己的數據庫, 有的是關系型數據庫（SQL），有的是非關系型數據庫（NoSQL）。開發企業事務往往牽涉到多個服務，要

【轉】微服務MySQL分庫分表資料到MongoDB同步方案

需求背景近年來，微服務概念持續火熱，網路上針對微服務和單體架構的討論也是越來越多，面對日益增長的業務需求是，很多公司做技術架構升級時優先選用微服務方式。我所在公司也是選的這個方向來升級技術架構，以支撐更大訪問量和更方便的業務擴充套件。發現問題微服務拆分主要分兩種

Java高並發高性能分布式框架從無到有微服務架構設計

創建最終轉移 lis 分布式 err 靜態頁面提升性能 squid 微服務架構模式（Microservice Architect Pattern）。近兩年在服務的瘋狂增長與雲計算技術的進步，讓微服務架構受到重點關註微服務架構是一種架構模式，它提倡將單一應用程序劃分

【星雲測試】Devops微服務架構下具有程式碼級穿透能力的精準測試

　　微服務是Devops場景下熱門的開發框架，在大型專案中被廣泛採用。它把一個大型的單個應用程式和服務拆分為數十個的支援微服務，獨立部署、互相隔離，通過擴充套件元件來處理功能瓶頸問題，比傳統的應用程式更能有效利用計算資源。微服務之間無需關心對方的模型，它通過事先約定好的介面進行資料流轉，使業務可以高

【雙11狂歡背後】微服務註冊中心如何承載大型系統的千萬級訪問？

一、問題起源 Spring Cloud架構體系中，Eureka是一個至關重要的元件，它扮演著微服務註冊中心的角色，所有的服務註冊與服務發現，都是依賴Eureka的。不少初學Spring Cloud的朋友在落地公司生產環境部署時，經常會問： ● Eureka Serve

Spring Cloud---【雙11狂歡背後】微服務註冊中心如何承載大型系統的千萬級訪問？

本文來源：石杉的架構筆記（ID：shishan100）一、問題起源 Spring Cloud架構體系中，Eureka是一個至關重要的元件，它扮演著微服務註冊中心的角色，所有的服務註冊與服務發現，都是依賴Eureka的。不少初

【架構師】微服務架構--REST與RPC

REST與RPC比較與應用場景 1.1.1 REST與RPC概念什麼是REST REST是一種架構風格，指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程式或設計就是 RESTful。REST規範

【Spring Cloud】微服務架構選型方案

1、技術架構 2、元件介紹 1、服務註冊與發現——Eureka 服務註冊與發現中心採用Eureka，以AP為核心的高可用註冊中心，保證高可用性和最終一致性，server之間互相註冊的replicate機制可以單點註冊、全域性感知，通過叢集式部署來避免單點故障導致服務不可用。

微服務架構下處理分散式事務，你必須知道的事兒

根據微服務架構的鼻祖 Martin Fowler 的忠告，微服務架構中應當儘量避免分散式事務。然而，在某些領域，分散式事務如同宿命中的對手無法避免。在工程領域，分散式事務的討論主要聚焦於強一致性和最終一致性的解決方案。典型方案包括：兩階段提交(2PC, Two-phase Commit)方案

阿里微服務架構下分散式事務解決方案－GTS

雖然微服務現在如火如荼，但對其實踐其實仍處於初級階段。即使網際網路巨頭的實踐也大多是試驗層面，鮮有核心業務系統微服務化的案例。GTS是目前業界第一款，也是唯一的一款通用的解決微服務分散式事務問題的中介軟體，而且可以保證資料的強一致性。本文將對GTS做出深入解讀。微服務倡導將複雜的單體應用拆分為若干個功能簡

微服務架構下分散式事務解決方案 —— 阿里GTS

原文地址:https://yq.aliyun.com/articles/5420201 微服務的發展微服務倡導將複雜的單體應用拆分為若干個功能簡單、鬆耦合的服務，這樣可以降低開發難度、增強擴充套件性、便於敏捷開發。當前被越來越多的開發者推崇，很多網際網路行業巨頭、開源社群等都

從 0 開始的微服務架構：（四）如何保障微服務架構下的數據一致性

網上行數解決方案 open 了解傳播發的目的 cati 雖然已經紅了很久，但是“微服務架構”正變得越來越重要，也將繼續火下去。各個公司與技術人員都在分享微服務架構的相關知識與實踐經驗，但我們發現，目前網上的這些相關文章中，要麽上來就是很有借鑒意義的幹貨，要麽就是以

微服務架構下業務單機QPS跑不上去應從哪些角度分析

應用運維性能分析微服務這是做應用運維老生常談的一個事兒，經常做，今天把他總結一下。不管什麽性質的業務，吞吐量的本質是木桶原理，能跑多大量取決於木桶最短的那個板，腦袋裏是不是立刻可以出現木桶的那個模型，哈哈！！換句話說，當有能力提高短板的高度時，業務的吞吐量就會有所上升，但同樣有個邊際效應，經

【分布式事務】微服務架構下的分布式事務問題

相關推薦