一、事務的概念 　　事務是一組操作的執行單元，相對於數據庫操作來講，事務管理的是一組SQL指令，比如增加，修改，刪除等，事務的一致性，要求，這個事務內的操作必須全部執行成功，如果在此過程種出現了差錯，比如有一條SQL語句沒有執行成功，那么這一組操作都將全部回滾 　　最經典的例子便是：A向B匯款 ...

現在先拋出問題，假設有一個主數據中心在北京M，然后有成都A，上海B兩個地方數據中心，現在的問題是，假設成都上海各自的數據中心有記錄變更，需要先同步到主數據中心，主數據中心更新完成之后，在把最新的數據分發到上海，成都的地方數據中心A，地方數據中心更新數據，保持和主數據中心一致性（數據庫結構 ...

一、強一致性事務的瓶頸 　　在《分布式強一致性事務》一文中介紹了分布式事務的常用協議2PC二階段提交，雖然2PC能在很大程度上實現分布式事務中各節點的ACID，但也存在同步阻塞問題，協調者單點故障，協調者因網絡原因導致的通知不周或收不全參與者回復導致的異常等問題。 　　同時，即使能穩定的使用 ...

分布式事務(1)-理論基礎 分布式事務(2)---強一致性分布式事務解決方案 分布式事務(4)---最終一致性方案之TCC 前面介紹強一致性分布式解決方案，這里用Atomikos框架寫一個實戰的demo。模擬下單扣減庫存的操作。 使用Atomikos，mybatis-plus框架搭建項目 ...

分布式事務(1)-理論基礎 分布式事務(3)---強一致性分布式事務Atomikos實戰 分布式事務(4)---最終一致性方案之TCC 強一致事務要求在任意時刻各節點數據在任意時刻都是一致的。強一致事務的解決方案主要有DTP模型（全局事務模型）、2PC、3PC。 強一致性數據一致性 ...

我覺得事務的管理不應該屬於Dubbo框架， Dubbo只需實現可被事務管理即可， 像JDBC和JMS都是可被事務管理的分布式資源， Dubbo只要實現相同的可被事務管理的行為，比如可以回滾， 其它事務的調度，都應該由專門的事務管理器實現 ...

最終一致性，從其名字看，已經放棄了強一致性，如果出現異常情況，很有可能會產生主業務已提交，邊緣業務最終也沒能一致的情況。如網絡持續不通，一段時間重試后，任務不得不放棄 因此最終一致性還有一層隱含信息->做好最終不一致的備案，否則可能造成不可預期的問題。 目前做法 和事務型數據庫一同提交 ...

分布式事務協議 下面介紹幾種實現分布式事務的協議。 兩階段提交協議 2PC 分布式系統的一個難點是如何保證架構下多個節點在進行事務性操作的時候保持一致性。為實現這個目的，二階段提交算法的成立基於以下假設： 該分布式系統中，存在一個節點作為協調者(Coordinator ...