目前的應(yīng)用系統(tǒng)，不管是企業(yè)級應(yīng)用還是互聯(lián)網(wǎng)應(yīng)用，最終數(shù)據(jù)的一致性是每個應(yīng)用系統(tǒng)都要面臨的問題，隨著分布式的逐漸普及，數(shù)據(jù)一致性更加艱難，但是也很難有銀彈的解決方案，也并不是引入特定的中間件或者特定的開源框架能夠解決的，更多的還是看業(yè)務(wù)場景，根據(jù)場景來給出解決方案。根據(jù)筆者最近幾年的了解，總結(jié)了幾個點(diǎn)，更多的應(yīng)用系統(tǒng)在編碼的時候，更加關(guān)注數(shù)據(jù)的一致性，這樣系統(tǒng)才是健壯的。

一、基礎(chǔ)理論

?? 目前關(guān)于事務(wù)的幾大理論包括：ACID事務(wù)特性，CAP分布式理論，以及BASE等。ACID在數(shù)據(jù)庫事務(wù)中體現(xiàn)，CAP和BASE則是分布式事務(wù)的理論，結(jié)合業(yè)務(wù)系統(tǒng)，例如訂單管理，例如倉儲管理等，可以借鑒這些理論，從而解決問題。

1、ACID 特性

2、CAP特性

• C(一致性)一致性是指數(shù)據(jù)的原子性，在經(jīng)典的數(shù)據(jù)庫中通過事務(wù)來保障，事務(wù)完成時，無論成功或回滾，數(shù)據(jù)都會處于一致的狀態(tài)，在分布式環(huán)境下，一致性是指多個節(jié)點(diǎn)數(shù)據(jù)是否一致；
• A(可用性)服務(wù)一直保持可用的狀態(tài)，當(dāng)用戶發(fā)出一個請求，服務(wù)能在一定的時間內(nèi)返回結(jié)果；
• P(分區(qū)容忍性)在分布式應(yīng)用中，可能因?yàn)橐恍┓植际降脑驅(qū)е孪到y(tǒng)無法運(yùn)轉(zhuǎn)，好的分區(qū)容忍性，使應(yīng)用雖然是一個分布式系統(tǒng)，但是好像一個可以正常運(yùn)轉(zhuǎn)的整體

3、BASE特性

• BA: Basic Availability 基本業(yè)務(wù)可用性；
• S: Soft state 柔性狀態(tài)；
• E: Eventual consistency 最終一致性；

二、最終一致性的常用做法

1、單數(shù)據(jù)庫事務(wù)

????? 如果應(yīng)用系統(tǒng)是單一的數(shù)據(jù)庫，那么這個很好保證，利用數(shù)據(jù)庫的事務(wù)特性來滿足事務(wù)的一致性，這時候的一致性是強(qiáng)一致性的。對于java應(yīng)用系統(tǒng)來講，很少直接通過事務(wù)的start和commit以及rollback來硬編碼，大多通過spring的事務(wù)模板或者聲明式事務(wù)來保證；

2、多數(shù)據(jù)庫事務(wù)

???? 針對多數(shù)據(jù)庫事務(wù)可以根據(jù)二階段提交協(xié)議，采用spring 3.0 + Atomikos + JTA進(jìn)行支持；

3、基于事務(wù)型消息隊(duì)列的最終一致性

???? 借助消息隊(duì)列，在處理業(yè)務(wù)邏輯的地方發(fā)送消息，業(yè)務(wù)邏輯處理成功后，提交消息，確保消息是發(fā)送成功的，之后消息隊(duì)列投遞來進(jìn)行處理，如果成功，則結(jié)束，如果沒有成功，則重試，直到成功，不過僅僅適用業(yè)務(wù)邏輯中，第一階段成功，第二階段必須成功的場景。對應(yīng)上圖中的C流程。

4、基于消息隊(duì)列+定時補(bǔ)償機(jī)制的最終一致性

???? 前面部分和上面基于事務(wù)型消息的隊(duì)列，不同的是，第二階段重試的地方，不再是消息中間件自身的重試邏輯了，而是單獨(dú)的補(bǔ)償任務(wù)機(jī)制。其實(shí)在大多數(shù)的邏輯中，第二階段失敗的概率比較小，所以單獨(dú)獨(dú)立補(bǔ)償任務(wù)表出來，可以更加清晰，能夠比較明確的直到當(dāng)前多少任務(wù)是失敗的。對應(yīng)上圖的E流程。

5、異步回調(diào)機(jī)制的引入

???? A應(yīng)用調(diào)用B，在同步調(diào)用的返回結(jié)果中，B返回成功給到A，一般情況下，這時候就結(jié)束了，其實(shí)在99.99%的情況是沒問題的，但是有時候?yàn)榱舜_保100%，記住最起碼在系統(tǒng)設(shè)計中100%，這時候B系統(tǒng)再回調(diào)A一下，告訴A，你調(diào)用我的邏輯，確實(shí)成功了。其實(shí)這個邏輯，非常類似TCP協(xié)議中的三次握手。上圖中的B流程。

6、類似double check機(jī)制的確認(rèn)機(jī)制

????還是上圖中異步回調(diào)的過程，A在同步調(diào)用B，B返回成功了。這次調(diào)用結(jié)束了，但是A為了確保，在過一段時間，這個時間可以是幾秒，也可以是每天定時處理，再調(diào)用B一次，查詢一下之前的那次調(diào)用是否成功。例如A調(diào)用B更新訂單狀態(tài)，這時候成功了，延遲幾秒后，A查詢B，確認(rèn)一下狀態(tài)是否是自己剛剛期望的。上圖中的D流程。

三、分布式事務(wù)的缺點(diǎn)

1、二階段提交協(xié)議缺點(diǎn)

??? 兩階段提交涉及到多個節(jié)點(diǎn)的網(wǎng)絡(luò)通信,通信時間如果過長,事務(wù)的相對時間也就會過長,那么鎖定資源的時間也就長了.在高并發(fā)的服務(wù)中,就會存在嚴(yán)重的性能瓶勁

?2、消息隊(duì)列

?? 在高并發(fā)的環(huán)境中，我們一般會采用消息隊(duì)列來避免分布式事務(wù)的執(zhí)行。

?? 在使用消息隊(duì)列時，我們需要做到可靠憑證的保存(分布式事務(wù)的消息)，有如下幾種方式：

?? 以支付寶和余額寶為例進(jìn)行說明.

?? 支付寶完成扣錢的動作時,記錄消息數(shù)據(jù),將消息數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)存在同一個數(shù)據(jù)庫實(shí)例中.

Begin Transactionupdate A set amount=amount-1000 where uid=100;insert into message(uid,amount,status) values (1,1000,1) End Transaction Commit;

將支付寶完成扣錢的消息及時發(fā)送給余額寶，余額寶完成處理后返回成功消息，支付寶收到消息后，消除消息表中對應(yīng)的消息記錄，即完成本次扣錢操作.

傳統(tǒng)方式是，我做完了，發(fā)你消息。解決一致性的方案的意思就是，我先發(fā)你消息，我做完了再跟你確認(rèn)我做完了。這是改進(jìn)后的有事務(wù)的消息中間件。

參見：http://coolshell.cn/articles/10910.html

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的分布式事务最终一致性常用方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。