前陣子從支付寶轉賬1萬塊錢到餘額寶，這是日常生活的一件普通小事，但作為網際網路研發人員的職業病，我就思考支付寶扣除1萬之後，如果系統掛掉怎麼辦，這時餘額寶賬戶並沒有增加1萬，資料就會出現不一致狀況了。

　　上述場景在各個型別的系統中都能找到相似影子，比如在電商系統中，當有使用者下單後，除了在訂單表插入一條記錄外，對應商品表的這個商品數量必須減1吧，怎麼保證？！在搜尋廣告系統中，當用戶點選某廣告後，除了在點選事件表中增加一條記錄外，還得去商家賬戶表中找到這個商家並扣除廣告費吧，怎麼保證？！等等，相信大家或多或多少都能碰到相似情景。

　　這些問題本質上都可以抽象為：當一個表資料更新後，怎麼保證另一個表的資料也必須要更新成功。

1 本地事務

　　還是以支付寶轉賬餘額寶為例，假設有

　　支付寶賬戶表：A（id，userId，amount）　　

　　餘額寶賬戶表：B（id，userId，amount）

　　使用者的userId=1；

　　從支付寶轉賬1萬塊錢到餘額寶的動作分為兩步：

　　1）支付寶表扣除1萬：update A set amount=amount-10000 where userId=1;

　　2）餘額寶表增加1萬：update B set amount=amount+10000 where userId=1;

　　如何確保支付寶餘額寶收支平衡呢？有人說這個很簡單嘛，可以用事務解決。

Begin transaction
         update A set amount=amount-10000 where userId=1;
         update B set amount=amount+10000 where userId=1;
End transaction
commit;

　　非常正確！如果你使用spring的話一個註解就能搞定上述事務功能。

@Transactional(rollbackFor=Exception.class)
    public void update() {
        updateATable(); //更新A表
        updateBTable(); //更新B表
    }

　　如果系統規模較小，資料表都在一個數據庫例項上，上述本地事務方式可以很好地執行，但是如果系統規模較大，比如支付寶賬戶表和餘額寶賬戶表顯然不會在同一個資料庫例項上，他們往往分佈在不同的物理節點上，這時本地事務已經失去用武之地。

　　既然本地事務失效，分散式事務自然就登上舞臺。

2 分散式事務—兩階段提交協議

　　兩階段提交協議（Two-phase Commit，2PC）經常被用來實現分散式事務。一般分為協調器C和若干事務執行者Si兩種角色，這裡的事務執行者就是具體的資料庫，協調器可以和事務執行器在一臺機器上。

　　1） 我們的應用程式（client）發起一個開始請求到TC；

　　2） TC先將<prepare>訊息寫到本地日誌，之後向所有的Si發起<prepare>訊息。以支付寶轉賬到餘額寶為例，TC給A的prepare訊息是通知支付寶資料庫相應賬目扣款1萬，TC給B的prepare訊息是通知餘額寶資料庫相應賬目增加1w。為什麼在執行任務前需要先寫本地日誌，主要是為了故障後恢復用，本地日誌起到現實生活中憑證 的效果，如果沒有本地日誌（憑證），容易死無對證；

　　3） Si收到<prepare>訊息後，執行具體本機事務，但不會進行commit，如果成功返回<yes>，不成功返回<no>。同理，返回前都應把要返回的訊息寫到日誌裡，當作憑證。

　　4） TC收集所有執行器返回的訊息，如果所有執行器都返回yes，那麼給所有執行器發生送commit訊息，執行器收到commit後執行本地事務的commit操作；如果有任一個執行器返回no，那麼給所有執行器傳送abort訊息，執行器收到abort訊息後執行事務abort操作。

　　注：TC或Si把傳送或接收到的訊息先寫到日誌裡，主要是為了故障後恢復用。如某一Si從故障中恢復後，先檢查本機的日誌，如果已收到<commit >，則提交，如果<abort >則回滾。如果是<yes>，則再向TC詢問一下，確定下一步。如果什麼都沒有，則很可能在<prepare>階段Si就崩潰了，因此需要回滾。

　　現如今實現基於兩階段提交的分散式事務也沒那麼困難了，如果使用java，那麼可以使用開源軟體atomikos(http://www.atomikos.com/)來快速實現。

　　不過但凡使用過的上述兩階段提交的同學都可以發現效能實在是太差，根本不適合高併發的系統。為什麼？

　　1）兩階段提交涉及多次節點間的網路通訊，通訊時間太長！

　　2）事務時間相對於變長了，鎖定的資源的時間也變長了，造成資源等待時間也增加好多！

　　正是由於分散式事務存在很嚴重的效能問題，大部分高併發服務都在避免使用，往往通過其他途徑來解決資料一致性問題。

3 使用訊息佇列來避免分散式事務

　　如果仔細觀察生活的話，生活的很多場景已經給了我們提示。

　　比如在北京很有名的姚記炒肝點了炒肝並付了錢後，他們並不會直接把你點的炒肝給你，往往是給你一張小票，然後讓你拿著小票到出貨區排隊去取。為什麼他們要將付錢和取貨兩個動作分開呢？原因很多，其中一個很重要的原因是為了使他們接待能力增強（併發量更高）。

　　還是回到我們的問題，只要這張小票在，你最終是能拿到炒肝的。同理轉賬服務也是如此，當支付寶賬戶扣除1萬後，我們只要生成一個憑證（訊息）即可，這個憑證（訊息）上寫著“讓餘額寶賬戶增加 1萬”，只要這個憑證（訊息）能可靠儲存，我們最終是可以拿著這個憑證（訊息）讓餘額寶賬戶增加1萬的，即我們能依靠這個憑證（訊息）完成最終一致性。

3.1 如何可靠儲存憑證（訊息）

　　有兩種方法：

3.1.1 業務與訊息耦合的方式

　　支付寶在完成扣款的同時，同時記錄訊息資料，這個訊息資料與業務資料儲存在同一資料庫例項裡（訊息記錄表表名為message）；

Begin transaction
         update A set amount=amount-10000 where userId=1;
         insert into message(userId, amount,status) values(1, 10000, 1);
End transaction
commit;

　　上述事務能保證只要支付寶賬戶裡被扣了錢，訊息一定能儲存下來。

　　當上述事務提交成功後，我們通過實時訊息服務將此訊息通知餘額寶，餘額寶處理成功後傳送回覆成功訊息，支付寶收到回覆後刪除該條訊息資料。

3.1.2 業務與訊息解耦方式

　　上述儲存訊息的方式使得訊息資料和業務資料緊耦合在一起，從架構上看不夠優雅，而且容易誘發其他問題。為了解耦，可以採用以下方式。

　　1）支付寶在扣款事務提交之前，向實時訊息服務請求傳送訊息，實時訊息服務只記錄訊息資料，而不真正傳送，只有訊息傳送成功後才會提交事務；

　　2）當支付寶扣款事務被提交成功後，向實時訊息服務確認傳送。只有在得到確認傳送指令後，實時訊息服務才真正傳送該訊息；

　　3）當支付寶扣款事務提交失敗回滾後，向實時訊息服務取消傳送。在得到取消傳送指令後，該訊息將不會被髮送；

　　4）對於那些未確認的訊息或者取消的訊息，需要有一個訊息狀態確認系統定時去支付寶系統查詢這個訊息的狀態並進行更新。為什麼需要這一步驟，舉個例子：假設在第2步支付寶扣款事務被成功提交後，系統掛了，此時訊息狀態並未被更新為“確認傳送”，從而導致訊息不能被髮送。

　　優點：訊息資料獨立儲存，降低業務系統與訊息系統間的耦合；

　　缺點：一次訊息傳送需要兩次請求；業務處理服務需要實現訊息狀態回查介面。

3.2 如何解決訊息重複投遞的問題

　　還有一個很嚴重的問題就是訊息重複投遞，以我們支付寶轉賬到餘額寶為例，如果相同的訊息被重複投遞兩次，那麼我們餘額寶賬戶將會增加2萬而不是1萬了。

　　為什麼相同的訊息會被重複投遞？比如餘額寶處理完訊息msg後，傳送了處理成功的訊息給支付寶，正常情況下支付寶應該要刪除訊息msg，但如果支付寶這時候悲劇的掛了，重啟後一看訊息msg還在，就會繼續傳送訊息msg。

　　解決方法很簡單，在餘額寶這邊增加訊息應用狀態表（message_apply），通俗來說就是個賬本，用於記錄訊息的消費情況，每次來一個訊息，在真正執行之前，先去訊息應用狀態表中查詢一遍，如果找到說明是重複訊息，丟棄即可，如果沒找到才執行，同時插入到訊息應用狀態表（同一事務）。

for each msg in queue
  Begin transaction
    select count(*) as cnt from message_apply where msg_id=msg.msg_id;
    if cnt==0 then
      update B set amount=amount+10000 where userId=1;
      insert into message_apply(msg_id) values(msg.msg_id);
  End transaction
  commit;

參考文獻

程立，大規模SOA系統中的分散式事務處理