[TOC] # 簡介 兩階段提交(2PC),在客戶端和多個數據庫之間增加了一個事務協調者,同時**將事務的提交分為準備和提交兩個階段** # 準備階段 事務協調者給每個數據庫發送prepare消息,**每個數據庫要在本地執行事務,寫本地的redo和undo日志,但不提交日志** 大致流程如下: 1. 事務協調者節點向所有數據庫詢問是否可以執行提交操作,并開始等待各參與者節點的響應 2. 數據庫節點執行詢問發起為止所有事務操作,并將undo信息和redo信息寫入日志 3. 數據庫節點響應事務協調者節點發起的詢問.如果數據庫節點的事務操作實際執行成功,則返回一個'同意'消息.如果執行失敗,則返回一個'中止'消息 # 提交階段 如果事務協調者收到了數據庫的中止消息或等待超時,則直接發給每個數據庫發送rollback消息,要求回滾操作. 如果事務協調者收到了數據庫的同意消息,則發送commit消息,要求進行提交操作. 執行完畢之后釋放所有事務處理過程中使用的資源 大致流程如下 1. 事務協調者節點向所有數據庫發起commit/rollback請求,并開始等待各參與者節點的響應 2. 數據節點執行commit/rollback動作并釋放事務占用的資源,之后向事務協調者發送完成消息 3. 事務協調者收到所有數據庫的反饋消息后完成或取消事務 # 問題 兩階段提交看似解決了分布式數據一致性的問題,其實這個設計存在一些明星的問題: 1. 阻塞執行,速度慢 : 從剛才描述可以看出,協調者和數據庫的一系列提交或回滾動作都是阻塞執行的,這必然導致整個分布式事務運行效率緩慢 2. 單點問題 : 兩階段提交的核心樞紐是事務協調者節點,如果這個節點失效了,那么整個事務機制也就癱瘓了.同時由于協調者失效,會導致數據庫的資源一直占有無法釋放 3. 數據不一致 : 試想一下,在提交階段,當事務協調者向所有數據發送commit請求之后,由于網絡問題只有一部分數據庫收到了請求消息并執行了commit消息,而另一部分數據庫沒有收到commit消息,多個數據庫之間就會產生數據不一致的問題