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

兩階段提交協議（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 如何可靠保存憑證（消息）

有兩種方法：

3.1.1 業務與消息耦合的方式

　　支付寶在完成扣款的同時，同時記錄消息數據，這個消息數據與業務數據保存在同一數據庫實例里。

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。

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

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;

ebay的研發人員其實在2008年就提出了應用消息狀態確認表來解決消息重復投遞的問題：http://queue.acm.org/detail.cfm?id=1394128。

 

補充:

　　之前看多阿里大神程立的一個關於分布式事務的文檔，目前使用較多的分布式事務解決方案有幾種：
　　一、結合MQ消息中間件實現的可靠消息最終一致性
　　二、TCC補償性事務解決方案
　　三、最大努力通知型方案

　　第一種方案：可靠消息最終一致性，需要業務系統結合MQ消息中間件實現，在實現過程中需要保證消息的成功發送及成功消費。即需要通過業務系統控制MQ的消息狀態
　　第二種方案：TCC補償性，分為三個階段TRYING-CONFIRMING-CANCELING。每個階段做不同的處理。
　　　　　　　　TRYING階段主要是對業務系統進行檢測及資源預留
　　　　　　　　CONFIRMING階段是做業務提交，通過TRYING階段執行成功后，再執行該階段。默認如果TRYING階段執行成功，CONFIRMING就一定能成功。
　　　　　　　　CANCELING階段是回對業務做回滾，在TRYING階段中，如果存在分支事務TRYING失敗，則需要調用CANCELING將已預留的資源進行釋放。
　　第三種方案：最大努力通知xing型，這種方案主要用在與第三方系統通訊時，比如：調用微信或支付寶支付后的支付結果通知。這種方案也是結合MQ進行實現，例如：通過MQ發送http請求，設置最大通知次數。達到通知次數后即不再通知。
　　　　　　　　具體的案例你也可以參考下這篇博客，它上面的這個案例就是結合電商支付做的系統分布式事務實現案例：http://www.roncoo.com/article/detail/124243

　　基於事務消息的MQ方案是目前公認的較為理想的分布式事務解決方案，各大電商都在應用這一方案。種方式適合的業務場景廣泛，而且比較可靠。不過這種方式技術實現的難度比較大。目前主流的開源MQ（ActiveMQ、RabbitMQ、Kafka）均未實現對事務消息的支持，所以需二次開發或者新造輪子。