概述

某些場景下，我們將業務數據落地之前，是需要先調用外部系統的多個寫接口，當這些寫接口都操作成功了，我們才將業務數據落地到自己本地的數據庫里面。比如說：

public void updateProductInfo(Product product) {  //1、將商品價格更新到價格系統  priceService.updatePrice(product);  //2、將庫存信息更新庫存系統  stockService.updateStock(product);  //3、將商品更新到本地數據庫  productService.updateProduct(product);}

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

• 1、調用價格系統、庫存系統的操作以及保存數據到本地DB都正常；
• 2、調用價格系統接口的時候就拋異常了;
• 3、調用價格系統接口正常，但是調用庫存系統的接口有異常;
• 4、調用價格系統和庫存系統的接口都正常了，但是將商品數據更新到本地數據庫出現異常。

如果是第一和第二這兩種情況，無需考慮數據一致性問題，但是如果出現了第三和第四這兩種情況，我們就得根據業務實際情況，考慮如何保證數據的一致性。

這里說的保證數據一致性，必須是由調用方來保證的，服務端是無法保證的。

重試和操作日志

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

調用價格系統接口正常，但是調用庫存系統的接口有異常。

庫存接口允許重試

如果庫存系統接口是冪等的,那么調用方可以使用重試的機制，多調用幾次，比如說3次。如果還是不成功，那之前價格系統接口的操作就得走反向操作,進行現場恢復。

庫存接口不允許重試

價格系統接口的操作得走反向操作，進行現場恢復

要實現反向操作，恢復現場，有一種辦法是使用分布式事務，但是實現起來實在太復雜了，性能也不好?？梢試L試使用操作日志來恢復現場。比如說，價格系統調用成功了，把這個操作狀態以及相關的業務數據記錄起來，當庫存操作失敗后，利用操作日志里的數據，將之前的價格操作恢復回來。這個恢復操作，價格系統可以單獨提供出一個接口。

如果恢復現場的操作也失敗了，這個時候只能人工介入解決了。沒其他辦法了。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對VeVb武林網的支持。