章節(jié)歸屬
二階段提交的作用
二階段提交是為了要保證分布式事務(wù)的原子性，理解這里的原子性：通過協(xié)調(diào)準(zhǔn)備、執(zhí)行兩步操作，整個(gè)過程要么成功，要么失敗回滾，對外部來說，該事務(wù)的狀態(tài)變化是原子的。
二階段提交的角色
概念解釋比較抽象，邊看邊理解即可。
TC (Transaction Coordinator) - 事務(wù)協(xié)調(diào)者
維護(hù)全局和分支事務(wù)的狀態(tài)，驅(qū)動全局事務(wù)提交或回滾。
TM (Transaction Manager) - 事務(wù)管理器
定義全局事務(wù)的范圍：開始全局事務(wù)、提交或回滾全局事務(wù)。
RM (Resource Manager) - 資源管理器
管理分支事務(wù)處理的資源，與TC交談以注冊分支事務(wù)和報(bào)告分支事務(wù)的狀態(tài)，并驅(qū)動分支事務(wù)提交或回滾。
XA規(guī)范
是X/Open DTP定義的事務(wù)協(xié)調(diào)者 與 數(shù)據(jù)庫 之間的接口規(guī)范，即 TC <--XA--> RM；事務(wù)些調(diào)整通過這個(gè)XA規(guī)范來通知數(shù)據(jù)庫事務(wù)的開始、結(jié)束（提交/回滾）
XA規(guī)范的實(shí)現(xiàn) 由數(shù)據(jù)庫廠商提供。
二階段提交的工作流程
整個(gè)流程是TC和 多個(gè)RM之間的一個(gè)互動的過程，簡單來說就是【預(yù)備->跑】 這樣兩個(gè)過程，即準(zhǔn)備和執(zhí)行兩個(gè)階段：
- 準(zhǔn)備階段：TC通知每個(gè)RM準(zhǔn)備，RM開始執(zhí)行分支事務(wù)，但是不提交，相關(guān)資源會被鎖；每個(gè)RM給TC反饋已準(zhǔn)備就緒，等待下一步的提交指令進(jìn)行分支事務(wù)提交。
- 提交階段：TC通知每個(gè)RM提交分支事務(wù)，RM完成分支事務(wù)提交后，釋放資源并反饋TC；TC確認(rèn)所有RM的分支事務(wù)完成后，流程結(jié)束
二階段提交的角色解讀
- TM即其實(shí)整個(gè)事務(wù)的發(fā)起者，這個(gè)發(fā)起者內(nèi)的邏輯決定了本次大事務(wù)覆蓋的分支事務(wù)有哪些，其執(zhí)行邏輯控制著整個(gè)大事務(wù)的開始、結(jié)束(提交/回滾）
- 由于每個(gè)RM(數(shù)據(jù)庫)可以保證自己數(shù)據(jù)庫中的分支事物，但不能保證除自己以外的其他RM(數(shù)據(jù)庫)的分支事務(wù)，因此需要第三方（TC）介入?yún)f(xié)調(diào)；
- 理論上這個(gè)TC可以是由TM自己來兼職，但從職責(zé)邊界的角度看，如果TC是獨(dú)立的，那么TM和RM就會變得很輕巧，TC的功能也會更內(nèi)聚，也更容易通過集群部署提升可用性。
二階段提交的異常流程
TC通知每個(gè)RM準(zhǔn)備，其中部分RM反饋準(zhǔn)備階段出錯(cuò)；或者TC在規(guī)定時(shí)間內(nèi)沒收到所有RM完成準(zhǔn)備的反饋； TC要發(fā)起回滾通知每個(gè)RM。
因天然的存在網(wǎng)絡(luò)和設(shè)備問題，會導(dǎo)致TC 和 RM 出現(xiàn)異常：
-
- TC異常：
- 1.1 TC發(fā)出【準(zhǔn)備】指令前出問題，對RM無影響，因?yàn)镽M都未開始事務(wù)，不占用RM的資源
- 1.2 TC發(fā)出【準(zhǔn)備】指令后【提交】指令前，TC出問題，各RM開始執(zhí)行事務(wù)并掛起等待下一步的提交指令，相關(guān)的資源會被鎖定，其他的事務(wù)若要操作被鎖定的資源也需等待；
- 1.3 TC發(fā)出【提交】指令后，TC出問題，若部分RM異常，那就出現(xiàn)了部分RM正常執(zhí)行，部分RM未正常執(zhí)行，即產(chǎn)生了數(shù)據(jù)不一致的問題。
-
- RM出問題
- 2.1 TC發(fā)出準(zhǔn)備指令后，部分RM反饋準(zhǔn)備階段出錯(cuò)，或者TC在規(guī)定時(shí)間內(nèi)沒收到所有RM完成準(zhǔn)備的反饋； TC要通知每個(gè)RM回滾。
- 2.2 TC發(fā)布提交指令后，部分RM出問題，那么也會產(chǎn)生數(shù)據(jù)的不一致問題
二階段的缺陷
所有問題可以歸為以下三種：
- 協(xié)調(diào)者故障：
需通過集群高可用來規(guī)避單機(jī)故障 - 性能問題（資源利用率低）：
等待指令，如果遇到網(wǎng)絡(luò)或節(jié)點(diǎn)問題，會導(dǎo)致長時(shí)間等待，處于掛起狀態(tài)；需要通過增加超時(shí)自省機(jī)制，來限制掛起時(shí)間，并指定超時(shí)后的默認(rèn)處理 - 數(shù)據(jù)不一致：
這個(gè)沒有絕對的保證，只能盡量。通過【鴕鳥算法】了解更多。
三階段提交協(xié)議
正常流程
- can commit： TC協(xié)調(diào)所有RM進(jìn)行預(yù)檢，預(yù)檢過程不鎖定資源
- pre commit：收到所有RM的can commit的正常反饋后，TC通知所有RM開啟并執(zhí)行事務(wù)但不提交事務(wù)
- do commit：收到所有RM的pre commit的正常反饋后,TC通知所有RM提交事務(wù)
關(guān)鍵設(shè)計(jì)
目標(biāo)是通過引入以下邏輯來修復(fù)二階段的缺陷：
- 引入預(yù)檢環(huán)節(jié)，避免在不具備鎖定資源的條件下鎖定資源
- 在TC和RM中都引入超時(shí)機(jī)制，超時(shí)后自醒，主動執(zhí)行自認(rèn)為合理的下一步邏輯（回滾或者提交），避免無上限的掛起：
2.1 TC端，遇到超時(shí)就給RM發(fā)abort指令，中斷整個(gè)事務(wù)
2.2 RM端，在收到can commit 后，pre commit之前，超時(shí)自醒后直接中斷RM的分支事務(wù)
2.3 RM端，在收到pre commit 指令后，等待下一步的do commit指令超時(shí)，直接提交事務(wù)（大概率是正確的選擇，但如果是錯(cuò)誤的選擇就導(dǎo)致了數(shù)據(jù)的不一致）
異常流程
1. can commit階段：
- 部分RM直接反饋不能開始事務(wù)，TC向所有RM發(fā)送abort請求。
- TC等待反饋超時(shí)，TC向所有RM發(fā)送abort請求。
- RM預(yù)檢沒問題，但一直無法接收到下一步的的指令（反饋can commit超時(shí) 或接收TC 下一步指令超時(shí)），執(zhí)行事務(wù)的中斷
- RM收到來自TC的abort請求之后執(zhí)行事務(wù)的中斷;
2. pre commit階段
- TC收到RM反饋異常，向所有RM發(fā)送abort請求，執(zhí)行回滾
- TC等待反饋超時(shí)，向所有RM發(fā)送abort請求，執(zhí)行回滾
3. do commit階段
- RM收到pre commit指令并正常執(zhí)行事務(wù)，給TC反饋pre commit完成后，理論上是要等待下一步的do commit指令后才提交事務(wù)；但是如果未能等到下一步的do commit指令超時(shí)了，會自主提交事務(wù)。因?yàn)榻?jīng)過預(yù)檢通過，執(zhí)行到這個(gè)階段整個(gè)事務(wù)成功的概率已經(jīng)很高了；
- 部分RM 執(zhí)行pre commit異常，部分RM 執(zhí)行 pre commit 正常，但此時(shí)TC掛了，那么通過RM的超時(shí)自醒機(jī)制,就出現(xiàn)部分RM提交，部分RM回滾，出現(xiàn)數(shù)據(jù)不一致。
- 另外一種情況，TC發(fā)送了abort 指令，RM超時(shí)未收到指令就提交了事務(wù)，其他RM收到了TC發(fā)送的abort指令后執(zhí)行了回滾，會出現(xiàn)數(shù)據(jù)不一致。
三階段的優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：通過預(yù)檢，避免了資源的無效占用；TC端和RM端各自的超時(shí)自醒處理，避免長時(shí)間資源占用不釋放。提高資源利用率
缺點(diǎn)：多出了一個(gè)流程，增加了復(fù)雜度；依然有數(shù)據(jù)不一致的問題
