案例背景

CAP 理論是分散式系統(tǒng)中最核心的基礎(chǔ)理論，雖然在面試中，面試官不會直白地問你CAP 理論的原理，但是在面試中遇到的分散式系統(tǒng)設(shè)計問題，都繞不開你對CAP 的理解和思考。

而且在面試中，針對面試不同職位的候選者，面試官的要求也會不一樣，要求你回答的深度也不一樣。所以在今天文章中，我會針對國中級研發(fā)工程師和資深研發(fā)工程師兩個不同的角度，分析面試想法。

案例分析

相信只要學(xué)習(xí)過分散式技術(shù)的相關(guān)知識，基本上就知道CAP 理論指的是什麼：

• C（Consistency）是資料一致性、
• A（Availability）是服務(wù)可用性、
• P（Partition tolerance）是分割區(qū)容錯性。

C、A、P 只能同時滿足兩個目標(biāo)，而由於在分散式系統(tǒng)中，P 是必須保留的，所以要在 C 和 A 間進行取捨。若要保證服務(wù)的可用性，就選擇 AP 模型，而要保證一致性的話，就選擇 CP模型。

很多候選者如果發(fā)現(xiàn)面試題（例如「為了資料容災(zāi)，我們會做資料的主從備份，那麼主從節(jié)點的資料一致性對呼叫端有什麼影響呢？」）涉及了對“CAP 的理解和思考”，會下意識地做出類似的答案：“ CAP 理論描述了在出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況下，要在C 和A 之間做取捨，所以會影響站在調(diào)用端的視角看系統(tǒng)是不可用的」。如果是我的話，大概會給個及格分，並認為這樣的回答，只能證明你有準(zhǔn)備，不能證明你有能力。

因為面試中遇到理論問題時，單純做浮於表面的概念性闡述，很難向面試官證明你的技術(shù)能力。面試官會覺得你是??一個剛接觸分散式系統(tǒng)，或是對分散式系統(tǒng)理解不夠深入的研發(fā)，如果這恰好是你第一個面試題，會直接影響面試官對你的第一印象，甚至影響你的定級。

從我的經(jīng)驗出發(fā)，如果你想答得更好，你需要先掌握 CAP 的原理、實務(wù)經(jīng)驗、技術(shù)認知，然後再結(jié)合具體的面試題具體分析。

問題解答

理解原理

#現(xiàn)在有一個分散式系統(tǒng)A，它有一個副本A1，在正常情況下，客戶端Client 寫入資料到系統(tǒng)A，然後資料從A 節(jié)點同步到A1 節(jié)點，再傳回給Client 成功狀態(tài)。

這時，客戶端Client 從任何節(jié)點A 或A1 讀取數(shù)據(jù)，都能讀取到最新寫入的數(shù)據(jù)，說明A 和A1的數(shù)據(jù)是一致的，並且A 和A1 也都是可用的。

但由於網(wǎng)路是不可靠的，節(jié)點 A 和 A1 的網(wǎng)路隨時會因為中斷而出現(xiàn)分區(qū)。所謂網(wǎng)路分區(qū)就是由於網(wǎng)路不通導(dǎo)致節(jié)點 A 和 A1 被隔離在不同的網(wǎng)路子集中，此時節(jié)點 A 的資料就無法及時同步到節(jié)點 A1 中了。

在分散式系統(tǒng)中，由於網(wǎng)路問題導(dǎo)致的網(wǎng)路分區(qū)是常態(tài)。也就是說出現(xiàn)網(wǎng)路分區(qū)時，根據(jù) CAP 理論，需要在 A 和 C 中進行取捨，也就是確保系統(tǒng)的可用性，或是保證資料一致性。

這裡你要注意了，上面的例子有個大前提，就是系統(tǒng)出現(xiàn)了網(wǎng)路分區(qū)，但實際情況是，在絕大多數(shù)時間裡並不存在網(wǎng)路分區(qū)（網(wǎng)路不會經(jīng)常出現(xiàn)問題）。那麼還要進行三選二嗎（CP 或 AP）？

其實，不同的分散式系統(tǒng)要根據(jù)業(yè)務(wù)場景和業(yè)務(wù)需求在 CAP 三者中進行權(quán)衡。 CAP 理論用於指導(dǎo)系統(tǒng)設(shè)計時需要衡量的因素，而非進行絕對地選擇。

當(dāng)網(wǎng)路沒有出現(xiàn)分區(qū)時，CAP 理論並沒有給出衡量A 和C 的因素，但如果你做過實際的分散式系統(tǒng)設(shè)計，一定會發(fā)現(xiàn)系統(tǒng)資料同步的延遲（Latency） ，也就是例子中節(jié)點A 同步資料到節(jié)點A1 的時間才是衡量A 和C 最重要的因素，此時就不會有絕對的AP 模型還是CP 模型了，而是源自於對實際業(yè)務(wù)場景的綜合考量。

因此，才會有如 PACELC「Reference1」 這樣的新模型優(yōu)化原有的 CAP 理論，理論指導(dǎo)實踐，實踐最佳化理論。

根據(jù)PACELC 模型的定義，如果有網(wǎng)路分割區(qū)產(chǎn)生，系統(tǒng)就必須在A 和C 之間取得平衡，否則（Else，即PACELC 中的E）當(dāng)系統(tǒng)運作在無網(wǎng)路分割區(qū)情況下，系統(tǒng)需要在L（延遲）和C 之間取得平衡。

PACELC

但要理解到這個程度還不夠，你還需要結(jié)合落地經(jīng)驗來證明。

實務(wù)經(jīng)驗

你要意識到，網(wǎng)路分散式的設(shè)計方案是資料一致性和系統(tǒng)可用性的權(quán)衡，並不是非此即彼，這一點尤其重要。所以即使無法做到強一致性（簡單來講強一致性就是在任何時刻所有的用戶查詢到的數(shù)據(jù)都是最新的），也可以根據(jù)自身的業(yè)務(wù)特點，採用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性。

這時就要引出 BASE 理論，它是 CAP 理論的延伸。 BASE 是Basically Available（基本上可用）、Soft State（軟狀態(tài)）和Eventually Consistent（最終一致性）三個單詞的簡寫，作用是保證系統(tǒng)的可用性，然後透過最終一致性來取代強一致性，它是目前分散式系統(tǒng)設(shè)計中最具指導(dǎo)意義的經(jīng)驗總結(jié)。那麼在實際專案中，你如何透過 BASE 理論來指導(dǎo)設(shè)計實務(wù)呢？

BASE 中的基本可用指的是保障核心功能的基本可用，其實是做了「可用性」方面的妥協(xié)，例如：

電商網(wǎng)站在雙十一大促等訪問壓力較大的時候，關(guān)閉商品排行榜等次要功能的展示，從而保證商品交易主流程的可用性，這也是我們常說的服務(wù)降級；

為了錯開雙十一高峰期，電商網(wǎng)站會將預(yù)售商品的支付時間延後十到二十分鐘，這就是流量削峰；

在你搶購商品的時候，往往會在隊列中等待處理，這也是常用的延遲隊列。

軟狀態(tài)和最終一致性指的是允許系統(tǒng)中的資料存在中間狀態(tài)，這同樣是為了系統(tǒng)可用性而犧牲一段時間窗內(nèi)的資料一致性，從而保證最終的資料一致性的做法。

目前這種處理數(shù)據(jù)的方式幾乎成了互聯(lián)網(wǎng)的標(biāo)配設(shè)計模式，最經(jīng)典的例子是在用戶下單的時候不需要真正地扣減庫存，而是僅在前臺計個數(shù)，然後透過非同步任務(wù)在背景批次處理。

如果你想應(yīng)徵的是國中級研發(fā)工程師，那麼結(jié)合上述思路，從理論理解到落地實踐，你已經(jīng)可以把 CAP 理論答得較為清楚了?；卮饐栴}的邏輯可以參考我給的建議：

• 先充分理解理論原理，不能只浮在概念上；
• #其次需要有自己的思考，表現(xiàn)出你思考能力的不同；
• 然後將理論結(jié)合於實踐，討論實際中處理問題時的思考邏輯。

技術(shù)認知

如果你應(yīng)徵的是高階研發(fā)工程師或架構(gòu)師，在回答時，還要盡可能地展示知識體系和技術(shù)判斷力，這是這兩個崗位的基本素質(zhì)。因為分散式技術(shù)錯綜複雜，各種技術(shù)又相互耦合，在面試中，如果你能通過一個 CAP 理論的知識點，擴展出一個脈絡(luò)清晰的分佈式核心技術(shù)知識體系，就會與其他人拉開差距。

分散式系統(tǒng)看起來就像一臺電腦。電腦包括五大體系結(jié)構(gòu)（即馮諾依曼結(jié)構(gòu)）。它有五大部件：

• 控制器
• 運算器
• 記憶體
• 輸入
• 輸出

你可以這麼理解：一個分散式系統(tǒng)也包含這五大部件，其中最重要的是計算與儲存。運算與儲存由一系列網(wǎng)路節(jié)點組成，每個節(jié)點之間的通訊就是輸入與輸出，各節(jié)點之間的調(diào)度管理就是控制器。

分散式架構(gòu)技術(shù)組成

這麼看來，分散式系統(tǒng)就像一個網(wǎng)路計算機，它的知識體系包括四個角度：

• 記憶體，即分散式儲存系統(tǒng)，如NoSQL 資料庫儲存；
• #運算器，即分散式運算，如分散式並行計算；
• 輸入輸出，即分散式系統(tǒng)通信，如同步RPC 呼叫和非同步訊息佇列；
• 控制器，即調(diào)度管理，如流量調(diào)度、任務(wù)調(diào)度與資源調(diào)度。

你可以從這四個角度來概括分散式系統(tǒng)的知識體系。

那麼具體的解題思路是什麼呢？以「Redis 是否可以作為分散式鎖定」為例，咱們一起來分析一下問題背後隱藏的分散式理論知識，以及作為高級研發(fā)工程師的解題思路。

解題想法

• 說明現(xiàn)實存在的問題

#一般使用setnx 方法，透過Redis 實作鎖定和逾時時間來控制鎖的失效時間。但在極端的情況下，當(dāng) Reids 主節(jié)點掛掉，但鎖還沒有同步到從節(jié)點時，根據(jù)哨兵機制，從就變成了主，繼續(xù)提供服務(wù)。這時，另外的執(zhí)行緒可以再來請求鎖，此時就會出現(xiàn)兩個執(zhí)行緒拿到了鎖的狀況。

• 迴歸理論的指導(dǎo)

根據(jù)對CAP 理論的理解，Redis 的設(shè)計模型是AP 模型，而分散式鎖定則是CP場景，那麼很明顯，將Redis 這種AP 模型的架構(gòu)應(yīng)用於CP 的場景，在底層的技術(shù)選型上就是錯誤的。

• 擴展到知識體系

Redis 屬於分散式儲存系統(tǒng)，你的腦中就要有對分散式儲存系統(tǒng)領(lǐng)域的知識體系。思考它的資料儲存、資料分佈、資料複製，以及資料一致性都是怎麼做的，用了哪些技術(shù)來實現(xiàn)，為什麼要做這樣的技術(shù)或演算法選型。你要學(xué)習(xí)從多維度、多角度去比較、分析同一分散式問題的不同方法，然後綜合權(quán)衡各種方法的優(yōu)缺點，最終形成自己的技術(shù)認知和技術(shù)判斷力。

• 有技術(shù)的判斷力

例如透過Redis，你能想到目前分散式快取系統(tǒng)的發(fā)展現(xiàn)狀以及技術(shù)實現(xiàn)，如果讓你造一個「Redis」出來，你會考慮哪些問題等。雖然在實際工作中不建議重複“造輪子”，但在面試中要表現(xiàn)出自己具備“造輪子”的能力。

總結(jié)

CAP 理論看似簡單，但在面試中，對它的理解深度可以從側(cè)面反映出你對分散式系統(tǒng)的整體理解能力和駕馭能力。

所以你不但要掌握如何在面試中回答案例中CAP 原理的問題，而且還要掌握回答問題的思路，以後遇到類似的理論性知識的考察，都可以從三個層面回答。