我們都知道微服務現在很火熱，那么我們將業務才開后隨之而來的數據一致性問題也很棘手，這篇博客我將闡述一下我是如何通過實踐加理論來完成最終一致的高可用并且講述一下dotnetcore下的cap是如何實現的,話不多說直接上問題。

　　1我們在編寫代碼的時候是否有過如下經歷的轉變:

//原先的業務 begin tranupdate table set column=x where id = y;update table2 set column = x where id = y; commit //進化后的業務需要調用第三方接口通知其完成方法：OtherService.Complete() 方法1： OtherService.Complete(); begin tranupdate table set column=x where id = y;update table2 set column = x where id = y; commit 方法2： begin tranOtherService.Complete();update table set column=x where id = y;update table2 set column = x where id = y; commit 方法3： begin tranupdate table set column=x where id = y;OtherService.Complete();update table2 set column = x where id = y; commit 方法4： begin tranupdate table set column=x where id = y;update table2 set column = x where id = y;OtherService.Complete(); commit 方法5： begin tranupdate table set column=x where id = y;update table2 set column = x where id = y; commit OtherService.Complete();

　　我們可以發現業務的進化是不可阻撓的,但是如何來確保本地事務的成功外加遠程調用的成功呢，首先我們排除業務邏輯上的，就是說如果不存在網絡問題那么一定是會成功的只要他執行了，那么根據aop我們會發現每個方法都會有6個切面：

　　誰也沒法保證在哪個切面會發生網絡或者斷電等異常，大家可以思考一下關于上述5種方法的任何切面出現問題會有什么影響哪些切面出問題是不會有數據不一致的:

通過上面我可以看到只有4-5方法出現了一個不一致，但是方法5不排除本身調用失敗，所以我們一般選擇的方法4，因為在所有這么多方法中只有方法4可以稱之為“偽事務”，這邊可以發現只要遠程調用出錯那么事務會回滾可以極大的保障數據一致性，但是也不排除切面5發生錯誤，一旦切面5發生錯誤那么數據就會不一直，除非手工的去處理。有人會說了我們用mq啊，mq有特殊機制可以確定后再去除消息（rabbitmq的ack機制。）那么我們再來看下這一系列的問題。假設基于方法4的前提下將方法調用改成mq的消息機制，我們來看：

假設前面執行一切正常但是在執行ack確認完成mq清除掉消息后（channel.BasicAck(ea.DeliveryTag, false);）網絡異常本地客戶端沒有得到正常的response那么一樣等于切面4報錯還是會產生消息不一致，那么說了這么多我們到底該如何才能保證消息不丟失呢。假設我們改造下mq，我先發一個消息給mq告訴他我等會會讓你干什么事，如果過了多少秒我還沒告訴你你來問我到底這件事還做不做了，這樣我們就可以保證我們發給mq的消息不丟失，我們來看一張圖

這個改進后我們發現其實還是有問題如果4-5步驟出問題了還是數據不一致，那么我們就需要再進一步改進

這樣我們就可以保證消息準確無誤的抵達系統B并且可以執行完成，但是這么做需要有一個強業務類型邏輯校驗，保證除了網絡等不可抗拒因素以外都要成功。但是有人要說了，就我們的水平不是人人都是bat里的怎么可能改進mq系統讓他支持，改源碼畢竟還是不太現實，那么接下來我就給大家帶來2種解決方案，而且其中一種就是cap的實現。

方案1

?

通過代碼我們可以看到利用本地數據庫事務特性將要對其他系統的處理消息插入本地消息表，之后再commit之后去執行并且更新消息表，自帶輪詢查詢消息表達到數據一致，cap就是這個方式來實現的最終一致。不過這種方法需要本地存儲支持事務特性，而且并發量受本地數據庫性能的限制，但是特點是實現起來簡單有效方便。那么第二種方案是自己實現一個獨立的可靠消息中間件。

方案2：

方案2這里要說的是系統a需要提供查詢接口來供消息系統查詢未處理的消息來確認是否要執行，系統b需要做的是提供查詢接口來讓消息系統來確認是否已經執行成功，因為消息系統在發消息給系統b的時候中間也會存在網絡終端問題，而且這樣一個消息系統就完全不存在事務的依賴關系，而且也不對原先的業務進行侵入，并發完全由消息系統自己獨立控制。尤其是系統B和消息系統需要做好的是消息的重復消費要保證冪等的關系，所謂的冪等就是我同一個消息我執行一次和執行n次都只會成功一次，具體可以靠并發字段或者rowversion來保證，之后有時間我會單獨寫一個獨立的消息中間件的demo，對了消息系統可以自身攜帶輪詢系統，也可以有第三方的控制臺程序或者其他定時程序來實現輪詢

轉載于:https://www.cnblogs.com/xuejiaming/p/9417386.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的分布式事务最终一致看这篇“大白话”的实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。