1 、三種模式git
- 消息驅動模式:Message Driven
- 事件溯源模式:Event Sourcing
- TCC模式:Try-Confirm-Cancel
二、消息驅動(Message Driven)github
2.1 微服務架構的事務問題數據庫
2.2 微服務架構的事務問題解決網絡
- 減小服務間調用
- 沒有服務間調用,經過消息驅動調用服務
2.3 注意的問題架構
- 消息中間件須要支持事務
- 如何處理重試的消息
- 發生業務異常時回滾操做
2.4 系統錯誤的處理框架
- 將出錯未處理的消息寫到失敗隊列,進行相應回滾操做
- 經過定時任務檢查超時訂單,對未完成的訂單作自動回滾
- 報錯出錯消息,人工處理
3 事件溯源(Event Sourcing)分佈式
3.1 msg-driven or event driven微服務
- 事件不要求持久化保存
- 消息只是爲了更新業務數據的狀態,數據庫纔是一等數據
- 不要求全部的數據操做都經過消息驅動
3.2 事件溯源(event-sourcing)性能
- 事件做爲一等數據保存
- 統一的事件管理器和接口,數據更新都由事件產生
- 數據庫中數據的當前狀態根據事件的聚合產生
- 聚合數據能夠保存在數據庫中、能夠根據時間從新生成
3.3 事件溯源優勢學習
- 歷史重現:從事件中從新生成視圖數據庫
- 方便的數據流處理與報告生成
- 性能(?)
- 服務的耦合
3.4 事件溯源缺點
- 只能保證事務的最終一致性
- 設計和開發思惟的轉變、學習成本
- 事件結構的改變
- 擴展性:Event Store的分佈式實現,事件的分佈式處理
3.5 消息驅動vs事件溯源
- 一等數據:事件 VS 業務數據
- 事件永久保存、歷史重現
- 全部數據更新都必須經過事件產生
- Event Sore服務承擔更多的功能
3.6 事件溯源的數據一致性
- 一個事件只處理一個服務的數據
- 保證事件的至少一次處理、冪等性
- 業務請求的錯誤處理:屢次重試失敗、網絡異常、服務不可用
3.7 事件溯源和CQRS
- CQRS:命令查詢職責分離
- C端執行命令,Q端執行查詢
3.8 使用Axon框架的設計過程
- 領域模型:帳戶Account
- 業務Command:建立帳戶、存款、取款
- 事件Event:帳戶建立、存款、取款
- 將帳戶信息保存到數據庫中,方便查詢
- 查詢Command:查詢帳戶
4 TCC模式(Try-Confirm/Cancel)
4.1 傳統事務管理過程
4.2 JTA事務管理過程
- do
- prepare / rollback
- commit / rollback
4.3 TCC模式事務管理過程
- Try
- Commit(Confirm)/ Cancel
4.4 TCC模式協調器的功能
- 接管事務管理,相似JTA的獨立事物管理器(非兩階段提交)
- 保存每一個資源上的事務記錄:跟蹤狀態、檢查超時
- 保證每一個資源上的事務性
- 處理各類錯誤:超時、重試、網絡異常、服務不可用
4.5 TCC模式實現分佈式事務
- 借鑑XA的統一資源管理,又不是兩階段提交
- 不一樣資源之間沒有鎖,事務過程數據沒有鎖、沒有隔離
- 出錯時可能屢次調用Confirm / Cancel方法、以及順序沒法保證
- Confirm/Cancel方法須要知足冪等性,即重複調用時結果一致
4.6 TCC模式實現思路,Service規範(沒有現成的框架)
- 將一個業務邏輯封裝成TccMethod類來調用
- 協調器保存TccMethod、TccRequest、TccResponse
- 服務會有一個專門的接口接收協調器的請求,處理Confirm / Cancel
- 服務不須要開放Cofirm/Cancel的接口
4.7 基於TCC模式開發的注意事項
- 合理設計try/confirm/cancel方法的功能
- 保證confirm/cancel方法的冪等性
- 設計合理的服務間調用:try方法能夠調用其餘服務
4.8 基於TCC模式的開發
- 沒有統一的規範,也沒有普遍使用的框架
- 協調器的開發比較複雜:須要保證各類出錯狀況下的最終一致性
- 協調器監控事務:事務及其參數、返回值保存在數據庫中
- TCC模式的服務組件的複用性
4.9 實現TCC模式的框架
實現服務接口規範、協調器,git上筆記好的實現
- https://github.com/liuyangming/ByteTCC
- https://github.com/QNJR-GROUP/EasyTransaction
- https://github.com/changmingxie/tcc-transaction