引言

隨著業(yè)務(wù)的發(fā)展，微服務(wù)架構(gòu)逐漸成為當(dāng)下業(yè)務(wù)中臺(tái)的主流架構(gòu)形式，它不但解決了各個(gè)應(yīng)用之間的解耦問題，同時(shí)也解決了單體應(yīng)用的性能問題實(shí)現(xiàn)可擴(kuò)展可動(dòng)態(tài)伸縮的能力。如下圖所示，業(yè)務(wù)中臺(tái)就是將平臺(tái)的通用能力進(jìn)行下沉，避免重復(fù)建設(shè)，形成底座平臺(tái)能力，上層的各個(gè)應(yīng)用服務(wù)都是基于中臺(tái)能力進(jìn)行快速構(gòu)建。但是隨著應(yīng)用規(guī)模的擴(kuò)大，原本在單體應(yīng)用中不是問題的問題，在微服務(wù)架構(gòu)中可能就是比較嚴(yán)重的問題，本文所要探討的服務(wù)之間的數(shù)據(jù)一致性便是其中最具代表性的問題。本文將結(jié)合常見的電商下單場(chǎng)景來說明業(yè)務(wù)中臺(tái)數(shù)據(jù)一致性方案。

數(shù)據(jù)一致性原理預(yù)備知識(shí)

在探討業(yè)務(wù)中臺(tái)數(shù)據(jù)一致性方案之前，我們先來一起回顧下數(shù)據(jù)庫事務(wù)的相關(guān)內(nèi)容，通過對(duì)數(shù)據(jù)庫事務(wù)的分析，我們可以看出來在微服務(wù)架構(gòu)中想要保證數(shù)據(jù)的一致性將會(huì)遇到什么樣的問題。

1、本地事務(wù)

事務(wù)的概念對(duì)于程序猿來說一定不陌生，這里的事務(wù)指的是數(shù)據(jù)庫事務(wù)。所謂數(shù)據(jù)庫事務(wù)，簡單來理解就是一套關(guān)于數(shù)據(jù)一致性維護(hù)的數(shù)據(jù)庫機(jī)制。 我們都知道，實(shí)際業(yè)務(wù)平臺(tái)大部分的業(yè)務(wù)數(shù)據(jù)還是保存在關(guān)系型數(shù)據(jù)庫中，在單體應(yīng)用的時(shí)代，數(shù)據(jù)庫實(shí)例本身可以保證事務(wù)的有效性。
數(shù)據(jù)庫事務(wù)需要滿足四個(gè)基本特征：

（1）原子性（Atomicity）：極端主義者，要么大家一起成功，有一個(gè)失敗都不行

（2）一致性（Consistency）: 數(shù)據(jù)具有一致性，不存在狀態(tài)不確定的狀況

（3）隔離性（Isolation）：事務(wù)之間互相不干擾，你走你的陽關(guān)道，我走我的獨(dú)木橋

（4）永久性（Durability）：一旦事務(wù)提交后，數(shù)據(jù)就記錄就會(huì)被持久化

都說王守義 13 香，筆者最近也下單了一部 pro 準(zhǔn)備換掉三年前的 iphone。那么我們以下單購買 iphone13 進(jìn)行舉例說明，我們暫時(shí)將如下圖所示，如果在一個(gè)完整事務(wù)中，存在生成訂單、扣減庫存、增加積分以及發(fā)放優(yōu)惠券這四項(xiàng)業(yè)務(wù)，那么要么這四項(xiàng)都成功，下單夠購買 13 香這個(gè)業(yè)務(wù)才算是成功，中間有一項(xiàng)失敗就會(huì)造成業(yè)務(wù)數(shù)據(jù)的不一致，因此需要進(jìn)行事務(wù)回滾，回滾到下單前的狀態(tài)，以保證業(yè)務(wù)數(shù)據(jù)的一致性。

2、分布式事務(wù)

隨著業(yè)務(wù)的不斷發(fā)展，業(yè)務(wù)復(fù)雜度也在不斷的增長，企業(yè)基于微服務(wù)架構(gòu)向下沉淀出了通用的業(yè)務(wù)中臺(tái)，數(shù)據(jù)的訪問形式變得復(fù)雜了，服務(wù)節(jié)點(diǎn)間的數(shù)據(jù)訪問通過 API 接口進(jìn)行。原本單數(shù)據(jù)庫實(shí)例只能保證數(shù)據(jù)庫實(shí)例內(nèi)部的事務(wù)，但是在跨數(shù)據(jù)庫實(shí)例以及分布式業(yè)務(wù)調(diào)用過程中，單數(shù)據(jù)庫實(shí)例已經(jīng)無法保證全局事務(wù)的有效性。因此我們需要分布式的事務(wù)機(jī)制來保證各個(gè)服務(wù)節(jié)點(diǎn)之間的數(shù)據(jù)邏輯一致，否則就會(huì)出現(xiàn)如下的數(shù)據(jù)不一致的問題。

針對(duì)分布式場(chǎng)景下的數(shù)據(jù)一致性問題，業(yè)界提出了 CAP 理論以及 BASE 理論，同時(shí)在這些理論的基礎(chǔ)之上產(chǎn)生了相應(yīng)的分布式事務(wù)解決方案。我們先來看下什么是 CAP 理論以及 BASE 理論。

CAP 理論

Consistency：數(shù)據(jù)一致性

Avalibility：數(shù)據(jù)可用性

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

任何一個(gè)分布式系統(tǒng)是沒法同時(shí)滿足 CAP 中的三項(xiàng)的，為什么這么說呢？我們來舉個(gè)簡單的例子來進(jìn)行說明。如下圖所示，訂單服務(wù)將生成的訂服務(wù)寫入訂單數(shù)據(jù)主庫，同時(shí)將數(shù)據(jù)同步到訂單數(shù)據(jù)從庫中，訂單服務(wù)從從庫中進(jìn)行訂單數(shù)據(jù)查詢，從人實(shí)現(xiàn)訂單數(shù)據(jù)的讀寫分離。那么我們繼續(xù)來看，當(dāng)系統(tǒng)滿足分區(qū)容錯(cuò)性之后，數(shù)據(jù)一致性和數(shù)據(jù)可用性之間存在怎樣的矛盾。

如果必須實(shí)現(xiàn)數(shù)據(jù)的一致性，那么當(dāng)訂單數(shù)據(jù)寫入主庫的時(shí)候，由于此時(shí)主庫還未將最新的訂單數(shù)據(jù)同步到從庫當(dāng)中，因此主庫和從庫出現(xiàn)了數(shù)據(jù)不一致的情況，但是一致性又要求必須實(shí)現(xiàn)數(shù)據(jù)的強(qiáng)一致，那么此時(shí)的只好將從庫鎖住不對(duì)外提供服務(wù)，直到主庫數(shù)據(jù)同步到從庫后再開放訂單數(shù)據(jù)查詢。因此在 這個(gè)過程中無法同時(shí)滿足數(shù)據(jù)一致性以及可用性。

對(duì)應(yīng)的 BASE 理論，其實(shí)就是一種 CAP 理論的實(shí)際權(quán)衡結(jié)果，既然無法做到強(qiáng)一致性，那么各個(gè)服務(wù)節(jié)點(diǎn)可以根據(jù)自身的業(yè)務(wù)特點(diǎn)實(shí)現(xiàn)數(shù)據(jù)的最終一致。所謂 BASE 理論指的就是：

a、Basically Available ― 基本可用，畢竟對(duì)于分布式系統(tǒng)來說，可用性比數(shù)據(jù)一致性性要重要的多

b、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ù)同步的過程中存在延時(shí)

c、Eventually consistent ― 最終一致性，強(qiáng)調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在進(jìn)過一段時(shí)間的同步后，最終能夠達(dá)到一個(gè)一致的狀態(tài)。最終一致性需要保證數(shù)據(jù)最終能夠一致而不需要保證數(shù)據(jù)實(shí)時(shí)的一致性。

看吧，實(shí)際上我們也不需要太為難我們自己，既然很難實(shí)現(xiàn)強(qiáng)一致性，那么實(shí)現(xiàn)最終一致性相對(duì)來說是一個(gè)非常劃算以及可行性較高的數(shù)據(jù)一致性解決方案。
有了前人大佬們總結(jié)的分布式理論，我們一起來看下幾種常見的分布式事務(wù)場(chǎng)景吧。

（1）一個(gè)事務(wù)中包含了多數(shù)據(jù)庫操作

我們還是以上面購買 13 香來舉個(gè)栗子，由于業(yè)務(wù)量的不斷攀升，之前的單數(shù)據(jù)庫實(shí)例已經(jīng)無法滿足當(dāng)前業(yè)務(wù)要求。因此我們將數(shù)據(jù)庫按照業(yè)務(wù)域進(jìn)行了拆分。我們簡化下購物的業(yè)務(wù)流程，簡化后包括生成訂單、扣減庫存以及增加積分，因此一個(gè)購物事務(wù)中包括了三個(gè)數(shù)據(jù)庫的操作，但是數(shù)據(jù)庫實(shí)例只能保證自身的事務(wù)特性，不能保證全局的事務(wù)特性。如果訂單生成，但是庫存沒有扣減，積分沒有增加，將數(shù)顯數(shù)據(jù)不一致問題，因此出現(xiàn)了分布式事務(wù)問題。

（2）一個(gè)事務(wù)中包含了多服務(wù)訪問同一數(shù)據(jù)庫

隨著業(yè)務(wù)的發(fā)展，原先單體項(xiàng)目的模塊越來越多，維護(hù)起來成本較高，比如訂單模塊修改了但是庫存模塊沒有修改，但是發(fā)布的時(shí)候還是需要發(fā)布整個(gè)應(yīng)用，萬一有個(gè) Bug 啥的還要回滾，不能做到功能和維護(hù)上面的隔離。因此我們需要對(duì)應(yīng)用不同的模塊進(jìn)行拆分，那么原本的內(nèi)部調(diào)用變成了兩個(gè)服務(wù)之間的遠(yuǎn)程調(diào)用，原本的本地事務(wù)就演變成了分布式事務(wù)。

（3）一個(gè)事務(wù)包含了多個(gè)微服務(wù)調(diào)用數(shù)據(jù)不一致引發(fā)的問題

在微服務(wù)架構(gòu)體系下面，原有的服務(wù)中的各個(gè)業(yè)務(wù)模塊經(jīng)過縱向拆分后，成為一個(gè)個(gè)獨(dú)立的服務(wù)，如前面的購物業(yè)務(wù)流程，整個(gè)過程涉及到多個(gè)微服務(wù)，因此數(shù)據(jù)庫提供的事務(wù)機(jī)制，只能保證一個(gè)微服務(wù)節(jié)點(diǎn)的事務(wù)，同樣不能保證全局的事務(wù)。因此當(dāng)一個(gè)微服務(wù)需要調(diào)用多個(gè)其他微服務(wù)完成對(duì)應(yīng)的業(yè)務(wù)時(shí)，分布式事務(wù)的問題就會(huì)出現(xiàn)。

數(shù)據(jù)一致性解決方案

正是因?yàn)榉植际轿⒎?wù)的復(fù)雜結(jié)構(gòu)，因此給維護(hù)數(shù)據(jù)一致性帶來了一定的挑戰(zhàn)，但是由于分布式理論的發(fā)展與實(shí)踐，為我們解決分布式系統(tǒng)提供了理論依據(jù)。

分布式系統(tǒng)數(shù)據(jù)一致性的保證的關(guān)鍵點(diǎn)就在于如何實(shí)現(xiàn)和單系統(tǒng)一樣的事務(wù)控制，在單點(diǎn)系統(tǒng)階段，數(shù)據(jù)的一致性通過數(shù)據(jù)庫本身的機(jī)制進(jìn)行保證。但是在分布式中臺(tái)系統(tǒng)中，數(shù)據(jù)一致性需要借助于外部的力量進(jìn)行保證。

當(dāng)下已經(jīng)有較為成熟的數(shù)據(jù)一致性解決方案了，下面我們來具體分析下各個(gè)解決方案，我們按照分布式系統(tǒng)是否強(qiáng)調(diào)數(shù)據(jù)的強(qiáng)一致性，我們可以將分布式事務(wù)分為剛性事務(wù)以及柔性事務(wù)。

1、剛性事務(wù)

所謂的剛性事務(wù)就是追求數(shù)據(jù)的強(qiáng)一致性，必須滿足數(shù)據(jù)庫事務(wù)的 ACID 特性。典型的剛性事務(wù)解決方案就是 XA 模型。它通過引入一個(gè)事務(wù)協(xié)調(diào)者的角色，站在全局的角度來看分布式事務(wù)，將各個(gè)子域合并為一個(gè)大的分布式事務(wù)來實(shí)現(xiàn)數(shù)據(jù)的一致性。

但是在實(shí)際的高并發(fā)場(chǎng)景下基本不會(huì)使用這樣的分布式解決方案，主要原因有以下幾點(diǎn)，我們以 XA 模型中最常見的兩階段提交的方案來說明其存在的不足之處。

（1）單點(diǎn)故障問題：由于引入了分布式事務(wù)的全局協(xié)調(diào)者的角色，那么如果一旦全局協(xié)調(diào)者產(chǎn)生故障，那么各個(gè)子事務(wù)參與者并不能獲取事務(wù)執(zhí)行結(jié)果狀態(tài)，導(dǎo)致子事務(wù)阻塞，因此我們需要花費(fèi)很大精力去保證事務(wù)協(xié)調(diào)者的高可用。

（2）性能問題：在大型分布式系統(tǒng)高并發(fā)場(chǎng)景下，由于參與分布式事務(wù)的 RM 過多，因此網(wǎng)絡(luò)通信次數(shù)、重試以及通信時(shí)間都會(huì)增加，導(dǎo)致可能的阻塞時(shí)間也會(huì)變長，從而降低了整個(gè)系統(tǒng)的吞吐狀況。

2、柔性事務(wù)

既然剛性事務(wù)在高并發(fā)場(chǎng)景下存在上述的問題，那么有沒有更好的數(shù)據(jù)一致性解決方案呢？這時(shí)候柔性分布式事務(wù)就派上用場(chǎng)了。柔性事務(wù)尊屬分布式事務(wù)的 BASE 理論，它允許一段時(shí)間內(nèi)的系統(tǒng)之間數(shù)據(jù)的不一致，但是在最終狀態(tài)下需要保證事務(wù)的一致性。

（1）TCC 模式

所謂 TCC 模式即為 Try-Confirm-Cancel，它是二階段提交的一種實(shí)現(xiàn)方式。它包含的主要操作如下所示：

**Try：**嘗試執(zhí)行業(yè)務(wù)，但是實(shí)際并沒有真正執(zhí)行，只是進(jìn)行數(shù)據(jù)檢查，鎖定業(yè)務(wù)資源，便于后續(xù)業(yè)務(wù)執(zhí)行需要

**Confirm：**執(zhí)行具體的業(yè)務(wù)操作，使用之前階段預(yù)留的業(yè)務(wù)資源數(shù)據(jù)

**Cancel：**如果在 try 階段某個(gè)事務(wù)執(zhí)行失敗，則取消之前的業(yè)務(wù)操作

Try 階段：

這個(gè)階段主要實(shí)現(xiàn)嘗試執(zhí)行對(duì)應(yīng)的業(yè)務(wù)，可以理解為一種預(yù)備執(zhí)行的狀態(tài)。因?yàn)樵谕瓿蓸I(yè)務(wù)流程之前，并不知道各個(gè)業(yè)務(wù)節(jié)點(diǎn)或者可以理解為子事務(wù)是否可以正常執(zhí)行，因此嘗試在各個(gè)子事務(wù)去預(yù)先執(zhí)行，看看能不能正常處理。

回到我們這個(gè)購買 13 香的例子當(dāng)中，訂單中心首先將訂單狀態(tài)修改為 UPDATING 狀態(tài)，而不是 COMPLETED 狀態(tài)。庫存中心可以將 13 香的庫存鎖住，積分中心同樣可以進(jìn)行預(yù)增加積分。

Confirm 階段：

如果有幸進(jìn)入這個(gè)階段，說明前期的 try 階段都已經(jīng)處理成功了，即為訂單的狀態(tài)成功變更為 UPDATING 狀態(tài)，庫存中的訂單數(shù)據(jù)量已經(jīng)被鎖定，用戶對(duì)應(yīng)的購物積分已經(jīng)預(yù)先增加了，這三個(gè)步驟都已經(jīng)完美實(shí)現(xiàn)了。對(duì)應(yīng)的 TCC 框架已經(jīng)感知到各個(gè) Try 階段的執(zhí)行結(jié)果，因此在執(zhí)行 Confirm 時(shí)候需要執(zhí)行對(duì)應(yīng)服務(wù)提供的 Confirm 接口去完成實(shí)際的數(shù)據(jù)提交。

TCC 框架需要分別調(diào)用各個(gè)服務(wù)的確認(rèn)提交接口完成對(duì)應(yīng)的本地事務(wù)提交。訂單服務(wù)需要將訂單狀態(tài)修改為訂單完成狀態(tài)、 庫存服務(wù)需要將將庫存進(jìn)行真實(shí)的扣減，用戶積分服務(wù)為用戶增加相應(yīng)的用戶積分。

Cancel 階段：

如果不幸走到這個(gè)階段，無論在哪個(gè)階段都需要對(duì)之前執(zhí)行的所有擦偶作執(zhí)行回滾，恢復(fù)原有數(shù)據(jù)。如在執(zhí)行到積分添加的過程中出現(xiàn)異常，那么代表這個(gè)分支事務(wù)在執(zhí)行中出現(xiàn)了問題，無法完成正常的事務(wù)提交。因此為了保證數(shù)據(jù)的一致性，需要將之前的數(shù)據(jù)進(jìn)行回滾操作。

在整個(gè) TCC 處理過程之中，還有一件事情需要特別注意，那就是為了保證業(yè)務(wù)的成功率，各個(gè)業(yè)務(wù)服務(wù)向 TCC 框架進(jìn)行 confirm 以及 TCC 向各個(gè)業(yè)務(wù)服務(wù)進(jìn)行 confirm 以及 cancel 的時(shí)候都需要進(jìn)行異常重試，以保證執(zhí)行的成功率，因此對(duì)應(yīng)的業(yè)務(wù)服務(wù)需要進(jìn)行冪等處理，防止重試導(dǎo)致的重復(fù)操作。

可以看得出來，TCC 模式下的微服務(wù)需要業(yè)務(wù)代碼重度耦合，實(shí)際編碼的體感很不好，需要借助于外部的 TCC 框架，同時(shí)需要在業(yè)務(wù)代碼中增加 Try、Cancel 處理流程需要的接口。上述的 TCC 解決方案，需要在用戶執(zhí)行完下單操作之后依次執(zhí)行訂單生成接口、庫存扣減接口以及用戶積分接口來完成整體的業(yè)務(wù)操作，但是在實(shí)際的業(yè)務(wù)場(chǎng)景中，我們大概率不會(huì)這么同步調(diào)用多個(gè)接口來完成具體業(yè)務(wù)，下面我們看看另外一種分布式數(shù)據(jù)一致性解決方案。

（2）可靠消息最終一致性

在實(shí)際的平臺(tái)中，我們通常使用消息事件來解決各個(gè)微服務(wù)之間的耦合問題。我們結(jié)合之前的購買 13 香的實(shí)際案例來進(jìn)行說明，可靠消息的事務(wù)模型實(shí)際上就是基于事件驅(qū)動(dòng)架構(gòu)，當(dāng)用戶在購買 13 香之后，創(chuàng)建了 13 香的訂單并完成支付，向消息中間件發(fā)送訂單已支付事件消息，訂閱了訂單支付支付之間消息的庫存服務(wù)、積分服務(wù)等，接收到對(duì)應(yīng)的訂單支付消息之后，執(zhí)行其對(duì)應(yīng)的業(yè)務(wù)流程，如扣減庫存以及增加用戶積分等。

從上述描述中我們可以看出來，可靠消息最終一致性的方案中，消息的可靠投遞是一切后續(xù)業(yè)務(wù)的重要前提，同時(shí)需要避免消息的重復(fù)消費(fèi)，因此對(duì)應(yīng)監(jiān)聽消息的服務(wù)的業(yè)務(wù)接口需要實(shí)現(xiàn)冪等性。我們來看如下的偽代碼。

public void generateOrder（） {

	try{
  boolean result = orderRepo.saveOrder(orderMpdel);
  
  if(result) {
    mqSender.sendMessage(orderModel);
  }
    
  
} catch(Exception e) {
  rollback();
}


}

在上述代碼中，無論是本地訂單數(shù)據(jù)保存（本地事務(wù)）處理失敗還是異步消息發(fā)送異常，我們都會(huì)進(jìn)行訂單數(shù)據(jù)回滾，這代碼看上去沒有什么毛病，但是我們?cè)僮屑?xì)分析下是不是真的沒有什么問題嗎？

由于引入了消息中間件，服務(wù)之間的調(diào)用不再是依次的同步調(diào)用，各自服務(wù)通過消費(fèi)對(duì)應(yīng)的訂單消息來實(shí)現(xiàn)各自的業(yè)務(wù)。當(dāng)用戶進(jìn)行下單操作后，訂單服務(wù)會(huì)生成對(duì)應(yīng)的訂單信息，而后發(fā)送訂單生成消息。但是由于是分布式系統(tǒng)，受網(wǎng)絡(luò)等因素的影響，有可能出現(xiàn)消息發(fā)送完成后訂單服務(wù)未接收到消息中間件返回的響應(yīng)信息，因此訂單服務(wù)將之前的訂單數(shù)據(jù)進(jìn)行了回滾，但是積分服務(wù)已經(jīng)將 MQ 中的訂單信息進(jìn)行了消費(fèi)，增加了用戶積分。這就造成了訂單與積分?jǐn)?shù)據(jù)不一致的情況。 另外如果在訂單生成之后，訂單服務(wù)掛掉了無法正常投遞消息也會(huì)造成數(shù)據(jù)不一致的情況。

a、本地消息表

通過本地消息表的方式將分布式事務(wù)拆解為本地事務(wù)的實(shí)現(xiàn)，如下圖所示，將訂單生成以及消息記錄表包裹在一個(gè)本地事務(wù)中，生成訂單信息后同時(shí)在本地消息表中插入一條訂單消息發(fā)送記錄用以記錄消息發(fā)送的狀態(tài)。如果消息發(fā)送失敗則記錄狀態(tài)，訂單服務(wù)進(jìn)行重試發(fā)送，超過重試次數(shù)后可以由定時(shí)服務(wù)進(jìn)行定時(shí)掃描本地未完成狀態(tài)的消息進(jìn)行重新發(fā)行消息，以保證消息的正常投遞。

當(dāng)消息到達(dá) MQ 之后，如果 MQ 進(jìn)行了正常的響應(yīng)則業(yè)務(wù)可以繼續(xù)。但是如果 MQ 未正常響應(yīng)，則訂單服務(wù)認(rèn)為 MQ 未能正常接收消息需要不斷進(jìn)行重試。

MQ 接收到消息并進(jìn)行持久化后，則響應(yīng)訂單服務(wù)說我這里已經(jīng)接收到你的訂單消息了，接下來的事情就交給我我吧，此時(shí)訂單服務(wù)不再進(jìn)行消息發(fā)送重試，本地消息表中的消息狀態(tài)為已發(fā)送。

消息發(fā)送成功后，積分服務(wù)將會(huì)消費(fèi)對(duì)應(yīng)的訂單消息，但是如果積分服務(wù)在執(zhí)行本地積分服務(wù)失敗后需要通知訂單服務(wù)將原來的訂單信息進(jìn)行回滾。

b、事務(wù)消息

關(guān)于事務(wù)消息，將在另外一篇文章詳細(xì)介紹，主要的思想是借助于 RocketMQ 的事務(wù)消息機(jī)制，將分布式事務(wù)轉(zhuǎn)換為兩階段提交的解決方案，從而實(shí)現(xiàn)依托于消息中間件的事務(wù)一致性解決方案。

總結(jié)

本文以最常見的電商購物案例為實(shí)際背景，圍繞如何實(shí)現(xiàn)業(yè)務(wù)中臺(tái)的數(shù)據(jù)一致性進(jìn)行了詳細(xì)的說明，分別從分布式系統(tǒng)數(shù)據(jù)一致性問題產(chǎn)生的背景、相關(guān)的分布式事務(wù)理論以及基于理論之上產(chǎn)生的相應(yīng)的解決方案總結(jié)了業(yè)務(wù)中臺(tái)的數(shù)據(jù)一致性的解決方案。重點(diǎn)闡述了柔分布式事務(wù)解決方案在業(yè)務(wù)中臺(tái)數(shù)據(jù)一致性實(shí)踐中的應(yīng)用。

到此這篇關(guān)于Java業(yè)務(wù)中臺(tái)確保數(shù)據(jù)一致性的解決方案的文章就介紹到這了,更多相關(guān)Java 數(shù)據(jù)一致性內(nèi)容請(qǐng)搜索服務(wù)器之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持服務(wù)器之家！

原文鏈接：https://blog.csdn.net/Diamond_Tao/article/details/120688343