分佈式事務

基本概念

本地事務

事務由資源管理器（如DBMS）本地管理

• 優勢：嚴格的ACID
• 缺點：不具有分佈事務處理能力

全局事務（DTP模型）

TX協議：應用或應用服務器與事務管理器的接口

XA協議：全局事務管理器與資源管理器的接口

• 優勢：嚴格的ACID
• 缺點：效率很是低

兩階段提交

• 優勢
  • 準備後，仍可提交或回滾
  • 準備時，一致性檢查必須OK
  • 準備後，事務結果仍然只在事務內可見
  • 準備後，事務結果已經持久化
• 缺點：
  • 潛在故障點多帶來的脆弱性
  • 準備後，提交前的故障引起一系列隔離與恢復難題

http://book.51cto.com/art/201309/410608.htm

跨域的全局事務（DTP模型）

• 缺點
  • 更高的協議成本
  • 脆弱，故障點多
  • 故障影響大，恢復困難
  • 複雜，更多架構與平臺約束

java企業平臺中的分佈式事務實現

• JTA
  • 面向應用、應用服務器與資源管理器的高層事務接口
• JTS
  • JTA事務管理器的實現標準，向上支持JTA，向下經過CORBA OTS實現跨事務域的互操做性
• EJB
• 優勢
  • 簡單一致的編程模型
  • 跨域分佈處理的ACID保證
• 侷限
  • DTP模型自己的侷限
  • 缺乏充分公開的大規模、高可用、密集事務應用的成功案例

JMS與分佈式事務：http://techv5.com/topic/1371/

其它資源

• ws-transaction標準
• jbossTransaction系統
• Paxos算法

原則

• 真正重要的是知足業務需求，而不是追求抽象、絕對的系統特性
• 帽子戲法
• 酸鹼（ACID-BASE Balance）

模式

• 服務模式
  • 可查詢操做
  • 冪等操做
  • TCC操做
  • 可補償操做
• 複合模式
  • 按期校對
  • 可靠消息
  • TCC
  • 補償

CAP定理

http://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86

對於共享數據系統，只能同時擁有如下三項中的兩個：

• Consistency(一致性): 全部 用戶看到一致的數據
• Availability(可用性): 對數據更新具有高可用性
• Tolerance to Network Partition(分區容忍性): 以實際效果而言，分區至關於對通訊的時限要求。系統若是不能在時限內達成數據一致性，就意味着發生了分區的狀況，必須就當前操做在C和A之間作出選擇

理解

• 容許至少一個節點更新狀態會致使數據不一致，即喪失了C性質。
  • 若是是多個節點，而後多個節點都是高可用的，此時確定有個前後順序，這時確定無法保證一致性。
• 若是爲了保證數據一致性，將分區一側的節點設置爲不可用，那麼又喪失了A性質。
  • 好比mysql主備節點，通常是主機統一對事務進行控制；備機只用來讀。這樣就尚失了A性質。
• 除非兩個節點能夠互相通訊，才能既保證C又保證A，這又會致使喪失P性質。
  • 若是要求同時達到一致性和可用性，那就無法分區了，由於一旦分區確定會有時間窗口致使上面C或A的不知足。

酸鹼平衡 （BASE）

• BA(Basic Availability)
  • 基本可用性
• S（soft state）
  • 柔性狀態
• E(Eventuall consistency)
  • 最終一致性

eBay的BASE最佳實踐

ebay沒有使用任何的分佈式事務客戶端或系統

他們使用其它技術來保證最終一致性 - careful ordering of database operations - asynchronous recovery events - reconciliation or settlement batches

分佈式事務方案一：按期校對

服務模式1：可查詢操做

服務操做的可標識性

服務操做具備全局惟一標識

複合模式1：按期校對

需保證在事務提交後才能發送

分佈式事務方案二：基於MQ

服務模式2：冪等操做

經過業務操做自己實現冪等性

服務模式2：可靠消息

實現：

• 業務活動的主動方，在完成業務處理的同一個本地事務中，記錄消息數據
• 業務處理事務提交後、經過實時消息通知業務被動方，實時通知成功後刪除消息數據
• 消息恢復系統按期找到未成功發送的消息，交給實時消息服務補發送

約束：

• 被動方的處理結果不影響主動方的處理
• 被動方的消息處理操做是冪等操做

成本：

• 可靠消息系統建設成本
• 消息數據CRUD成本

適用範圍

• 對最終一致性時間敏感度較高
• 下降業務被方實現成本

可靠消息的另外一種實現

實現

• 業務處理在業務事務提交前，向實時消息服務請求發送消息，實時消息服務只記錄消息數據，而不真正發送
• 業務處理服務在業務事務提交後，向實時消息服務確認發送。只有在獲得確認發送指令後，實時消息服務才真正發送消息
• 業務處理在業務事務回滾後，向實時消息服務取消發送
• 消息狀態確認系統按期找到未確認發送或回溯的消息，向業務處理服務詢問消息狀態，業務處理服務根據消息ID或消息內容肯定該消息是否有效。

成本

• 一次消息發送須要兩次請求
• 業務處理服務需實現消息狀態回查接口

優勢：

• 消息數據獨立存儲、獨立伸縮
• 下降業務系統與消息系統間的耦合

分佈式事務方案三：基於TCC

服務模式3：TCC操做

Try: 嘗試執行業務

• 完成全部業務檢查（一致性）
• 預留必須業務資源（準隔離性）

Confirm: 確認執行業務

• 真正執行業務
• 不做任何業務檢查
• 只使用Try階段預留的業務資源
• Confirm操做知足冪等性

Cancel: 取消執行業務

• 釋放Try階段預留的業務資源
• Cancel操做知足冪等生

與2PC協議比較

• 位於業務服務層而非資源層
• 沒有單獨的準備階段，Try操做兼備資源操做與準備能力
• Try操做能夠靈活選擇業務資源的鎖定粒度
• 較高開發成本

複合模式3：TCC模式

適用範圍 - 強隔離性、嚴格一致性要求的業務活動 - 適用於執行時間較短的業務

分佈式事務方案四：基於補償（百度錢包方案）

適用範圍 - 弱隔離性、弱一致性要求的業務活動 - 特別適用於執行時間較長的業務,如工做流

通常適合於金融系統，例如加錢減錢

基礎設施

• 服務框架
  • 業務系統jar包
• 消息系統
  • mq
• 數據存儲
  • 業務活動日誌管理
• 分佈式任務調度
  • 業務活動恢復任務
  • 消息恢復任務
  • 按期校對任務
• 服務註冊中心
  • 提供服務元數據集中註冊、查詢與管理能力，支持事務相關屬性的描述

參考

• 大規模SOA系統中的分佈事務處事_程立.pdf
• 用消息隊列和消息應用狀態表來消除分佈式事務 http://techv5.com/topic/1380/
• 用消息隊列來解決數據一致性問題 http://rfwiki.diandian.com/post/2013-01-08/40047419557
• 用Spring和RabbitMQ技術應對消息傳送挑戰 http://www.infoq.com/cn/presentations/Spring-RabbitMQ-technology
• Base: An Acid Alternative In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability. http://queue.acm.org/detail.cfm?id=1394128
• 案例分析：基於消息的分佈式架構 http://www.infoq.com/cn/articles/message-based-distributed-architecture
• 中間件技術及雙十一實踐·消息中間件篇 http://jm-blog.aliapp.com/?p=3483