在寫一篇之前說一下TCC模型，即try confirm cancel（嘗試---->送出---->復原）,tcc模型是一個非常典型的2pc（二階段）送出，所謂的兩個階段是指：第一階段：準備階段(投票階段)和第二階段：送出階段（執行階段）。
準備階段
事務協調者(事務管理器)給每個參與者(資料總管)發送Prepare消息，每個參與者要麼直接傳回失敗(如權限驗證失敗)，要麼在本地執行事務，寫本地的redo和undo日志，但不送出，到達一種“萬事俱備，隻欠東風”的狀态。 可以進一步将準備階段分為以下三個步驟：
- ）協調者節點向所有參與者節點詢問是否可以執行送出操作(vote)，并開始等待各參與者節點的響應。
- ）參與者節點執行詢問發起為止的所有事務操作，并将Undo資訊和Redo資訊寫入日志。（注意：若成功這裡其實每個參與者已經執行了事務操作）
- ）各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它傳回一個”同意”消息；如果參與者節點的事務操作實際執行失敗，則它傳回一個”中止”消息。
送出階段
如果協調者收到了參與者的失敗消息或者逾時，直接給每個參與者發送復原(Rollback)消息；否則，發送送出(Commit)消息；參與者根據協調者的指令執行送出或者復原操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源) 接下來分兩種情況分别讨論送出階段的過程。
當協調者節點從所有參與者節點獲得的相應消息都為”同意”時:
1）協調者節點向所有參與者節點發出”正式送出(commit)”的請求。
2）參與者節點正式完成操作，并釋放在整個事務期間内占用的資源。
3）參與者節點向協調者節點發送”完成”消息。
4）協調者節點受到所有參與者節點回報的”完成”消息後，完成事務。
如果任一參與者節點在第一階段傳回的響應消息為”中止”，或者 協調者節點在第一階段的詢問逾時之前無法擷取所有參與者節點的響應消息時：
1）協調者節點向所有參與者節點發出”復原操作(rollback)”的請求。
2）參與者節點利用之前寫入的Undo資訊執行復原，并釋放在整個事務期間内占用的資源。
3）參與者節點向協調者節點發送”復原完成”消息。
- ）協調者節點受到所有參與者節點回報的”復原完成”消息後，取消事務。
其實正常的流程也就是我們上面的圖，曾經有“杠精”說過，如果所有的提供者、消費者挂掉會怎麼辦？
其實，最好的做法就是不去理它
TCC模型了解完了之後，我們可以說說一個高性能TCC架構——hmily（How Much I Love You），名字起得挺有詩意哈，看來作者也是一位性情中人，哈哈
下一篇我會從源碼開始解析Hmily架構