書接上回，程式設計師窮開心通過資料庫實現了轉賬事務的強一致性。滄海桑田，世事變幻，話說李雷又要向韓梅梅轉賬100元，但事情有了變化。

故事的發展

李雷賬戶在火星人民銀行，韓梅梅搬到了水星，賬戶在水星人民銀行。程式設計師窮開心在海綿寶第三方支付公司寫程式。由於CAP悖論，火星人民銀行和水星人民銀行都不對外提供二階段提交事務介面。

CAP定理（帽子理論）

定理：任何分散式系統只可同時滿足CAP二點，沒法三者兼顧。[參考][2]

• C：Consistency，一致性, 資料一致更新，所有資料變動都是同步的
• A：Availability，可用性, 好的響應效能，完全的可用性指的是在任何故障模型下，服務都會在有限的時間處理響應
• P：Partition tolerance，分割槽容錯性，可靠性

關係型資料庫由於關係型資料庫是單節點的，因此不具有分割槽容錯性，但是具有一致性和可用性，而分散式的服務化系統都需要滿足分割槽容錯性，那麼我們必須在一致性和可用性中進行權衡，具體表現在服務化系統處理的異常請求在某一個時間段內可能是不完全的，但是經過自動的或者手工的補償後，達到了最終的一致性。

BASE模型

BASE模型不同於ACID模型，通過犧牲高一致性獲得可用性或可靠性。所以BASE模型也稱為弱一致性事務模型，柔性事務模型。BASE模型包含個三個元素：

• BA：Basically Available，基本可用
• S：Soft State，軟狀態，狀態可以有一段時間不同步
• E：Eventually Consistent，最終一致，最終資料是一致的就可以了，而不是時時保持強一致

弱一致性事務模型分為

• 兩階段型
• 補償型
• 非同步確保型
• 最大努力通知型幾種。

在實現方案上，又可以分為：

• 訊息日誌方案：本地訊息表、MQ（非事務訊息）、[MQ（事務訊息）][4]
• 分散式鎖方案：redis、關係資料庫行級獨佔鎖、zookeeper
• 對賬補償方案

在實際業務系統中以上事務模型經常會混合使用。