三、Kafka CAP和ISR

1、CAP介紹

• C（Consistency）：一致性，也就是寫入什麼，讀出來什麼。這就要求：主從之間的數據實現一致性，這裏指的是partition的leader 和 flower之間的一致性

  強一致性： 若是數據更新後，併發訪問狀況下可當即感知 ==> 監聽器、leader輪詢通知
  最終一致若是以後一段時間後，必定能夠感知該更新 ==> flower定時來拉取
  弱一致：容許很長時間以後才同步

• A（Availability）：可用性。集羣能確保在必定時間內相應請求

• P（Partition tolerance）：分區容錯性。因爲網絡緣由，分區以前的通訊（同步）可能會失敗，這種狀況須要考慮到而且解決。

CAP矛盾 ==> C 和 A的矛盾

• 一、CAP最多隻能實現其中兩點，其中P是確定要實現的，因此只能在C 和 A之間作取捨。

• 二、要想實現強一致性，leader接受到數據以後，就必須等到全部replica同步過去以後才能響應procuder ack。若是replication同步失敗，則leader沒法響應ack，這就無法實現可用性（A）。

• 三、反之亦然

2、kafka 使用ISR實現C 和 A之間的平衡

• 一、kafka對每個partition都會在zookeeper上維護一個ISR列表記錄着那些和leader同步很是及時的replication，這樣只要這些副本同步成功了，就能夠響應producer的ACK。

• 二、問題？ 若是leader失敗了，一個未徹底同步數據的replication被選擇爲了leader，那豈不是數據丟失？不一致？

  答案：是的，這種狀況能夠保證可用性，可是不能保證一致性
  
    	這裏有一個參數能夠指定只容許ISR中的replication做爲leader來保證一致性
    	unclean.leader.election.enable=false
  
    	一樣的，若是ISR中的replication都不能啓動，就會一直沒有leader，無法對外服務
    	也就是雖然保證了一致性，可是就會丟失了可用性

3、原理詳解

• 一、關於參數

  • 1.一、broker端參數

    replication.factor：partition副本數量
      unclean.leader.election.enable：leader掛了以後，如何選舉leader

  • 1.2Topic配置，建立topic時指定

    min.insync.replicas = 1：ISR中至少有多少個分區

  • 1.三、producer端參數

    request.required.asks = 0：不確認，發了就完事，沒有可靠性
      request.required.asks = 1：leader收到數據就返回ack確認，不能保證flower同步，可能會丟失
      request.required.asks = -1：要求leader和ISR表中的flower都同步完成才向producer返回ack確
      認，安全性最高，性能最低
      retries：若是沒有ack相應，失敗以後重試的次數

• 二、關於做用

  • 2.一、producer設置ack的做用

    producer的request.required.asks = -1只有設置爲 -1時，纔會涉及到leader和flower之間同步的
      問題，而0和1參數都不須要等待flower同步。
    
      因爲有的flower掛了、或者同步速度很慢，若是leader須要等到全部flower都同步完成才向producer相應
      ack，黃花菜都涼了，因此leader在zookeeper的/broker/topics/{topic}/partitions/
      {partition}/state下維護了一個ISR列表來記錄那些同步及時的flower，加快ack相應時間，格式爲：
      {"controller_epoch":18,"leader":-1,"version":1,"leader_epoch":86,"isr":[]}。

  • 2.二、ISR剔除和加入的規則參數

    rerplica.lag.time.max.ms=10000
      若是leader發現flower超過10秒沒有向它發起fech請求，那麼leader考慮這個flower是否是程序出了點
      問題或者資源緊張調度不過來，它太慢了，不但願它拖慢後面的進度，就把它從ISR中移除。
    
      rerplica.lag.max.messages=4000 
      相差4000條就移除，flower慢的時候，保證高可用性，同時知足這兩個條件後又加入ISR中，在可用性與一
      致性作了動態平衡   亮點

  • 2.三、leader的選舉參數unclean.leader.election.enable

    true：第一個flower啓動設置爲leader，可用性高，一致性低。若是是ISR以外的flower做爲leader，那
      麼ISR的flower offset會比這個leader要大，須要進行刪除，和新leader一直後才能進行同步會丟二、三、四、5
      這幾條數據
    
      false：必定要ISR中的flower啓動才設置爲leader，可用性低，一致性高。ISR的數據和原來Leader一
      致，因此不會丟數據，flower繼續同步便可。kafka 0.11以後將原來的默認值true改成false，提升了一
      致性