深入浅出理解基于 Kafka 和 ZooKeeper 的分布式消息队列

消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。

消息队列在电商系统、消息通讯、日志收集等应用中扮演着关键作用，以阿里为例，其研发的消息队列(MQ)服务于阿里集团超过11年，在历次天猫双十一活动中支撑了万亿级的数据洪峰，为大规模交易提供了有力保障。

目前在生产环境，使用较多的消息队列有 ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ 等。本场 Chat 将介绍基于 Kafka 和 ZooKeeper 的分布式消息队列。

本场 Chat，您将清楚以下问题：

1. Kafka，Zookeeper 是什么？
2. 基于 Kafka 和 ZooKeeper 的分布式消息队列架构是怎样的？
3. Kafka 为什么要将 Topic 进行分区？
4. 分布式消息队列中 Zookeeper 以怎样的形式存在，起什么作用？
5. 消息队列发布-订阅全流程是怎样的？

特别说明：本场Chat仅仅作为分享，不足之处，还请读者包容，谢谢

消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。

本场 Chat 主要内容：

• Kafka 的架构解读；
• Kafka 为什么要将 Topic 进行分区；
• Kafka 高可靠性实现基础解读；
• Kafka 复制原理和同步方式；
• Leader 选举机制，及如何确保新选举出的 Leader 是优选；
• 同步副本 ISR；
• Kafka 数据可靠性和持久性保证；
• 深入解读 HW 机制；
• Kafka 架构中 ZooKeeper 以怎样的形式存在；
• 全程解析：Producer -> kafka -> consumer。

相关内容链接：

1. 《分布式中间件实践之路》
2. 《Python 快速入门实战教程》
3. 《分布式锁的最佳实践之：基于 Etcd 的分布式锁》
4. 《基于 Redis 的分布式锁实现及踩坑案例》
5. 《一个高可靠性商用 Redis 集群方案介绍》

---

1. Kafka 总体架构

基于 Kafka-ZooKeeper 的分布式消息队列系统总体架构如下：

如上图所示，一个典型的 Kafka 体系架构包括若干 Producer（消息生产者），若干 broker（作为 Kafka 节点的服务器），若干 Consumer（Group），以及一个 ZooKeeper 集群。Kafka通过 ZooKeeper 管理集群配置、选举 Leader 以及在 consumer group 发生变化时进行 Rebalance（即消费者负载均衡，在下一课介绍）。Producer 使用 push（推）模式将消息发布到 broker，Consumer 使用 pull（拉）模式从 broker 订阅并消费消息。

上图仅描摹了一个总体架构，并没有对作为 Kafka 节点的 broker 进行深入刻画，事实上，它的内部细节相当复杂，如下图所示，Kafka 节点涉及 Topic、Partition 两个重要概念。

在 Kafka 架构中，有几个术语：

• Producer：生产者，即消息发送者，push 消息到 Kafka 集群中的 broker（就是 server）中；
• Broker：Kafka 集群由多个 Kafka 实例（server） 组成，每个实例构成一个 broker，说白了就是服务器；
• Topic：producer 向 kafka 集群 push 的消息会被归于某一类别，即Topic，这本质上只是一个逻辑概念，面向的对象是 producer 和 consumer，producer 只需要关注将消息 push 到哪一个 Topic 中，而 consumer 只需要关心自己订阅了哪个 Topic；
• Partition：每一个 Topic 又被分为多个 Partitions，即物理分区；出于负载均衡的考虑，同一个 Topic 的 Partitions 分别存储于 Kafka 集群的多个 broker 上；而为了提高可靠性，这些 Partitions 可以由 Kafka 机制中的 replicas 来设置备份的数量；如上面的框架图所示，每个 partition 都存在两个备份；
• Consumer：消费者，从 Kafka 集群的 broker 中 pull 消息、消费消息；
• Consumer group：high-level consumer API 中，每个 consumer 都属于一个 consumer-group，每条消息只能被 consumer-group 中的一个 Consumer 消费，但可以被多个 consumer-group 消费；
• replicas：partition 的副本，保障 partition 的高可用；
• leader：replicas 中的一个角色， producer 和 consumer 只跟 leader 交互；
• follower：replicas 中的一个角色，从 leader 中复制数据，作为副本，一旦 leader 挂掉，会从它的 followers 中选举出一个新的 leader 继续提供服务；
• controller：Kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种 failover；
• ZooKeeper：Kafka 通过 ZooKeeper 来存储集群的 meta 信息等，文中将详述。

1.1 Topic & Partition

一个 topic 可以认为是一类消息，每个 topic 将被分成多个 partition，每个 partition 在存储层面是 append log 文件。任何发布到此 partition 的消息都会被追加到log文件的尾部，每条消息在文件中的位置称为 offset（偏移量），offset 为一个 long 型的数字，它唯一标记一条消息。 Kafka 机制中，producer push 来的消息是追加（append）到 partition 中的，这是一种顺序写磁盘的机制，效率远高于随机写内存，如下示意图：

1.2 Kafka 为什么要将 Topic 进行分区？

简而言之：负载均衡 + 水平扩展。

前已述及，Topic 只是逻辑概念，面向的是 producer 和 consumer；而 Partition 则是物理概念。可以想象，如果 Topic 不进行分区，而将 Topic 内的消息存储于一个 broker，那么关于该 Topic 的所有读写请求都将由这一个 broker 处理，吞吐量很容易陷入瓶颈，这显然是不符合高吞吐量应用场景的。有了 Partition 概念以后，假设一个 Topic 被分为 10 个 Partitions，Kafka 会根据一定的算法将 10 个 Partition 尽可能均匀的分布到不同的 broker（服务器）上，当 producer 发布消息时，producer 客户端可以采用 random、key-hash 及 轮询 等算法选定目标 partition，若不指定，Kafka 也将根据一定算法将其置于某一分区上。Partiton 机制可以极大的提高吞吐量，并且使得系统具备良好的水平扩展能力。

在创建 topic 时可以在 $KAFKA_HOME/config/server.properties 中指定这个 partition 的数量（如下所示），当然可以在 topic 创建之后去修改 partition 的数量。

# The default number of log partitions per topic. More partitions allow greater# parallelism for consumption, but this will also result in more files across# the brokers.num.partitions=3

在发送一条消息时，可以指定