cap算法
簡介：
- 一致性： 在寫操作完成之后開始的讀操作，必須返回該值矩父，或者以后寫操作的值。（在一致的系統(tǒng)中排霉，客戶端將值寫入任何服務(wù)器并獲得響應(yīng)后窍株，它希望能夠從其讀取的任何服務(wù)器讀取該值）。
- 可用性： 系統(tǒng)中每個(gè)非故障的節(jié)點(diǎn)收到的請(qǐng)求必須獲得響應(yīng)。（在可用的系統(tǒng)中夹姥，如果我們客戶端向服務(wù)器發(fā)送請(qǐng)求杉武，且該服務(wù)器沒有崩潰，則服務(wù)器必須響應(yīng)客戶端辙售，并不允許服務(wù)器忽略客戶端的請(qǐng)求）轻抱。
- 分區(qū)容錯(cuò)性： 網(wǎng)絡(luò)將被允許任意丟失從一個(gè)節(jié)點(diǎn)發(fā)送另一節(jié)點(diǎn)的許多消息。
為什么不存在一個(gè)同時(shí)支持cap的服務(wù)旦部？
-
我們先假設(shè)存在一個(gè)服務(wù)同時(shí)支持“一致性”祈搜，“可用性”，“分區(qū)容錯(cuò)性”士八。 如圖下：image.png
- 這個(gè)時(shí)候出現(xiàn)了網(wǎng)絡(luò)分區(qū)（即G1服務(wù)器和G2服務(wù)器不能交流）容燕。客戶端先向G1服務(wù)器提交請(qǐng)求婚度，需要把v0改成v1蘸秘。因?yàn)榉?wù)需要滿足可用性。所以G
1 需要正確響應(yīng)服務(wù)的請(qǐng)求蝗茁，把v0 改成v1醋虏，但是網(wǎng)絡(luò)分區(qū)了，G2服務(wù)器并不能收到變更哮翘，在G2中服務(wù)還是v0颈嚼。 - 此時(shí)客戶端去G2請(qǐng)求值，G2依然返回v0饭寺，所以并不滿足一致性的要求阻课，所以此服務(wù)不存在。
- 綜上所述艰匙，不可能存在同時(shí)滿足cap的服務(wù)限煞。
cap結(jié)論：
分布式服務(wù)必定會(huì)發(fā)生網(wǎng)絡(luò)分區(qū)的問題（服務(wù)器間狀態(tài)不能同步）。此時(shí)只能在一致性 和 可用性 中作出一個(gè)取舍旬薯。 如果要求強(qiáng)一致性晰骑，那么只能犧牲可用性适秩，拒絕客戶端的寫請(qǐng)求绊序，如果要求服務(wù)的可用性，那么服務(wù)之間的狀態(tài)必定不能同步秽荞，所以一定會(huì)犧牲一致性骤公。
