关于消息队列的认知和理解

消息队列的作用

1.解耦合
2.异步处理
3.流量削峰
4.消息通讯
使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ

消息队列的应用场景

一.解耦合

假使现在有个订单系统和库存系统：应用场景是用
户下单后----》通知库存系统，传统做法是订单系统调用库存系统的接口

• 假如库存系统无法访问，那么就导致了订单系统下单失败，如何解决上述问题呢，如图：
  
• 订单系统下单后，将消息发送给消息队列，返回用户下单成功
• 库存系统获取下单信息进行库存操作
• 假如在下单时，库存系统崩坏，那么订单系统不会受到影响，可以正常使用，实现了订单系统与库存系统的解耦合。

二.异步处理

用户在注册成功后，需要发送注册短信和注册邮件，如图：

1.将注册消息写入数据库，先发送邮件，再发送注册短信。任务全部完成后返回数据给客户端

2.将注册消息写入数据库后，利用并发处理将注册邮件和短信一起发送，完成任务后，返回给客户端。用户得到的响应时间比之前快一倍。

3.引入消息队列。如图，用户得到响应的时间也就是将注册信息写入数据库的时间（写入消息队列的时间可以忽略不计），用户得到的响应时间大大提高

三.流量削峰

最近看了一篇博客，举个最简单的例子：
在疫情期间，口罩被抢购一空，某平台推出一个口罩抢购活动，规则如下：
每天下午三点预约，晚上八点进行抢购。
该活动持续了一个周，也是见证一个百万并发量从出现问题到完善的完整过程。活动第一天，在抢购的时候，三点进行预约，已经有百万预约了，晚上八点抢购的时候估计也会有百万的并发量了，第一天抢购的时候，由于并发量太高，直接把服务器弄崩抛出异常，该平台开始维护系统，这种情况只出现在前两天，而后期再进行抢购操作的时候，虽然响应很慢，但是再也没有出现过系统崩坏的现象了。估计这里就是使用了MQ（可能之前也是使用的MQ但是这里换成了一个吞吐量级别更高的MQ）
假设数据库一次性能处理并发请求是3w条，到了晚上八点抢购的时候，每秒并发上百万。此时，使用了MQ。那么每秒有百万个请求写入了MQ，然后拉取3w请求处理，处理完再拉取…那么在客户端这边也就是等待时间长了点。这样可以缓解短时间内高流量压垮应用，也可以控制活动的人数。

四.消息通讯

P2P模式相信大家都不陌生：
其中配p2p模式中包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。如图：

• 在此模式中，每个消息只有一个消费者（一旦被消费那么消息就不存在消息队列中）
• 发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列
• 接收者在成功接收消息之后需向队列应答成功
• 如果希望在成功接收消息后需向队列应答成功

MQ的缺点

缺点：

• ①系统可用性降低：本来没什么问题，比如异步处理来说，本来异步请求虽然慢但是如果一个系统挂掉，另一个可以同步不会受到牵连。但是加上MQ以后如果MQ挂掉，那么两个系统都会收到牵连
• ②系统复杂程度提高：非要加个MQ进来，如何保证没有重复消费呢？如何处理消息丢失的情况？怎么保证消息传递的顺序？问题太多。
• ③一致性的问题：
  所以。消息队列其实是一套非常复杂的架构，你在享受MQ带来的好处的同时，也要做各种技术方案把MQ带来的一系列的问题解决掉，等一切都做好之后，系统的复杂程度硬生生提高了一个等级。

推荐MQ的使用

• 一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；
• 后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他，对公司而言，几乎处于不可控的状态，但是确实人是开源的，比较稳定的支持，活跃度也高；
• 不过现在确实越来越多的公司，会去用RocketMQ，确实很不错，但是我提醒一下自己想好社区万一突然黄掉的风险，对自己公司技术实力有绝对自信的，我推荐用RocketMQ，否则回去老老实实用RabbitMQ吧，人是活跃开源社区，绝对不会黄
• 所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择
• 如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范
• 本文章记录作者对MQ的理解，如有侵权，请告知删除