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

一.CAP使用場景?

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

常用方案,把SQL放前面,MQ放后面,MQ執(zhí)行失敗了,我們把整個SQL進(jìn)行回滾,這種方案在單應(yīng)用下是可行的,它的回滾成本并不高

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

我非要回滾

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

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

有沒有更好的解決方案?

二.CAP是干什么用的?

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

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

三.CAP是如何實現(xiàn)最終一致性的?

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

當(dāng)上游向中臺發(fā)送消息失敗時,CAP還是會標(biāo)注該業(yè)務(wù)執(zhí)行成功,但是持久化在數(shù)據(jù)庫里的消息狀態(tài)是失敗的,它會執(zhí)行重試策略,重試策略執(zhí)行完后,還是失敗,就不會重試了

CAP是基于數(shù)據(jù)庫的強一致性來實現(xiàn)最終一致性的,簡單來說,就是執(zhí)行業(yè)務(wù)的SQL,跟持久化消息的SQL在一個事務(wù)里

當(dāng)中臺接到上游訂單后,執(zhí)行分單的SQL錯誤了,怎么搞呢?

CAP 在發(fā)布/訂閱的基礎(chǔ)上新增了一個回調(diào),中臺會把任務(wù)的執(zhí)行結(jié)果通知給上游, 回調(diào)相當(dāng)于中臺給上游發(fā)消息,上游根據(jù)回調(diào)的結(jié)果決定接下來怎么做

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

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

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

四.CAP簡單入門?

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

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

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

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

---

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。