場景

不知道大家有沒有遇到這樣的情況，就是去自動取款機取錢的時候，比如說你去取1000塊錢，這個時候系統會先幫你把1000塊錢扣除，然後自動取款機再把錢吐出來。但是如果取款機出現問題，會發現錢被扣了，但是錢沒有取出來。我第一次遇到這個問題的時候很擔心，當時跨行取取了3000塊錢，簡訊提醒我錢已經被扣了，但是錢沒取出來，於是準備去找櫃檯幫忙處理的時候，手機上又收到一筆交易提醒，提示錢被退回來了！

在這個事情中，引發了一個對於資料一致性的思考

基於整個資金處理鏈路的體驗，大概的流程是這樣:

場景分析

如果真實的場景是如我這個圖所畫的那樣的話， 會存在幾個問題

1. A銀行同步呼叫B銀行的遠端介面來扣款，如果介面處理比較耗時或者出現網路故障時，會導致比較阻塞的時間比較長，那麼對於使用者的感覺就是取款機頁面一直在轉圈圈。

2. 當出款失敗的時候，A銀行的本地交易表狀態改成了4出款失敗，並且同步呼叫B銀行的介面把扣減的3000元回滾。如果回滾失敗，就會導致使用者的錢被扣了，但是沒有取出現金來。

遠端介面的非同步呼叫

對於第三方的呼叫，並且對效能有一定要求的流程中，一定不能用同步的方式。所以我們通過非同步化改造一下第一個流程

非同步流程的話，我之前做支付業務的時候，是這麼做的

A銀行呼叫B銀行的介面，引入了一個非同步訊息佇列，把所有的交易指令直接丟給訊息佇列非同步去處理。B銀行收到指令執行完以後，再通過

http協議把結果寫回給A銀行

出款失敗的資料回滾

我們先不管方案引入以後會帶來哪些問題，我們先把原來的問題解決掉。

當取款機出款失敗的時候，這筆交易要回滾。按照上面的圖來看，實際上就存在一個數據一致性問題，也就是交易記錄表要記錄這筆交易是失敗的，並且

要把這筆錢退回到賬戶上。這種一致性問題實際上就是大家所說的分散式事務問題

分散式事務問題也叫分散式資料一致性問題

其實在分散式架構中，分散式事務問題，是非常常見的問題。既然是常見，那肯定會有解決辦法。這裡我並不打算展開他的各種解決方案，給大家講講

架構思維層面的東西

首先我們知道資料庫事務會滿足ACID特性：

原子性（A）；一致性（C）；隔離性（I）；永續性（D）；

而在這四大特性中，一致性是最基本的特性，其它的三個特性都為了保證一致性而存在的！

而在分散式場景中，這種單庫事務就沒什麼意義了。

分散式場景中的事務一致性方案

在分散式架構中，有很多種解決一致性問題的方案，比如TCC（事務補償）、比如基於可靠性訊息的最終一致性、比如基於2pc協議的強一致性、

對於很多中介軟體裡面的一致性協議，有paxos、Raft等演算法 ；這些大家都可以自己去看看

我們前面說過，在分散式架構下，分散式事務的問題是很常見的。所以目前市面上提供的解決方案也比較多。那麼這裡就涉及到兩個概念

一個是強一致性、 一個是弱一致性

所謂的強一致性，就是保證跨節點的資料的強一致，要麼同時成功，要麼同時失敗

而所謂的弱一致性，其實就是一種最終一致性，

CAP和BASE

強一致性和弱一致性有什麼區別，或者對系統會產生什麼樣的影響呢？我們來分析一下

CAP 定理，又被叫作布魯爾定理。對於設計分散式系統(不僅僅是分散式事務)的架構師來說，CAP 就是你的入門理論。

1.C (一致性)：對某個指定的客戶端來說，讀操作能返回最新的寫操作。對於資料分佈在不同節點上的資料來說，如果在某個節點更新了資料，那麼在其他節點如果都能讀取到這個最新的資料，那麼就稱為強一致，如果有某個節點沒有讀取到，那就是分散式不一致。

2.A (可用性)：非故障的節點在合理的時間內返回合理的響應(不是錯誤和超時的響應)。可用性的兩個關鍵一個是合理的時間，一個是合理的響應。

合理的時間指的是請求不能無限被阻塞，應該在合理的時間給出返回。合理的響應指的是系統應該明確返回結果並且結果是正確的

3.P (分割槽容錯性)：當出現網路分割槽後，系統能夠繼續工作。打個比方，這裡叢集有多臺機器，有臺機器網路出現了問題，但是這個叢集仍然可以正常工作。

熟悉 CAP 的人都知道，三者不能共有，因為在分散式系統中，網路無法 100% 可靠，分割槽其實是一個必然現象。

如果我們選擇了 CA 而放棄了 P，那麼當發生分割槽現象時，為了保證一致性，這個時候必須拒絕請求，但是 A 又不允許，所以分散式系統理論上不可能選擇 CA 架構，只能選擇 CP 或者 AP 架構。

對於 CP 來說，放棄可用性，追求一致性和分割槽容錯性。

對於 AP 來說，放棄一致性(這裡說的一致性是強一致性)，追求分割槽容錯性和可用性，這是很多分散式系統設計時的選擇，後面的 BASE 也是根據 AP 來擴充套件。

BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫，是對 CAP 中 AP 的一個擴充套件。

基本可用：分散式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。

軟狀態：允許系統中存在中間狀態，這個狀態不影響系統可用性，這裡指的是 CAP 中的不一致。

最終一致：最終一致是指經過一段時間後，所有節點資料都將會達到一致。

BASE 解決了 CAP 中理論沒有網路延遲，在 BASE 中用軟狀態和最終一致，保證了延遲後的一致性。

對於網際網路公司，使用者體驗是最重要的，所以為了避免強一致帶來的阻塞，會採用最終一致性方案來解決資料一致性問題。而用得比較多的都是基於本地訊息表+非同步佇列 以及基於可靠性訊息佇列來實現最終一致性方案

出款失敗場景改造

基於理論的鋪墊，我們可以思考並改造一下取款的邏輯

這個環節到這裡就結束了嗎？其實還沒有

僅僅利用可靠性訊息佇列來保證資料的最終一致性還是不夠的，如果訊息佇列本身的可靠性出現問題也會帶來資料不一致問題。

所以一般的做法是，在A銀行端做一個本地訊息表，記錄這筆訊息的處理狀態。然後通過定時任務來輪詢訊息表，來實現資料最終一致性

訊息表設計

訊息表中有交易必須要用到的業務欄位，也有設計到訊息重發的輔助欄位

Id 交易流水號

status 交易狀態

lastUpdateTime 最後更新時間