zk本身是做分佈式數據一致性的一個解決方案，分佈式應用程序可以基於它實現發佈訂閱、負載均衡、集羣管理、分佈式協調、分佈式鎖等功能
在說zk之前還是要說一下集中式到分佈式的演進，對於後續的理解也是很有幫助的
1 集中式系統
集中式系統，是由一臺或多臺主計算機組成的中心節點，數據集中存儲於這個中心節點中，並且整個系統的所有業務單元都集中部署在這個中心節點上，系統的所有功能均由其集中處理。也就是說，在集中式系統中，每個終端或客戶端機器僅僅負責數據的錄入和輸出，而數據的存儲與控制處理完全交由主機來完成。
集中式系統最大的特點就是部署結構簡單。由於集中式系統往往基於底層性能卓越的大型主機，因此無須考慮如何對服務進行多個節點的部署，也就不用考慮多個節點之間的分佈式協作問題。
2 分佈式系統
分佈式系統是一個硬件或軟件組件分佈在不同的網絡計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統
分佈式系統的幾個特點：
- 分佈性
- 對等性
- 併發性
- 缺乏全局時鐘
- 故障總會發生
3 分佈式系統容易出現的問題
3.1 通信異常
從集中式到分佈式，通信需要依靠網絡，但是網絡總會有一些時候不會很可靠，所以也就需要考慮網絡的因素。分佈式系統在各個節點之中進行通信，因此每次通信都會伴隨着網絡不可用的風險，硬件設備也會有可能出現不可用的情況。
由於在通信中引入了網絡，所以同時也要考慮網絡延遲的問題，分佈式比單機的響應時間要長，因此消息丟失和消息延遲就會變得更加普遍。
3.2 網絡分區
當網絡發生異常，分佈式系統中只有一部分節點可以正常通信，另一些節點不能，這個現象就被稱爲腦裂。網絡分區出現時，分佈式系統就會出現局部小集羣，極端情況下，這些小集羣就會獨立完成原本需要整個分佈式系統完成的功能，包括數據得事務處理，這裏對分佈式一致性的要求就比較高了。
3.3 三態
在分佈式系統中，每一個請求的發送都對應着三種情況，成功、失敗、超時，這就被稱爲三態。當網絡出現異常時，如果出現超時，我們沒有辦法確定出現問題的位置，有可能在發送過程中丟失了消息，也有可能在接受返回的消息事丟失了消息。
3.4 節點故障
分佈式系統中的某個節點出現宕機或僵死的現象。
4 從ACID到CAP/BASE
4.1 ACID
事務 是一系列對系統中數據進行訪問與更新的操作所組成的一個程序執行邏輯單元。
一個事務要不就全部執行，要不就全不執行。
事務有四個特徵，分別是原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability），簡稱爲事務的ACID。
4.1.1 原子性
事務的執行只有兩種結果：
- 全部執行
- 全不執行
4.1.2 一致性
事務的執行不能破壞數據庫的完整性和一致性，一個事務在執行之前和之後，數據庫都必須處於一致性狀態，必須從一個狀態到另外的一個狀態。
如果數據庫在運行過程中被中斷，這些未完成的事務對數據庫的修改就只執行了一部分，此時就造成了數據不一致的狀態。
4.1.3 隔離性
在併發環境中，併發的事務時相互隔離的，一個事務不能被其他的事務所幹擾。不同的事務併發操作相同的數據時，每個事務都有自己完整的數據空間，一個事務內部的操作與使用的數據對其他事務時隔離的，併發執行各個事務之間不能互相干擾
4.1.4 持久性
事務提交成功之後，對數據庫中對應的數據狀態是永久性的。
4.2 CAP和BASE理論
4.2.1 CAP
1. C（Consistency）一致性
一致性是指在多個副本之間能否保持一致的特性。在一致性的需求下，當一個系統在數據一致性的狀態下執行更新操作後，應該保證系統的數據仍然處於一致的狀態
例如，在分佈式系統中，A 將一個節點的值 v1 更改爲了 v2 ，但是 B 從另一個節點中讀取到的值還是 v1 ，這個時候就造成了不一致。
2. A（Availability）可用性
可用性是指系統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求是能夠在有限的時間內返回結果。
有限的時間內：對於一個用戶的請求要在指定的時間內返回處理結果，如果超過了這個時間範圍，那麼就被認爲是不可用的
返回結果：要求系統完成的用戶請求之後返回一個正常的響應結果，即成功或失敗，而不是一個讓用戶感覺疑惑的結果
3. P（Partition tolerance）分區容錯性
分區容錯性約束了一個分佈式系統需要具有如下特徵：分佈式系統在遇到任何網絡分區故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網絡環境都發生了故障。
網絡分區是指在分佈式系統中，不同的節點分佈在不同的子網絡中，由於一些特殊的原因導致這些子網絡之間出現網絡不連通的狀況，丹格格自網絡的內部是正常的，從而導致整個系統的網絡環境被分成了若干個孤立的區域。
| 放棄CAP定理 | 說明 |
|---|---|
| 放棄 C | 要高可用並允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，爲了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。 典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統可以正常的服務，然後在數據的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗，但也不至於造成用戶購物流程的嚴重阻塞。 但是，這裏說的放棄一致性，並不是完全不需要數據一致性，放棄的只是數據的強一致性，保留了數據的最終一致性。 |
| 放棄 A | 如果不要求A（可用），相當於每個請求都需要在服務器之間保持強一致，而P（分區）會導致同步時間無限延長(也就是等待數據同步完才能正常訪問服務)，一旦發生網絡故障或者消息丟失等情況，就要犧牲用戶的體驗，等待所有數據全部一致了之後再讓用戶訪問系統。 設計成CP的系統其實不少，最典型的就是分佈式數據庫，如Redis、HBase等。對於這些分佈式數據庫來說，數據的一致性是最基本的要求，因爲如果連這個標準都達不到，那麼直接採用關係型數據庫就好，沒必要再浪費資源來部署分佈式數據庫。 |
| 放棄 P | 如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但放棄P的同時也就意味着放棄了系統的擴展性，也就是分佈式節點受限，沒辦法部署子節點，這是違背分佈式系統設計的初衷的。 傳統的關係型數據庫RDBMS：Oracle、MySQL就是CA。 |
一般來說，分區容錯性不可避免，因此可以認爲CAP的P總是成立，剩下的A和P無法同時做到
4.2.2 BASE
BASE是Basically Available（基本可用）、Soft state（軟狀態）、Eventtually consistent（最終一致性）三個短語的簡寫
1. Basically Available（基本可用）
指分佈式系統在出現不可預知故障的時候，允許損失部分可用性
比如：
響應時間的損失：響應時間適當延長，0.5s增加至1-2s
功能上的損失：在節日大促時，會對某些業務進行降級保護
2. Soft state（軟狀態）
弱狀態也成爲軟狀態，和硬狀態相對，是指允許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時
3. Eventtually consistent（最終一致性）
最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證數據能夠達到一致，而不需要實時保證系統數據的強一致性