分布式事務(wù)

分布式事務(wù)場景如何設(shè)計系統(tǒng)架構(gòu)及解決數(shù)據(jù)一致性問題，個人理解最終方案把握以下原則就可以了，那就是：大事務(wù)=小事務(wù)（原子事務(wù)）+異步（消息通知），解決分布式事務(wù)的最好辦法其實就是不考慮分布式事務(wù)，將一個大的業(yè)務(wù)進行拆分，整個大的業(yè)務(wù)流程，轉(zhuǎn)化成若干個小的業(yè)務(wù)流程，然后通過設(shè)計補償流程從而考慮最終一致性。

成都創(chuàng)新互聯(lián)公司長期為上千余家客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為尚義企業(yè)提供專業(yè)的成都網(wǎng)站設(shè)計、成都網(wǎng)站制作，尚義網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

什么是事務(wù)

事務(wù)（Transaction）及其ACID屬性

事務(wù)是由一組SQL語句組成的邏輯處理單元，事務(wù)具有以下4個屬性，通常簡稱為事務(wù)的ACID屬性：

1. 原子性（Atomicity）：事務(wù)是一個原子操作單元，其對數(shù)據(jù)的修改，要么全都執(zhí)行，要么全都不執(zhí)行。

2. 一致性（Consistent）：在事務(wù)開始和完成時，數(shù)據(jù)都必須保持一致狀態(tài)。這意味著所有相關(guān)的數(shù)據(jù)規(guī)則都必須應(yīng)用于事務(wù)的修改，以保持?jǐn)?shù)據(jù)的完整性；事務(wù)結(jié)束時，所有的內(nèi)部數(shù)據(jù)結(jié)構(gòu)（如B樹索引或雙向鏈表）也都必須是正確的。

3. 隔離性（Isoation）：數(shù)據(jù)庫系統(tǒng)提供一定的隔離機制，保證事務(wù)在不受外部并發(fā)操作影響的“獨立”環(huán)境執(zhí)行。這意味著事務(wù)處理過程中的中間狀態(tài)對外部是不可見的，反之亦然。

4. 持久性（Durabe）：事務(wù)完成之后，它對于數(shù)據(jù)的修改是永久性的，即使出現(xiàn)系統(tǒng)故障也能夠保持。

典型場景：銀行轉(zhuǎn)賬業(yè)務(wù)

例如：李雷賬戶中有500塊錢，韓梅梅賬戶有200塊錢，李雷要從自己的賬戶中轉(zhuǎn)100塊錢給韓梅梅，轉(zhuǎn)賬（事務(wù)）成功執(zhí)行完成后應(yīng)該是李雷賬戶減100變?yōu)?00，韓梅梅賬戶加100變?yōu)?00，不能出現(xiàn)其他情況，即在事務(wù)開始和結(jié)束時數(shù)據(jù)都必須保持一致狀態(tài)（一致性），事務(wù)結(jié)束時所有的數(shù)據(jù)及結(jié)構(gòu)都必須是正確的。并且同樣的轉(zhuǎn)賬操作（同一流水，即一次轉(zhuǎn)賬操作）無論執(zhí)行多少次結(jié)果都相同（冪等性）。

電商場景：流量充值業(yè)務(wù)

再說我們做的一個項目：中國移動-流量充值能力中心，核心業(yè)務(wù)流程為：

1. 用戶進入流量充值商品購買頁面，選擇流量商品；

2. 購買流量充值商品，有庫存限制則判斷庫存，生成流量購買訂單；

3. 選擇對應(yīng)的支付方式（和包、銀聯(lián)、支付寶、微信）進行支付操作；

4. 支付成功后，近實時流量到賬即可使用流量商品；

此業(yè)務(wù)流程看似不是很復(fù)雜對吧，不涉及到類似電商業(yè)務(wù)的實物購買，但是我認(rèn)為其中的區(qū)別并不是很大，只是缺少電商中的物流發(fā)貨流程，其他流程幾乎是一樣的，也有庫存以及優(yōu)惠折扣等業(yè)務(wù)存在。

整個系統(tǒng)交互如下圖：

分布式事務(wù)

上述兩個場景的業(yè)務(wù)需求已經(jīng)說完了，接著談?wù)劮植际绞聞?wù)，要說分布式事務(wù)那就先聊聊本地事務(wù)與分布式事務(wù)：

相同點：首先都是要保證數(shù)據(jù)正確（即ACID），本地事務(wù)與分布式事務(wù)還可以對應(yīng)為：剛性事務(wù)與柔性事務(wù)，在我個人理解剛性事務(wù)與柔性事務(wù)的最大區(qū)別就是：一個完整的事務(wù)操作是否可以在同一物理介質(zhì)（例如：內(nèi)存）上同時完成；柔性事務(wù)就是一個完整事務(wù)需要跨物理介質(zhì)或跨物理節(jié)點（網(wǎng)絡(luò)通訊），那么排它鎖、共享鎖等等就沒有用武之地了（這里并不是指大事務(wù)拆小事務(wù)【本地事務(wù)】后），無法保證原子性（Atomicity）完成事務(wù)。個人理解分布式（柔性）事務(wù)本質(zhì)意義上就是-偽事務(wù)，柔性事務(wù)其實就是根據(jù)不同的業(yè)務(wù)場景使用不同的方法實現(xiàn)最終一致性，因為可以根據(jù)業(yè)務(wù)的特性做部分取舍，在業(yè)務(wù)過程中可以容忍一定時間內(nèi)的數(shù)據(jù)不一致。

支付寶的柔性事務(wù)實現(xiàn)方式有四種分別針對不同的業(yè)務(wù)場景，如下圖：

1. 兩階段型

2. 補償型

3. 異步確保型

4. 最大努力通知型

流量交易中心的業(yè)務(wù)場景

通過Dubbo實現(xiàn)了微服務(wù)化，大致拆分如下：

1. 商品服務(wù)

2. 訂單服務(wù)

3. 庫存服務(wù)

4. 支付服務(wù)

5. 直充服務(wù)

6. 消息服務(wù)

7. 等其他服務(wù)

場景一：

庫存數(shù)量與訂單數(shù)量一致性，采用補償型+最大努力通知型，采用原因為不涉及跨機房和長事務(wù)（正常情況下庫存與訂單服務(wù)處理很快）：

1. 用戶下單先減庫存，庫存減成功后；

2. 調(diào)用下單服務(wù)：

3. 2-1. 下單成功，兩事務(wù)均提交完成；

4. 2-2. 下單失敗，庫存回滾，兩事務(wù)均失敗，此處還有一個保障機制（最大努力通知型），就是如果調(diào)用庫存服務(wù)異常，確定庫存回滾失敗了，則放入消息服務(wù)（延時消息隊列）分階段定時重試，努力重試保證庫存服務(wù)正常后成功回滾。

場景二：

訂單信息、支付信息、充值信息三者之間的一致性，采用異步確保型的原因是，整個業(yè)務(wù)鏈路太長且跨不同的機房系統(tǒng)，網(wǎng)絡(luò)延遲較高，業(yè)務(wù)方面恰好不需要非常高的實時性，所以采用小事務(wù)+異步通知，目前正常情況下用戶從下單到完成支付到流量到賬平均為1-5分鐘左右：

1. 下單成功即訂單服務(wù)創(chuàng)建訂單成功并發(fā)送支付請求到支付網(wǎng)關(guān)系統(tǒng)（訂單狀態(tài)-待支付，超過1小時未支付則流轉(zhuǎn)為超時未付撤銷，此處用到了RocketMQ的延時消費恰好實現(xiàn)定時器業(yè)務(wù)場景）。

2. 返回支付頁面，用戶在支付交易系統(tǒng)完成支付業(yè)務(wù)流程，支付網(wǎng)關(guān)異步通知流量中心，流量中心接收到支付成功狀態(tài)后修改訂單狀態(tài)-支付成功，并給支付網(wǎng)關(guān)返回成功結(jié)果（此處并發(fā)壓力目前不大，暫時沒有再進行異步解耦）。

3. 流量中心修改完訂單狀態(tài)后，調(diào)用消息服務(wù)將直充業(yè)務(wù)放入消息隊列，對直充業(yè)務(wù)進行解耦（原因是直充需要調(diào)用31省移動CRM系統(tǒng)，此鏈路過長，且部分省CRM系統(tǒng)耗時非常大，每個省的處理能力不同，經(jīng)常出現(xiàn)20秒以上的超時，因此要考慮部分超時較高的省份拖垮系統(tǒng)，進行業(yè)務(wù)的削峰填谷）；

4. 3-1. 當(dāng)直充成功時，修改訂單狀態(tài)-已完成；

5. 3-2. 當(dāng)直充失敗時（移動特性，例如：直充時正好用戶銷戶或者停機了），修改訂單狀態(tài)為待退款，并調(diào)用支付網(wǎng)關(guān)系統(tǒng)的退款接口，退款成功后支付網(wǎng)關(guān)異步通知流量中心，流量中心修改訂單狀態(tài)為-退款成功；

6. 3-3. 當(dāng)直充超時時，調(diào)用定時任務(wù)服務(wù)進行超時重試機制（第一次重試在10分鐘后執(zhí)行、第二次在30分鐘后、第三次…..），直到最大超時重試次數(shù)后還得不到直充結(jié)果，訂單狀態(tài)會卡在支付成功狀態(tài)，依賴T+1對賬稽核流程保證最終一致性，訂單狀態(tài)根據(jù)對賬結(jié)果流轉(zhuǎn)為：已完成或待退款–>退款成功。

場景三：

直充到賬后的消息通知（APP消息推送或短信通知），采用最大努力通知型，這個業(yè)務(wù)場景比較簡單，在直充成功后，訂單狀態(tài)流轉(zhuǎn)為已完成，此時通過消息服務(wù)進行到賬通知業(yè)務(wù)的解耦，調(diào)用消息服務(wù)失敗的情況下，使用定時任務(wù)努力通知。

場景四：

對賬稽核：

按照支付賬期每日進行T+1對賬，對賬原則：以支付交易記錄為準(zhǔn)，對流量中心訂單記錄+支付網(wǎng)關(guān)交易記錄+省CRM充值記錄三方比對，將某些中間狀態(tài)的訂單（例如：支付成功、待退款）核對后將訂單狀態(tài)流轉(zhuǎn)完結(jié)（已完成、退款成功）。

結(jié)算稽核：

對賬成功后的數(shù)據(jù)定期進入結(jié)算流程，對支付網(wǎng)關(guān)周期內(nèi)的支付金額與結(jié)算數(shù)據(jù)的金額進行核對，稽核成功后進行財務(wù)結(jié)算流程，將錢結(jié)算給省公司，并提供結(jié)算明細(xì)給省公司，供省公司與直充成本記錄進行復(fù)核。

以下是流量中心的部分架構(gòu)設(shè)計，總體原則方向：微服務(wù)化

流量中心-架構(gòu)設(shè)計

架構(gòu)設(shè)計思想：在系統(tǒng)初期設(shè)計時以及部分硬性環(huán)境約束下，我們根據(jù)業(yè)務(wù)拆分為多個子系統(tǒng)（微服務(wù)）：商品服務(wù)、訂單服務(wù)、庫存服務(wù)、支付網(wǎng)關(guān)、統(tǒng)一接口平臺、對賬服務(wù)、結(jié)算服務(wù)、網(wǎng)關(guān)對接服務(wù)等，后續(xù)還會增加：賬戶服務(wù)、虛擬貨幣服務(wù)、卡券服務(wù)等等…。按照微服務(wù)的核心設(shè)計思想，所有服務(wù)完全獨立、隔離，因此所有服務(wù)從上至下：請求接入（連接管理）、請求處理（計算服務(wù)）、數(shù)據(jù)存儲（存儲服務(wù)）進行拆分，接入與計算盡最大可能實現(xiàn)無狀態(tài)，數(shù)據(jù)存儲進行垂直+水平拆分，垂直拆分：商品庫-MySQL（讀多寫少，主從架構(gòu)+讀寫分離）+redis（讀多寫少，集群方式）、訂單庫-mysql（讀寫均衡，多主多從+水平拆分）、庫存專用庫-redis（分布式+主備容災(zāi)）、外部交易系統(tǒng)-支付網(wǎng)關(guān)、外部辦理系統(tǒng)-統(tǒng)一接口平臺。

此架構(gòu)目前已支撐總交易額3.6億，總訂單4680萬，日均交易額500萬，日訂單量50萬，后續(xù)業(yè)務(wù)量持續(xù)增加的情況下按照微服務(wù)思想繼續(xù)拆分，例如將訂單服務(wù)再拆分為：下單服務(wù)、查單服務(wù)，直到根據(jù)業(yè)務(wù)需求與系統(tǒng)關(guān)系耦合性拆分到最細(xì)粒度為止。

1. 性能擴展：應(yīng)用層計算服務(wù)（無狀態(tài)應(yīng)用）通過增加服務(wù)節(jié)點同比提升運算性能，配套質(zhì)量（性能）監(jiān)控服務(wù)dubbo monitor及整合Netflix的Hystrix熔斷器對業(yè)務(wù)質(zhì)量進行管理實現(xiàn)應(yīng)用層的動態(tài)擴縮容。

2. 容量擴展：數(shù)據(jù)層存儲服務(wù)（有狀態(tài)應(yīng)用）通過對數(shù)據(jù)水平拆分實現(xiàn)容量的無限擴容，NOSQL類方案：Codis中間件；關(guān)系型數(shù)據(jù)庫：Mycat數(shù)據(jù)庫分庫分表中間件。目前項目中采用twitter的snowflake唯一ID生成器（根據(jù)業(yè)務(wù)場景優(yōu)化后）自己實現(xiàn)數(shù)據(jù)的水平拆分和路由規(guī)則。

3. 存儲性能：Nosql：針對讀多寫少場景-使用淘寶的Tedis（多寫隨機讀的特性提高性能），讀寫均衡使用-Codis；Mysql：讀多寫少場景使用一主多從架構(gòu)（例如商品信息），讀寫均衡場景使用多主多從架構(gòu)（例如訂單信息）。

整體拆分原則如下圖：

cdn.xitu.io/2019/3/26/169ba6a252d0bdc2?imageView2/0/w/1280/h/960/format/webp/ignore-error/1">