目錄

• 二階段提交協議
• TCC（Try-Confirm-Cancel）
• • 預留成功
  • 預留失敗
• 三階段提交協議
• 總結
• Some questions
• • reference

ACID理論時對事務特性的抽象和總結，想要實現ACID需要掌握二階段提交協議以及TCC
這里是有關協議的論文PDF鏈接：

CONCURRENCY CONTROLAND RECOVERY IN DATABASE
SYSTEMS

二階段提交協議

二階段提交協議：通過二階段的協商來完成一個提交操作

首先定義一個分布式事務操作，發起這個事務到分布式系統種的節點中。某一個節點收到消息后扮演協調者身份，與其他節點聯系，發送網絡消息，發起二階段提交。
然后協調者進入請求提交階段（即投票階段），其他節點進行評估，評估事務中需要操作的對象和對象狀態是否準備好、是否提交新操作，然后回復協調者，
協調者收到所有回復后，進入提交執行階段（即完成階段）。協調者先執行事務，然后通知其他節點，其他節點接收到通知后也執行事務，然后將事務結果返回給協調者。
協調者將總結果返回給客戶。

需要注意的是：
在第一階段，每個參與者投票表決事務是放棄還是提交。一旦參與者投票要求提交事務，那么就不允許放棄事務。即：
在一個參與者投票要求提交事務之前，它必須保證能夠執行提交協議中它自己的那一部分，即使參與者出現故障或者中途被替換。

不過二階段協議也存在問題：
1、在提交請求階段，需要預留資源，在資源預留期間，其他人不能操作（MySQL XA協議在第一階段會將相關資源鎖定）
2、數據庫是獨立的系統

所以無法根據業務特點彈性調整鎖的粒度，會影響到數據庫的并發性能。

TCC（Try-Confirm-Cancel）

TCC是預留、確認、撤銷三個操作的簡稱，包含了預留、確認or撤銷兩個階段。

預留成功

進入預留階段，步驟如下：

如果預留階段的執行都沒有問題，就進入確認階段，步驟如下：

預留失敗

假設節點2分配資源失敗了：

那么會進入撤銷階段：

TCC本質：補償事務
它的核心思想是針對每個操作都要注冊一個與其對應的確認操作和補償操作（也可以稱為撤銷操作）。
它是一個業務層面的協議，TCC的三個操作需要在業務代碼中編碼實現。為了實現一致性，確認操作和補償操作必須是冪等的，因為這2個操作可能會失敗重試。
Tips：冪等性是指同一操作對同一系統的任意多次執行，所產生的影響均與一次執行的影響相同，不會因為多次執行而產生副作用。常見的實現方法有Token、索引等。本質是通過唯一標識，標記同一操作的方式來消除多次執行的副作用。

三階段提交協議

三階段提交協議，針對二階段提交協議的痛點：協調者故障，參與者長期鎖定資源，引入了詢問階段和超市機制，來減少資源被長時間鎖定的情況，但是會導致集群各個節點在正常運行的情況下，使用更多的消息進行協商，增加系統負載和響應延遲。所以三階段提交協議很少使用。

總結

Some questions

在兩階段提交協議中，如果一個節點在第一階段確認可以提交，但是它之后崩潰了，第二階段無法實現自己那部分事務，此時該如何是好？
需要將提交的相關信息持久化到磁盤，然后重啟，恢復到之前狀態

reference

ACID理論：CAP的酸，追求一致性