1、分佈式系統中CAP分別代表什麼？對它們的理解？
CAP即一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。
- 一致性（Consistency）：所有節點同時看到相同的數據
- 可用性（Availability）：任何時候，讀寫都是成功的
- 分區容錯性（Partition tolerance）：當部分節點出現消息丟失或者分區故障的時候，分佈式系統仍然能夠繼續運行
CAP理論指在分佈式系統中，最多隻能同時滿足其中兩點，不能三者兼顧。
2、爲什麼分佈式系統不能三者兼顧？
首先分佈式系統與單機系統不同，涉及到多個節點的通訊和交互，那麼節點間的分區故障是必然會發生的，所以分區容錯性（P）是必然要保證的，不然就成了單機系統。所以只能在可用性（A）和一致性（C）裏做選擇。
如果我們選擇可用性（A），那麼系統始終會響應客戶端的請求，返回信息。如果發生了網絡分區，那麼一些節點就不能返回最新的數據，只能返回當前自己手裏認爲最新的數據。
如果我們選擇一致性（C），那麼節點每次響應客戶端的一定是最新的數據，不會返回舊數據。但節點在拿最新數據的時候，因爲網絡故障、消息丟失等問題，無法拿到最新數據，那麼當客戶端請求過來的時候，爲了保證一致性，就只能返回錯誤信息了。
所以只能選擇AP或者CP
3、對Base理論的理解？
對於 CAP 來說，放棄強一致性（這裏說的一致性是強一致性），追求分區容錯性和可用性，這是很多分佈式系統設計時的選擇。在工程實踐中，基於 CAP 定理逐步演化，就提出了 Base 理論。
Base 是三個短語的簡寫，即基本可用（Basically Available）、軟狀態（Soft State）和最終一致性（Eventually Consistent）。
Base 理論的核心思想是最終一致性，即使無法做到強一致性（Strong Consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual Consistency）。
- 基本可用（Basically Available）：不保證任何時候，讀寫都是成功的。而是系統能夠基本運行，一直提供服務。基本可用強調了當分佈式系統出現故障的時候，允許損失部分可用性，相比於可能的系統，可能出現的是響應延遲或者服務降級等。
- 軟狀態（Soft-state）：軟狀態可以對應 ACID 事務中的原子性（在 ACID 的事務中，實現的是強制一致性，要麼全做要麼不做，所有用戶看到的數據一致。其中的原子性（Atomicity）要求多個節點的數據副本都是一致的，強調數據的一致性，可以理解爲一種“硬狀態”），軟狀態則是允許系統中的數據存在中間狀態，並認爲該狀態不影響系統的整體可用性，即允許系統在多個不同節點的數據副本存在數據延時。
- 最終一致性（Eventually Consistent）：數據不可能一直是軟狀態，必須在一個時間期限之後達到各個節點的一致性，在期限過後，應當保證所有副本保持數據一致性，也就是達到數據的最終一致性。在系統設計中，最終一致性實現的時間取決於網絡延時、系統負載、不同的存儲選型、不同數據複製方案設計等因素。
4、如何理解數據一致性？數據一致性有幾種模型？
我理解的數據一致性就是多個節點間的數據保持同步。
數據一致性模型可以分爲強一致性和弱一致性。在大多數系統中，都要犧牲強一致性來保證系統的高可用性，只需要保證最終一致性即可，只要這個最終時間是在用戶可以接受的範圍內即可。比如網站的積分排行榜，它會告訴你一小時更新一次，並不是實時更新。
強一致性：也就是我們上面說的CAP理論中的C。當數據發生變化時，後續進程訪問到的都是最新的數據。這是對用戶最友好的，但需要犧牲可用性。
弱一致性：系統在數據寫入成功之後，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之後可以讀到。用戶讀到某一操作對系統數據的更新需要一段時間，我們稱這段時間爲“不一致性窗口”。
-
最終一致性：是弱一致性的特例，強調的是所有的數據副本，在經過一段時間的同步之後，最終都能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
到達最終一致性的時間 ，就是不一致窗口時間，在沒有故障發生的前提下，不一致窗口的時間主要受通信延遲，系統負載和複製副本的個數影響。
最終一致性模型根據其提供的不同保證可以劃分爲更多的模型，包括因果一致性和會話一致性等。
- 因果一致性：因果一致性要求有因果關係的操作需要有先後順序。比如進程A在更新完某個數據後通知進程B，那麼進程B之後對該數據的訪問都能獲取到進程A更新後的最新值，並且進程B要更新該數據的話，必須基於進程A更新後的最新值。
- 會話一致性：會話一致性將對系統數據的訪問過程框定在了一個會話當中，約定了系統能保證在同一個有效的會話中實現“讀己之所寫”的一致性，就是在你的一次訪問中，執行更新操作之後，客戶端能夠在同一個會話中始終讀取到該數據項的最新值。實際開發中有分佈式的 Session 一致性問題，可以認爲是會話一致性的一個應用。
5、設計系統時，強一致性和弱一致性怎麼選擇？
對數據比較敏感，數據實時性、嚴謹性要求比較高的系統，應該選擇強一致性，比如銀行之類的涉及到交易的系統。而對於數據沒有這麼敏感的系統，則可以選擇弱一致性，比如會員網站的積分排行榜，用戶個人信息更改等。
6、CAP理論和Base理論的關係
Base理論是在CAP理論上發展出來的，CAP 理論描述了分佈式系統中數據一致性、可用性、分區容錯性之間的制約關係，當你選擇了其中的兩個時，就不得不對剩下的一個做一定程度的犧牲。
Base 理論則是對 CAP 理論的實際應用，也就是在分區和副本存在的前提下，通過一定的系統設計方案，放棄強一致性，實現基本可用，這是大部分分佈式系統的選擇，比如 NoSQL 系統、微服務架構。在這個前提下，如何把基本可用做到最好，就是分佈式工程師們追求的。
除了 CAP 和 Base，還有 ACID 原理，ACID 是一種強一致性模型，強調原子性、一致性、隔離性和持久性，主要用於在數據庫實現中。Base 理論面向的是高可用、可擴展的分佈式系統，ACID 適合傳統金融等業務，在實際場景中，不同業務對數據的一致性要求不一樣，ACID 和 Base 理論往往會結合使用。