CAP原則和資料一致性
------------恢復內容開始------------
CAP定義
CAP理論作為分散式系統的基礎理論,它描述的是一個分散式系統有在以下三個特性[1]：
一致性（Consistency）
可用性（Availability）
分割槽容錯性（Partition tolerance）
- （Particion tolerance）三者最多同時只能實現兩點，無法三者兼顧
這三個特性最多隻能同時實現兩點，不可能三者兼顧，即出現 CA、CP、AP 三種情況。
-
一致性（C）
即更新操作成功後，所有節點在同一時間的資料完全一致，在併發讀寫時會出現這個問題。 -
可用性（A）
使用者訪問資料時，系統能在正常響應時間內返回結果。 -
分割槽容錯性（P）
分散式系統在遇到某個節點或網路分割槽故障時，仍然能夠對外提供滿足一致性和可用性的服務。
也就是說部分故障不影響整體使用。
取捨策略
CAP三個特性只能滿足其中兩個，那麼取捨的策略就共有三種：
-
CA without P：如果不要求P（不允許分割槽），則C（強一致性）和A（可用性）是可以保證的。但放棄P的同時也就意味著放棄了系統的擴充套件性，也就是分散式節點受限，沒辦法部署子節點，這是違背分散式系統設計的初衷的。傳統的關係型資料庫RDBMS：Oracle、MySQL就是CA。
-
CP without A：如果不要求A（可用），相當於每個請求都需要在伺服器之間保持強一致，而P（分割槽）會導致同步時間無限延長(也就是等待資料同步完才能正常訪問服務)，一旦發生網路故障或者訊息丟失等情況，就要犧牲使用者的體驗，等待所有資料全部一致了之後再讓使用者訪問系統。設計成CP的系統其實不少，最典型的就是分散式資料庫，如Redis、HBase等。對於這些分散式資料庫來說，資料的一致性是最基本的要求，因為如果連這個標準都達不到，那麼直接採用關係型資料庫就好，沒必要再浪費資源來部署分散式資料庫。
-
AP wihtout C：要高可用並允許分割槽，則需放棄一致性。一旦分割槽發生，節點之間可能會失去聯絡，為了高可用，每個節點只能用本地資料提供服務，而這樣會導致全域性資料的不一致性。典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統可以正常的服務，然後在資料的一致性方面做了些犧牲，雖然多少會影響一些使用者體驗，但也不至於造成使用者購物流程的嚴重阻塞。
推導
- 如果要求對資料進行分割槽，就說明節點之間必須進行通訊，涉及到通訊，就無法保證在有限時間內完成指定任務
- 如果要求兩個操作之間要完整的進行，因為涉及到通訊，所以肯定存在某一個時刻之完成一部分的業務操作，在通訊完成的這段時間內，資料不一致。
- 如果要求資料一致性，那麼就必須在通訊完成這段時間內保護資料，使得任何訪問這些資料的操作不可用
結論
- 在大型網站中，資料是快速增加的，因此分割槽容錯性必不可少。當資料變得龐大之後，網路和伺服器會頻繁出現故障，要想保證應用可用，必須把正分散式處理系統的高可用性。
- 在大型網站中，通常會選擇強化分散式儲存系統的可用性和伸縮性，在一定程度上放棄一致性。
資料一致性
-
強一致性（加鎖）
- 一旦有寫操作寫入任何一個伺服器，立即在其他伺服器之間同步複製新的資料，這樣任何伺服器上任何讀操作總是能看到最近寫入的新資料。
-
弱一致性
- 和強一致性相對，系統並不保證連續程序或者執行緒的訪問都會返回最新的更新過的值。系統在資料寫入成功之後，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之後可以讀到。但會盡可能保證在某個時間級別（比如秒級別）之後，可以讓資料達到一致性狀態[2]。
-
最終一致性
- 屬於弱一致性
- 應用於分散式系統中
- 當寫入請求達到半數以上的時候，就認為是寫入成功
引用
[1].https://leetcode-cn.com/circle/article/mMsOBF/
[2].https://www.jianshu.com/p/056c55935194
------------恢復內容結束------------