原文參考：https://www.jianshu.com/p/ff7dd5b349f1
一、CAP理論概述
1、cap
分布式系統中，一致性、可用性、分區容錯性不可兼得，最多只可同時滿足兩個。
C(Consistency 一致性)：
* A read is guaranteed to return the most recent write for a given client.
* 在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
* 注：在一個節點上修改數據，在另一個節點上能讀取到修改后的數據
* 某個節點的數據更新結果對后面通過其它節點的讀操作可見
* 立即可見，稱為強一致性
* 部分或者全部感知不到該更新，稱為弱一致性
* 在一段時間（通常該時間不固定）后，一定可以感知該更新，稱為最終一致性
A(Availability 可用性):
* A non-failing node will return a reasonable response within a reasonable amount of time（no error or timeout）
* 在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
* 注：在用戶可容忍的范圍內返回數據
* 一個沒有發生故障的節點必須在有限的時間內返回合理的結果
* Vs數據庫的HA：一個節點宕機，其它節點仍然可用
P(Partition Tolerance 分區容錯性)：
* The system will continue to function when network partitions occur.
* 以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
* 注：一個分布式集群，分成多個小的集群，小的集群內部可相互通信，對於用戶透明
* 部分節點宕機或者無法與其它節點通信時，各分區間還可保持分布式系統的功能
簡單來說：
C：不管訪問集群中的哪個節點，返回的結果都是一樣的。
A：集群中的一個或者某個節點掛掉，仍然可以提供服務。
P：集群內部出現通信故障，服務A的數據沒法同步到其他節點時，客戶端訪問服務A，服務A仍然能返回未同步到其他節點的數據。
二、kafka ISR實現CAP中可用性與數據一致性的動態平衡
1、kafka ISR實現CAP中可用性與數據一致性的動態平衡
Kafka的數據復制方案接近於Master-Slave，不同的是，Kafka既不是完全的同步復制，也不是完全的一步復制，而是基於ISR的動態復制方案。
ISR，In-Sync Replica，每個Partition的Leader都會維護這樣一個列表，其中包含了所有與之同步的Replica。每次寫入數據時
，只有ISR中的所有Replica都復制完，Leader才會將這條數據置為Commit，它才能被Consumer消費。
與同步復制不同的是，這個ISR是由Leader動態維護的，如果Follower不能緊跟上Leader，它將被Leader從ISR中移除，待它
重新“跟上”Leader后，會被Leader再次加入ISR中。每次改變ISR后，Leader會將最新ISR持久化到Zookeeper中。
那么如何判斷Follower是否“跟上”Leader？
如果Follower在replica.lag.time.max.ms時間內未向Leader發送Fetch請求（數據復制請求），則Leader將其從ISR中移除。
2、為什么使用ISR方案
Leader可移除不能及時與之同步的Follower，所以與同步復制相比可以避免最慢的Follower拖慢整體速度，提高系統可用性。
從Consumer角度來看，ISR中所有Replica都始終處於同步狀態，從而與異步復制相比提高了數據一致性。
3、ISR相關配置
Broker的min.insync.replicas參數制定了Broker所要求的ISR最小長度，默認值為1.極限情況下ISR可以只包含Leader，但此時如果Leader宕機，則該Partition不可用，
可用性不可保證。
只有被ISR中所有Replica同步的消息才被commit，但是Producer在寫數據時，Leader不需要ISR中所有Replica同步該數據才確認收到數據。
Producer可以通過acks參數指定最少需要多少個Replica確認收到該消息才視為該消息發送成功。acks默認值為1，即Leader收到該消息后立即告訴Producer收到該消息，
此時如果在ISR中的消息復制完該消息前Leader宕機，那該條消息會丟失。推薦做法是：將acks設置為all或-1，此時只有ISR中的所有Replica都收到該數據（也及消息被commit），
Leader才會告訴Producer該消息發送成功，這樣保證了不會有未知的數據丟失。
三、kafka的高性能
順序寫磁盤
將寫磁盤的過程變為順序寫，可極大提高對磁盤的利用率。Consumer通過offset順序消費這些數據，且不刪除已經消費的數據，從而避免隨機寫磁盤的過程。
Kafka刪除舊數據的方式是刪除整個Segment對應的log文件和整個index文件，而不是刪除部分內容。
充分利用Page Cache
Page Cache的優點：
I/O Scheduler會將連續的小塊寫組裝成大塊的物理寫從而提高性能。
I/O Scheduler會嘗試將一些寫操作重新按順序排好，從而減少磁頭移動時間。
充分利用所有空閑內存（非JVM內存）。
讀操作可以直接在Page Cache內進行。如果消費和生產速度相當，甚至不需要通過物理磁盤交換數據。
如果進程重啟，JVM內的Cache會失效，但Page Cache仍然可用。
零拷貝
Kafka中存在大量網絡數據持久化到磁盤（Producer到Broker）和磁盤文件通過網絡發送（Broker到Consumer）的過程，
這個過程中，傳統模式下要進行數據的四次拷貝，但是Kafka通過零拷貝技術將其減為了一次，大大增加了效率，
零拷貝技術：
傳統的讀取文件數據並發送到網絡的步驟如下：
（1）操作系統將數據從磁盤文件中讀取到內核空間的頁面緩存；
（2）應用程序將數據從內核空間讀入用戶空間緩沖區；
（3）應用程序將讀到數據寫回內核空間並放入socket緩沖區；
（4）操作系統將數據從socket緩沖區復制到網卡接口，此時數據才能通過網絡發送。
“零拷貝技術”只用將磁盤文件的數據復制到頁面緩存中一次，然后將數據從頁面緩存直接發送到網絡中（發送給不同的訂閱者時，都可以使用同一個頁面緩存），避免了重復復制操作。
如果有10個消費者，傳統方式下，數據復制次數為4*10=40次，而使用“零拷貝技術”只需要1+10=11次，一次為從磁盤復制到頁面緩存，10次表示10個消費者各自讀取一次頁面緩存。
減少網絡開銷
批處理：
批處理減少了網絡傳輸的overhead，又提高了寫磁盤的效率。
Kafka的API做中，從send接口來看，一次只能發送一個ProducerRecord，但是send方法並不是立即將消息發送出去，而是通過batch.size和linger.ms控制實際發送頻率，
從而實現批量發送。
數據壓縮降低網絡負載
高效的序列化方式