CAP定理|理論
在一個分布式系統中，
- Consistency（資料一致性）
- Availability（服務可用性）
- Partition tolerance（磁區容錯性）
三者不可兼得，最多只能同時滿足二點，沒法三者兼顧，
一致性(Consistency)
在分布式系統中的所有資料備份，在同一時刻是否具有相同的值（所有節點持有的是否都是同一份最新的資料），
比如資料庫主庫寫，從庫讀，用戶完成支付再查詢訂單狀態，主庫執行寫操作把訂單狀態改為了已支付，從從庫查詢訂單狀態時要是已支付，資料是一致的、同步的，
更新操作執行成功后所有的用戶都應該讀到最新的資料，即所有資料備份都是最新的資料，這樣的系統被認為具有強一致性，
優點： 資料一致，資料不會出錯；缺點： 效率低下，
- 強一致性（strong consistency）
任何時刻，所有用戶都能讀取到最近一次成功更新的資料，所有用戶讀取的資料都是最新的，
- ? 單調一致性（monotonic consistency）
任何時刻，用戶一旦讀取到某個資料在某次更新后的值，就不會再讀到比這個值更舊的值，即讀取到的資料的版本是單調遞增的，
- 會話一致性（session consistency）
在某次會話中，用戶一旦讀取到某個資料在某次更新后的值，在本次會話中就不會再讀取到比這個值更舊的值，
會話一致性是在單調一致性的基礎上進一步放松約束，只保證單個用戶、單個會話內的單調性，在不同用戶或同一用戶的不同會話之間則沒有保障，
- 最終一致性（eventual consistency）
不能保證用戶讀取到的是最近一次更新后的資料，但系統可以保證資料最侄訓達到完全一致的狀態，只是所需時間不能保障，
- 弱一致性（weak consistency）
用戶無法在確定時間內讀到最新的資料，
不滿足強一致性，但一般都要使用一些方式（加鎖），使資料具有最終一致性，
可用性(Availablity)
負載過大后，系統是否還能回應客戶端的讀寫請求，回應指的是在正常時間內處理完請求，
比如原來qps（每秒訪問量）是1000，現在漲到10000，依然能正常訪問，
磁區容錯性(Partition-torlerance)
即高可用性，一個節點崩潰、故障，不會影響到其它節點，
怎么才能做到？增加機器數量，做集群，少數節點掛掉，集群整體依然可用，
集群節點越多，磁區容錯性越強，但完成這些機器資料同步花費的時間也越多，IO壓力大，資料一致性越得不到保證（越差），
滿足CA，不滿足p
滿足A=>在指定時間內處理完請求，滿足C=>完成機器的資料同步，要在指定時間內處理完請求、并完成資料同步，那集群的機器就得少（機器多了同步要花大量時間、時間不夠），所以不滿足P，
滿足CP，不滿足A
滿足P=>集群、機器多，滿足C=>資料同步、要花時間，機器又多、還要等這些機器完成資料同步才處理請求，那完成回應的時間就得不到保證，所以不滿足A，
滿足AP，不滿足C
滿足A=>指定時間內完成，滿足P=>集群、機器多，機器又多、還要再指定時間內完成這些機器的資料同步，指定時間內資料可能復制不完、同步得不到保證，所以不滿足C，
一臺機器肯定是不行的，一旦發生什么故障，比如該服務器網路故障，系統就掛了，
一般都要做集群來保證磁區容錯性（P，高可用），所以往往是在A、C之間取舍，
ZK保證了資料一致性（C），但選舉新的leader時集群不能對外提供服務，不滿足可用性（A），
Eureka保證了可用性（A），Eureka是去中心化的，集群每個節點的地位都是一樣的，一個Eureka Server掛了，其它的Eureka Server不受影響，依然能對外提供服務，
但每個Erueka Server都需要從其它所有的Eureka Server上同步資料，容易受網路故障影響，網路波動一下資料就不一致了，不滿足資料一致性（C），
選擇注冊中心時，看專案對A、C中哪一個需求更高：
對C要求高的，比如銀行的專案都涉及錢財，優先選擇ZK，負載大了大不了用戶訪問不了，錢財好歹是安全的、賬目好歹是對的，
對A要求高的，比如選課系統，高考、四六級查分，電商系統，負載大時依然要可用、扛得住，優先選Eureka，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/16289.html
標籤：架構設計
下一篇：推薦一款高效的處理延遲任務神器