三、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，提升了一
      致性