個人物聯網項目(十四) 分佈式事務

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自己，因此這塊必須保證它的持續高可用和穩定性，後續在項目中碰到的細節問題我會繼續分享。