下面我们来介绍下Kafka怎么调优可用性相关的参数。可用性反映的是kafka集群应对崩溃的能力。无论broker,producer,consumer出现崩溃，kafka依然保持可用状态而不会因为异常就中断服务。下面我们就从topic,producer,broker和consumer这几个方面来看怎么调优可用性。
从topic来看，当topic的分区数很多时，一旦分区leader所在的broker发生问题，就需要进行leader选举。而leader选举是通过controller进行的，controller处理leader请求是单线程的，大量的leader选举请求只能放入队列中处理，而且在受影响分区leader选举之前无论producer还是consumer都无法工作，所以topic分区数越多，恢复的时间就越慢。因此应该根据机器配置及调优目标，合理地确定topic分区数。
在producer端，我们要首先关注acks参数。当设置acks为all时，broker端参数min.insync.replicas的效果会影响producer端的可用性。该参数设置的越大，kafka就会让越多的follower副本同步写入日志。当出现isr的数量小于min.insync.replica的值时，producer将不会对指定的分区发送消息，从而影响了服务的可用性。但如果设置了一个很小的值，那么producer将能够容忍更多的副本被踢出isr。只要剩余的isr副本数大于min.insync.replicas即可。此时producer可以一直正常工作，不会出现服务中断的情况，因此实现了高可用性。
broker端影响高可用最直接的方式就是broker崩溃。在broker崩溃之后leader选举有两种：1.先从isr中选2.根据unclean.leader.election.enable值决定知否从非isr中选。但是需要注意的是，当unclean.leader.election.enable为true时，将允许controller从非isr中选择leader，这样可能会存在丢失数据的风险。broker端影响高可用性的另一个参数是num.recovery.threads.per.data.dir。当broker从崩溃中恢复后，broker会首先扫描并加载底层的分区数据执行清理和其他broker的同步任务。这一过程被称为日志加载或日志恢复。默认情况下，每个broker都只用一个线程来做这些事情。假设某个broker的log.dirs配置了10个日志目录，那么该broker使用单线程顺序扫描加载这些目录。显然，每个日志目录的加载任务是互不依赖的，非常适合多线程来做。因此kafka的broker端num.recovery.threads.per.data.dir参数就是用来做这个的。适当增加该参数值可以提高服务从崩溃中恢复的能力。在实际使用中，可以根据broker的机器配置来设置该参数。
对于consumer来说，高可用性主要是由consumer group实现的。当group下的某个consumer实例出问题了，group的coordinator能够自动检测出这种崩溃并及时地开启rebalance将这些consumer实例的分区配置给其他存活的实例。显然我们想让coordinator能够快速的检测出这些异常。consumer端参数session.timeout.ms就是用来做这件事情的。coordinator保证检测出异常的时间最多不会超过session.timeout.ms指定的值，因此要实现consumer端高可用，可以设置该参数为一个较低的值，比如为5-10秒。这种异常实际上包括了2种情况。第一种是崩溃，也就是服务实例异常。coordinator只能保证session.timeout.ms内检测出这种异常并开启rebalance。第二种则是consumer自身的问题导致，比如消息处理时间过长从而导致超时。此时consumer将告知coordinator它要离开该group。对于这种情况，用户需要增加max.poll.interval.ms参数的值让consumer实例有更多的时间来处理消息，从而达到consumer的高可用性。
下面总结一下调优高可用性的相关参数
broker端
1.避免创建过多的分区
2.设置min.insync.replicas=1
3.设置num.recovery.threads.per.data.dir为broke端参数logs.dir中设置的目录数
producer端
1.设置acks=1，如果要设置为all，则需要遵循上面broker端的min.insync.replicas配置
consumer端
1.设置session.timeout.ms为较低的值，比如为10000
2.设置max.poll.interval.ms为比消息平均处理时间更大的值
3.设置max.poll.records和max.parition.fetch.bytes来降低consumer处理消息的时间，从而避免频繁的rebalance。
到这里，我们就介绍了kafka可用性的相关参数，kafka可用性的相关参数就介绍到这里了。