CAP的學習和應用

性能優化真言:隊列緩存分佈式  異步調優堆配置

前言:用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