場(chǎng)景

不知道大家有沒(méi)有遇到這樣的情況，就是去自動(dòng)取款機(jī)取錢的時(shí)候，比如說(shuō)你去取1000塊錢，這個(gè)時(shí)候系統(tǒng)會(huì)先幫你把1000塊錢扣除，然后自動(dòng)取款機(jī)再把錢吐出來(lái)。但是如果取款機(jī)出現(xiàn)問(wèn)題，會(huì)發(fā)現(xiàn)錢被扣了，但是錢沒(méi)有取出來(lái)。我第一次遇到這個(gè)問(wèn)題的時(shí)候很擔(dān)心，當(dāng)時(shí)跨行取取了3000塊錢，短信提醒我錢已經(jīng)被扣了，但是錢沒(méi)取出來(lái)，于是準(zhǔn)備去找柜臺(tái)幫忙處理的時(shí)候，手機(jī)上又收到一筆交易提醒，提示錢被退回來(lái)了!

[[278573]]

在這個(gè)事情中，引發(fā)了一個(gè)對(duì)于數(shù)據(jù)一致性的思考

基于整個(gè)資金處理鏈路的體驗(yàn)，大概的流程是這樣:

場(chǎng)景分析

如果真實(shí)的場(chǎng)景是如我這個(gè)圖所畫的那樣的話， 會(huì)存在幾個(gè)問(wèn)題

• A銀行同步調(diào)用B銀行的遠(yuǎn)程接口來(lái)扣款，如果接口處理比較耗時(shí)或者出現(xiàn)網(wǎng)絡(luò)故障時(shí)，會(huì)導(dǎo)致比較阻塞的時(shí)間比較長(zhǎng)，那么對(duì)于用戶的感覺(jué)就是取款機(jī)頁(yè)面一直在轉(zhuǎn)圈圈。
• 當(dāng)出款失敗的時(shí)候，A銀行的本地交易表狀態(tài)改成了4出款失敗，并且同步調(diào)用B銀行的接口把扣減的3000元回滾。如果回滾失敗，就會(huì)導(dǎo)致用戶的錢被扣了，但是沒(méi)有取出現(xiàn)金來(lái)。

遠(yuǎn)程接口的異步調(diào)用

對(duì)于第三方的調(diào)用，并且對(duì)性能有一定要求的流程中，一定不能用同步的方式。所以我們通過(guò)異步化改造一下第一個(gè)流程

異步流程的話，我之前做支付業(yè)務(wù)的時(shí)候，是這么做的

A銀行調(diào)用B銀行的接口，引入了一個(gè)異步消息隊(duì)列，把所有的交易指令直接丟給消息隊(duì)列異步去處理。B銀行收到指令執(zhí)行完以后，再通過(guò)

http協(xié)議把結(jié)果寫回給A銀行

出款失敗的數(shù)據(jù)回滾

我們先不管方案引入以后會(huì)帶來(lái)哪些問(wèn)題，我們先把原來(lái)的問(wèn)題解決掉。

當(dāng)取款機(jī)出款失敗的時(shí)候，這筆交易要回滾。按照上面的圖來(lái)看，實(shí)際上就存在一個(gè)數(shù)據(jù)一致性問(wèn)題，也就是交易記錄表要記錄這筆交易是失敗的，并且

要把這筆錢退回到賬戶上。這種一致性問(wèn)題實(shí)際上就是大家所說(shuō)的分布式事務(wù)問(wèn)題

分布式事務(wù)問(wèn)題也叫分布式數(shù)據(jù)一致性問(wèn)題

其實(shí)在分布式架構(gòu)中，分布式事務(wù)問(wèn)題，是非常常見(jiàn)的問(wèn)題。既然是常見(jiàn)，那肯定會(huì)有解決辦法。這里我并不打算展開(kāi)他的各種解決方案，給大家講講

架構(gòu)思維層面的東西

首先我們知道數(shù)據(jù)庫(kù)事務(wù)會(huì)滿足ACID特性：

• 原子性(A);
• 一致性(C);
• 隔離性(I);
• 持久性(D);

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

而在分布式場(chǎng)景中，這種單庫(kù)事務(wù)就沒(méi)什么意義了。

分布式場(chǎng)景中的事務(wù)一致性方案

在分布式架構(gòu)中，有很多種解決一致性問(wèn)題的方案，比如TCC(事務(wù)補(bǔ)償)、比如基于可靠性消息的最終一致性、比如基于2pc協(xié)議的強(qiáng)一致性、

對(duì)于很多中間件里面的一致性協(xié)議，有paxos、Raft等算法 ;這些大家都可以自己去看看

我們前面說(shuō)過(guò)，在分布式架構(gòu)下，分布式事務(wù)的問(wèn)題是很常見(jiàn)的。所以目前市面上提供的解決方案也比較多。那么這里就涉及到兩個(gè)概念

• 一個(gè)是強(qiáng)一致性、 一個(gè)是弱一致性

所謂的強(qiáng)一致性，就是保證跨節(jié)點(diǎn)的數(shù)據(jù)的強(qiáng)一致，要么同時(shí)成功，要么同時(shí)失敗

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

CAP和BASE

強(qiáng)一致性和弱一致性有什么區(qū)別，或者對(duì)系統(tǒng)會(huì)產(chǎn)生什么樣的影響呢?我們來(lái)分析一下

CAP 定理，又被叫作布魯爾定理。對(duì)于設(shè)計(jì)分布式系統(tǒng)(不僅僅是分布式事務(wù))的架構(gòu)師來(lái)說(shuō)，CAP 就是你的入門理論。

1.C (一致性)：對(duì)某個(gè)指定的客戶端來(lái)說(shuō)，讀操作能返回最新的寫操作。對(duì)于數(shù)據(jù)分布在不同節(jié)點(diǎn)上的數(shù)據(jù)來(lái)說(shuō)，如果在某個(gè)節(jié)點(diǎn)更新了數(shù)據(jù)，那么在其他節(jié)點(diǎn)如果都能讀取到這個(gè)最新的數(shù)據(jù)，那么就稱為強(qiáng)一致，如果有某個(gè)節(jié)點(diǎn)沒(méi)有讀取到，那就是分布式不一致。

2.A (可用性)：非故障的節(jié)點(diǎn)在合理的時(shí)間內(nèi)返回合理的響應(yīng)(不是錯(cuò)誤和超時(shí)的響應(yīng))。可用性的兩個(gè)關(guān)鍵一個(gè)是合理的時(shí)間，一個(gè)是合理的響應(yīng)。

合理的時(shí)間指的是請(qǐng)求不能無(wú)限被阻塞，應(yīng)該在合理的時(shí)間給出返回。合理的響應(yīng)指的是系統(tǒng)應(yīng)該明確返回結(jié)果并且結(jié)果是正確的

3.P (分區(qū)容錯(cuò)性)：當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)后，系統(tǒng)能夠繼續(xù)工作。打個(gè)比方，這里集群有多臺(tái)機(jī)器，有臺(tái)機(jī)器網(wǎng)絡(luò)出現(xiàn)了問(wèn)題，但是這個(gè)集群仍然可以正常工作。

熟悉 CAP 的人都知道，三者不能共有，因?yàn)樵诜植际较到y(tǒng)中，網(wǎng)絡(luò)無(wú)法 100% 可靠，分區(qū)其實(shí)是一個(gè)必然現(xiàn)象。

如果我們選擇了 CA 而放棄了 P，那么當(dāng)發(fā)生分區(qū)現(xiàn)象時(shí)，為了保證一致性，這個(gè)時(shí)候必須拒絕請(qǐng)求，但是 A 又不允許，所以分布式系統(tǒng)理論上不可能選擇 CA 架構(gòu)，只能選擇 CP 或者 AP 架構(gòu)。

對(duì)于 CP 來(lái)說(shuō)，放棄可用性，追求一致性和分區(qū)容錯(cuò)性。

對(duì)于 AP 來(lái)說(shuō)，放棄一致性(這里說(shuō)的一致性是強(qiáng)一致性)，追求分區(qū)容錯(cuò)性和可用性，這是很多分布式系統(tǒng)設(shè)計(jì)時(shí)的選擇，后面的 BASE 也是根據(jù) AP 來(lái)擴(kuò)展。

BASE 是 Basically Available(基本可用)、Soft state(軟狀態(tài))和 Eventually consistent (最終一致性)三個(gè)短語(yǔ)的縮寫，是對(duì) CAP 中 AP 的一個(gè)擴(kuò)展。

• 基本可用：分布式系統(tǒng)在出現(xiàn)故障時(shí)，允許損失部分可用功能，保證核心功能可用。
• 軟狀態(tài)：允許系統(tǒng)中存在中間狀態(tài)，這個(gè)狀態(tài)不影響系統(tǒng)可用性，這里指的是 CAP 中的不一致。
• 最終一致：最終一致是指經(jīng)過(guò)一段時(shí)間后，所有節(jié)點(diǎn)數(shù)據(jù)都將會(huì)達(dá)到一致。

BASE 解決了 CAP 中理論沒(méi)有網(wǎng)絡(luò)延遲，在 BASE 中用軟狀態(tài)和最終一致，保證了延遲后的一致性。

對(duì)于互聯(lián)網(wǎng)公司，用戶體驗(yàn)是最重要的，所以為了避免強(qiáng)一致帶來(lái)的阻塞，會(huì)采用最終一致性方案來(lái)解決數(shù)據(jù)一致性問(wèn)題。而用得比較多的都是基于本地消息表+異步隊(duì)列 以及基于可靠性消息隊(duì)列來(lái)實(shí)現(xiàn)最終一致性方案

出款失敗場(chǎng)景改造

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

這個(gè)環(huán)節(jié)到這里就結(jié)束了嗎?其實(shí)還沒(méi)有

僅僅利用可靠性消息隊(duì)列來(lái)保證數(shù)據(jù)的最終一致性還是不夠的，如果消息隊(duì)列本身的可靠性出現(xiàn)問(wèn)題也會(huì)帶來(lái)數(shù)據(jù)不一致問(wèn)題。

所以一般的做法是，在A銀行端做一個(gè)本地消息表，記錄這筆消息的處理狀態(tài)。然后通過(guò)定時(shí)任務(wù)來(lái)輪詢消息表，來(lái)實(shí)現(xiàn)數(shù)據(jù)最終一致性

消息表設(shè)計(jì)

消息表中有交易必須要用到的業(yè)務(wù)字段，也有設(shè)計(jì)到消息重發(fā)的輔助字段

• Id 交易流水號(hào)
• status 交易狀態(tài)
• lastUpdateTime 最后更新時(shí)間