性能優化真言:隊列緩存分布式 異步調優堆配置
前言:用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錯誤了,怎么搞呢?
這個時候我們應該把這個異常告訴它的上游, 簡單來說,就是當前服務已經GG了,請你不要給我再給我任務了,請把任務轉給其他服務,如果沒有任何服務能夠執行任務,那么你幫我把消息緩存起來,等我修復好了,再執行這些任務
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