本發(fā)明涉及數(shù)據處理，尤其涉及一種多系統(tǒng)間的事務數(shù)據一致性保障方法以及一種多系統(tǒng)間的事務數(shù)據一致性保障系統(tǒng)。

背景技術：

1、隨著通信運營商智慧中臺規(guī)范的落地，其中對于組件、能力的要求進一步提高，引入了微服務這種新興的軟件架構，在微服務體系結構中，可以將應用分解為多個更小顆粒度的服務,各個服務可以由不同的團隊并行獨立開發(fā)、部署。

2、當一個系統(tǒng)采用了微服務架構后，原有的業(yè)務可能并沒有發(fā)生變化，但系統(tǒng)已被拆分成了很多新的微服務，與傳統(tǒng)架構相比，微服務架構下會更依賴通過各微服務之間的協(xié)作來實現(xiàn)一個完整的業(yè)務流程。由于每個微服務對應著單獨的數(shù)據事務，所以不同微服務協(xié)作的這種方式不可避免的產生了事務一致性這種問題。

3、比如為處理一用戶請求，在caller系統(tǒng)中需要先后完成兩項任務a和b，分別由不同的系統(tǒng)完成(a任務由系統(tǒng)providera完成，b任務由系統(tǒng)providerb完成)，先處理了a任務，a任務處理成功后再處理b任務。但是在實際中，由于網絡、業(yè)務等多方面的原因很可能會造成a任務處理成功但是b任務處理失敗，導致providera和providerb系統(tǒng)中數(shù)據的不一致。

4、雖然可以采用異步消息的處理方式，但是這種方式也存在著幾方面的弊端：

5、1、異步處理并不適用于對實時性要求比較高的場景；

6、2、異步消息在處理失敗后沒有有效的措施能夠回滾已成功提交的事務。

技術實現(xiàn)思路

1、針對上述問題，本發(fā)明提供了一種多系統(tǒng)間的事務數(shù)據一致性保障方法及系統(tǒng)，通過事務提供方與事務調用方之間的協(xié)調作用進行保障，事務提供方需要具備對于同一任務發(fā)起的一次請求或者多次請求的結果是一致的能力，不會因為多次發(fā)起而產生副作用，事務調用方需要具備任務請求失敗后自動重試的能力，解決了微服務在組合編排為組合服務時產生的事務一致性問題，提高了系統(tǒng)的支撐能力和容錯能力，降低了處理錯誤、異常數(shù)據的人工成本。

2、為實現(xiàn)上述目的，本發(fā)明提供了一種多系統(tǒng)間的事務數(shù)據一致性保障方法，應用于事務提供方，包括：

3、根據請求信息生成接口調用id，并根據所述接口調用id由分布式緩存中提取緩存值；

4、若所述分布式緩存中存在所述緩存值且非空，則根據所述請求信息進行業(yè)務請求處理；

5、根據請求處理結果對所述分布式緩存中的記錄進行更新或刪除。

6、在上述技術方案中，優(yōu)選地，若所述分布式緩存中存在所述緩存值且非空，則根據所述請求信息進行業(yè)務請求處理，具體過程包括：

7、若所述分布式緩存中存在所述緩存值且非空，則直接返回所述緩存值；

8、若所述分布式緩存中存在所述緩存值但為空，則返回請求正在處理標志；

9、若所述分布式緩存中不存在所述緩存值，則將請求信息記錄至所述分布式緩存中。

10、在上述技術方案中，優(yōu)選地，根據請求處理結果對所述分布式緩存中的記錄進行更新或刪除，具體過程包括：

11、若業(yè)務請求處理成功，則將所述請求處理結果更新至所述分布式緩存中；

12、若業(yè)務請求處理失敗，則刪除所述分布式緩存中與該業(yè)務請求對應的記錄。

13、本發(fā)明還提出一種多系統(tǒng)間的事務數(shù)據一致性保障方法，應用于事務調用方，包括：

14、對共享變量和計數(shù)器變量進行定義和初始化，并創(chuàng)建任務子線程；

15、通過所述任務子線程調用目標任務接口，并根據調用結果更新共享狀態(tài)；

16、讀取內存中的共享變量，并根據所述共享變量確定任務執(zhí)行結果；

17、根據所述任務執(zhí)行結果，在任務失敗時根據重試策略或回滾策略進行處理。

18、在上述技術方案中，優(yōu)選地，所述對共享變量和計數(shù)器變量進行定義和初始化，并創(chuàng)建任務子線程，具體過程包括：

19、定義共享變量flag，并初始化為undef；

20、定義計數(shù)器變量cnt并初始化為0，定義重試次數(shù)的閾值x；

21、創(chuàng)建任務子線程。

22、在上述技術方案中，優(yōu)選地，所述通過所述任務子線程調用目標任務接口，并根據調用結果更新共享狀態(tài)，具體過程包括：

23、通過所述任務子線程調用實際目標任務的api接口；

24、若api接口調用成功，修改共享變量flag為success，否則修改共享變量flag為fail。

25、在上述技術方案中，優(yōu)選地，所述讀取內存中的共享變量，并根據所述共享變量確定任務執(zhí)行結果，具體過程包括：

26、讀取所述內存中的共享變量flag，若所述共享變量flag為success，則任務執(zhí)行成功，執(zhí)行步驟結束；

27、若所述共享變量flag為undef，則任務執(zhí)行無響應，且若此時計數(shù)器cnt未達到預設重試次數(shù)閾值則循環(huán)重新創(chuàng)建子線程；

28、若所述共享變量flag為fail，則任務執(zhí)行失敗。

29、在上述技術方案中，優(yōu)選地，根據所述任務執(zhí)行結果，在任務失敗時根據重試策略或回滾策略進行處理，具體過程包括：

30、在任務失敗時，根據所述回滾策略，重置所述共享變量flag為undef；

31、創(chuàng)建任務回滾子線程，調用實際回滾任務的api接口，并在調用成功時修改所述共享變量flag為success，否則修改所述共享變量flag為fail；

32、重置計數(shù)器cnt為0；

33、若主線程阻塞，等待所述任務回滾子線程響應；

34、對計數(shù)器cnt值增加1，記錄回滾子線程的執(zhí)行次數(shù)；

35、讀取內存中的共享變量flag，若所述共享變量flag為success，則回滾任務執(zhí)行成功，執(zhí)行步驟結束；

36、若所述共享變量flag仍未undef，則回滾任務執(zhí)行未完成或無響應，且若此時計數(shù)器cnt未達到預設重試次數(shù)閾值，則循環(huán)等待任務回滾子線程響應，若達到，則記錄失敗日志，執(zhí)行步驟結束；

37、若所述共享變量flag為fail，則記錄失敗日志，執(zhí)行步驟結束。

38、本發(fā)明還提出一種多系統(tǒng)間的事務數(shù)據一致性保障系統(tǒng)，應用于事務提供方，包括：

39、接口調用模塊，用于根據請求信息生成接口調用id，并根據所述接口調用id由分布式緩存中提取緩存值；

40、業(yè)務請求模塊，用于在所述分布式緩存中存在所述緩存值且非空時，根據所述請求信息進行業(yè)務請求處理；

41、記錄更新模塊，用于根據請求處理結果對所述分布式緩存中的記錄進行更新或刪除。

42、在上述技術方案中，優(yōu)選地，多系統(tǒng)間的事務數(shù)據一致性保障系統(tǒng)，應用于事務調用方，包括：

43、線程創(chuàng)建模塊，用于對共享變量和計數(shù)器變量進行定義和初始化，并創(chuàng)建任務子線程；

44、接口調用模塊，用于通過所述任務子線程調用目標任務接口，并根據調用結果更新共享狀態(tài)；

45、結果確定模塊，用于讀取內存中的共享變量，并根據所述共享變量確定任務執(zhí)行結果；

46、失敗處理模塊，用于根據所述任務執(zhí)行結果，在任務失敗時根據重試策略或回滾策略進行處理。

47、與現(xiàn)有技術相比，本發(fā)明的有益效果為：通過事務提供方與事務調用方之間的協(xié)調作用進行保障，事務提供方需要具備對于同一任務發(fā)起的一次請求或者多次請求的結果是一致的能力，不會因為多次發(fā)起而產生副作用，事務調用方需要具備任務請求失敗后自動重試的能力，解決了微服務在組合編排為組合服務時產生的事務一致性問題，提高了系統(tǒng)的支撐能力和容錯能力，降低了處理錯誤、異常數(shù)據的人工成本。