0x0 前言
之前看過很多關(guān)于CAP的文章缝呕，一直很懵逼筹麸，今天談?wù)勎以陧椖恐杏龅降膯栴}以及對于CAP的理解
0x1 什么是CAP
1998年耸携，加州大學的計算機科學家 Eric Brewer 提出纵诞，分布式系統(tǒng)有三個指標忙干。
- Consistency
- Availability
- Partition tolerance
它們的第一個字母分別是 C器予、A、P捐迫。
Eric Brewer 說乾翔，這三個指標不可能同時做到。這個結(jié)論就叫做 CAP 定理施戴。
0x2 工作中遇到的分布式問題
在去年項目微服務(wù)化時末融，遇到一個問題：
各個微服務(wù)組件雖然在業(yè)務(wù)上盡力解耦，但是仍然有部分數(shù)據(jù)是公共的暇韧，例如：人員信息，區(qū)域組織信息浓瞪，設(shè)備信息等懈玻。
這些基礎(chǔ)信息如何處理呢？有兩種方案：
- 使用時通過rest調(diào)用查詢到本地乾颁；
- 直接在本地也保存一份副本涂乌；
使用第一種方案，顯然效率是一個大問題英岭，而且該方案有個嚴重的問題是：當某個基礎(chǔ)服務(wù)掛掉或和其他服務(wù)連接出現(xiàn)問題時湾盒，其他服務(wù)都無法繼續(xù)提供服務(wù)，即不滿足分區(qū)容錯（Partition tolerance）诅妹。
若使用第二種方案罚勾，那么每個服務(wù)不會受到其他服務(wù)掛掉或者與其他服務(wù)網(wǎng)絡(luò)不通的影響（因為本地有業(yè)務(wù)所需的全部數(shù)據(jù)），但是引入了另一個問題：各個服務(wù)數(shù)據(jù)可能存在不一致（Consistency）吭狡。
這時尖殃，我們需要看是否要保障數(shù)各個微服務(wù)據(jù)一致性，若需要保障一致性划煮，那么每次基礎(chǔ)數(shù)據(jù)服務(wù)在接收到變更送丰、刪除、增加請求時弛秋，都要對其他微服務(wù)也進行相應(yīng)的更新器躏，此時引入了一個新的問題：如果有一個服務(wù)掛掉俐载，則本次用戶的變更請求就會失敗，不滿足可用性（Availability）登失。
最終遏佣，決定使用mq通知的形式：當基礎(chǔ)數(shù)據(jù)變更后，發(fā)送MQ通知到Topic壁畸，各個微服務(wù)監(jiān)聽topic來修改本地存儲的相應(yīng)數(shù)據(jù)贼急。這個方案雖然不能保證強一致性，但是數(shù)據(jù)最終是一致的捏萍。
