Fescar概念

轉載:https://github.com/seata/seata/wiki/概覽
幾個點,持續更新:
有個疑惑:之前對於tcc-transaction的理解是:每個分支事務鎖住資源,並不提交,等全部都confirm了,然後統一提交。 而Fescar是每個分支都會直接提交併生成日誌,不佔住資源;如果最後全局的結果是提交那麼就什麼都不做,如果最後結果回滾的話就解析日誌來重新更新。 但Fescar這樣的話,是會維護一個全局寫排他鎖的,保證分支提交的更新在全局確認提交之前不會被讀取,但這樣的話不也是佔住了資源嗎?這樣有什麼好處?

轉載:芋道源碼
l這個全局鎖的機制是服務端維護的一個鎖並非數據庫層面的,所以這個鎖僅針對fescar發起的事務有效。比如A事務包含BCD分支,需要修改TableA,後續事務如果想修改TableA就需要經過lockkey檢查,直到A事務釋放鎖。如果有一個業務操作沒有發起事務也去修改TableA,這個是不需要lockkey檢查的(有可能)。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章