聊聊消息队列，通俗易懂

前言

关于消息队列，断断续续的也看了很多资料，正好所在的项目在实际业务中使用到了消息队列，今天就来简单将消息队列方面的知识梳理一下，希望对各位小伙伴有点帮助！

我们从三个方面也聊聊消息队列，什么是消息队列？消息队列的使用场景，使用消息队列有哪些弊端？

什么是消息队列

对于传统的应用程序，如果需要向另一个应用程序发送信息，只需要向其发出请求即可！

这种方式虽然简单直接，但是如果应用程序2突然挂了，应用程序1可能会因为服务异常，而无法继续提供服务！

设想一下，在应用程序1和应用程序2之间，插入一个消息服务，主要用于接受消息和发送消息，这样应用程序1和应用程序2之间的依赖关系就解耦了，同时也不会因为任何一方当服务不可用时，无法继续提供服务！

其中插入的消息服务被称为消息队列！

使用场景

异步处理

发送者将消息发送给消息队列之后，不需要同步等待消息接收者处理完毕，而是立即返回进行其它操作。消息接收者从消息队列中订阅消息之后异步处理。

例如在注册流程中通常需要发送验证邮件来确保注册用户身份的合法性，可以使用消息队列使发送验证邮件的操作异步处理，用户在填写完注册信息之后就可以完成注册，而将发送验证邮件这一消息发送到消息队列中。

只有在业务流程允许异步处理的情况下才能这么做，例如上面的注册流程中，如果要求用户对验证邮件进行点击之后才能完成注册的话，就不能再使用消息队列。

流量削锋

在高并发的场景下，如果短时间有大量的请求到达会压垮服务器。

可以将请求发送到消息队列中，服务器按照其处理能力从消息队列中订阅消息进行处理。

应用解耦

如果模块之间不直接进行调用，模块之间耦合度就会很低，那么修改一个模块或者新增一个模块对其它模块的影响会很小，从而实现可扩展性。

通过使用消息队列，一个模块只需要向消息队列中发送消息，其它模块可以选择性地从消息队列中订阅消息从而完成调用。

可靠性

发送端的可靠性

发送端完成操作后一定能将消息成功发送到消息队列中。

实现方法：在本地数据库建一张消息表，将消息数据与业务数据保存在同一数据库实例里，这样就可以利用本地数据库的事务机制。事务提交成功后，将消息表中的消息转移到消息队列中，若转移消息成功则删除消息表中的数据，否则继续重传。

接收端的可靠性

接收端能够从消息队列成功消费一次消息。

两种实现方法：

• 保证接收端处理消息的业务逻辑具有幂等性：只要具有幂等性，那么消费多少次消息，最后处理的结果都是一样的。
• 保证消息具有唯一编号，并使用一张日志表来记录已经消费的消息编号。

总结

消息队列有很多优点，但是，引入消息队列也会带来很明显的弊端：

系统可用性降低：在引入消息队列之前，你不用考虑消息丢失或者消息队列服务挂掉等等的情况，但是引入消息队列之后你就需要去考虑这些问题！

系统复杂性提高：加入消息队列之后，你需要保证消息没有被重复消费、处理消息没有被正确处理的情况等等问题！

引入消息队列虽然会带来一些问题，俗话说，兵来将挡、水来土掩，这句话同样适用于 IT 开发者，有坑填坑！

对于系统可用性降低方面，通常常用的解决方案就是搭建消息服务集群，具体技术实现上可以是主从架构或者分布式架构，即时一台消息队列服务机器挂了，也不会影响消息队列无法提供服务！

对于系统复杂性提高方面，常用的解决方案也很多，例如接受者接受到消息之后，可以先将消息写入数据库，即时没有被正确处理，还可以走人工处理，或者消息消费失败，将消息重新入队等待下一次消费等等。