在现实生活中，并不是所有消息都是生产了之后就立马投递给消费者。比如你定了杯奶茶，但是不想商家立马配送，而是想中午再让商家派送。

那么问题来了，有没有解决方案呢？

当然有，没有什么是一个中间层解决不了的，如果有，那就再加一层。

解决这样问题的中间件就是-RocketMQ。

image::mq/image-2024-09-26-15-20-11-076.png[]

=== RocketMQ是什么？

RocketMQ是阿里自研的国产消息队列，目前已经是Apache的顶级项目，和其他消息队列一样，它接收来自生产者的消息，将消息分类，每一个类都是一个topic，消费者根据需要订阅topic，获取里面的消息。

image::mq/image-2024-09-26-16-41-58-161.png[]

很像kafka，因为RocketMQ很多功能就是借鉴的kafka，那么问题很自然就来了，既然RocketMQ借鉴了kafka又很多功能都相同，那他们之间的区别又是什么呢？

=== RocketMQ

如果主备分区在同一台主机上，那么这台主机挂了还是会导致该分区不可用，我们可以将副本放到和分区的主在不同的主机上，这样就能有效避免因为一条主机挂掉导致该分区直接不可用的情况，只有这样才是真正实现了高可用。

.主备在不同主机上

image::mq/image-2024-09-26-10-28-56-757.png[]

当副本在不同主机上之后，如果原先的分区挂了，那么会在副本Follower所在的分区选举出一个新的主分区Leader partition，这样就实现了消息的灾备，保证了消息队列的高可用性。

.灾备实现

image::mq/image-2024-09-26-10-31-00-800.png[]

=== 持久化和过期策略

当消息队列的分区都有灾备时，那么单个主机的挂掉不会影响消息队列的高可用性，但是如果所有的broker都挂了，那么原先保存在消息队列中的消息就会全部都丢失了。为了解决这个问题我们不能只把数据存储到内存里，还要持久化到磁盘中，这样哪怕所有的broker都挂了，数据也不会丢失，系统重启之后，消息队列能从磁盘中读出数据，继续工作。

.分区数据持久化

image::mq/image-2024-09-26-10-44-03-437.png[]

持久化之后消息队列就不再惧怕主机挂了或者重启了，但是新的问题又来了。随着消息队列的运行，持久化的数据越来越多，有一天终于把所有磁盘空间都占用了，这样依然会导致消息队列不可用，所以我们需要对数据添加保留策略，也就是所谓的retention policy，用来决定哪些数据能保留哪些数据能删除，比如磁盘数据超过一定大小开始删除，或者消息放置一段时间之后会被清理掉。

=== consumer group

到这里，消息队列针对广播消费已经接近完美了，但是还有一个问题，假如A和B两个人来完成老板安排的任务，那么同一个任务只需要交个一个人完成就行了，另外一个人去完成其他任务，只有这样才能达到资源的最优比。消息队列中也需要引入消费者组的概念，只要A和B是同一个组的，那么在消费消息时同一个消息只会有一个收到。这样消息队列只需要按照消费者组来保存消费者偏移量，就能保证各个消费者组内消息不重复也不会丢失。

加入消费者组（consumer group）的概念之后，不同消费者组维护自己的消费进度，互不打搅。

.消费者组

image::mq/image-2024-09-26-11-49-35-412.png[]

=== zookeeper

节点和组件太多，可以使用zookeeper组件来管理数据和状态，他会定期和broker进行通讯，以此判断某些broker是不是跪了，某些消费到哪里了。

image::mq/image-2024-09-26-14-19-34-857.png[]

到了这里一个简陋的消息队列已经成为一个高性能、高扩展性、高可用，并且支持持久化的消息队列，这个就是我们所熟知的kafka，partition以及broker等相关概念都是出自于kafka。

image::mq/image-2024-09-26-14-39-01-956.png[]

=== kafka应用场景

开篇就说了消息队列主要的作用就是削峰填谷以及异步解耦，消息队列是异步场景中最常用的中间件之一，也被称为分布式万金油，比如上流空间流量忽高忽低，想要削峰填谷，提升cpu/gpu的利用率，用它。系统比较庞大，消息流向盘根错节，想要拆解组件降低系统耦合性，用它。秒杀活动，请求激增，想要保护服务的同时又不影响用户，还得用它。当然凡事无绝对，具体方案还是得根据具体情况而定，做架构做到最后，就是在做折中。

=== 总结

• kafka 是消息队列，像消息队列投递消息的是生产者，消费消息的是消费者。增加生产者和消费者的实例个数可以提升系统吞吐。多个消费者可以组成一个消费者组，不同消费者组维护自己的消费进度，互不打搅。

• kafka 将消息分为多个 topic，每个 topic 内部拆分为多个 partition，每个 partition 又有自己的副本，不同的 partition 会分布在不同的 broker 上，提升性能的同时，还增加了系统可用性和可扩展性。