MyCAT、DRDS、TIDB、TDSQL、TBase 在實現分散式事務時的區別及其各自的優勢？

TBase是基於PostgreSQL開發的企業級分散式HTAP資料庫，這裡介紹下TBase在分散式事務方面的一些經驗：

**1.傳統基於MVCC+2PC+GTM做的分散式事務，在高併發的情況下這種基於GTM全域性快照的設計會在GTM上有比較大的效能壓力。**一個是GTM加鎖遍歷生成全域性快照中活動事務列表計算的開銷以及鎖衝突開銷，另一個是高併發下活動事務列表過大導致快照大小膨脹帶來的網路開銷。這兩點導致這種設計在高併發情況下效能受限。

**2.Google Spanner基於原子時鐘和true time api實現了一致性的分散式事務，但需要昂貴的裝置支援。**Google Percolator採用全域性時鐘提供一致性分散式事務，但Percolator在一階段提交時需要遍歷資料將鎖資訊寫入到資料單位，二階段時又需要遍歷資料釋放鎖寫入提交時間戳等資訊。事務提交開銷變大且與資料量相關。

**3.TBase在參考Spanner/Percolator的基礎上，為避免上述效能問題，創新性的結合MVCC+2PC提出了一種輕量級的基於全域性時鐘（GTS）的一致性分散式協議及演算法。**主要思路是在兩階段提交中的prepare階段作為全域性同步點結合GTS的原子遞增性保證多節點間的資料一致性和隔離性。基本消除GTM的網路開銷問題，並將GTM單點壓力分散到分散式多節點中。主要從以下幾個方面進行優化：

MVCC從基於全域性快照事務ID+事務狀態的可見性判斷，優化為基於GTS+事務狀態的可見性判斷在當前節點prepare到收到commit通知之前會有事務鎖保證全域性一致

為了避免Percolator的提交開銷變大的情況，TBase在提交時只記錄一次事務提交GTS到時間戳日誌，避擴音交開銷。

後續進行可見性判斷時，結合時間戳日誌判斷事務狀態，且對時間戳日誌進行快取加速。隨後在tuple的header記錄中快取事務狀態及提交GTS資訊，進一步加速後續掃描的可見性判斷。

1.TBase同時對MVCC空間回收進行改造，融入到基於GTS的一致性分散式事務中。

2.優化後GTM只負責分配全域性時間戳，且設計了一種多核可擴充套件的全域性原子遞增時間戳演算法進一步提高單點GTS分配效能。