數據庫 inf 一個數 目前 ima 支付寶 下一個 一段時間 QQ

在微服務架構下，每個服務對應一個數據庫，這就出現了原來單體中對同一個庫的操作變成了跨服務數據庫的操作。 遇到有事務約束的場景，比如轉賬匯款、訂單狀態和庫存扣減，就從本地事務過渡到分布式事務來了。 微服務利用最終一致性解決這個問題 最終一致性：不同服務節點再一段時間後，節點間的數據會最終達到一致的狀態 有兩種方法可以完成最終一致性 ：

1.可靠性時間模式

前序事件發生，後序事件一定發生。可靠性事件的缺點是不能回滾。一般借助消息隊列和內部表來完成。

支付寶余額轉賬到余額寶余額為例： 當發起一個請求到支付寶服務的時候，支付寶會執行扣款事件，並將這個事件記錄下來，並且發送消息到余額寶服務，之後余額寶執行加款事件並將該消息投遞到支付寶服務，支付寶服務得到該條消息後刪除事件記錄。如果余額寶服務出現故障，支付寶服務一直沒有接受到回送的消息，定時任務會檢測該事件一直存在數據庫當中，並一直發送消息給余額寶直到余額寶服務恢復加款後回送消息支付寶給刪除記錄。

2.補償事務-sagsas模型

sag是一系列有序本地事務，每個本地事務通過更新數據庫或者發送消息來觸發下一個本地事務。 每一個本地事務都會發送消息並確認消息，如果本地事務失敗，sag會有序的執行補償事務來回滾剛才的操作。它的特點就是支持回滾。 每一個事務都有發送消息和接收確認消息的操作 該方案比較復雜，目前還沒有開源框架來支持。

微服務的數據一致性