tcc、2pc、percolator（2pc改進，改進第二階段，不用commit兩次）、goldendb（2pc改進，改進第一階段，不用通訊兩次，直接跟事務管理器通訊一次）
以小明轉賬給小紅2000為例：
寫操作優化方法：
1 快取寫提交：將所有寫操作快取起來，直到 commit 語句時一起執行能減少一輪共識演算法開銷，避免了1的問題能減少一輪共識演算法開銷，但是
1.1 如果某個業務場景同時存在長事務和海量併發的特點，那麼這個快取就可能被撐爆或者成為瓶頸
1.2 在 mysql 中如果出現事務競爭，判斷優先順序的規則是 first write win，也就是對同一條記錄先執行寫操作的事務獲勝。而db因為快取了所有寫 sql，所以就變成了 first commit win，也就是先提交的事務獲勝，導致錯誤
3 並行提交：在2的基礎上，準備階段時寫入事務標誌，使commit階段也並行執行，得到反饋後，非同步提交
這樣就只需要一輪共識演算法的開銷了使用mvcc解決顯式的讀寫衝突
pgxc也是使用單機的mvcc來解決這個問題，遇到的挑戰是：
1 保證產生單調遞增事務 id，這需要由乙個集中點來統一生成
2 提供全域性快照。每個事務要把自己的狀態傳送給乙個集中點，由它維護乙個全域性事務列表，並向所有事務提供快照
這就是全域性事務管理器的功能了，或者叫全域性時鐘
newsql，可以分為是否有全域性事務列表，如果沒有，則等於不採用mvcc，如果有，則比如cockroachdb，實現了序列化：
全域性事務列表是否存在和實現哪種隔離級別這兩個因素都會影響設計
隱式的衝突由時間的不確定性造成，可以使用等待來消除不確定性：「waiting out the uncertainty」，等待不確定性過去
寫等待：寫盤時間往後寫寫衝突則通過樂觀、悲觀鎖來完成影響範圍大，所有包含寫操作的事務都要至少等待乙個誤差週期
適用於誤差很小的系統，spanner 能夠將時間誤差控制在 7 毫秒以內，所以有條件使用該方式
讀等待：衝突時關閉，重啟後重新判斷
影響範圍小，只有當讀操作時間戳與訪問資料項的提交時間戳落入不確定時間視窗後才會觸發，但讀等待的週期可能更長，可能是數個誤差週期，因為要跳過所有不確定時間視窗（實現方式是重啟）
適用於誤差更大的系統，cockroachdb 對誤差的預期達到 250 毫秒。
分布式協議更多使用悲觀，一是事務衝突少是使用樂觀協議的前提，但這個前提並不是普遍成立，二是現有應用系統使用的單體資料庫多是悲觀協議，這是相容性上的挑戰
樂觀鎖可以理解就是使用percolator（相對樂觀，雖然區域性是悲觀，但全域性是樂觀，嚴格樂觀則是rvw（讀-驗證-寫）），悲觀鎖則是在原有的區域性有效性確認前，增加一輪全域性有效性確認，還要增加死鎖檢測機制
併發控制協議體系如下：
2pl為資料庫常用的協議：
根據加鎖和釋放鎖時機的不同，2pl 又有一些變體：c2pl（事務在開始時設定它需要的所有鎖）、s2pl（事務一直持有已經獲得的所有寫鎖，直到事務終止，如percolator）、ss2pl（事務一直持有已經獲得的所有鎖，直到事務終止）
而效能優於s2pl的工程化實現則為cockroachdb 的序列化快照隔離（ssi，同樣是相對樂觀），而 ssi 的 核心，就是序列化圖檢測（sgt），有依賴關係的事務則會畫上一條有向邊，如果形成環，說明無法序列化，比如死鎖、rw（第二個寫操作新增了第乙個讀操作應該讀取的值，可 能導致讀取值過期）
解決rw可以使用基於rtc的方案：
當執行任何的讀取操作時，操作的時間戳都會被記錄在所訪問節點的本地 rtc 中；
當任何寫操作訪問這個節點時，都會以將要訪問的 key 為輸入，向 rtc 查詢最大的讀時間戳（mrt）；
如果 mrt 大於這個寫入操作的時間戳，那繼續寫入就會形成 rw 依賴。這時就必須終止並重啟寫入事務，讓寫入事務拿到乙個更大的時間戳重新嘗試（類似mysql的間隙鎖原理）
paxos 是對單值或者一種狀態達成共識的過程，而 2pc 是對多個不同資料項的變更或者多個狀態，達成一致的過程
同乙個事務中發生變更的資料必定擁有用相同的提交時間戳，所以使用時間戳就可以回溯同一事務內的相關操作。同時，晚提交的事務一定擁有更大的時間戳
分布式資料庫
網路選課系統中分布式資料庫設計 何翠雙王巧雲張麗麗 摘要 關鍵字 選課 分布式 資料庫 distributed system of on line course choosing abstract key words course choosing distributed database 隨著學校...
分布式資料庫
1 背景 我們知道資料是乙個公司的命脈，隨著業務越做越大，資料量也會越來越大，計算也會越來越複雜，效能，可靠性，可擴充套件性的需求就會越來越強烈，這個時候乙個集中式的資料庫顯然已經滿足不了需求了。對於技術決策者來說有兩條路可以走，第一 按照現有的大型資料庫的解決方案，比如sql server clu...
分布式資料庫
一 分布式資料庫的出現的場景 網際網路 軟體國產化 o2o 五新 新零售 新製造，新金融 新資源 新技術 等主題接連提出來，並且在各個行業落地，給資料庫帶來了巨大機會，具體包含3個方向 1.遠超單機資料庫容量的資料儲存和訪問峰值 2.實時資料分析檢索 oltp兼顧olap 3.更高階別的容災需求。這...