6月安卓手機(jī)性價(jià)比榜：Note 12 Turbo斷層式碾壓
6月份有一個(gè)618，雖然這是京東周年慶的日子，但別的電商也都不約而同的跟進(jìn)了，反正促銷沒(méi)壞處，廠商和用戶都能滿意。618期間一些產(chǎn)品也出現(xiàn)了歷史低價(jià)，那么各個(gè)價(jià)位段的產(chǎn)品性價(jià)比
支付重構(gòu)
考慮支付重構(gòu)的時(shí)候，自然想到原本屬于一個(gè)本地事務(wù)中的處理，現(xiàn)在要跨應(yīng)用了要怎么處理。拿充值訂單舉個(gè)栗子吧，假設(shè)：原本訂單模塊和賬戶模塊是放在一起的，現(xiàn)在需要做服務(wù)拆分，拆分成訂單服務(wù)，賬戶服務(wù)。原本收到充值回調(diào)后，可以將修改訂單狀態(tài)和增加金幣放在一個(gè)mysql事務(wù)中完成的，但是呢，因?yàn)榉?wù)拆分了，就面臨著需要協(xié)調(diào)2個(gè)服務(wù)才能完成這個(gè)事務(wù)。
所以就帶出來(lái)，我們今天要分享和討論的話題是：怎么解決分布式場(chǎng)景下數(shù)據(jù)一致性問(wèn)題，暫且用分布式事務(wù)來(lái)定義吧。
同樣的問(wèn)題還存在于其他的場(chǎng)景：
送禮：
1. 調(diào)用支付服務(wù)：先扣送禮用戶的金幣，然后給主播加相應(yīng)的荔枝2. 確認(rèn)第一步成功后，播放特效，發(fā)聊天室送禮評(píng)論等充值成功消息：
1. 完成充值訂單2. 發(fā)送訂單完成的kafka消息在涉及支付交易等付費(fèi)接口的時(shí)候，數(shù)據(jù)一致性的問(wèn)題就顯得尤為重要，因?yàn)槎际清X(qián)啊
問(wèn)題肯定不是新問(wèn)題，也就是目前已經(jīng)有相應(yīng)的解決方案了，那就看一下現(xiàn)在是怎么來(lái)解決這類問(wèn)題的吧。
以購(gòu)買(mǎi)基礎(chǔ)商品成功后發(fā)送支付訂單完成消息為例：
假設(shè)支付下單購(gòu)買(mǎi)基礎(chǔ)商品，此刻已經(jīng)收到支付回調(diào)，訂單已經(jīng)處理成功了，這個(gè)時(shí)候kafka服務(wù)故障，消息發(fā)送失??；而這個(gè)時(shí)候處理訂單的事務(wù)已經(jīng)提交了，怎么保證訂單完成的消息一定能發(fā)出去呢？
解讀一下這個(gè)流程：
綠色部分，表示流程正常運(yùn)行的交互過(guò)程：
黃色部分，表示流程出現(xiàn)了異常，數(shù)據(jù)可能存在不一致現(xiàn)象。這個(gè)時(shí)候就需要進(jìn)行流程恢復(fù)
問(wèn)題：
說(shuō)解決方案之前，我們先了解一下這些方案的理論依據(jù)，有助于幫助我們來(lái)理解和實(shí)踐這些方案
如果說(shuō)本地事務(wù)是解決單個(gè)數(shù)據(jù)源上的數(shù)據(jù)操作的一致性問(wèn)題的話，那么分布式事務(wù)則是為了解決跨越多個(gè)數(shù)據(jù)源上數(shù)據(jù)操作的一致性問(wèn)題。
從客戶端角度，多進(jìn)程并發(fā)訪問(wèn)時(shí)，更新過(guò)的數(shù)據(jù)在不同進(jìn)程如何獲取的不同策略，決定了不同的一致性。對(duì)于關(guān)系型數(shù)據(jù)庫(kù)，要求更新過(guò)的數(shù)據(jù)能被后續(xù)的訪問(wèn)都能看到，這是強(qiáng)一致性。如果能容忍后續(xù)的部分或者全部訪問(wèn)不到，則是弱一致性。如果經(jīng)過(guò)一段時(shí)間后要求能訪問(wèn)到更新后的數(shù)據(jù)，則是最終一致性.
從服務(wù)端角度，如何盡快將更新后的數(shù)據(jù)分布到整個(gè)系統(tǒng)，降低達(dá)到最終一致性的時(shí)間窗口，是提高系統(tǒng)的可用度和用戶體驗(yàn)非常重要的方面。對(duì)于分布式數(shù)據(jù)系統(tǒng)：
如果W+R>N，寫(xiě)的節(jié)點(diǎn)和讀的節(jié)點(diǎn)重疊，則是強(qiáng)一致性。例如對(duì)于典型的一主一備同步復(fù)制的關(guān)系型數(shù)據(jù)庫(kù)，N=2,W=2,R=1，則不管讀的是主庫(kù)還是備庫(kù)的數(shù)據(jù)，都是一致的。
如果W+R<=N，則是弱一致性。例如對(duì)于一主一備異步復(fù)制的關(guān)系型數(shù)據(jù)庫(kù)，N=2,W=1,R=1，則如果讀的是備庫(kù)，就可能無(wú)法讀取主庫(kù)已經(jīng)更新過(guò)的數(shù)據(jù)，所以是弱一致性。
分布式環(huán)境下（數(shù)據(jù)分布）要任何時(shí)刻保證數(shù)據(jù)一致性是不可能的，只能采取妥協(xié)的方案來(lái)保證數(shù)據(jù)最終一致性。這個(gè)也就是著名的CAP定理。
圖片
需要明確的一點(diǎn)是，對(duì)于一個(gè)分布式系統(tǒng)而言，分區(qū)容錯(cuò)性是一個(gè)最基本的要求。因?yàn)?既然是一個(gè)分布式系統(tǒng)，那么分布式系統(tǒng)中的組件必然需要被部署到不同的節(jié)點(diǎn)，否則也就無(wú)所謂分布式系統(tǒng)了，因此必然出現(xiàn)子網(wǎng)絡(luò)。而對(duì)于分布式系統(tǒng)而言，網(wǎng) 絡(luò)問(wèn)題又是一個(gè)必定會(huì)出現(xiàn)的異常情況，因此分區(qū)容錯(cuò)性也就成為了一個(gè)分布式系統(tǒng)必然需要面對(duì)和解決的問(wèn)題。因此系統(tǒng)架構(gòu)師往往需要把精力花在如何根據(jù)業(yè)務(wù) 特點(diǎn)在C（一致性）和A（可用性）之間尋求平衡。
BASE是Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）三個(gè)短語(yǔ)的縮寫(xiě)。BASE理論是對(duì)CAP中一致性和可用性權(quán)衡的結(jié)果，其來(lái)源于對(duì)大規(guī)?；ヂ?lián)網(wǎng)系統(tǒng)分布式實(shí)踐的總結(jié)， 是基于CAP定理逐步演化而來(lái)的。BASE理論的核心思想是：即使無(wú)法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性。
BASE理論面向的是大型高可用可擴(kuò)展的分布式系統(tǒng)，和傳統(tǒng)的事物ACID特性是相反的，它完全不同于ACID的強(qiáng)一致性模型，而是通過(guò)犧牲強(qiáng)一致性來(lái)獲得可用性，并允許數(shù)據(jù)在一段時(shí)間內(nèi)是不一致的，但最終達(dá)到一致?tīng)顟B(tài)。但同時(shí)，在實(shí)際的分布式場(chǎng)景中，不同業(yè)務(wù)單元和組件對(duì)數(shù)據(jù)一致性的要求是不同的，因此在具體的分布式系統(tǒng)架構(gòu)設(shè)計(jì)過(guò)程中，ACID特性和BASE理論往往又會(huì)結(jié)合在一起。
不同于ACID的剛性事務(wù)，在分布式場(chǎng)景下基于BASE理論，就出現(xiàn)了柔性事務(wù)的概念。要想通過(guò)柔性事務(wù)來(lái)達(dá)到最終的一致性，就需要依賴于一些特性，這些特性在具體的方案中不一定都要滿足，因?yàn)椴煌姆桨敢蟛灰粯?；但是都不滿足的話，是不可能做柔性事務(wù)的。
在分布式事務(wù)執(zhí)行過(guò)程中，如果某一個(gè)步驟執(zhí)行出錯(cuò)，就需要明確的知道其他幾個(gè)操作的處理情況，這就需要其他的服務(wù)都能夠提供查詢接口，保證可以通過(guò)查詢來(lái)判斷操作的處理情況。
為了保證操作的可查詢，需要對(duì)于每一個(gè)服務(wù)的每一次調(diào)用都有一個(gè)全局唯一的標(biāo)識(shí)，可以是業(yè)務(wù)單據(jù)號(hào)（如訂單號(hào)）、也可以是系統(tǒng)分配的操作流水號(hào)（如支付記錄流水號(hào)）。除此之外，操作的時(shí)間信息也要有完整的記錄。
冪等性，其實(shí)是一個(gè)數(shù)學(xué)概念。冪等函數(shù)，或冪等方法，是指可以使用相同參數(shù)重復(fù)執(zhí)行，并能獲得相同結(jié)果的函數(shù)。
f(f(x)) = f(x)
在編程中一個(gè)冪等操作的特點(diǎn)是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。也就是說(shuō)，同一個(gè)方法，使用同樣的參數(shù)，調(diào)用多次產(chǎn)生的業(yè)務(wù)結(jié)果與調(diào)用一次產(chǎn)生的業(yè)務(wù)結(jié)果相同。這一個(gè)要求其實(shí)也比較好理解，因?yàn)橐ＷC數(shù)據(jù)的最終一致性，很多解決防范都會(huì)有很多重試的操作，如果一個(gè)方法不保證冪等，那么將無(wú)法被重試。冪等操作的實(shí)現(xiàn)方式有多種，如在系統(tǒng)中緩存所有的請(qǐng)求與處理結(jié)果、檢測(cè)到重復(fù)操作后，直接返回上一次的處理結(jié)果等
XA是X/Open CAE Specification (Distributed Transaction Processing)模型中定義的TM（Transaction Manager）與RM（Resource Manager）之間進(jìn)行通信的接口。
在XA規(guī)范中，數(shù)據(jù)庫(kù)充當(dāng)RM角色，應(yīng)用需要充當(dāng)TM的角色，即生成全局的txId，調(diào)用XAResource接口，把多個(gè)本地事務(wù)協(xié)調(diào)為全局統(tǒng)一的分布式事務(wù)。
圖片
二階段提交是XA的標(biāo)準(zhǔn)實(shí)現(xiàn)。它將分布式事務(wù)的提交拆分為2個(gè)階段：prepare和commit/rollback。
2PC模型中，在prepare階段需要等待所有參與子事務(wù)的反饋，因此可能造成數(shù)據(jù)庫(kù)資源鎖定時(shí)間過(guò)長(zhǎng)，不適合并發(fā)高以及子事務(wù)生命周長(zhǎng)較長(zhǎng)的業(yè)務(wù)場(chǎng)景。兩階段提交這種解決方案屬于犧牲了一部分可用性來(lái)?yè)Q取的一致性。
saga的提出，最早是為了解決可能會(huì)長(zhǎng)時(shí)間運(yùn)行的分布式事務(wù)（long-running process）的問(wèn)題。所謂long-running的分布式事務(wù)，是指那些企業(yè)業(yè)務(wù)流程，需要跨應(yīng)用、跨企業(yè)來(lái)完成某個(gè)事務(wù)，甚至在事務(wù)流程中還需要有手工操作的參與，這類事務(wù)的完成時(shí)間可能以分計(jì)，以小時(shí)計(jì)，甚至可能以天計(jì)。這類事務(wù)如果按照事務(wù)的ACID的要求去設(shè)計(jì)，勢(shì)必造成系統(tǒng)的可用性大大的降低。試想一個(gè)由兩臺(tái)服務(wù)器一起參與的事務(wù)，服務(wù)器A發(fā)起事務(wù)，服務(wù)器B參與事務(wù)，B的事務(wù)需要人工參與，所以處理時(shí)間可能很長(zhǎng)。如果按照ACID的原則，要保持事務(wù)的隔離性、一致性，服務(wù)器A中發(fā)起的事務(wù)中使用到的事務(wù)資源將會(huì)被鎖定，不允許其他應(yīng)用訪問(wèn)到事務(wù)過(guò)程中的中間結(jié)果，直到整個(gè)事務(wù)被提交或者回滾。這就造成事務(wù)A中的資源被長(zhǎng)時(shí)間鎖定，系統(tǒng)的可用性將不可接受。
而saga，則是一種基于補(bǔ)償?shù)南Ⅱ?qū)動(dòng)的用于解決long-running process的一種解決方案。目標(biāo)是為了在確保系統(tǒng)高可用的前提下盡量確保數(shù)據(jù)的一致性。 還是上面的例子，如果用saga來(lái)實(shí)現(xiàn)，那就是這樣的流程：服務(wù)器A的事務(wù)先執(zhí)行，如果執(zhí)行順利，那么事務(wù)A就先行提交；如果提交成功，那么就開(kāi)始執(zhí)行事務(wù)B，如果事務(wù)B也執(zhí)行順利，則事務(wù)B也提交，整個(gè)事務(wù)就算完成。但是如果事務(wù)B執(zhí)行失敗，那事務(wù)B本身需要回滾，這時(shí)因?yàn)槭聞?wù)A已經(jīng)提交，所以需要執(zhí)行一個(gè)補(bǔ)償操作，將已經(jīng)提交的事務(wù)A執(zhí)行的操作作反操作，恢復(fù)到未執(zhí)行前事務(wù)A的狀態(tài)。這樣的基于消息驅(qū)動(dòng)的實(shí)現(xiàn)思路，就是saga。我們可以看出，saga是犧牲了數(shù)據(jù)的強(qiáng)一致性，僅僅實(shí)現(xiàn)了最終一致性，但是提高了系統(tǒng)整體的可用性。
TCC 其實(shí)就是采用的補(bǔ)償機(jī)制，其核心思想是：針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷）操作。TCC模型是把鎖的粒度完全交給業(yè)務(wù)處理。它分為三個(gè)階段：
下面對(duì)TCC模式下，A賬戶往B賬戶匯款100元為例子，對(duì)業(yè)務(wù)的改造進(jìn)行詳細(xì)的分析：
圖片
匯款服務(wù)和收款服務(wù)分別需要實(shí)現(xiàn)，Try-Confirm-Cancel接口，并在業(yè)務(wù)初始化階段將其注入到TCC事務(wù)管理器中。
[匯款服務(wù)]Try： 檢查A賬戶有效性，即查看A賬戶的狀態(tài)是否為“轉(zhuǎn)帳中”或者“凍結(jié)”； 檢查A賬戶余額是否充足； 從A賬戶中扣減100元，并將狀態(tài)置為“轉(zhuǎn)賬中”； 預(yù)留扣減資源，將從A往B賬戶轉(zhuǎn)賬100元這個(gè)事件存入消息或者日志中；Confirm： 不做任何操作；Cancel： A賬戶增加100元； 從日志或者消息中，釋放扣減資源。[收款服務(wù)]Try： 檢查B賬戶賬戶是否有效；Confirm： 讀取日志或者消息，B賬戶增加100元； 從日志或者消息中，釋放扣減資源；Cancel： 不做任何操作。由此可以看出，TCC模型對(duì)業(yè)務(wù)的侵入強(qiáng)，改造的難度大。
本地消息表這種實(shí)現(xiàn)方式應(yīng)該是業(yè)界使用最多的，其核心思想是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理，這種思路是來(lái)源于ebay。我們可以從下面的流程圖中看出其中的一些細(xì)節(jié)：
圖片
基本思路就是：
消息生產(chǎn)方，需要額外建一個(gè)消息表，并記錄消息發(fā)送狀態(tài)。消息表和業(yè)務(wù)數(shù)據(jù)要在一個(gè)事務(wù)里提交，也就是說(shuō)他們要在一個(gè)數(shù)據(jù)庫(kù)里面。然后消息會(huì)經(jīng)過(guò)MQ發(fā)送到消息的消費(fèi)方。如果消息發(fā)送失敗，會(huì)進(jìn)行重試發(fā)送。
消息消費(fèi)方，需要處理這個(gè)消息，并完成自己的業(yè)務(wù)邏輯。此時(shí)如果本地事務(wù)處理成功，表明已經(jīng)處理成功了，如果處理失敗，那么就會(huì)重試執(zhí)行。如果是業(yè)務(wù)上面的失敗，可以給生產(chǎn)方發(fā)送一個(gè)業(yè)務(wù)補(bǔ)償消息，通知生產(chǎn)方進(jìn)行回滾等操作。
生產(chǎn)方和消費(fèi)方定時(shí)掃描本地消息表，把還沒(méi)處理完成的消息或者失敗的消息再發(fā)送一遍。如果有靠譜的自動(dòng)對(duì)賬補(bǔ)賬邏輯，這種方案還是非常實(shí)用的。
事務(wù)消息作為一種異步確保型事務(wù)， 將兩個(gè)事務(wù)分支通過(guò)MQ進(jìn)行異步解耦，事務(wù)消息的設(shè)計(jì)流程同樣借鑒了兩階段提交理論，整體交互流程如下圖所示：
圖片
有一些第三方的MQ是支持事務(wù)消息的，比如RocketMQ，但是市面上一些主流的MQ都是不支持事務(wù)消息的，比如 RabbitMQ 和 Kafka 都不支持。
最大努力通知方案主要也是借助MQ消息系統(tǒng)來(lái)進(jìn)行事務(wù)控制，這一點(diǎn)與可靠消息最終一致方案一樣?？磥?lái)MQ中間件確實(shí)在一個(gè)分布式系統(tǒng)架構(gòu)中，扮演者重要的角色。最大努力通知方案是比較簡(jiǎn)單的分布式事務(wù)方案，它本質(zhì)上就是通過(guò)定期校對(duì)，實(shí)現(xiàn)數(shù)據(jù)一致性。
最大努力通知方案的實(shí)現(xiàn):
最大努力通知方案的特點(diǎn):
屬性 | 2PC | TCC | 本地消息表 | 事務(wù)消息 | 盡最大努力通知 |
事務(wù)一致性 | 強(qiáng) | 弱 | 弱 | 弱 | 弱 |
復(fù)雜性 | 中 | 高 | 低 | 低 | 低 |
業(yè)務(wù)侵入性 | 小 | 大 | 中 | 中 | 中 |
使用局限性 | 大 | 大 | 小 | 中 | 中 |
性能 | 低 | 中 | 高 | 高 | 高 |
維護(hù)成本 | 低 | 高 | 低 | 中 | 中 |
分布式事務(wù)服務(wù)（Distributed Transaction Service，簡(jiǎn)稱 DTS）是一個(gè)分布式事務(wù)框架，用來(lái)保障在大規(guī)模分布式環(huán)境下事務(wù)的最終一致性。DTS 從架構(gòu)上分為 xts-client 和 xts-server 兩部分，前者是一個(gè)嵌入客戶端應(yīng)用的 Jar 包，主要負(fù)責(zé)事務(wù)數(shù)據(jù)的寫(xiě)入和處理；后者是一個(gè)獨(dú)立的系統(tǒng)，主要負(fù)責(zé)異常事務(wù)的恢復(fù)。
核心概念
在 DTS 內(nèi)部，我們將一個(gè)分布式事務(wù)的關(guān)聯(lián)方，分為發(fā)起方和參與者兩類：
發(fā)起方： 分布式事務(wù)的發(fā)起方負(fù)責(zé)啟動(dòng)分布式事務(wù)，觸發(fā)創(chuàng)建相應(yīng)的主事務(wù)記錄。發(fā)起方是分布式事務(wù)的協(xié)調(diào)者，負(fù)責(zé)調(diào)用參與者的服務(wù)，并記錄相應(yīng)的事務(wù)日志，感知整個(gè)分布式事務(wù)狀態(tài)來(lái)決定整個(gè)事務(wù)是 COMMIT 還是 ROLLBACK。
參與者： 參與者是分布式事務(wù)中的一個(gè)原子單位，所有參與者都必須在一階段接口（Prepare）中標(biāo)注（Annotation）參與者的標(biāo)識(shí)，它定義了 prepare、commit、rollback 3個(gè)基本接口，業(yè)務(wù)系統(tǒng)需要實(shí)現(xiàn)這3個(gè)接口，并保證其業(yè)務(wù)數(shù)據(jù)的冪等性，也必須保證 prepare 中的數(shù)據(jù)操作能夠被提交（COMMIT）或者回滾（ROLLBACK）。從存儲(chǔ)結(jié)構(gòu)上，DTS 的事務(wù)狀態(tài)數(shù)據(jù)可以分為主事務(wù)記錄（Activity）和分支事務(wù)記錄（Action）兩類：
這應(yīng)該屬于我們上面所說(shuō)的TCC模式。
本地消息表這種實(shí)現(xiàn)方式的思路，其實(shí)是源于ebay，后來(lái)通過(guò)支付寶等公司的布道，在業(yè)內(nèi)廣泛使用。其基本的設(shè)計(jì)思想是將遠(yuǎn)程分布式事務(wù)拆分成一系列的本地事務(wù)。如果不考慮性能及設(shè)計(jì)優(yōu)雅，借助關(guān)系型數(shù)據(jù)庫(kù)中的表即可實(shí)現(xiàn)。
舉個(gè)經(jīng)典的跨行轉(zhuǎn)賬的例子來(lái)描述。第一步，扣款1W，通過(guò)本地事務(wù)保證了憑證消息插入到消息表中。第二步，通知對(duì)方銀行賬戶上加1W了。那問(wèn)題來(lái)了，如何通知到對(duì)方呢？
通常采用兩種方式：
類似使用本地消息表+消息通知的還有去哪兒，蘑菇街
最大努力通知型。如支付寶、微信的支付回調(diào)接口方式，不斷回調(diào)直至成功，或直至調(diào)用次數(shù)衰減至失敗狀態(tài)。
2PC/3PC需要資源管理器(mysql, redis)支持XA協(xié)議，且整個(gè)事務(wù)的執(zhí)行期間需要鎖住事務(wù)資源，會(huì)降低性能。故先排除。
TCC的模式，需要事務(wù)接口提供try,confirm,cancel三個(gè)接口，提高了編程的復(fù)雜性。需要依賴于業(yè)務(wù)方來(lái)配合提供這樣的接口。推行難度大，暫時(shí)排除。
最大努力通知型，應(yīng)用于異構(gòu)或者服務(wù)平臺(tái)當(dāng)中
可以看到ebay的經(jīng)典模式中，分布式的事務(wù)，是通過(guò)本地事務(wù)+可靠消息，來(lái)達(dá)到事務(wù)的最終一致性的。但是出現(xiàn)了事務(wù)消息，就把本地事務(wù)的工作給涵蓋在事務(wù)消息當(dāng)中了。所以，接下來(lái)要基于事務(wù)消息來(lái)套我們的應(yīng)用場(chǎng)景，看起是否滿足我們對(duì)分布式事務(wù)產(chǎn)品的要求。
本文鏈接：http://www.www897cc.com/showinfo-26-39536-0.html從一筆交易充值，考慮到分布式事務(wù)處理
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)