前言:用CAP有一段時間了,這里簡單記錄一下,這么好用的東西,小伙伴們趕緊上車吧

一.CAP使用場景?

平時工作中經常使用到MQ,如(kafka,rabbitmq...),用來簡單的發布/訂閱,經常會遇到以下幾個問題

常用方案,把SQL放前面,MQ放后面,MQ執行失敗了,我們把整個SQL進行回滾,這種方案在單應用下是可行的,它的回滾成本并不高

我們模擬一個簡單的分布式場景:上游下單->中臺分單->下游發貨

我非要回滾

站在業務角度分析,客戶滿足下單條件,已經下單成功了,但是上游服務在給中臺發送MQ的時候失敗了,這種情況很明顯是不允許回滾的

補救的辦法,就是標記這個訂單的狀態,給客戶一個假成功的狀態,后臺再寫個任務調度去處理,每個發送消息的地方都得這樣處理,非常的麻煩費事,而且業務跟MQ耦合在一起了

有沒有更好的解決方案?

二.CAP是干什么用的?

CAP提供分布式事務的最終一致性解決方案

這里簡單說下強一致性,與最終一致性

三.CAP是如何實現最終一致性的?

CAP具備傳統EventBus的全部功能,簡單的發布/訂閱非常好理解,CAP在此基礎上持久化了消息(就是把每條消息保存到了數據庫),我們還是拿下單場景來說明

當上游向中臺發送消息失敗時,CAP還是會標注該業務執行成功,但是持久化在數據庫里的消息狀態是失敗的,它會執行重試策略,重試策略執行完后,還是失敗,就不會重試了

CAP是基于數據庫的強一致性來實現最終一致性的,簡單來說,就是執行業務的SQL,跟持久化消息的SQL在一個事務里

當中臺接到上游訂單后,執行分單的SQL錯誤了,怎么搞呢?

CAP 在發布/訂閱的基礎上新增了一個回調,中臺會把任務的執行結果通知給上游, 回調相當于中臺給上游發消息,上游根據回調的結果決定接下來怎么做

極端情況,中臺的數據庫掛了,至少上游緩存了所有發送的消息,我們也可以通過這些消息進行溯源,重新消費這些消息即可

作者原文博客地址(建議完整的看一遍,你品,你細品):

https://www.cnblogs.com/savorboard/p/cap-document.html

四.CAP簡單入門?

做為一個萌新,怎么優(jian)雅(dan)的使用CAP呢

http://cap.dotnetcore.xyz/user-guide/zh/getting-started/quick-start/

五.CAP使用中遇到的問題?

原文鏈接：https://www.cnblogs.com/tibos/p/11858095.html

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?

總結

以上是生活随笔為你收集整理的CAP的学习和应用的全部內容，希望文章能夠幫你解決所遇到的問題。

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