你是一个程序员，假设你维护了两个服务 A 和 B。 B 服务每秒只能处理 100 个消息，但 A 服务却每秒发出 200 个消息，B 服务哪里顶得住，分分钟被压垮。 那么问题就来了，有没有办法让 B 在不被压垮的同时，还能处理掉 A 的消息？ 当然有，没有什么是加一层中间层不能解决的，如果有，那就再加一层。 这次我们要加的中间层是 消息队列 Kafka。

什么是消息队列

为了保护 B 服务，我们很容易想到可以在 B 服务的内存中加入一个队列。

说白了，它其实是个链表，链表的每个节点就是一个消息。每个节点有一个序号，我们叫它 Offset，记录消息的位置。 B 服务依据自己的处理能力，消费链表里的消息。能处理多少是多少，不断更新已处理 Offset 的值。

但这有个问题，来不及处理的消息会堆积在内存里，如果 B 服务更新重启，这些消息就都丢了。 这个好解决，将队列挪出来，变成一个单独的进程。就算 B 服务重启，也不会影响到了队列里的消息。

这样一个简陋的队列进程，其实就是所谓的消息队列。 而像 A 服务这样负责发数据到消息队列的角色，就是生产者，像 B 服务这样处理消息的角色，就是消费者。

但这个消息队列属实过于简陋，像什么高性能，高扩展性，高可用，它是一个都不沾。 我们来看下怎么优化它。

高性能

B 服务由于性能较差，消息队列里会不断堆积数据，为了提升性能，我们可以扩展更多的消费者, 这样消费速度就上去了，相对的我们就可以增加更多生产者，提升消息队列的吞吐量。

随着生产者和消费者都变多，我们会发现它们会同时争抢同一个消息队列，抢不到的一方就得等待，这不纯纯浪费时间吗！ 有解决方案吗？有！ 首先是对消息进行分类，每一类是一个 topic，然后根据 topic 新增队列的数量，生产者将数据按 topic 投递到不同的队列中，消费者则根据需要订阅不同的 topic。这就大大降低了 topic 队列的压力。

但单个 topic 的消息还是可能过多，我们可以将单个队列，拆成好几段，每段就是一个 partition 分区，每个消费者负责一个 partition。 这就大大降低了争抢，提升了消息队列的性能。

高扩展性

随着 partition 变多，如果 partition 都在同一台机器上的话，就会导致单机 cpu 和内存过高，影响整体系统性能。

于是我们可以申请更多的机器，将 partition 分散部署在多台机器上，这每一台机器，就代表一个 broker。我们可以通过增加 broker 缓解机器 cpu 过高带来的性能问题。

高可用

到这里，其实还有个问题，如果其中一个 partition 所在的 broker 挂了，那 broker 里所有 partition 的消息就都没了。这高可用还从何谈起？ 有解决方案吗？ 有，连你喜欢的女生都知道手机里多聊几个沸羊羊，你却不知道要给 partition 加备胎吗？ 我们可以给 partition 多加几个副本，也就是 replicas，将它们分为 Leader 和 Follower。Leader 负责应付生产者和消费者的读写请求，而 Follower 只管同步 Leader 的消息。

将 Leader 和 Follower 分散到不同的 broker 上，这样 Leader 所在的 broker 挂了，也不会影响到 Follower 所在的 broker, 并且还能从 Follower 中选举出一个新的 Leader partition 顶上。这样就保证了消息队列的高可用。

持久化和过期策略

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

但问题又来了，磁盘总是有限的，这一直往里写数据迟早有一天得炸。 所以我们还可以给数据加上保留策略，也就是所谓的 retention policy，比如磁盘数据超过一定大小或消息放置超过一定时间就会被清理掉。

consumer group

到这里，这个消息队列好像就挺完美了。但其实还有个问题，按现在的消费方式，每次新增的消费者只能跟着最新的消费 Offset 接着消费。 如果我想让新增的消费者从某个 Offset 开始消费呢？ 听起来这个需求很刁钻？我举个例子你就明白了。

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

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

ZooKeeper

相信你也发现了，组件太多了，而且每个组件都有自己的数据和状态，所以还需要有个组件去统一维护这些组件的状态信息，于是我们引入 ZooKeeper 组件。它会定期和 broker 通信，获取 整个 kafka 集群的状态，以此判断 某些 broker 是不是跪了，某些消费组消费到哪了。

Kafka 是什么

好了，到这里，当初那个简陋的消息队列，就成了一个高性能，高扩展性，高可用，支持持久化的超强消息队列，没错，它就是我们常说的消息队列 Kafka，上面涉及到各种概念，比如 partition 和 broker 什么的，都出自它。

kafka 的应用场景

消息队列是架构中最常见的中间件之一，使用场景之多，堪称万金油！ 比如上游流量忽高忽低，想要削峰填谷，提升 cpu/gpu 利用率，用它。 又比如系统过大，消息流向盘根错节，想要拆解组件，降低系统耦合，还是用它。 再比如秒杀活动，请求激增，想要保护服务的同时又尽量不影响用户，还得用它。 当然，凡事无绝对，方案还得根据实际情况来定，做架构做到最后，都是在做折中。

总结

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