概述
某些場景下，我們將業(yè)務數(shù)據(jù)落地之前，是需要先調(diào)用外部系統(tǒng)的多個寫接口，當這些寫接口都操作成功了，我們才將業(yè)務數(shù)據(jù)落地到自己本地的數(shù)據(jù)庫里面。比如說：
|
1
2
3
4
5
6
7
8
|
public void updateproductinfo(product product) { //1、將商品價格更新到價格系統(tǒng) priceservice.updateprice(product); //2、將庫存信息更新庫存系統(tǒng) stockservice.updatestock(product); //3、將商品更新到本地數(shù)據(jù)庫 productservice.updateproduct(product);} |
就上面這個例子(例子是虛構(gòu)的,只是為了說明問題而已)，它的執(zhí)行路徑有幾種：
- 1、調(diào)用價格系統(tǒng)、庫存系統(tǒng)的操作以及保存數(shù)據(jù)到本地db都正常；
- 2、調(diào)用價格系統(tǒng)接口的時候就拋異常了;
- 3、調(diào)用價格系統(tǒng)接口正常，但是調(diào)用庫存系統(tǒng)的接口有異常;
- 4、調(diào)用價格系統(tǒng)和庫存系統(tǒng)的接口都正常了，但是將商品數(shù)據(jù)更新到本地數(shù)據(jù)庫出現(xiàn)異常。
如果是第一和第二這兩種情況，無需考慮數(shù)據(jù)一致性問題，但是如果出現(xiàn)了第三和第四這兩種情況，我們就得根據(jù)業(yè)務實際情況，考慮如何保證數(shù)據(jù)的一致性。
這里說的保證數(shù)據(jù)一致性，必須是由調(diào)用方來保證的，服務端是無法保證的。
重試和操作日志
以上面提到的第三種情況來說明一下。
調(diào)用價格系統(tǒng)接口正常，但是調(diào)用庫存系統(tǒng)的接口有異常。
庫存接口允許重試
如果庫存系統(tǒng)接口是冪等的,那么調(diào)用方可以使用重試的機制，多調(diào)用幾次，比如說3次。如果還是不成功，那之前價格系統(tǒng)接口的操作就得走反向操作,進行現(xiàn)場恢復。
庫存接口不允許重試
價格系統(tǒng)接口的操作得走反向操作，進行現(xiàn)場恢復
要實現(xiàn)反向操作，恢復現(xiàn)場，有一種辦法是使用分布式事務，但是實現(xiàn)起來實在太復雜了，性能也不好。可以嘗試使用操作日志來恢復現(xiàn)場。比如說，價格系統(tǒng)調(diào)用成功了，把這個操作狀態(tài)以及相關的業(yè)務數(shù)據(jù)記錄起來，當庫存操作失敗后，利用操作日志里的數(shù)據(jù)，將之前的價格操作恢復回來。這個恢復操作，價格系統(tǒng)可以單獨提供出一個接口。
如果恢復現(xiàn)場的操作也失敗了，這個時候只能人工介入解決了。沒其他辦法了。
總結(jié)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對服務器之家的支持。如果你想了解更多相關內(nèi)容請查看下面相關鏈接
原文鏈接：https://blog.csdn.net/linsongbin1/article/details/80092824
