cap算法
簡介：
- 一致性： 在寫操作完成之后開始的讀操作，必須返回該值，或者以后寫操作的值。（在一致的系統(tǒng)中，客戶端將值寫入任何服務(wù)器并獲得響應(yīng)后，它希望能夠從其讀取的任何服務(wù)器讀取該值）。
- 可用性： 系統(tǒng)中每個非故障的節(jié)點(diǎn)收到的請求必須獲得響應(yīng)。（在可用的系統(tǒng)中，如果我們客戶端向服務(wù)器發(fā)送請求，且該服務(wù)器沒有崩潰，則服務(wù)器必須響應(yīng)客戶端，并不允許服務(wù)器忽略客戶端的請求）。
- 分區(qū)容錯性： 網(wǎng)絡(luò)將被允許任意丟失從一個節(jié)點(diǎn)發(fā)送另一節(jié)點(diǎn)的許多消息。
為什么不存在一個同時支持cap的服務(wù)？
-
我們先假設(shè)存在一個服務(wù)同時支持“一致性”，“可用性”，“分區(qū)容錯性”。 如圖下：image.png
- 這個時候出現(xiàn)了網(wǎng)絡(luò)分區(qū)（即G1服務(wù)器和G2服務(wù)器不能交流）。客戶端先向G1服務(wù)器提交請求，需要把v0改成v1。因?yàn)榉?wù)需要滿足可用性。所以G
1 需要正確響應(yīng)服務(wù)的請求，把v0 改成v1，但是網(wǎng)絡(luò)分區(qū)了，G2服務(wù)器并不能收到變更，在G2中服務(wù)還是v0。 - 此時客戶端去G2請求值，G2依然返回v0，所以并不滿足一致性的要求，所以此服務(wù)不存在。
- 綜上所述，不可能存在同時滿足cap的服務(wù)。
cap結(jié)論：
分布式服務(wù)必定會發(fā)生網(wǎng)絡(luò)分區(qū)的問題（服務(wù)器間狀態(tài)不能同步）。此時只能在一致性 和 可用性 中作出一個取舍。 如果要求強(qiáng)一致性，那么只能犧牲可用性，拒絕客戶端的寫請求，如果要求服務(wù)的可用性，那么服務(wù)之間的狀態(tài)必定不能同步，所以一定會犧牲一致性。
