強一致性的分散式事務幾種模式對比

四種分散式事務模式的對比

第一種 XA模式

MySQL XA 是基於Open Group的Distributed Transaction Processing標準實現的，支援分散式事務，允許多個資料庫例項參與一個全域性的事務。MySQl XA 從MySQL 5.0 開始引入，僅innodb儲存引擎支援MySQL XA事務。

第二種 LCN模式

LCN 是一款事務協調性的框架，框架本身並不建立事務，只是對本地事務做協調控制。因此該框架與其他第三方的框架相容性強，支援所有的關係型資料庫事務，支援多資料來源，支援與第三方資料庫框架一塊使用（例如 sharding-jdbc），在使用框架的時候只需要新增分散式事務的註解即可，對業務的侵入性低。

官網地址：www.codingapi.com/docs/home/

第三種 AT模式

Seata 是一款開源的分散式事務解決方案，致力於提供高效能和簡單易用的分散式事務服務，提供了 AT、TCC、SAGA 和 XA 四種事務模式。這裡主要說明的是AT模式。Seata的AT模式本質上對2PC協議的優化演進，它是工作在Java應用層的中介軟體，通過對支援本地 ACID 事務的關係型資料庫的分支事務的協調來驅動完成全域性事務。

官網地址：seata.io/zh-cn/

第四種 RT模式

RT 是一款開源的為php各大框架提供分散式事務的composer包。RT模式是reset transaction的簡稱，也就是重置型事務的意思。特別適用於orm框架，寫法跟普通事務一致，預設支援mysql，http協議的服務，簡單易用。

部落格：Laravel基於reset機制實現分散式事務

對RT模式的疑問

疑問1：RT模式相比AT模式，少了事務協調器(TC)，但是為何很多方面都要優於AT模式？

AT模式請求每個api服務後，都提交了事務。如果其中某一個服務出現異常了，需要全部回滾，這時AT模式需要每次執行sql語句時，生成反向sql並且記錄到undo_log表，事務協調器把異常服務和前面正常服務的所有反向sql執行一遍。這樣子實現了所有資料回退。

相比之下，RT模式請求每個api服務後，都全部回滾，生成正向sql並且記錄到reset_transaction表。所以不需要事務管理器去管理服務。如果其中某一個服務出現異常了，由業務發起rollback或者網路異常下放棄往後執行程式碼。奇怪，連程式碼執行一半放棄了都沒事，那是因為所有的正向sql只有最後一步提交事務的時候，才全部處理。

疑問2：RT模式相比AT模式，是如何做到資料一致性？

AT模式在本地事務提交前必須先向服務端註冊分支，分支註冊資訊中包含由表名和行主鍵組成的全域性鎖，簡單來說就像mysql的序列化。通過序列化實現了資料的一致性。如果其它服務也有相同表資料的更新時，還是會有髒資料產生。

相比之下，RT模式在本地事務呼叫api服務介面都不加鎖，但是要保留校驗值。在最後一步提交時候，對sql的校驗值進行校驗，以此來保證資料一致性，並且大大地提升效能。

提問3：RT模式為何喜歡跟AT模式比較，不跟TCC模式比較呢？
RT模式和AT模式是屬於強一致性事務，TCC是屬於最終一致性事務，所以RT模式最適合的比較物件是AT模式。而且AT模式是阿里seata框架的主要推廣的模式，使用的人特別多，已經成為強一致性分散式事務的領頭羊。

提問4：RT模式有哪些缺點呢？

RT模式因為是重置型，有一個缺點是每次的讀檔，是把之前相同一個服務下執行過的sql語句又重新執行一遍。如果呼叫訂單服務次數是m，呼叫賬戶服務次數是n，總共執行sql語句的次數等於(1+m)m/2+(1+n)n/2。不過也不用太擔心，因為讀檔是把mysql拼接成一條sql語句，加快讀檔的效率。這一塊，後續還在研究中，努力做得更加完善。

個人筆記

由於分散式事務解決方案這一塊，幾乎被java壟斷，所以我也只能含著淚去閱讀seata的原始碼。正是不斷地瞭解seata，越加發現RT模式的閃光點，所以忍不住要把RT模式的閃光點展示出來。希望php也能誕生出強一致性的分散式解決方案，方便php的微服務框架解決資料一致性的問題。

本作品採用《CC 協議》，轉載必須註明作者和本文連結