建站
咨詢
售后
建站咨詢
新聞中心
一次跨行取款失敗，而引發(fā)對分布式事務(wù)的思考
作者：IT知識課堂 2019-10-09 11:42:10
開發(fā)
前端
分布式 不知道大家有沒有遇到這樣的情況，就是去自動取款機(jī)取錢的時候，比如說你去取1000塊錢，這個時候系統(tǒng)會先幫你把1000塊錢扣除，然后自動取款機(jī)再把錢吐出來。但是如果取款機(jī)出現(xiàn)問題，會發(fā)現(xiàn)錢被扣了，但是錢沒有取出來。在這個事情中，引發(fā)了一個對于數(shù)據(jù)一致性的思考
創(chuàng)新互聯(lián)從2013年開始，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目網(wǎng)站制作、網(wǎng)站建設(shè)網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元紅山做網(wǎng)站,已為上家服務(wù),為紅山各地企業(yè)和個人服務(wù),聯(lián)系電話:028-86922220
場景
不知道大家有沒有遇到這樣的情況，就是去自動取款機(jī)取錢的時候，比如說你去取1000塊錢，這個時候系統(tǒng)會先幫你把1000塊錢扣除，然后自動取款機(jī)再把錢吐出來。但是如果取款機(jī)出現(xiàn)問題，會發(fā)現(xiàn)錢被扣了，但是錢沒有取出來。我第一次遇到這個問題的時候很擔(dān)心，當(dāng)時跨行取取了3000塊錢，短信提醒我錢已經(jīng)被扣了，但是錢沒取出來，于是準(zhǔn)備去找柜臺幫忙處理的時候，手機(jī)上又收到一筆交易提醒，提示錢被退回來了!
[[278573]]
在這個事情中，引發(fā)了一個對于數(shù)據(jù)一致性的思考
基于整個資金處理鏈路的體驗，大概的流程是這樣:
場景分析
如果真實的場景是如我這個圖所畫的那樣的話， 會存在幾個問題
- A銀行同步調(diào)用B銀行的遠(yuǎn)程接口來扣款，如果接口處理比較耗時或者出現(xiàn)網(wǎng)絡(luò)故障時，會導(dǎo)致比較阻塞的時間比較長，那么對于用戶的感覺就是取款機(jī)頁面一直在轉(zhuǎn)圈圈。
- 當(dāng)出款失敗的時候，A銀行的本地交易表狀態(tài)改成了4出款失敗，并且同步調(diào)用B銀行的接口把扣減的3000元回滾。如果回滾失敗，就會導(dǎo)致用戶的錢被扣了，但是沒有取出現(xiàn)金來。
遠(yuǎn)程接口的異步調(diào)用
對于第三方的調(diào)用，并且對性能有一定要求的流程中，一定不能用同步的方式。所以我們通過異步化改造一下第一個流程
異步流程的話，我之前做支付業(yè)務(wù)的時候，是這么做的
A銀行調(diào)用B銀行的接口，引入了一個異步消息隊列，把所有的交易指令直接丟給消息隊列異步去處理。B銀行收到指令執(zhí)行完以后，再通過
http協(xié)議把結(jié)果寫回給A銀行
出款失敗的數(shù)據(jù)回滾
我們先不管方案引入以后會帶來哪些問題，我們先把原來的問題解決掉。
當(dāng)取款機(jī)出款失敗的時候，這筆交易要回滾。按照上面的圖來看，實際上就存在一個數(shù)據(jù)一致性問題，也就是交易記錄表要記錄這筆交易是失敗的，并且
要把這筆錢退回到賬戶上。這種一致性問題實際上就是大家所說的分布式事務(wù)問題
分布式事務(wù)問題也叫分布式數(shù)據(jù)一致性問題
其實在分布式架構(gòu)中，分布式事務(wù)問題，是非常常見的問題。既然是常見，那肯定會有解決辦法。這里我并不打算展開他的各種解決方案，給大家講講
架構(gòu)思維層面的東西
首先我們知道數(shù)據(jù)庫事務(wù)會滿足ACID特性：
- 原子性(A);
- 一致性(C);
- 隔離性(I);
- 持久性(D);
而在這四大特性中，一致性是最基本的特性，其它的三個特性都為了保證一致性而存在的!
而在分布式場景中，這種單庫事務(wù)就沒什么意義了。
分布式場景中的事務(wù)一致性方案
在分布式架構(gòu)中，有很多種解決一致性問題的方案，比如TCC(事務(wù)補(bǔ)償)、比如基于可靠性消息的最終一致性、比如基于2pc協(xié)議的強(qiáng)一致性、
對于很多中間件里面的一致性協(xié)議，有paxos、Raft等算法 ;這些大家都可以自己去看看
我們前面說過，在分布式架構(gòu)下，分布式事務(wù)的問題是很常見的。所以目前市面上提供的解決方案也比較多。那么這里就涉及到兩個概念
- 一個是強(qiáng)一致性、 一個是弱一致性
所謂的強(qiáng)一致性，就是保證跨節(jié)點的數(shù)據(jù)的強(qiáng)一致，要么同時成功，要么同時失敗
而所謂的弱一致性，其實就是一種最終一致性，
CAP和BASE
強(qiáng)一致性和弱一致性有什么區(qū)別，或者對系統(tǒng)會產(chǎn)生什么樣的影響呢?我們來分析一下
CAP 定理，又被叫作布魯爾定理。對于設(shè)計分布式系統(tǒng)(不僅僅是分布式事務(wù))的架構(gòu)師來說，CAP 就是你的入門理論。
1.C (一致性)：對某個指定的客戶端來說，讀操作能返回最新的寫操作。對于數(shù)據(jù)分布在不同節(jié)點上的數(shù)據(jù)來說，如果在某個節(jié)點更新了數(shù)據(jù)，那么在其他節(jié)點如果都能讀取到這個最新的數(shù)據(jù)，那么就稱為強(qiáng)一致，如果有某個節(jié)點沒有讀取到，那就是分布式不一致。
2.A (可用性)：非故障的節(jié)點在合理的時間內(nèi)返回合理的響應(yīng)(不是錯誤和超時的響應(yīng))?？捎眯缘膬蓚€關(guān)鍵一個是合理的時間，一個是合理的響應(yīng)。
合理的時間指的是請求不能無限被阻塞，應(yīng)該在合理的時間給出返回。合理的響應(yīng)指的是系統(tǒng)應(yīng)該明確返回結(jié)果并且結(jié)果是正確的
3.P (分區(qū)容錯性)：當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)后，系統(tǒng)能夠繼續(xù)工作。打個比方，這里集群有多臺機(jī)器，有臺機(jī)器網(wǎng)絡(luò)出現(xiàn)了問題，但是這個集群仍然可以正常工作。
熟悉 CAP 的人都知道，三者不能共有，因為在分布式系統(tǒng)中，網(wǎng)絡(luò)無法 100% 可靠，分區(qū)其實是一個必然現(xiàn)象。
如果我們選擇了 CA 而放棄了 P，那么當(dāng)發(fā)生分區(qū)現(xiàn)象時，為了保證一致性，這個時候必須拒絕請求，但是 A 又不允許，所以分布式系統(tǒng)理論上不可能選擇 CA 架構(gòu)，只能選擇 CP 或者 AP 架構(gòu)。
對于 CP 來說，放棄可用性，追求一致性和分區(qū)容錯性。
對于 AP 來說，放棄一致性(這里說的一致性是強(qiáng)一致性)，追求分區(qū)容錯性和可用性，這是很多分布式系統(tǒng)設(shè)計時的選擇，后面的 BASE 也是根據(jù) AP 來擴(kuò)展。
BASE 是 Basically Available(基本可用)、Soft state(軟狀態(tài))和 Eventually consistent (最終一致性)三個短語的縮寫，是對 CAP 中 AP 的一個擴(kuò)展。
- 基本可用：分布式系統(tǒng)在出現(xiàn)故障時，允許損失部分可用功能，保證核心功能可用。
- 軟狀態(tài)：允許系統(tǒng)中存在中間狀態(tài)，這個狀態(tài)不影響系統(tǒng)可用性，這里指的是 CAP 中的不一致。
- 最終一致：最終一致是指經(jīng)過一段時間后，所有節(jié)點數(shù)據(jù)都將會達(dá)到一致。
BASE 解決了 CAP 中理論沒有網(wǎng)絡(luò)延遲，在 BASE 中用軟狀態(tài)和最終一致，保證了延遲后的一致性。
對于互聯(lián)網(wǎng)公司，用戶體驗是最重要的，所以為了避免強(qiáng)一致帶來的阻塞，會采用最終一致性方案來解決數(shù)據(jù)一致性問題。而用得比較多的都是基于本地消息表+異步隊列 以及基于可靠性消息隊列來實現(xiàn)最終一致性方案
出款失敗場景改造
基于理論的鋪墊，我們可以思考并改造一下取款的邏輯
這個環(huán)節(jié)到這里就結(jié)束了嗎?其實還沒有
僅僅利用可靠性消息隊列來保證數(shù)據(jù)的最終一致性還是不夠的，如果消息隊列本身的可靠性出現(xiàn)問題也會帶來數(shù)據(jù)不一致問題。
所以一般的做法是，在A銀行端做一個本地消息表，記錄這筆消息的處理狀態(tài)。然后通過定時任務(wù)來輪詢消息表，來實現(xiàn)數(shù)據(jù)最終一致性
消息表設(shè)計
消息表中有交易必須要用到的業(yè)務(wù)字段，也有設(shè)計到消息重發(fā)的輔助字段
- Id 交易流水號
- status 交易狀態(tài)
- lastUpdateTime 最后更新時間
當(dāng)前題目：一次跨行取款失敗，而引發(fā)對分布式事務(wù)的思考
轉(zhuǎn)載注明：http://m.fisionsoft.com.cn/article/djdpiij.html
