關於分佈式事務的處理

通常事務解決方案：

兩個階段：將提交分紅兩階段進行的目的很明確，就是儘量晚地提交事務，讓事務在提交前儘量地完成全部能完成的工做，這樣，最後的提交階段將是一個耗時極短的微小操做，這種操做在一個分佈式系統中失敗的機率是很是小的

 

準備階段：事務協調者(事務管理器)給每一個參與者(資源管理器)發送Prepare消息，每一個參與者要麼直接返回失敗(如權限驗證失敗)，要麼在本地執行事務，寫本地的redo和undo日誌，但不提交。

 

提交階段：若是協調者收到了參與者的失敗消息或者超時，直接給每一個參與者發送回滾(Rollback)消息；不然，發送提交(Commit)消息。

 

一階段提交(Best Efforts 1PC模式)：從應用程序向數據庫發出提交請求到數據庫完成提交或回滾以後將結果返回給應用程序的過程。

 

TCC編程模式：也是兩階段提交的一個變種。TCC提供了一個編程框架，將整個業務邏輯分爲三塊：Try、Confirm和Cancel三個操做。以在線下單爲例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態，若是更新訂單失敗，則進入Cancel階段，會去恢復庫存。

 

通常商城分佈式事務解決：

在後臺管理系統中更新商品後，須要同步搜索系統、詳情繫統商品信息：這時候會發送MQ消息，而後在搜索系統、詳情繫統會訂閱消息，接收到消息後執行對應操做。

在後臺中，管理系統在同一個事務中執行的內容：更新商品數據，發送MQ消息；若是更新商品數據失敗那麼則回滾，而且不會發送MQ消息；若是發送MQ消息失敗，那麼也將回滾商品數據的更新。

在搜索系統、詳情繫統中監聽MQ消息，執行對應的同步更新操做，若是消息接收失敗那麼ActiveMQ會從新發送6次消息，而且作了消息持久化，只要搜索系統、詳情繫統沒有接收消息那麼下次則會重發保證消息的成功傳遞。至於接收到消息後搜索、詳情繫統的執行失敗是不會回滾在後臺管理系統的操做的；因此在開發過程當中須要保證搜索、詳情繫統的執行成功率很是高。