分布式事務(wù)

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

企業(yè)建站必須是能夠以充分展現(xiàn)企業(yè)形象為主要目的，是企業(yè)文化與產(chǎn)品對(duì)外擴(kuò)展宣傳的重要窗口，一個(gè)合格的網(wǎng)站不僅僅能為公司帶來(lái)巨大的互聯(lián)網(wǎng)上的收集和信息發(fā)布平臺(tái)，創(chuàng)新互聯(lián)面向各種領(lǐng)域：LED顯示屏等成都網(wǎng)站設(shè)計(jì)、網(wǎng)絡(luò)營(yíng)銷(xiāo)推廣解決方案、網(wǎng)站設(shè)計(jì)等建站排名服務(wù)。

什么是事務(wù)

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

事務(wù)是由一組SQL語(yǔ)句組成的邏輯處理單元，事務(wù)具有以下4個(gè)屬性，通常簡(jiǎn)稱(chēng)為事務(wù)的ACID屬性：

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

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

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

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

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

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

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

再說(shuō)我們做的一個(gè)項(xiàng)目：中國(guó)移動(dòng)-流量充值能力中心，核心業(yè)務(wù)流程為：

1. 用戶(hù)進(jìn)入流量充值商品購(gòu)買(mǎi)頁(yè)面，選擇流量商品；

2. 購(gòu)買(mǎi)流量充值商品，有庫(kù)存限制則判斷庫(kù)存，生成流量購(gòu)買(mǎi)訂單；

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

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

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

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

分布式事務(wù)

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

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

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

1. 兩階段型

2. 補(bǔ)償型

3. 異步確保型

4. 大努力通知型

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

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

1. 商品服務(wù)

2. 訂單服務(wù)

3. 庫(kù)存服務(wù)

4. 支付服務(wù)

5. 直充服務(wù)

6. 消息服務(wù)

7. 等其他服務(wù)

場(chǎng)景一：

庫(kù)存數(shù)量與訂單數(shù)量一致性，采用補(bǔ)償型+大努力通知型，采用原因?yàn)椴簧婕翱鐧C(jī)房和長(zhǎng)事務(wù)（正常情況下庫(kù)存與訂單服務(wù)處理很快）：

1. 用戶(hù)下單先減庫(kù)存，庫(kù)存減成功后；

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

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

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

場(chǎng)景二：

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

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

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

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

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

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

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

場(chǎng)景三：

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

場(chǎng)景四：

對(duì)賬稽核：

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

結(jié)算稽核：

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

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

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

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

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

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

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

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

整體拆分原則如下圖：

創(chuàng)新互聯(lián)www.cdcxhl.cn，專(zhuān)業(yè)提供香港、美國(guó)云服務(wù)器，動(dòng)態(tài)BGP最優(yōu)骨干路由自動(dòng)選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機(jī)房獨(dú)有T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確進(jìn)行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動(dòng)現(xiàn)已開(kāi)啟，新人活動(dòng)云服務(wù)器買(mǎi)多久送多久。