CAP 理論是分散式系統中最核心的基礎理論，雖然在面試中，面試官不會直白地問你CAP 理論的原理，但是在面試中遇到的分散式系統設計問題，都繞不開你對CAP 的理解和思考。
而且在面試中，針對面試不同職位的候選者，面試官的要求也會不一樣，要求你回答的深度也不一樣。所以在今天文章中，我會針對國中級研發工程師和資深研發工程師兩個不同的角度，分析面試想法。
相信只要學習過分散式技術的相關知識，基本上就知道CAP 理論指的是什麼：
Consistency）是資料一致性、Availability）是服務可用性、 Partition tolerance）是分割區容錯性。 C、A、P 只能同時滿足兩個目標，而由於在分散式系統中，P 是必須保留的，所以要在 C 和 A 間進行取捨。若要保證服務的可用性，就選擇 AP 模型，而要保證一致性的話，就選擇 CP模型。
很多候選者如果發現面試題（例如「為了資料容災，我們會做資料的主從備份，那麼主從節點的資料一致性對呼叫端有什麼影響呢？」）涉及了對“CAP 的理解和思考”，會下意識地做出類似的答案：“ CAP 理論描述了在出現網絡分區的情況下，要在C 和A 之間做取捨，所以會影響站在調用端的視角看系統是不可用的」。如果是我的話，大概會給個及格分，並認為這樣的回答，只能證明你有準備，不能證明你有能力。
因為面試中遇到理論問題時，單純做浮於表面的概念性闡述，很難向面試官證明你的技術能力。面試官會覺得你是一個剛接觸分散式系統，或是對分散式系統理解不夠深入的研發，如果這恰好是你第一個面試題，會直接影響面試官對你的第一印象，甚至影響你的定級。
從我的經驗出發，如果你想答得更好，你需要先掌握 CAP 的原理、實務經驗、技術認知，然後再結合具體的面試題具體分析。
#現在有一個分散式系統A，它有一個副本A1，在正常情況下，客戶端Client 寫入資料到系統A，然後資料從A 節點同步到A1 節點，再傳回給Client 成功狀態。
這時，客戶端Client 從任何節點A 或A1 讀取數據，都能讀取到最新寫入的數據，說明A 和A1的數據是一致的，並且A 和A1 也都是可用的。
但由於網路是不可靠的，節點 A 和 A1 的網路隨時會因為中斷而出現分區。所謂網路分區就是由於網路不通導致節點 A 和 A1 被隔離在不同的網路子集中，此時節點 A 的資料就無法及時同步到節點 A1 中了。
在分散式系統中，由於網路問題導致的網路分區是常態。也就是說出現網路分區時，根據 CAP 理論，需要在 A 和 C 中進行取捨，也就是確保系統的可用性，或是保證資料一致性。
這裡你要注意了，上面的例子有個大前提，就是系統出現了網路分區，但實際情況是，在絕大多數時間裡並不存在網路分區（網路不會經常出現問題）。那麼還要進行三選二嗎（CP 或 AP）？
其實，不同的分散式系統要根據業務場景和業務需求在 CAP 三者中進行權衡。 CAP 理論用於指導系統設計時需要衡量的因素，而非進行絕對地選擇。
當網路沒有出現分區時，CAP 理論並沒有給出衡量A 和C 的因素，但如果你做過實際的分散式系統設計，一定會發現系統資料同步的延遲（Latency） ，也就是例子中節點A 同步資料到節點A1 的時間才是衡量A 和C 最重要的因素，此時就不會有絕對的AP 模型還是CP 模型了，而是源自於對實際業務場景的綜合考量。
因此，才會有如 PACELC「Reference1」 這樣的新模型優化原有的 CAP 理論，理論指導實踐，實踐最佳化理論。
根據PACELC 模型的定義，如果有網路分割區產生，系統就必須在A 和C 之間取得平衡，否則（Else，即PACELC 中的E）當系統運作在無網路分割區情況下，系統需要在L（延遲）和C 之間取得平衡。
PACELC
但要理解到這個程度還不夠，你還需要結合落地經驗來證明。
你要意識到，網路分散式的設計方案是資料一致性和系統可用性的權衡，並不是非此即彼，這一點尤其重要。所以即使無法做到強一致性（簡單來講強一致性就是在任何時刻所有的用戶查詢到的數據都是最新的），也可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性。
這時就要引出 BASE 理論，它是 CAP 理論的延伸。 BASE 是Basically Available（基本上可用）、Soft State（軟狀態）和Eventually Consistent（最終一致性）三個單詞的簡寫，作用是保證系統的可用性，然後透過最終一致性來取代強一致性，它是目前分散式系統設計中最具指導意義的經驗總結。那麼在實際專案中，你如何透過 BASE 理論來指導設計實務呢？
BASE 中的基本可用指的是保障核心功能的基本可用，其實是做了「可用性」方面的妥協，例如：
電商網站在雙十一大促等訪問壓力較大的時候，關閉商品排行榜等次要功能的展示，從而保證商品交易主流程的可用性，這也是我們常說的服務降級；
為了錯開雙十一高峰期，電商網站會將預售商品的支付時間延後十到二十分鐘，這就是流量削峰；
在你搶購商品的時候，往往會在隊列中等待處理，這也是常用的延遲隊列。
軟狀態和最終一致性指的是允許系統中的資料存在中間狀態，這同樣是為了系統可用性而犧牲一段時間窗內的資料一致性，從而保證最終的資料一致性的做法。
目前這種處理數據的方式幾乎成了互聯網的標配設計模式，最經典的例子是在用戶下單的時候不需要真正地扣減庫存，而是僅在前台計個數，然後透過非同步任務在背景批次處理。
如果你想應徵的是國中級研發工程師，那麼結合上述思路，從理論理解到落地實踐，你已經可以把 CAP 理論答得較為清楚了。回答問題的邏輯可以參考我給的建議：
如果你應徵的是高階研發工程師或架構師，在回答時，還要盡可能地展示知識體系和技術判斷力，這是這兩個崗位的基本素質。因為分散式技術錯綜複雜，各種技術又相互耦合，在面試中，如果你能通過一個 CAP 理論的知識點，擴展出一個脈絡清晰的分佈式核心技術知識體系，就會與其他人拉開差距。
分散式系統看起來就像一台電腦。電腦包括五大體系結構（即馮諾依曼結構）。它有五大部件：
你可以這麼理解：一個分散式系統也包含這五大部件，其中最重要的是計算與儲存。運算與儲存由一系列網路節點組成，每個節點之間的通訊就是輸入與輸出，各節點之間的調度管理就是控制器。
分散式架構技術組成
這麼看來，分散式系統就像一個網路計算機，它的知識體系包括四個角度：
你可以從這四個角度來概括分散式系統的知識體系。
那麼具體的解題思路是什麼呢？以「Redis 是否可以作為分散式鎖定」為例，咱們一起來分析一下問題背後隱藏的分散式理論知識，以及作為高級研發工程師的解題思路。
#一般使用setnx 方法，透過Redis 實作鎖定和逾時時間來控制鎖的失效時間。但在極端的情況下，當 Reids 主節點掛掉，但鎖還沒有同步到從節點時，根據哨兵機制，從就變成了主，繼續提供服務。這時，另外的執行緒可以再來請求鎖，此時就會出現兩個執行緒拿到了鎖的狀況。
根據對CAP 理論的理解，Redis 的設計模型是AP 模型，而分散式鎖定則是CP場景，那麼很明顯，將Redis 這種AP 模型的架構應用於CP 的場景，在底層的技術選型上就是錯誤的。
Redis 屬於分散式儲存系統，你的腦中就要有對分散式儲存系統領域的知識體系。思考它的資料儲存、資料分佈、資料複製，以及資料一致性都是怎麼做的，用了哪些技術來實現，為什麼要做這樣的技術或演算法選型。你要學習從多維度、多角度去比較、分析同一分散式問題的不同方法，然後綜合權衡各種方法的優缺點，最終形成自己的技術認知和技術判斷力。
例如透過Redis，你能想到目前分散式快取系統的發展現狀以及技術實現，如果讓你造一個「Redis」出來，你會考慮哪些問題等。雖然在實際工作中不建議重複“造輪子”，但在面試中要表現出自己具備“造輪子”的能力。
CAP 理論看似簡單，但在面試中，對它的理解深度可以從側面反映出你對分散式系統的整體理解能力和駕馭能力。
所以你不但要掌握如何在面試中回答案例中CAP 原理的問題，而且還要掌握回答問題的思路，以後遇到類似的理論性知識的考察，都可以從三個層面回答。
以上是美團面試：說說CAP，我的回答方式很特別的詳細內容。更多資訊請關注PHP中文網其他相關文章！
