轉載：https://github.com/seata/seata/wiki/概覽
幾個點，持續更新：
有個疑惑：之前對於tcc-transaction的理解是：每個分支事務鎖住資源，並不提交，等全部都confirm了，然後統一提交。 而Fescar是每個分支都會直接提交併生成日誌，不佔住資源；如果最後全局的結果是提交那麼就什麼都不做，如果最後結果回滾的話就解析日誌來重新更新。 但Fescar這樣的話，是會維護一個全局寫排他鎖的，保證分支提交的更新在全局確認提交之前不會被讀取，但這樣的話不也是佔住了資源嗎？這樣有什麼好處？
轉載：芋道源碼
l這個全局鎖的機制是服務端維護的一個鎖並非數據庫層面的，所以這個鎖僅針對fescar發起的事務有效。比如A事務包含BCD分支，需要修改TableA，後續事務如果想修改TableA就需要經過lockkey檢查，直到A事務釋放鎖。如果有一個業務操作沒有發起事務也去修改TableA，這個是不需要lockkey檢查的（有可能）。