k

CAP帽子理論。

consistency：一致性 Availability：可用性 partition tolerance：分區容忍型

CA ：mysql oracle（拋棄了網絡分區）

CP：hbase redis mongodb（拋棄了可用性）

AP：cassandra simpleDB（拋棄了強一致性,采用弱一致性或者最終一致性,不定時一致性）

一致性的方案

master-slave（hadoop）

WNR 讀取後還得判斷哪個數據是最新的。常用做法（版本號或者時間戳）

平時讀取數據是從leader上讀取,follower是為了防止leader宕機進行可用性保證。數據是follower從leader拉取,類似consumer

kafka既不是同步也不是異步機制,而是采用了isr機制。（kafka一旦數據進行commit就必須保證所有的數據都被commit）

一旦發現follower和leader相距的數據過大,就會進行節點移除。差距過大的條件為時間或者條目數：

這是kafka區別與其他系統一個亮點,既不采用同步復制也不采用異步,而且采用了中間的動態控制的設計。

min,insync.replicas是kafka備份的選取,通常是2比較安全一些

request.required.acks

0：這意味著生產者producer不等待來自broker同步完成的確認繼續發送下一條（批）消息。此選項提供最低的延遲但最弱的耐久性保證（當服務器發生故障時某些數據會丟失，如leader已死，但producer並不知情，發出去的信息broker就收不到）。

1：這意味著producer在leader已成功收到的數據並得到確認後發送下一條message。此選項提供了更好的耐久性為客戶等待服務器確認請求成功（被寫入死亡leader但尚未復制將失去了唯一的消息）。

-1：這意味著producer在follower副本確認接收到數據後才算一次發送完成。
此選項提供最好的耐久性，我們保證沒有信息將丟失，只要至少一個同步副本保持存活。

從上圖可以看出kafka只有commit的數據才會可以被消費。比如3---4時候M3數據會丟失，因為leader宕機的時候M3從來沒被commit過,所以數據在默認retry還沒成功就會丟失,但是如果retry成功後會插入M5之後,順序性也就變了（所以kafka的順序性是comit順序而不是發送順序,而且處理不好也會存在數據丟失的情況）,一旦宕機節點恢復就需要check out所有落後數據,直到isr設置的臨界點（比如4K條目）才會被加入到ISR列表中。

有選項可以配置全部節點掛掉時候,是恢復isr中的列表,還是全部機器無論在不在ISR中（默認選項）

備份數目不能超過broker數量

默認kafka的replicas和leader都會盡量均勻分配。因為讀寫都是通過leader所以需要盡量性能均勻些

kafka數據禍福和failover