效能優化真言:佇列快取分散式  非同步調優堆配置

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

一.CAP使用場景?

平時工作中經常使用到MQ,如(kafka,rabbitmq...),用來簡單的釋出/訂閱,經常會遇到以下幾個問題
A.SQL執行成功了,訊息傳送失敗了
B.SQL執行失敗了,訊息傳送成功了

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

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

我非要回滾

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

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

有沒有更好的解決方案?

二.CAP是幹什麼用的?

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

這裡簡單說下強一致性,與最終一致性
強一致性,資料庫裡的CAID就是強一致性,它們對外永遠只有一個狀態,要麼成功,要麼失敗
最終一致性,能容忍應用部分成功,在一段時間後,能達到全部成功狀態
很明顯在分散式環境裡,任何東西都有可能宕機,如資料庫,快取,MQ都有可能出現問題,任何一個元件出現問題,都不影響業務最終執行的結果,這就是系統的穩定性

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

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

當上遊向中臺傳送訊息失敗時,CAP還是會標註該業務執行成功,但是持久化在資料庫裡的訊息狀態是失敗的,它會執行重試策略,重試策略執行完後,還是失敗,就不會重試了
這個時候很明顯就是MQ掛了,修復MQ後,取出這些重試策略執行後任失敗訊息從新錄入MQ即可

CAP是基於資料庫的強一致性來實現最終一致性的,簡單來說,就是執行業務的SQL,跟持久化訊息的SQL在一個事務裡

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

CAP 在釋出/訂閱的基礎上新增了一個回撥,中臺會把任務的執行結果通知給上游, 回撥相當於中臺給上游發訊息,上游根據回撥的結果決定接下來怎麼做

極端情況,中臺的資料庫掛了,至少上游快取了所有傳送的訊息,我們也可以通過這些訊息進行溯源,重新消費這些訊息即可

作者原文部落格地址(建議完整的看一遍,你品,你細品):
https://www.cnblogs.com/savorboard/p/cap.html
https://www.cnblogs.com/savorboard/p/cap-document.html

四.CAP簡單入門?

做為一個萌新,怎麼優(jian)雅(dan)的使用CAP呢
首先你得需要一個MQ,這裡推薦rabbitmq,操作簡單,視覺化頁面功能強大,其次就是一個數據庫(sqlserver,mysql,postgresql,mongodb)
然後就簡單的配置一下連線就可以用了,幫助文件寫的非常詳細,這裡就不再贅述了,直接貼上地址

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

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

我在使用過程中遇到的問題,大多數都很low,除了docker裡裝的kafka坑了我,其它基本上都沒啥子問題
CAP使用過程中遇到問題,可以去github上先搜下issues,任無法解決可以提issues