成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

分布式系列第一彈:分布式一致性!

開(kāi)發(fā) 前端 分布式 分布式
互聯(lián)網(wǎng)時(shí)代和環(huán)境下,為了快速需求響應(yīng)和提高系統(tǒng)吞吐,往往進(jìn)行微服務(wù)化改造,將復(fù)雜系統(tǒng)和數(shù)據(jù)進(jìn)行拆分;這時(shí)候的一致性指分布式服務(wù)化系統(tǒng)之間的弱一致性,包括應(yīng)用系統(tǒng)一致性和數(shù)據(jù)一致性.

[[436204]]

背景

互聯(lián)網(wǎng)時(shí)代和環(huán)境下,為了快速需求響應(yīng)和提高系統(tǒng)吞吐,往往進(jìn)行微服務(wù)化改造,將復(fù)雜系統(tǒng)和數(shù)據(jù)進(jìn)行拆分;

這時(shí)候的一致性指分布式服務(wù)化系統(tǒng)之間的弱一致性,包括應(yīng)用系統(tǒng)一致性和數(shù)據(jù)一致性;

生活中的一致性例子:

銀行處理轉(zhuǎn)賬時(shí),扣減你賬戶上的余額,然后增加別人賬戶的余額;

如果扣減你的賬戶余額成功,增加別人賬戶余額失敗,那么你就會(huì)損失這筆資金。

反過(guò)來(lái),如果扣減你的賬戶余額失敗,增加別人賬戶余額成功,那么銀行就會(huì)損失這筆資金,銀行需要賠付;

下面通過(guò)理論和實(shí)際方案的介紹,來(lái)學(xué)習(xí)分布式一致性相關(guān)內(nèi)容!

基礎(chǔ)理論

ACID

數(shù)據(jù)庫(kù)管理系統(tǒng)(DBMS)在寫(xiě)入或更新資料的過(guò)程中,為保證事務(wù)是正確可靠的,所必須具備的四個(gè)特性:原子性(atomicity)、一致性(consistency)、隔離性(isolation)、持久性(durability)。

在數(shù)據(jù)庫(kù)系統(tǒng)中,一個(gè)事務(wù)是指:由一系列數(shù)據(jù)庫(kù)操作組成的一個(gè)完整的邏輯過(guò)程。

例如銀行轉(zhuǎn)帳,從原賬戶扣除金額,以及向目標(biāo)賬戶添加金額,這兩個(gè)數(shù)據(jù)庫(kù)操作的總和,構(gòu)成一個(gè)完整的邏輯過(guò)程,不可拆分。

這個(gè)過(guò)程被稱(chēng)為一個(gè)事務(wù),具有ACID特性

CAP理論

一致性(Consistency)

在分布式環(huán)境下,一致性是指數(shù)據(jù)在多個(gè)副本之間能否保持一致的特性。

在一致性的需求下,當(dāng)一個(gè)系統(tǒng)在數(shù)據(jù)一致的狀態(tài)下執(zhí)行更新操作后,應(yīng)該保證系統(tǒng)的數(shù)據(jù)仍然處于一致的狀態(tài)

可用性(Availability)

可用性是指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài),對(duì)于用戶的每一個(gè)操作請(qǐng)求總是能夠在有限的時(shí)間內(nèi)返回結(jié)果。

  • "有限時(shí)間內(nèi)"是指,對(duì)于用戶的一個(gè)操作請(qǐng)求,系統(tǒng)必須能夠在指定的時(shí)間內(nèi)返回對(duì)應(yīng)的處理結(jié)果,如果超過(guò)了這個(gè)時(shí)間范圍,那么系統(tǒng)就被認(rèn)為是不可用的
  • "返回結(jié)果"是可用性的另一個(gè)非常重要的指標(biāo),它要求系統(tǒng)在完成對(duì)用戶請(qǐng)求的處理后,返回一個(gè)正常的響應(yīng)結(jié)果

分區(qū)容錯(cuò)性(Partition Tolerance)

分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時(shí)候,仍然需要能夠保證對(duì)外提供滿足一致性和可用性的服務(wù),除非是整個(gè)網(wǎng)絡(luò)環(huán)境都發(fā)生了故障

實(shí)際情況

CAP理論證明,任何分布式系統(tǒng)只可同時(shí)滿足二點(diǎn),沒(méi)法三者兼顧

滿足C和A,那么P能不能滿足呢?

滿足C需要所有的服務(wù)器的數(shù)據(jù)要一樣,也就是說(shuō)要實(shí)現(xiàn)數(shù)據(jù)的同步,那么同步要不要時(shí)間?肯定是要的,并且機(jī)器越多,同步的時(shí)間肯定越慢,這里問(wèn)題就來(lái)了,我們同時(shí)也滿足了A,也就是說(shuō),我要同步時(shí)間短才行。這樣的話,機(jī)器就不能太多了,也就是說(shuō)P是滿足不了的

滿足C和P,那么A能不能滿足呢?

滿足P需要很多服務(wù)器,假設(shè)有1000臺(tái)服務(wù)器,同時(shí)滿足了C,也就是說(shuō)要保證每臺(tái)機(jī)器的數(shù)據(jù)都一樣,那么同步的時(shí)間可就很大,在這種情況下,我們肯定是不能保證用戶隨時(shí)訪問(wèn)每臺(tái)服務(wù)器獲取到的數(shù)據(jù)都是最新的,想要獲取最新的,你就得等,等全部同步完了,你就可以獲取到了,但是我們的A要求短時(shí)間就可以拿到想要的數(shù)據(jù)啊,這不就是矛盾了,所以說(shuō)這里A是滿足不了了

對(duì)于分布式系統(tǒng)而言,網(wǎng)絡(luò)問(wèn)題又是一個(gè)必定會(huì)出現(xiàn)的異常情況,因此分區(qū)容錯(cuò)性也就成為了一個(gè)分布式系統(tǒng)必然需要面對(duì)和解決的問(wèn)題。

因此往往需要把精力花在如何根據(jù)業(yè)務(wù)特點(diǎn)在C(一致性)和A(可用性)之間尋求平衡

BASE理論

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á)到最終一致性。

接下來(lái)看一下BASE中的三要素:

基本可用(Basically Available)

基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時(shí)候,允許損失部分可用性(注意,這絕不等價(jià)于系統(tǒng)不可用)。

比如:

  • 響應(yīng)時(shí)間上的損失。正常情況下,一個(gè)在線搜索引擎需要在0.5秒之內(nèi)返回給用戶相應(yīng)的查詢(xún)結(jié)果,但由于出現(xiàn)故障,查詢(xún)結(jié)果的響應(yīng)時(shí)間增加了1~2秒
  • 系統(tǒng)功能上的損失:正常情況下,在一個(gè)電子商務(wù)網(wǎng)站上進(jìn)行購(gòu)物的時(shí)候,消費(fèi)者幾乎能夠順利完成每一筆訂單,但是在一些節(jié)日大促購(gòu)物高峰的時(shí)候,由于消費(fèi)者的購(gòu)物行為激增,為了保護(hù)購(gòu)物系統(tǒng)的穩(wěn)定性,部分消費(fèi)者可能會(huì)被引導(dǎo)到一個(gè)降級(jí)頁(yè)面

軟狀態(tài)(Soft State)

軟狀態(tài)指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài),并認(rèn)為該中間狀態(tài)的存在不會(huì)影響系統(tǒng)的整體可用性,即允許系統(tǒng)在不同節(jié)點(diǎn)的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)同步的過(guò)程存在延時(shí)

最終一致性(Eventually Consistent)

最終一致性強(qiáng)調(diào)的是所有的數(shù)據(jù)副本,在經(jīng)過(guò)一段時(shí)間的同步之后,最終都能夠達(dá)到一個(gè)一致的狀態(tài)。

因此,最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達(dá)到一致,而不需要實(shí)時(shí)保證系統(tǒng)數(shù)據(jù)的強(qiáng)一致性。

總的來(lái)說(shuō),BASE理論面向的是大型高可用可擴(kuò)展的分布式系統(tǒng),和傳統(tǒng)的事務(wù)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é)合在一起。

分布式一致性協(xié)議

兩階段提交協(xié)議(2PC)

第一階段(投票階段):

  1. 協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)詢(xún)問(wèn)是否可以執(zhí)行提交操作,并開(kāi)始等待各參與者節(jié)點(diǎn)的響應(yīng)
  2. 參與者節(jié)點(diǎn)執(zhí)行詢(xún)問(wèn)發(fā)起為止的所有事務(wù)操作,并將Undo信息和Redo信息寫(xiě)入日志(注意:若成功這里其實(shí)每個(gè)參與者已經(jīng)執(zhí)行了事務(wù)操作)
  3. 各參與者節(jié)點(diǎn)響應(yīng)協(xié)調(diào)者節(jié)點(diǎn)發(fā)起的詢(xún)問(wèn),如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行成功,則它返回一個(gè)"同意"消息;
  4. 如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行失敗,則它返回一個(gè)"中止"消息

第二階段(提交執(zhí)行階段):

當(dāng)協(xié)調(diào)者節(jié)點(diǎn)從所有參與者節(jié)點(diǎn)獲得的相應(yīng)消息都為"同意"時(shí):

協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出"正式提交"的請(qǐng)求

參與者節(jié)點(diǎn)正式完成操作,并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源

參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送"完成"消息

協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的"完成"消息后,完成事務(wù)

存在的問(wèn)題:

資源被同步阻塞

在數(shù)據(jù)提交的過(guò)程中,所有參與處理的服務(wù)器都處于阻塞狀態(tài),如果其他線程想訪問(wèn)臨界區(qū)的資源,需要等待該條會(huì)話請(qǐng)求在本地執(zhí)行完成后釋放臨界區(qū)資源。

因此,采用二階段提交算法也會(huì)降低程序并發(fā)執(zhí)行的效率。

單點(diǎn)問(wèn)題

此外,還會(huì)發(fā)生單點(diǎn)問(wèn)題。單點(diǎn)問(wèn)題也叫作單點(diǎn)服務(wù)器故障問(wèn)題,它指的是當(dāng)作為分布式集群系統(tǒng)的調(diào)度服務(wù)器發(fā)生故障時(shí),整個(gè)集群因?yàn)槿鄙賲f(xié)調(diào)者而無(wú)法進(jìn)行二階段提交算法。

單點(diǎn)問(wèn)題也是二階段提交最大的缺點(diǎn),因此使用二階段提交算法的時(shí)候通常都會(huì)進(jìn)行一些改良,以滿足對(duì)系統(tǒng)穩(wěn)定性的要求。

在Commit 階段出現(xiàn)數(shù)據(jù)不一致

當(dāng)統(tǒng)計(jì)集群中的服務(wù)器可以進(jìn)行事務(wù)操作時(shí),協(xié)調(diào)服務(wù)器會(huì)向這些處理事務(wù)操作的服務(wù)器發(fā)送 commit 提交請(qǐng)求。

如果在這個(gè)過(guò)程中,其中的一臺(tái)或幾臺(tái)服務(wù)器發(fā)生網(wǎng)絡(luò)故障,無(wú)法接收到來(lái)自協(xié)調(diào)服務(wù)器的提交請(qǐng)求,導(dǎo)致這些服務(wù)器無(wú)法完成最終的數(shù)據(jù)變更,就會(huì)造成整個(gè)分布式集群出現(xiàn)數(shù)據(jù)不一致的情況。

三階段提交協(xié)議(3PC)

三階段提交其實(shí)是在二階段算法的基礎(chǔ)上進(jìn)行了優(yōu)化和改進(jìn)。

為了解決二階段協(xié)議中的同步阻塞等問(wèn)題,三階段提交協(xié)議在協(xié)調(diào)者和參與者中都引入了超時(shí)機(jī)制,并且把兩階段提交協(xié)議的第一個(gè)階段拆分成了兩步:詢(xún)問(wèn),然后再鎖資源,最后真正提交。

注意事項(xiàng)

一旦進(jìn)入階段3,發(fā)生 協(xié)調(diào)者出現(xiàn)問(wèn)題 或 協(xié)調(diào)者和參與者之間的網(wǎng)絡(luò)出現(xiàn)故障,即參與者無(wú)法及時(shí)接收到來(lái)自協(xié)調(diào)者的 DoCommit 或 abort 請(qǐng)求,針對(duì)這種異常情況,參與者都會(huì)在等待超時(shí)之后,繼續(xù)進(jìn)行事務(wù)提交。

三階段提交協(xié)議存在的問(wèn)題

參與者接收到 PreCommit 消息后,如果網(wǎng)絡(luò)出現(xiàn)分區(qū),此時(shí)協(xié)調(diào)者和部分參與者無(wú)法進(jìn)行正常的網(wǎng)絡(luò)通信,該部分參與者依然會(huì)進(jìn)行事務(wù)的提交,必然出現(xiàn)數(shù)據(jù)的不一致性。

TCC

無(wú)論是 2PC 還是 3PC,都存在一個(gè)大粒度資源鎖定的問(wèn)題。

我們先來(lái)想象這樣一種場(chǎng)景,用戶在電商網(wǎng)站購(gòu)買(mǎi)商品1000元,使用余額支付800元,使用紅包支付200元。

我們看一下在 2PC 中的流程:

prepare 階段:

  • 下單系統(tǒng)插入一條訂單記錄,不提交
  • 余額系統(tǒng)減 800 元,給記錄加鎖,寫(xiě) redo 和 undo 日志,不提交
  • 紅包系統(tǒng)減 200 元,給記錄加鎖,寫(xiě) redo 和 undo 日志,不提交

commit 階段:

  • 下單系統(tǒng)提交訂單記錄
  • 余額系統(tǒng)提交,釋放鎖
  • 紅包系統(tǒng)提交,釋放鎖

為什么說(shuō)這是一種大粒度的資源鎖定呢?

是因?yàn)樵?prepare 階段,當(dāng)數(shù)據(jù)庫(kù)給用戶余額減 800 元之后,為了維持隔離性,會(huì)給該條記錄加鎖,在事務(wù)提交前,其它事務(wù)無(wú)法再訪問(wèn)該條記錄。

但實(shí)際上,我們只需要預(yù)留其中的 800 元,不需要鎖定整個(gè)用戶余額。這是 2PC 和 3PC 的局限,因?yàn)檫@兩者是資源層的協(xié)議,無(wú)法提供更靈活的資源鎖定操作。

為了解決這個(gè)問(wèn)題,TCC 應(yīng)運(yùn)而生。TCC 本質(zhì)上也是一個(gè)二階段提交協(xié)議,但和 JTA 中的二階段協(xié)議不同的是,它是一個(gè)服務(wù)層的協(xié)議,因此開(kāi)發(fā)者可以根據(jù)業(yè)務(wù)自由控制資源鎖定的粒度。

我們先來(lái)看一下 TCC 協(xié)議的運(yùn)行過(guò)程。

TCC 將事務(wù)的提交過(guò)程分為 try-confirm-cancel(實(shí)際上 TCC 就是 try、confirm、cancel 的簡(jiǎn)稱(chēng)) 三個(gè)階段:

  • try:完成業(yè)務(wù)檢查、預(yù)留業(yè)務(wù)資源
  • confirm:使用預(yù)留的資源執(zhí)行業(yè)務(wù)操作(需要保證冪等性)
  • cancel:取消執(zhí)行業(yè)務(wù)操作,釋放預(yù)留的資源(需要保證冪等性)

流程如下:

  1. 事務(wù)發(fā)起方向事務(wù)協(xié)調(diào)器發(fā)起事務(wù)請(qǐng)求,事務(wù)協(xié)調(diào)器調(diào)用所有事務(wù)參與者的 try 方法完成資源的預(yù)留,這時(shí)候并沒(méi)有真正執(zhí)行業(yè)務(wù),而是為后面具體要執(zhí)行的業(yè)務(wù)預(yù)留資源,這里完成了一階段。
  2. 如果事務(wù)協(xié)調(diào)器發(fā)現(xiàn)有參與者的 try 方法預(yù)留資源時(shí)候發(fā)現(xiàn)資源不夠,則調(diào)用參與方的 cancel 方法回滾預(yù)留的資源,需要注意 cancel 方法需要實(shí)現(xiàn)業(yè)務(wù)冪等,因?yàn)橛锌赡苷{(diào)用失敗(比如網(wǎng)絡(luò)原因參與者接受到了請(qǐng)求,但是由于網(wǎng)絡(luò)原因事務(wù)協(xié)調(diào)器沒(méi)有接受到回執(zhí))會(huì)重試。
  3. 如果事務(wù)協(xié)調(diào)器發(fā)現(xiàn)所有參與者的 try 方法返回都 OK,則事務(wù)協(xié)調(diào)器調(diào)用所有參與者的 confirm 方法,不做資源檢查,直接進(jìn)行具體的業(yè)務(wù)操作。
  4. 如果協(xié)調(diào)器發(fā)現(xiàn)所有參與者的 confirm 方法都 OK 了,則分布式事務(wù)結(jié)束。
  5. 如果協(xié)調(diào)器發(fā)現(xiàn)有些參與者的 confirm 方法失敗了,或者由于網(wǎng)絡(luò)原因沒(méi)有收到回執(zhí),則協(xié)調(diào)器會(huì)進(jìn)行重試。這里如果重試一定次數(shù)后還是失敗,常見(jiàn)的是做事務(wù)補(bǔ)償。

通過(guò)一個(gè)支付場(chǎng)景看看 TCC 在該場(chǎng)景中的流程:

Try操作

  • tryX 下單系統(tǒng)創(chuàng)建待支付訂單
  • tryY 凍結(jié)賬戶紅包 200 元
  • tryZ 凍結(jié)資金賬戶 800 元

Confirm操作

  • confirmX 訂單更新為支付成功
  • confirmY 扣減賬戶紅包 200 元
  • confirmZ 扣減資金賬戶 800 元

Cancel操作

  • cancelX 訂單處理異常,資金紅包退回,訂單支付失敗
  • cancelY 凍結(jié)紅包失敗,賬戶余額退回,訂單支付失敗
  • cancelZ 凍結(jié)余額失敗,賬戶紅包退回,訂單支付失敗

可以看到,我們使用了凍結(jié)代替了原先的賬號(hào)鎖定(實(shí)際操作中,凍結(jié)操作可以用數(shù)據(jù)庫(kù)減操作+日志實(shí)現(xiàn)),這樣在凍結(jié)操作之后,事務(wù)提交之前,其它事務(wù)也能使用賬戶余額,提高了并發(fā)性。

總結(jié)一下,相比于二階段提交協(xié)議,TCC 主要有以下區(qū)別:

  • 2PC 位于資源層而 TCC 位于服務(wù)層。
  • 2PC 的接口由第三方廠商實(shí)現(xiàn),TCC 的接口由開(kāi)發(fā)人員實(shí)現(xiàn)。
  • TCC 可以更靈活地控制資源鎖定的粒度。
  • TCC 對(duì)應(yīng)用的侵入性強(qiáng)。業(yè)務(wù)邏輯的每個(gè)分支都需要實(shí)現(xiàn) try、confirm、cancel 三個(gè)操作,應(yīng)用侵入性較強(qiáng),改造成本高。

比如,你的訂單服務(wù)中本來(lái)只有一個(gè)接口

  1. //修改代碼狀態(tài) 
  2. orderClient.updateStatus(); 

都要拆為三個(gè)接口,即:

  1. orderClient.tryUpateStatus(); 
  2. orderClient.confirmUpateStatus(); 
  3. orderClient.cancelUpateStatus(); 

目前TCC的實(shí)現(xiàn)有如下幾個(gè)

  • tcc-transaction:
  • ByteTCC
  • spring-cloud-rest-tcc

最終一致性模式

緩存一致性模式

高并發(fā)系統(tǒng)中一個(gè)常見(jiàn)的核心需求就是億級(jí)的讀需求,顯然,關(guān)系型數(shù)據(jù)庫(kù)并不是解決高并發(fā)讀需求的最佳方案,互聯(lián)網(wǎng)的經(jīng)典做法就是使用緩存

常用緩存方式分為本地緩存和分布式緩存兩種;如果對(duì)性能要求不是非常的高,優(yōu)先使用分布式緩存;對(duì)于數(shù)據(jù)實(shí)時(shí)性和分布式一直性要求不高的可以使用本地緩存,比如某些人員的配置,即使不同機(jī)器的配置短時(shí)間不相同也不影響正常業(yè)務(wù)流轉(zhuǎn)

數(shù)據(jù)庫(kù)與緩存只需要保持弱一致性,而不需要強(qiáng)一致性,常用的緩存方案參考:美團(tuán)面試題:緩存一致性,我是這么回答的!

查詢(xún)模式

服務(wù)操作都需要提供一個(gè)查詢(xún)接口,用來(lái)向外部輸出操作執(zhí)行的狀態(tài)。

服務(wù)操作的使用方可以通過(guò)查詢(xún)接口,得知服務(wù)操作執(zhí)行的狀態(tài),然后根據(jù)不同狀態(tài)來(lái)做不同的處理操作

舉個(gè)例子:

定時(shí)任務(wù)監(jiān)聽(tīng)生成中的訂單、單發(fā)送群消息,RD收到群消息查詢(xún)訂單的具體狀態(tài)判斷系統(tǒng)是否有問(wèn)題,是否需要人工修復(fù)

補(bǔ)償模式

如果整個(gè)操作處于不正常的狀態(tài),我們需要修正操作中有問(wèn)題的子操作,這可能需要重新執(zhí)行未完成的子操作,后者取消已經(jīng)完成的子操作,通過(guò)修復(fù)使整個(gè)分布式系統(tǒng)達(dá)到一致,為了讓系統(tǒng)最終一致而做的努力都叫做補(bǔ)償

  1. 自動(dòng)恢復(fù):程序根據(jù)發(fā)生不一致的環(huán)境,通過(guò)繼續(xù)未完成的操作,或者回滾已經(jīng)完成的操作,自動(dòng)來(lái)達(dá)到一致
  2. 通知運(yùn)營(yíng):如果程序無(wú)法自動(dòng)恢復(fù),并且設(shè)計(jì)時(shí)考慮到了不一致的場(chǎng)景,可以提供運(yùn)營(yíng)功能,通過(guò)運(yùn)營(yíng)手工進(jìn)行補(bǔ)償
  3. 通知技術(shù):如果很不巧,系統(tǒng)無(wú)法自動(dòng)回復(fù),又沒(méi)有運(yùn)營(yíng)功能,那必須通過(guò)技術(shù)手段來(lái)解決,技術(shù)手段包括走數(shù)據(jù)庫(kù)變更或者代碼變更來(lái)解決,這是最糟的一種場(chǎng)景

舉個(gè)例子:

監(jiān)聽(tīng)到生成中訂單后,系統(tǒng)自動(dòng)重新推送入庫(kù)消息重新生成入庫(kù)單進(jìn)行重試,如果系統(tǒng)沒(méi)法自動(dòng)恢復(fù)需要RD接入定位修復(fù)問(wèn)題

異步確保模式

異步確保模式是補(bǔ)償模式的一個(gè)典型案例,經(jīng)常應(yīng)用到使用方對(duì)響應(yīng)時(shí)間要求并不太高,我們通常把這類(lèi)操作從主流程中摘除,通過(guò)異步的方式進(jìn)行處理,處理后把結(jié)果通過(guò)通知系統(tǒng)通知給使用方,這個(gè)方案最大的好處能夠?qū)Ω卟l(fā)流量進(jìn)行削峰,例如:電商系統(tǒng)中的物流、配送,以及支付系統(tǒng)中的計(jì)費(fèi)、入賬等

實(shí)踐中,將要執(zhí)行的異步操作封裝后持久入庫(kù),然后通過(guò)定時(shí)撈取未完成的任務(wù)進(jìn)行補(bǔ)償操作來(lái)實(shí)現(xiàn)異步確保模式,只要定時(shí)系統(tǒng)足夠健壯,任何一個(gè)任務(wù)最終會(huì)被成功執(zhí)行

舉個(gè)例子:

采購(gòu)系統(tǒng)進(jìn)行預(yù)算釋放和耗用,會(huì)同步記錄日志,后期通過(guò)異步和定時(shí)任務(wù)重試保證釋放和耗用成功

定期校對(duì)模式

在操作的主流程中的系統(tǒng)間執(zhí)行校對(duì)操作,我們可以事后異步的批量校對(duì)操作的狀態(tài),如果發(fā)現(xiàn)不一致的操作,則進(jìn)行補(bǔ)償,補(bǔ)償操作與補(bǔ)償模式中的補(bǔ)償操作是一致的

實(shí)現(xiàn)定期校對(duì)的一個(gè)關(guān)鍵就是分布式系統(tǒng)中需要有一個(gè)自始至終唯一的ID,常用的唯一id生成方案

舉個(gè)例子:

財(cái)務(wù)那邊的對(duì)賬系統(tǒng)定期校對(duì)結(jié)算數(shù)據(jù)和業(yè)務(wù)單據(jù)數(shù)據(jù)的一致性

可靠消息模式

對(duì)于異步的操作可以使用消息隊(duì)列,通過(guò)消息隊(duì)列將調(diào)用方和被調(diào)用方進(jìn)行解耦,提高系統(tǒng)響應(yīng)速度,同時(shí)能夠達(dá)到消峰目的;

對(duì)于消息隊(duì)列,我們需要建立特殊的設(shè)施保證可靠的消息發(fā)送以及處理機(jī)的冪等

消息的可靠發(fā)送

發(fā)送消息之前,把消息持久到數(shù)據(jù)庫(kù),狀態(tài)標(biāo)記為待發(fā)送,然后發(fā)送消息,如果發(fā)送成功,將消息改為發(fā)送成功。定時(shí)任務(wù)定時(shí)從數(shù)據(jù)庫(kù)撈取一定時(shí)間內(nèi)未發(fā)送的消息,將消息發(fā)送

使用第三方消息管理器,發(fā)送消息之前,先發(fā)送一個(gè)預(yù)消息給第三方消息管理器,消息管理器將其持久到數(shù)據(jù)庫(kù),并標(biāo)記狀態(tài)為待發(fā)送,發(fā)送成功后,標(biāo)記消息為發(fā)送成功。定時(shí)任務(wù)定時(shí)從數(shù)據(jù)庫(kù)撈取一定時(shí)間內(nèi)未發(fā)送的消息,回查業(yè)務(wù)系統(tǒng)是否要繼續(xù)發(fā)送,根據(jù)查詢(xún)結(jié)果來(lái)確定消息的狀態(tài)

消息處理器的冪等性

保證消息一定要發(fā)送出去,那么就需要有重試機(jī)制,有了重試機(jī)制,消息一定會(huì)重復(fù),那么我們需要對(duì)重復(fù)做處,常用幾種方案

  • 使用數(shù)據(jù)庫(kù)表的唯一索引進(jìn)行防重,拒絕重復(fù)的請(qǐng)求
  • 使用分布式中間件Redis進(jìn)行防重
  • 使用狀態(tài)機(jī)防重,單據(jù)相關(guān)的業(yè)務(wù)會(huì)涉及到狀態(tài)機(jī),狀態(tài)在不同情況下會(huì)發(fā)生變更,如果狀態(tài)機(jī)已經(jīng)處于下一個(gè)狀態(tài),這時(shí)候來(lái)一個(gè)上一個(gè)狀態(tài)的變更,理論上是不能夠變更的,保證了有限狀態(tài)機(jī)的冪等
  • 使用樂(lè)觀鎖防重,數(shù)據(jù)更新帶條件,這也是在系統(tǒng)設(shè)計(jì)的時(shí)候,合理的選擇樂(lè)觀鎖,通過(guò)version或者其他條件來(lái)做樂(lè)觀鎖,這樣保證更新及時(shí)在并發(fā)的情況下,也不會(huì)有太大的問(wèn)題

舉個(gè)例子:

單據(jù)保存的http接口,前端提交時(shí)增加唯一id,通過(guò)Redis進(jìn)行防重提交,防止重復(fù)建單

訂單對(duì)接出入庫(kù)系統(tǒng)進(jìn)行mq異步交互,通過(guò)訂單的中間態(tài)狀態(tài)進(jìn)行重試,下游做防重

 

責(zé)任編輯:姜華 來(lái)源: 月伴飛魚(yú)
相關(guān)推薦

2019-10-11 23:27:19

分布式一致性算法開(kāi)發(fā)

2019-09-05 08:43:34

微服務(wù)分布式一致性數(shù)據(jù)共享

2021-06-03 15:27:31

RaftSOFAJRaft

2021-07-28 08:39:25

分布式架構(gòu)系統(tǒng)

2022-06-07 12:08:10

Paxos算法

2017-09-21 10:59:36

分布式系統(tǒng)線性一致性測(cè)試

2024-11-28 10:56:55

2025-06-09 08:00:37

分布式文件系統(tǒng)

2023-11-06 09:06:54

分布式一致性數(shù)據(jù)

2020-10-28 11:15:24

EPaxos分布式性算法

2017-09-22 12:08:01

數(shù)據(jù)庫(kù)分布式系統(tǒng)互聯(lián)網(wǎng)

2021-06-06 12:45:41

分布式CAPBASE

2024-05-27 10:42:55

2021-08-13 11:50:23

AnalyticDB 分布式數(shù)據(jù)庫(kù)

2018-03-19 09:50:50

分布式存儲(chǔ)系統(tǒng)

2025-03-14 08:00:00

分布式系統(tǒng)服務(wù)器一致性

2021-06-16 08:33:02

分布式事務(wù)ACID

2020-05-11 10:30:57

2PC分布式協(xié)議

2017-04-06 11:59:19

分布式服務(wù)化系統(tǒng)

2024-06-04 10:58:30

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)

主站蜘蛛池模板: 久久在线精品 | 久久久精品网站 | 久久久久久国产精品 | 国产乱码精品一区二三赶尸艳谈 | 日韩欧美在线播放 | 日日摸日日碰夜夜爽亚洲精品蜜乳 | 亚洲二区视频 | 日韩网| 久久手机在线视频 | 国产精品久久久久999 | 亚洲精品电影网在线观看 | 欧美日韩精品免费观看 | 中文字幕一区二区三区精彩视频 | 日韩国产一区二区 | 欧美精品一区三区 | 国产91精品在线 | 欧美激情国产日韩精品一区18 | av大片| 一级毛片中国 | 欧美精品啪啪 | 日本啊v在线 | 国产激情一区二区三区 | 自拍在线 | 一区二区免费在线观看 | 91免费在线视频 | 欧美一级久久 | 日韩国产精品一区二区三区 | 日韩在线免费视频 | 97视频精品| 天堂资源 | 成人精品视频在线观看 | 91私密视频 | 国产亚洲欧美日韩精品一区二区三区 | 国产精品1区2区3区 国产在线观看一区 | 一区二区三区四区在线免费观看 | 久久欧美高清二区三区 | 日韩美女一区二区三区在线观看 | 久久久久久黄 | 免费在线观看成人 | 国产成人精品a视频 | 四虎影音 |