概述

某些場(chǎng)景下，我們將業(yè)務(wù)數(shù)據(jù)落地之前，是需要先調(diào)用外部系統(tǒng)的多個(gè)寫接口，當(dāng)這些寫接口都操作成功了，我們才將業(yè)務(wù)數(shù)據(jù)落地到自己本地的數(shù)據(jù)庫(kù)里面。比如說：

public void updateProductInfo(Product product) {
  //1、將商品價(jià)格更新到價(jià)格系統(tǒng)
  priceService.updatePrice(product);
  //2、將庫(kù)存信息更新庫(kù)存系統(tǒng)
  stockService.updateStock(product);
  //3、將商品更新到本地?cái)?shù)據(jù)庫(kù)
  productService.updateProduct(product);
}

就上面這個(gè)例子(例子是虛構(gòu)的,只是為了說明問題而已)，它的執(zhí)行路徑有幾種：

• 1、調(diào)用價(jià)格系統(tǒng)、庫(kù)存系統(tǒng)的操作以及保存數(shù)據(jù)到本地DB都正常；
• 2、調(diào)用價(jià)格系統(tǒng)接口的時(shí)候就拋異常了;
• 3、調(diào)用價(jià)格系統(tǒng)接口正常，但是調(diào)用庫(kù)存系統(tǒng)的接口有異常;
• 4、調(diào)用價(jià)格系統(tǒng)和庫(kù)存系統(tǒng)的接口都正常了，但是將商品數(shù)據(jù)更新到本地?cái)?shù)據(jù)庫(kù)出現(xiàn)異常。

如果是第一和第二這兩種情況，無需考慮數(shù)據(jù)一致性問題，但是如果出現(xiàn)了第三和第四這兩種情況，我們就得根據(jù)業(yè)務(wù)實(shí)際情況，考慮如何保證數(shù)據(jù)的一致性。

這里說的保證數(shù)據(jù)一致性，必須是由調(diào)用方來保證的，服務(wù)端是無法保證的。

重試和操作日志

以上面提到的第三種情況來說明一下。

調(diào)用價(jià)格系統(tǒng)接口正常，但是調(diào)用庫(kù)存系統(tǒng)的接口有異常。

庫(kù)存接口允許重試

如果庫(kù)存系統(tǒng)接口是冪等的,那么調(diào)用方可以使用重試的機(jī)制，多調(diào)用幾次，比如說3次。如果還是不成功，那之前價(jià)格系統(tǒng)接口的操作就得走反向操作,進(jìn)行現(xiàn)場(chǎng)恢復(fù)。

庫(kù)存接口不允許重試

價(jià)格系統(tǒng)接口的操作得走反向操作，進(jìn)行現(xiàn)場(chǎng)恢復(fù)

要實(shí)現(xiàn)反向操作，恢復(fù)現(xiàn)場(chǎng)，有一種辦法是使用分布式事務(wù)，但是實(shí)現(xiàn)起來實(shí)在太復(fù)雜了，性能也不好?？梢試L試使用操作日志來恢復(fù)現(xiàn)場(chǎng)。比如說，價(jià)格系統(tǒng)調(diào)用成功了，把這個(gè)操作狀態(tài)以及相關(guān)的業(yè)務(wù)數(shù)據(jù)記錄起來，當(dāng)庫(kù)存操作失敗后，利用操作日志里的數(shù)據(jù)，將之前的價(jià)格操作恢復(fù)回來。這個(gè)恢復(fù)操作，價(jià)格系統(tǒng)可以單獨(dú)提供出一個(gè)接口。

如果恢復(fù)現(xiàn)場(chǎng)的操作也失敗了，這個(gè)時(shí)候只能人工介入解決了。沒其他辦法了。

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接

最新評(píng)論