我們都知道微服務現在很火熱，那麼我們將業務才開後隨之而來的數據一致性問題也很棘手，這篇博客我將闡述一下我是如何通過實踐加理論來完成最終一致的高可用並且講述一下dotnetcore下的cap是如何實現的,話不多說直接上問題。 1我們在編寫代碼的時候是否有過如下經歷的轉變: 我們可以發現業務的進化是不可 ...
我們都知道微服務現在很火熱，那麼我們將業務才開後隨之而來的數據一致性問題也很棘手，這篇博客我將闡述一下我是如何通過實踐加理論來完成最終一致的高可用並且講述一下dotnetcore下的cap是如何實現的,話不多說直接上問題。
1我們在編寫代碼的時候是否有過如下經歷的轉變:
//原先的業務
begin tran
update table set column=x where id = y;
update table2 set column = x where id = y;
commit
//進化後的業務需要調用第三方介面通知其完成方法：OtherService.Complete()
方法1：
OtherService.Complete();
begin tran
update table set column=x where id = y;
update table2 set column = x where id = y;
commit
方法2：
begin tran
OtherService.Complete();
update table set column=x where id = y;
update table2 set column = x where id = y;
commit
方法3：
begin tran
update table set column=x where id = y;
OtherService.Complete();
update table2 set column = x where id = y;
commit
方法4：
begin tran
update table set column=x where id = y;
update table2 set column = x where id = y;
OtherService.Complete();
commit
方法5：
begin tran
update 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，對了消息系統可以自身攜帶輪詢系統，也可以有第三方的控制台程式或者其他定時程式來實現輪詢
