上篇我們說了什么是注冊中心和常見的注冊中心，本文將講述CAP 原則與 BASE 理論，作者是公眾號：哈嘍沃德先生，請多關注，
一、CAP 原則
CAP 原則又稱 CAP 定理，指的是在一個分布式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（磁區容錯性），三者不可得兼，
CAP 由 Eric Brewer 在 2000 年 PODC 會議上提出，該猜想在提出兩年后被證明成立，成為我們熟知的 CAP 定理，CAP 三者不可兼得，
1、取舍策略
CAP 三個特性只能滿足其中兩個，那么取舍的策略就共有三種：
- 「CA without P」：如果不要求P（不允許磁區），則C（強一致性）和A（可用性）是可以保證的，但放棄 P 的同時也就意味著放棄了系統的擴展性，也就是分布式節點受限，沒辦法部署子節點，這是違背分布式系統設計的初衷的，
- 「CP without A」：如果不要求A（可用），相當于每個請求都需要在服務器之間保持強一致，而P（磁區）會導致同步時間無限延長（也就是等待資料同步完才能正常訪問服務），一旦發生網路故障或者訊息丟失等情況，就要犧牲用戶的體驗，等待所有資料全部一致了之后再讓用戶訪問系統，設計成 CP 的系統其實不少，最典型的就是分布式資料庫，如 Redis、HBase等，對于這些分布式資料庫來說，資料的一致性是最基本的要求，因為如果連這個標準都達不到，那么直接采用關系型資料庫就好，沒必要再浪費資源來部署分布式資料庫，
- 「AP without C」：要高可用并允許磁區，則需放棄一致性，一旦磁區發生，節點之間可能會失去聯系，為了高可用，每個節點只能用本地資料提供服務，而這樣會導致全域資料的不一致性，典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完，這其實就是先在A（可用性）方面保證系統可以正常的服務，然后在資料的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗，但也不至于造成用戶購物流程的嚴重阻塞，
2、總結
現如今，對于多數大型互聯網應用的場景，主機眾多、部署分散，而且現在的集群規模越來越大，節點只會越來越多，所以節點故障、網路故障是常態，因此磁區容錯性也就成為了一個分布式系統必然要面對的問題，那么就只能在 C 和 A 之間進行取舍，但對于傳統的專案就可能有所不同，拿銀行的轉賬系統來說，涉及到金錢的對于資料一致性不能做出一絲的讓步，C 必須保證，出現網路故障的話，寧可停止服務，可以在 A 和 P 之間做取舍，
總而言之，沒有最好的策略，好的系統應該是根據業務場景來進行架構設計的，只有適合的才是最好的，
二、BASE 理論
CAP 理論已經提出好多年了，難道真的沒有辦法解決這個問題嗎？也許可以做些改變，比如 C 不必使用那么強的一致性，可以先將資料存起來，稍后再更新，實作所謂的 “最終一致性”，
這個思路又是一個龐大的問題，同時也引出了第二個理論 BASE 理論，
BASE：全稱 Basically Available（基本可用），Soft state（軟狀態），和 Eventually
consistent（最終一致性）三個短語的縮寫，來自 ebay 的架構師提出，
BASE 理論是對 CAP 中一致性和可用性權衡的結果，其來源于對大型互聯網分布式實踐的總結，是基于 CAP 定理逐步演化而來的，其核心思想是：
既然無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency），
1、Basically Available（基本可用）
基本可用是指分布式系統在出現故障的時候，允許損失部分可用性（例如回應時間、功能上的可用性），需要注意的是，基本可用絕不等價于系統不可用，
回應時間上的損失：正常情況下搜索引擎需要在 0.5 秒之內回傳給用戶相應的查詢結果，但由于出現故障（比如系統部分機房發生斷電或斷網故障），查詢結果的回應時間增加到了 1~2 秒，
功能上的損失：購物網站在購物高峰（如雙十一）時，為了保護系統的穩定性，部分消費者可能會被引導到一個降級頁面，
2、Soft state（軟狀態）
什么是軟狀態呢？相對于原子性而言，要求多個節點的資料副本都是一致的，這是一種 “硬狀態”，
軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性，分布式存盤中一般一份資料會有多個副本，允許不同副本資料同步的延時就是軟狀態的體現，
3、Eventually consistent（最終一致性）
系統不可能一直是軟狀態，必須有個時間期限，在期限過后，應當保證所有副本保持資料一致性，從而達到資料的最終一致性，這個時間期限取決于網路延時，系統負載，資料復制方案設計等等因素，
實際上，不只是分布式系統使用最終一致性，關系型資料庫在某個功能上，也是使用最終一致性的，比如備份，資料庫的復制都是需要時間的，這個復制程序中，業務讀取到的值就是舊值，當然，最侄訓是達成了資料一致性，這也算是一個最終一致性的經典案例，
4、總結
總的來說，BASE 理論面向的是大型高可用可擴展的分布式系統，和傳統事務的 ACID 是相反的，它完全不同于 ACID 的強一致性模型，而是通過犧牲強一致性來獲得可用性，并允許資料在一段時間是不一致的，更多Java微服務架構，spring全家桶教程 歡迎點擊獲取，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/88042.html
標籤：Java
上一篇：Mybatis-快取