当我试图用一则通俗的比喻来说明这个概念的时候，我想到一个有意思的比喻：如果把队列抽象成一个集合体，那么消息队列也就是一堆消息的集合。按照这个思路我想到了「杂志」。这不就是一堆消息的集合吗，关心这些消息的人都能通过「购买」来获得这些消息，而我可以通过不同种类的「杂志」或许到不同的消息。并且如果我作为出版方，我可以提供所有出版过的「杂志」，也可以选择让读者只能购买近期的。
二、为什么需要消息队列？ 好处一：解耦假设我们做了一个会议室预定系统，我们的一个设备坏了。我们需要通知预定这个会议室的所有人，于是我们需要发邮件，伪代码如下：
@Service public class EquipmentServiceImpl implements EquipmentService { @Autowired private EmailService emailService; @Autowired private EquipmentRepository equipmentRepository; public void setEquipmentBroken(Long id) { Equipment equipment = equipmentRepository.findById(id); equipment.setStatus(Equipment.StatusEnum.BROKEN); emailService.sendEmail(); } }问题来了，如果我们后来发现设备坏了并且需要更改可用库存的数量，这时候我们是不是要在这里加入 InventoryService 库存服务的代码呢？后来如果经理说设备坏了应该通知他才对啊，所以我们要不要加入 emailService.sendEmailTo(Manager) 这样的代码呢？
随着我们业务模块接入越来越多，我们的代码与其他模块越来越耦合，修改代码的难度也指数级的增加，所以我们引入「消息队列」，把「设备坏了」这样的消息发送到队列中，其他关心这条消息的业务就会得到这样的「通知」，然后就会去做对应的事，这样各个模块之间就解耦了。伪代码看上去如下：
public void setEquipmentBroken(Long id) { Equipment equipment = equipmentRepository.findById(id); equipment.broken(); eventBus.publish(new EquipmentBrokenEvent(equipment.id)); } 好处二：异步处理接着上面的例子，假设我们已经把「发送邮件」、「修改库存」以及「通知经理」的代码都写入了我们的 Service 代码中，它们分别耗时：30ms、50ms、80ms，并且我们得知，原本最主要的功能其实是「发送邮件」，但我们完成主要的功能之后却等待了更多的额外时间，这显示是不合理的。
所以我们为了提高用户体验&提高吞吐量，我们其实可以引入「消息队列」来进行异步的操作。
好处三：削峰/限流
假设我们的服务器最多能支持每秒 1000 个请求，而我们公司在节日要搞促销，为了避免服务器挂掉我们额外申请了两台服务器做了负载均衡，于是我们现在的机器最理想的情况能够支持每秒 3000 个请求，但奈何活动太火爆了，每秒来的请求有大概 4000 个，这些多出来的请求就可能导致服务器给直接挂掉了。
所以我们就引入了一个「消息队列」，让消息不直接到达服务器，而是先让「消息队列」保存这些数据，然后让下面的服务器每一次都取各自能处理的请求数再去处理，这样当请求数超过服务器最大负载时，就不至于把服务器搞挂了。
三、消息队列适用的场景基于上面的描述，我们大概能想到「消息队列」的局限性，例如当「生产者」需要「从消费者获得反馈」时，就会出现一定的问题。例如我之前尝试着使用「事件驱动」的方式编码时，我想要把 Service 的一些主逻辑给转移到关注该事件的监听器上时，发现有点问题，我原本的意图是想让一部分代码解耦，但作为主逻辑的一部分我需要保证它们准确的执行，当我使用「消息」的方式传递出去时，我无法得到消费者的反馈，所以最终我还是把主逻辑给迁回来了，算是一次失败的尝试吧。
场景一：异步处理通过上述的问题你也看到了，「消息队列」适用于异步处理，并且是那些不期望从消费者得到反馈的处理。就好像一开始说到的设备坏了的问题，我只需要通知设备坏了，至于之后需要做什么事，关心的人自然会去做相应的处理。
场景二：日志收集