前言
事務是數據庫系統中非常有趣也非常重要的概念，它是數據庫管理系統執行過程中的一個邏輯單元，它能夠保證一個事務中的所有操作要麼全部執行，要麼全部執行；在 SOA 與微服務架構大行其道的今天，在分佈式的多個服務中保證業務的一致性就需要我們實現分佈式事務。
數據庫事務
數據庫事務（簡稱：事務），是數據庫管理系統執行過程中的一個邏輯單位，由一個有限的數據庫操作序列構成，這些操作要麼全部執行,要麼全部不執行，是一個不可分割的工作單位。
數據庫事務的幾個典型特性：原子性(Atomicity )、一致性( Consistency )、隔離性( Isolation)和持久性(Durabilily)，簡稱就是ACID。
- 原子性： 事務作為一個整體被執行，包含在其中的對數據庫的操作要麼全部被執行，要麼都不執行。
- 一致性： 指在事務開始之前和事務結束以後，數據不會被破壞，假如A賬戶給B賬戶轉10塊錢，不管成功與否，A和B的總金額是不變的。
- 隔離性： 多個事務併發訪問時，事務之間是相互隔離的，即一個事務不影響其它事務運行效果。簡言之，就是事務之間是進水不犯河水的。
- 持久性： 表示事務完成以後，該事務對數據庫所作的操作更改，將持久地保存在數據庫之中。
分佈式事務
分佈式事務： 就是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的分佈式系統的不同節點之上。簡單來說，分佈式事務指的就是分佈式系統中的事務，它的存在就是為了保證不同數據庫節點的數據一致性。
為什麼需要分佈式事務？接下來分兩方面闡述：
微服務架構下的分佈式事務
隨著互聯網的快速發展，輕盈且功能劃分明確的微服務，登上了歷史舞臺。比如，一個用戶下訂單，購買直播禮物的服務，被拆分成三個service，分別是金幣服務（coinService），下訂單服務（orderService）、禮物服務（giftService）。這些服務都部署在不同的機器上（節點），對應的數據庫（金幣數據庫、訂單數據庫、禮物數據庫）也在不同節點上。
用戶下單購買禮物，禮物數據庫、金幣數據庫、訂單數據庫在不同節點上，用本地事務是不可以的，那麼如何保證不同數據庫（節點）上的數據一致性呢？這就需要分佈式事務啦~
分庫分表下的分佈式事務
隨著業務的發展，數據庫的數據日益龐大，超過千萬級別的數據，我們就需要對它分庫分表（以前公司是用mycat分庫分表，後來用sharding-jdbc）。一分庫，數據又分佈在不同節點上啦，比如有的在深圳機房，有的在北京機房~你再想用本地事務去保證，已經無動於衷啦~還是需要分佈式事務啦。
比如A轉10塊給B，A的賬戶數據是在北京機房，B的賬戶數據是在深圳機房。流程如下：
CAP 理論&BASE 理論
學習分佈式事務，當然需要了解 CAP 理論和BASE 理論。
CAP理論
CAP理論作為分佈式系統的基礎理論，指的是在一個分佈式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），這三個要素最多隻能同時實現兩點。
一致性(C：Consistency)：
一致性是指數據在多個副本之間能否保持一致的特性。例如一個數據在某個分區節點更新之後，在其他分區節點讀出來的數據也是更新之後的數據。
可用性(A：Availability)：
可用性是指系統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求總是能夠在有限的時間內返回結果。這裡的重點是"有限時間內"和"返回結果"。
分區容錯性（P:Partition tolerance）:
分佈式系統在遇到任何網絡分區故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務。
選擇 說明 CA 放棄分區容錯性，加強一致性和可用性，其實就是傳統的單機數據庫的選擇 AP 放棄一致性，分區容錯性和可用性，這是很多分佈式系統設計時的選擇 CP 放棄可用性，追求一致性和分區容錯性，網絡問題會直接讓整個系統不可用
BASE 理論
BASE 理論， 是對CAP中AP的一個擴展，對於我們的業務系統，我們考慮犧牲一致性來換取系統的可用性和分區容錯性。BASE是Basically Available(基本可用)，Soft state（軟狀態）,和 Eventually consistent（最終一致性）三個短語的縮寫。
Basically Available
基本可用：通過支持局部故障而不是系統全局故障來實現的。如將用戶分區在 5 個數據庫服務器上，一個用戶數據庫的故障隻影響這臺特定主機那 20% 的用戶，其他用戶不受影響。
Soft State
軟狀態，狀態可以有一段時間不同步
Eventually Consistent
最終一致，最終數據是一致的就可以了，而不是時時保持強一致。
本地消息表
ebay最初提出本地消息表這個方案，來解決分佈式事務問題。業界目前使用這種方案是比較多的，它的核心思想就是將分佈式事務拆分成本地事務進行處理。可以看一下基本的實現流程圖：
基本實現思路
發送消息方：
- 需要有一個消息表，記錄著消息狀態相關信息。
- 業務數據和消息表在同一個數據庫，即要保證它倆在同一個本地事務。
- 在本地事務中處理完業務數據和寫消息表操作後，通過寫消息到MQ消息隊列。
- 消息會發到消息消費方，如果發送失敗，即進行重試。
消息消費方：
- 處理消息隊列中的消息，完成自己的業務邏輯。
- 此時如果本地事務處理成功，則表明已經處理成功了。
- 如果本地事務處理失敗，那麼就會重試執行。
- 如果是業務上面的失敗，給消息生產方發送一個業務補償消息，通知進行回滾等操作。
生產方和消費方定時掃描本地消息表，把還沒處理完成的消息或者失敗的消息再發送一遍。如果有靠譜的自動對賬補賬邏輯，這種方案還是非常實用的。
優點&缺點：
該方案的優點是很好地解決了分佈式事務問題，實現了最終一致性。缺點是消息表會耦合到業務系統中。
閱讀更多 java架構 的文章
