Kafka如何配置高可用

前言

电话面试的时候，发现去总结Kafka如何保证高可用时，整个脑袋是懵的，其实Kafka的原理我是懂的，可就是说不出来，这篇文章用来描述下Kafka在不同的情况下，如何保证高可用。
具体Kafka原理解析，请移步Kafka数据可靠性深度解读

消息中间件出问题的可能性

• Producer发送到消息中间件时出问题（从Producer发送消息开发，到中间件返回成功为止）
• 消息中间件收到消息，处理时出问题（即中间件向Producer返回成功开始算起，到消息存储到硬盘设备为止）
• Consumer消费消息时出问题（从消息中间件拿到消息开始，到向中间件返回消费完成为止）

Producer发送到消息中间件时出问题

1. 发送消息到中间件遇到网络问题
   此时，Producer会收到异常，尝试重新发送即可。此时中间件还是仅收到一条消息
2. 中间件返回Producer成功遇到网络问题
   此时，Producer会受到异常，尝试重新发送即可。此时中间件就可能重复收到多条消息，这个就无法避免了。

消息中间件收到消息，处理时出问题

该内容后续着重介绍，消息中间件出问题，也主要是这部分出的问题

Consumer消费消息时出问题

1. 中间件发送到Consumer时遇到网络问题
   此时，由于中间件未收到消费成功的返回，且超过timeout时间，该消息可以被重新消费。即保证至少被成功消费一次。
2. Consumer返回消费成功时遇到网络问题
   Consumer不管是遇到网络问题，还是消费时抛出异常，都无法给中间件消费成功的返回，那在timeout之后，该消息可以被重新消费。即保证至少被成功消费一次。跟上面的处理方式类似，为了保证消息不会被重复消息，需要业务侧提供消息去重的逻辑。

Kafka可靠性级别(request.required.acks)

• 1（默认）：这意味着Producer在ISR中的Leader已成功收到的数据并得到确认后发送下一条message。如果Leader宕机了，则会丢失数据。
• 0：这意味着Producer无需等待来自Broker的确认而继续发送下一批消息。这种情况下数据传输效率最高，但是数据可靠性确是最低的。
• -1：Producer需要等待ISR中的所有Follower都确认接收到数据后才算一次发送完成，可靠性最高。但是这样也不能保证数据不丢失。

Kafka可靠性级别为1，即仅Leader收到消息即算成功

如果Leader收到消息返回成功，可还未同步Follower时，Leader就宕机了。此时消息永远回不来的了。概率性问题，如果对消息发送成功的要求较高，不建议使用这个配置。

Kafka可靠性级别为0，即Producer无需确认Kafka是否成功存储消息

该可靠性最低，但是数据传输效率最高，如果对消息发送成功的要求较低，可使用该配置。

Kafka可靠性级别为-1，即Leader必须等到所有ISR中所有Follower确认成功

该可靠性最高，可也并不是配置了这个可靠性之后就无忧了，同时还需要额外一些配置来保证消息确实存储成功。

• 配置replication的副本数(default.replication.refactor)
• 配置ISR中最小副本数(min.insync.replicas)

ISR最大的数量就是replication的副本数，如果ISR数量小于要求数量，write功能是肯定不能提供了。根据是否还有存活的ISR来判断是否还能有read功能。

假设所有Follower都已同步Leader的消息，此时Leader宕机，可直接从ISR中选举Leader，消息不会丢失。
假设Leader宕机时，各个Follower同步Leader消息的进度不同，此时会在ISR中重新选举Leader，并向Producer抛异常，让Producer重新发送消息。
这个时候，新的Leader会让Follower截取消息到上次的HW，这样Leader和Follower的消息就同步，并且抛弃掉上个Leader宕机时对应的未处理的消息。此时Producer重新发送的消息，Leader就不会有重复消息了。
在后续，如果之前Leader恢复了，也要截取消息到上面所有的HW的位置，然后再从新的Leader中同步消息，自己成为了Follower。