Kafka 副本和集群

在生产环境中，Kafka 总是以“集群+分区”方式运行的，以保证可靠性和性能。下面是一个3副本的 Kafka 集群实例。

首先，需要启动3个 Kafka Broker，Broker 的配置文件分别如下，

broker.id=0
listeners=PLAINTEXT://192.168.232.23:9092
log.dirs=/tmp/kafka-logs
broker.id=1
listeners=PLAINTEXT://192.168.232.23:9093
log.dirs=/tmp/kafka-logs-1
broker.id=1
listeners=PLAINTEXT://192.168.232.23:9094
log.dirs=/tmp/kafka-logs-2

虽然每个 Broker 只配置了一个端口，实际上，Kafka 会多占用一个，可能是用来 Broker 之间的复制的。另外，3个 Broker 都配置了，

zookeeper.connect=localhost:2181
delete.topic.enable=true

在同一个 Zookeeper 上的 Broker 会被归类到一个集群中。注意，这些配置中并没有指定哪一个 Broker 是主节点，哪些 Broker 是从节点，Kafka 采用的办法是从可选的 Broker 中，选出每个分区的 Leader。也就是说，对某个 Topic 来说，可能0节点是 Leader，另外一些 Topic，可能1节点是 Leader；甚至，如果 topic1 有2个分区的话，分区1的 Leader 是0节点，分区2的 Leader 是1节点。

这种对等的设计，对于故障恢复是十分有用的，在节点崩溃的时候，Kafka 会自动选举出可用的从节点，将其升级为主节点。在崩溃的节点恢复，加入集群之后，Kafka 又会将这个节点加入到可用节点，并自动选举出新的主节点。

实验如下，先新建一个3副本，2分区的 Topic，

bin/kafka-topics.sh --create --zookeeper 192.168.232.23:2181 --replication-factor 3 --partitions 2 --topic topic1

初始状况下，topic1 的状态如下，

$ bin/kafka-topics.sh --describe --zookeeper 192.168.232.23:2181 --topic topic1
Topic:topic1    PartitionCount:2        ReplicationFactor:3     Configs:
        Topic: topic1   Partition: 0    Leader: 0       Replicas: 0,1,2 Isr: 0,1,2
        Topic: topic1   Partition: 1    Leader: 1       Replicas: 1,2,0 Isr: 1,2,0

对于上面的输出，即使没有文档，也可以看懂大概：topic1 有2个分区，Partition 0 和 Partition 1，Leader 分别在 Broker 0 和 1。Replicas 表示副本在哪些 Broker 上，Isr（In-Sync Replicas）表示处于同步状态中的 Broker，如果有 Broker 宕机了，那么 Replicas 不会变，但是 Isr 会仅显示没有宕机的 Broker，详见下面的实验。

然后分2个线程，运行之前写的 Producer 和 Consumer 的示例代码，Producer 采用异步发送，消息采用同步复制。在有消息传送的情况下，kill -9 停掉其中2个 Broker（Broker 0 和 Broker 1），模拟突然宕机。此时，topic1 状态如下，

$ bin/kafka-topics.sh --describe --zookeeper 192.168.232.23:2181 --topic topic1
Topic:topic1    PartitionCount:2        ReplicationFactor:3     Configs:
        Topic: topic1   Partition: 0    Leader: 2       Replicas: 0,1,2 Isr: 2
        Topic: topic1   Partition: 1    Leader: 2       Replicas: 1,2,0 Isr: 2

可见，Kafka 已经选出了新的 Leader，消息传送没有中断。接着再启动被停掉的那两个 Broker，并查看 topic1 的状态，如下，

$ bin/kafka-topics.sh --describe --zookeeper 192.168.232.23:2181 --topic topic1
Topic:topic1    PartitionCount:2        ReplicationFactor:3     Configs:
        Topic: topic1   Partition: 0    Leader: 2       Replicas: 0,1,2 Isr: 2,1,0
        Topic: topic1   Partition: 1    Leader: 2       Replicas: 1,2,0 Isr: 2,1,0
$ bin/kafka-topics.sh --describe --zookeeper 192.168.232.23:2181 --topic topic1
Topic:topic1    PartitionCount:2        ReplicationFactor:3     Configs:
        Topic: topic1   Partition: 0    Leader: 2       Replicas: 0,1,2 Isr: 2,1,0
        Topic: topic1   Partition: 1    Leader: 1       Replicas: 1,2,0 Isr: 2,1,0

可以发现， 有一个短暂的时间，topic1 的两个分区的 Leader 都是 Broker 2，但是在 Kafka 重新选举之后，分区1的 Leader 变为 Broker 1。说明 Kafka 倾向于用不同的 Broker 做分区的 Leader，这样更能达到负载均衡的效果。

再来看看 Producer 和 Consumer 的日志，下面这个片段是2个 Broker 宕机前后的日志，