Kafka高可靠配置解析

在高可靠场景使用kafka作为消息队列时，要求即使有Broker宕机也不能出现消息丢失。为了实现这一目的，很多人都知道要将producer的ack设置成all或-1。然而除了Producer的配置外还有两个服务端配置也会影响宕机时的消息可靠性，分别是min.insync.replicas和unclean.leader.election.enable。本文将描述这两个配置如何影响可靠性，以及推荐配置。

1. min.insync.replicas

min.insync.replicas使用默认配置1，该参数规定了Kafka Partition的最小同步副本。如果当前同步副本数小于该值，则Producer不能向该Partition中生产消息。

min.insync.replicas配置为1，只要副本Leader可用即可写消息，在如下场景存在数据丢失风险：

假设Partition 3个副本中，两个副本未处于同步状态，如下图所示：

此时，如果副本1所在节点故障，副本2或副本3升为Leader，Leader切换后，消息记录以新Leader为准，未同步的第6,7,8条数据将会丢失，如下图所示：

2. unclean.leader.election.enable

unclean.leader.election.enable使用默认配置true，该参数规定是否允许非ISR的副本成为Leader。在min.insync.replicas配置值大于1的前提下，unclean.leader.election.enable配置为true，如下场景仍有数据丢失风险：假设partition有3副本，min.insync.replicas配置为2，副本1和副本2处于同步状态，副本3处于未同步状态，如下图所示：

当副本1和副本2同时故障，unclean.leader.election.enable配置为true，允许处于非同步状态的副本3升为Leader，副本1和副本2恢复后，消息记录以新Leader为准，副本1、副本2上的消息6,7,8将丢失，如下图所示：

3. 建议配置

配置Topic副本数为3，min.insync.replicas为2，unclean.leader.election.enable为false，Producer ack配置为all。可以保证极端情况下即使1个Broker宕机也不会出现数据丢失。