由於框架一開始的定位就是需要支援強一致性分布式儲存，所以如何實現分布式事務成為乙個大挑戰。作者學習了cockroachdb及tidb等資料庫的實現方式後，決定參考tidb的實現方式，但不同於使用樂觀方式而是採用悲觀鎖方式，遇到事務衝突採用排隊的方式而不是重啟事務。
參考下圖舉例說明一下流程：
業務服務開始事務，其所在的節點作為事務協調者新建乙個事務例項（使用hlc作為事務開始時間戳）；
協調者將命令1加入事務命令列表（如果是第乙個命令則作為事務主記錄），同時向表1的raftleader傳送命令，表1狀態機處理命令時上鎖成功後返回（包含當前節點的hlc）；
同步驟2，但記錄事務主記錄是哪個，用於檢測事務狀態；
業務服務處理完後通知協調者遞交事務，協調者選取所有事務參與者節點最大的hlc作為事務遞交時間戳；
協調者傳送事務遞交命令至事務主記錄所在表1的raftleader，在表1raftgroup持久化事務主記錄狀態後通知協調者立即向業務服務返回事務是否成功遞交；
事務主記錄所在的raftleader向其他參與者的raftleader非同步通知事務遞交。
每個raftgroup's leader都有定時器進行事務狀態檢測：
簡單說明一下每個raft節點的狀態機的處理流程：
接收到讀命令時，如果與當前鎖衝突，則根據事務開始時間戳判斷是通知衝突事務向後更新遞交時間戳，還是忽略該衝突。
如果raft節點意外崩潰後重新啟動時，會先從儲存載入鎖資訊恢復當前鎖列表。根據作者的經驗，鎖並不是影響併發效能的原因，衝突才是，所以做了個簡單的併發測試。
虛擬機器(i74c8g) wrk -t2 -c120 測試約3900tps
對比參照(macbookpro13 i74c16g)：
64執行緒: 呼叫64000次共耗時: 4008毫秒 平均每秒呼叫: 15968
分布式事務 二階段提交
一 二階段提交演算法描述 在分布式系統中，事務往往包含有多個參與者的活動，單個參與者上的活動是能夠保證原子性的，而多個參與者之間原子性的保證則需要通過兩階段提交來實現，兩階段提交是分布式事務實現的關鍵。很明顯，兩階段提交保證了分布式事務的原子性，這些子事務要麼都做，要麼都不做。而資料庫的一致性是由資...
分布式事務 二階段協議
在單個資料庫例項時候，我們可以在乙個資料來源的事務 本地事務 內做多步資料庫操作，在事務內的多個操作要麼全部執行生效，要麼全部不生效。在多資料例項節點時候，我們對多個例項的資料來源進行操作時候就沒辦法把多個操作放到乙個大的事務內來管理了，因為多個例項操作的是不同的資料來源，而資料庫自帶的事務是針對單...
分布式事務 二階段提交與三階段提交
一 二階段提交演算法描述 在分布式系統中，事務往往包含有多個參與者的活動，單個參與者上的活動是能夠保證原子性的，而多個參與者之間原子性的保證則需要通過兩階段提交來實現，兩階段提交是分布式事務實現的關鍵。很明顯，兩階段提交保證了分布式事務的原子性，這些子事務要麼都做，要麼都不做。而資料庫的一致性是由資...