消息中间件（消息队列）关键知识点总结

 

一、什么是消息队列？

消息队列，是分布式系统中重要的组件。

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

目前主流的消息队列有

• Kafka
• RabbitMQ
• RocketMQ ，老版本是 MetaQ 。
• ActiveMQ ，目前用的人越来越少了。

另外，消息队列容易和 Java 中的本地 MessageQueue 搞混，所以消息队列更多被称为消息中间件、分布式消息队列等等。

二、消息队列由哪些角色组成？

如下图所示：

MQ 角色

• 生产者（Producer）：负责产生消息。
• 消费者（Consumer）：负责消费消息
• 消息代理（Message Broker）：负责存储消息和转发消息两件事情。其中，转发消息分为推送和拉取两种方式。
  • 拉取（Pull），是指 Consumer 主动从 Message Broker 获取消息
  • 推送（Push），是指 Message Broker 主动将 Consumer 感兴趣的消息推送给 Consumer 。

三、主流消息中间件及选型

首先，产品应该是开源的。开源意味着如果队列使用中遇到bug，可以很快修改，而不用等待开发 者的更新。 其次，产品必须是近几年比较流行的，要有一个活跃的社区。这样遇到问题很快就可以找到解决方 法。同时流行也意味着bug较少。流行的产品一般跟周边系统兼容性比较好。

最后，作为消息队列，要具备以下几个特性：

1. 消息传输的可靠性：保证消息不会丢失。
2. 支持集群，包括横向扩展，单点故障都可以解决。
3. 性能要好，要能够满足业务的性能需求。

四、Kafka、RabbitMQ、RocketMQ 有什么优缺点？

RabbitMQ

RabbitMQ开始是用在电信业务的可靠通信的，也是少有的几款支持AMQP协议的产品之一。

优点

• 1. 轻量级，快速，部署使用方便
• 2. 支持灵活的路由配置。RabbitMQ中，在生产者和队列之间有一个交换器模块。根据配置的路 由规则，生产者发送的消息可以发送到不同的队列中。路由规则很灵活，还可以自己实现。
• 3. RabbitMQ的客户端支持大多数的编程语言。

缺点

• 1. 如果有大量消息堆积在队列中，性能会急剧下降
• 2. RabbitMQ的性能在Kafka和RocketMQ中是最差的，每秒处理几万到几十万的消息。如果应 用要求高的性能，不要选择RabbitMQ。
• 3. RabbitMQ是Erlang开发的，功能扩展和二次开发代价很高。

RocketMQ

RocketMQ是一个开源的消息队列，使用java实现。借鉴了Kafka的设计并做了很多改进。 RocketMQ主要用于有序，事务，流计算，消息推送，日志流处理，binlog分发等场景。经过了历次的双11考验，性能，稳定性可可靠性没的说。

RocketMQ几乎具备了消息队列应该具备的所有特性和功能。

java开发，阅读源代码、扩展、二次开发很方便。

对电商领域的响应延迟做了很多优化。在大多数情况下，响应在毫秒级。如果应用很关注响应时 间，可以使用RocketMQ。

性能比RabbitMQ高一个数量级，每秒处理几十万的消息

缺点：

跟周边系统的整合和兼容不是很好。

Kafka

Kafka的可靠性，稳定性和功能特性基本满足大多数的应用场景。

跟周边系统的兼容性是数一数二的，尤其是大数据和流计算领域，几乎所有相关的开源软件都支持 Kafka。

Kafka高效，可伸缩，消息持久化。支持分区、副本和容错。

Kafka是Scala和Java开发的，对批处理和异步处理做了大量的设计，因此Kafka可以得到非常高的 性能。它的异步消息的发送和接收是三个中最好的，但是跟RocketMQ拉不开数量级，每秒处理几十万 的消息。

如果是异步消息，并且开启了压缩，Kafka最终可以达到每秒处理2000w消息的级别。

但是由于是异步的和批处理的，延迟也会高，不适合电商场景。

五、 消息中间件应用场景

一般来说，有四大类使用场景：

• 应用解耦
• 异步处理
• 流量削峰
• 消息通讯
• 日志处理

其中，应用解耦、异步处理是比较核心的。

 

电商秒杀案例：

比如6.18，活动从0:00开始，仅限前 200 名，秒杀即将开始时，用户会疯狂刷新 APP或者浏览器来 保证自己能够尽早的看到商品。

• 当秒杀开始前，用户在不断的刷新页面，系统应该如何应对高并发的读请求呢？
• 在秒杀开始时，大量并发用户瞬间向系统请求生成订单，扣减库存，系统应该如何应对高并发 的写请求呢？

系统应该如何应对高并发的读请求

• 使用缓存策略将请求挡在上层中的缓存中
• 能静态化的数据尽量做到静态化
• 加入限流（比如对短时间之内来自某一个用户，某一个IP、某个设备的重复请求做丢弃处理）

系统应该如何应对高并发的写请求

生成订单，扣减库存，用户这些操作不经过缓存直达数据库。如果在 1s内，有 1 万个数据连接同 时到达，系统的数据库会濒临崩溃。如何解决这个问题呢？我们可以使用 消息队列。

  消息队列的作用：

• 削去秒杀场景下的峰值写流量——流量削峰
• 通过异步处理简化秒杀请求中的业务流程——异步处理
• 解耦，实现秒杀系统模块之间松耦合——解耦

削去秒杀场景下的峰值写流量

将秒杀请求暂存于消息队列，业务服务器响应用户“秒杀结果正在处理中。。。”，释放系统资源去 处理其它用户的请求。

削峰填谷，削平短暂的流量高峰，消息堆积会造成请求延迟处理，但秒杀用户对于短暂延迟有一定容忍度。

秒杀商品有 1000 件，处理一次购买请求的时间是 500ms，那么总共就需要 500s 的时间。这时你 部署 10 个队列处理程序，那么秒杀请求的处理时间就是 50s，也就是说用户需要等待 50s 才可以看到 秒杀的结果，这是可以接受的。这时会并发 10 个请求到达数据库，并不会对数据库造成很大的压力。

通过异步处理简化秒杀请求中的业务流程

先处理主要的业务，异步处理次要的业务，如主要流程是生成订单、扣减库存；次要流程比如购买成功之后会给用户发优惠券，增加用户的积 分。 此时秒杀只要处理生成订单，扣减库存的耗时，发放优惠券、增加用户积分异步去处理了。

解耦，实现秒杀系统模块之间松耦合

将秒杀数据同步给数据团队，有两种思路：

• 1. 使用 HTTP 或者 RPC 同步调用，即提供一个接口，实时将数据推送给数据服务。 系统的耦合度高，如果其中一个服务有问题，可能会导致另一个服务不可用。
• 2. 使用消息队列 将数据全部发送给消息队列，然后数据服务订阅这个消息队列，接收数据进行处理。

五、面试题精选

1、如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？

消息积压处理办法：临时紧急扩容：

先修复 consumer 的问题，确保其恢复消费速度，然后将现有 cnosumer 都停掉。
新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。
然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消息。
MQ中消息失效：假设你用的是 RabbitMQ，RabbtiMQ 是可以设置过期时间的，也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq 里，而是大量的数据会直接搞丢。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去，把白天丢的数据给他补回来。也只能是这样了。假设 1 万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。

mq消息队列块满了：如果消息积压在 mq 里，你很长时间都没有处理掉，此时导致 mq 都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。

2、如何保证消息不被重复消费？或者说，如何保证消息消费时的幂等性？

先说为什么会重复消费：正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除；

但是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者。

针对以上问题，一个解决思路是：保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影响；保证消息等幂性；

比如：在写入消息队列的数据做唯一标示，消费消息时，根据唯一标识判断是否消费过；

假设你有个系统，消费一条消息就往数据库里插入一条数据，要是你一个消息重复两次，你不就插入了两条，这数据不就错了？但是你要是消费到第二次的时候，自己判断一下是否已经消费过了，若是就直接扔了，这样不就保留了一条数据，从而保证了数据的正确性。