MQ系列（五）| Kafka 快速入门

合集 - 消息队列(7)

1.MQ系列（六）| RocketMQ 快速入门2024-12-132.MQ系列（七）| RocketMQ 为什么性能不如Kafka?2024-12-14

3.MQ系列（五）| Kafka 快速入门2024-12-13

4.MQ系列（四）| RabbitMQ 死信队列和延迟队列2024-12-125.MQ系列（一）| RabbitMQ 快速入门2024-12-076.MQ系列（三）| RabbitMQ 消息确认机制2024-12-107.MQ系列（二）| RabbitMQ 整合 SpringBoot2024-12-09

收起

Kafka 快速入门介绍

参考：Kafka 是什么？

架构

一个高性能，高扩展性，高可用，支持持久化的超强消息队列，它就是我们常说的消息队列 Kafka
Zookeeper 协调管理多个 broker 组成，内部有多个 topic 分类，每个 topic 又分成多个 partition ，每个 partition 有多个副本 replia，不同的partition 会分布在不同 broker 上，提升性能同时，还增加了系统可用性和可扩展性

高性能

对消息进行分类，每个类是一个 topic

单个 topic 的消息可能过多，可将单个队列拆分成多个段，每段就是一个分区 partition ，每个消费者负责一个 partition

高扩展性

可将 partition 分部在多台设备，每台设备代表一个 broker

高可用

存在一个问题，如果其中一个partition所在的 broker 挂了，那么这部分的消息不久丢失了吗？

可以给partition 多加几个副本 replica，从中分为 Leader 和 Follower，Leader 负责生产者和消费者的读写，Follower 负责同步数据

将Leader 和 Follower 分散在不同的 broker 上，这样如果 Leader所在的broker 挂了，也不影响 Follower所在的broker，还能从 Followe 选举新的Leader partition 顶上

持久化过期策略

假设所有 broker 都挂了，那岂不是数据全丢了？
为了解决这个问题，我们不能光把数据放内存里，还要持久化到磁盘中，这样哪怕全部 broker 都挂了，数据也不会全丢，重启服务后，也能从磁盘里读出数据，继续工作。

磁盘总是有限的，提供保留策略 retention policy，数据超过大小或者时间清理掉

消费者组 Comsumer Group

• 每次新增的消费者只能跟着最新的消费 Offset 接着消费
• 哪怕 B 服务有多个实例，但本质上，它只有一个消费业务方，新增实例一般也是接着之前的 offset 继续消费
• 假设现在来了个新的业务方，C 服务，它想从头开始消费消息队列里的数据，这时候就不能跟在 B 服务的 offset 后边继续消费了

消息队列加入消费者组（consumer group）的概念，B 和 C 服务各自是一个独立的消费者组，不同消费者组维护自己的消费进度，互不打搅

Zookeeper

ZooKeeper 组件。它会定期和 broker 通信，获取 整个 kafka 集群的状态，以此判断 某些 broker 是不是跪了，某些消费组消费到哪了。

kafka 的应用场景

消息队列是架构中最常见的中间件之一，使用场景之多，堪称万金油！

• 削峰填谷：上游流量忽高忽低，想要提升 cpu/gpu 利用率
• 降低系统耦合： 系统过大，消息流向盘根错节，想要拆解组件
• 保护服务：再比如秒杀活动，请求激增，保护服务尽量不影响用户

总结

• kafka 是消息队列，像消息队列投递消息的是生产者，消费消息的是消费者。增加生产者和消费者的实例个数可以提升系统吞吐。多个消费者可以组成一个消费者组，不同消费者组维护自己的消费进度，互不打搅。
• kafka 将消息分为多个 topic，每个 topic 内部拆分为多个 partition，每个 partition 又有自己的副本，不同的 partition 会分布在不同的 broker 上，提升性能的同时，还增加了系统可用性和可扩展性。