2.0平臺服務化架構，必然分庫，分庫又必然面臨一個分布式事務處理問題，所以無論是設計還是編碼遠遠比1.0單體應用架構的工作量要大。不過做任何事情，重點不在實施，而是在思路，所以要解決分布式事務問題，還得先想清楚屢清楚怎麽去做才是重點之重。

分布式事務處理方法其實大把，無需擔憂找不到解決方法，關鍵是要找到滿足自己業務場景，適合自己業務場景的方法，我之前做的項目涉及個分布式事務處理的方法也有好幾個，其中記憶較為清晰的是一個移動充值的業務，大概業務就是用戶通過銀行在線支付完成後，然後給自己的手機號碼充值，這個裏面就涉及到銀行充值和手機話費充值兩個一致性的事務，當初用的就是通過每天淩晨的對賬來處理這種事務問題，實現思路就是手機話費充值這端每天淩晨會上傳一個訂單文件到一個FTP服務器，然後通知銀行那邊去拿這個對賬單文件來對賬，然後再實行差補各種結算。當然具體問題還得具體分析，如果我們現在的業務場景直接也生搬硬套用這種方式來處理會不會也行呢？肯定不行！

我們的業務場景流程：用戶通過APP掃碼搖搖車，消費1塊錢，針對每條訂單馬上所有參與方進行算賬。

1. 用戶賬戶扣1塊錢。

2. 平臺分2毛錢。

3. 城市合夥人賬戶分4毛錢。

4. 商家賬戶分4毛錢。

備註:前面在2.0架構體系裏面已經說過分庫分成用戶庫，平臺庫，城市合夥人庫，商家庫。

所以像這種業務場景，我們這邊目前采用的是基於日誌(事件)的最終一致性來實現分布式事務，當然裏面涉及到知識點也較多，包括數據庫單機事務，MQ消息通知，定時調度，異步等。

在詳細介紹基於日誌(事件)的最終一致性之前，必須先稍微說下柔性事務和剛性事務，其實這些概念沒那麽復雜，所謂的剛性事務是指嚴格遵循ACID原則的事務, 例如單機環境下的數據庫事務，就是之前我們1.0平臺spring事務實現那種。柔性事務稍微復雜點，是指遵循BASE理論的事務, 常見的實現方式有很多種: 兩階段提交(2PC)，TCC補償型提交，基於消息的異步確保型，最大努力通知型等。

我說這麽多其實就是想說：大事務=小事務(原子事務)+異步(消息通知)。

這個裏面每個庫裏面都有兩個事件表，eventPublish(待發布事件表)和eventProcess(待處理事件表)，表設計如下，也可以針對自己業務場景具體設計。

好啦，舉個簡單例子，APP掃碼啟動搖搖車(涉及兩個微服務)。

1. 用戶減少資金(數據庫A)

2. 商家增加資金(數據庫B)

基於日誌(事件)的最終一致性實現思路如下：

1.用戶服務在接收到用戶請求後開啟事務, 減少資金, 並且在eventPublish表創建一條status為1(待發布)的記錄， payload記錄的是事件內容， 提交事務。

2.用戶服務中的定時器掃描，方法裏面開啟事務, 然後查詢eventPublish是否有status為1的記錄，查詢到記錄之後，拿到payload信息，通過MQ將消息發布商家（商家端有MQ實時監聽）。

3.商家服務監聽到MQ傳來的用戶減少資金事件(先判斷下數據庫是否已經存在，如果存在，通過MQ發消息給用戶，向用戶端返回接收成功的消息)， 在eventProcess表創建一條status為1(待處理)的記錄，payload記錄的是事件內容, 如果保存成功, 向用戶端（用戶端有MQ實時監聽）返回接收成功的消息。(目的是用戶端將eventPublish的status為2，下次掃描就不會掃描到了)

4.用戶端監聽到接收成功後的消息，將eventPublish的status為2(已發布)，下次掃描就不會掃描到了，要不然會持續往商家那邊發消息，告訴商家那邊增加資金。

5.商家服務中的定時器掃描，方法裏面開啟事務， 然後查詢eventProcess是否有status為1(待處理)的記錄，查詢到記錄之後， 拿到payload信息，處理業務給商家增加資金. 處理成功之後修改數據庫中eventProcess的status為2(已完成),，最後提交事務。

大概實現思路就是這樣，這種處理方式網絡請求吞吐量是比較高的，基本都是分段式異步處理的。

當然我們的業務場景比這個更加復雜些，一個流程涉及到的原子庫更多，但是大概的思路都是類似處理，整個設計如下：

我們的具體業務情況整個流程還有兩塊也在優化中。

1.異常容災處理，比如分段式進入到中間某段由於各種原因無法進行下一步，而且連續不斷通過MQ和調度在執行多次，這個時候我們會檢測，如果嘗試重試多次無效，會進入到二級消息隊列，並可以後臺人工參與處理。

2.單鏈路方式的靈活性再加強，比如用戶的下一段並不是到商家，也有可能是城市合夥人，或者其它，這個時候可以通過MQ的傳遞參數進行判斷，下一段的到達點。

總之基於MQ分布式業務的處理場景，瓶頸穩定性在於MQ本身，所以這塊必須保證它的持續高可用和穩定性，後續在項目中碰到的細節問題我會繼續分享。

我的物聯網項目(十四) 分布式事務