RabbitMq是一个基于erlang语言写的消息队列，是典型的生产消费者模型。关于队列，我相信大家也都熟悉，特点是有序、先进先出。而消息队列的特性有很多，最常用的莫过于：
- 解耦
假设A系统和BCD系统有业务调用，如果B系统不需要了，或者又有E系统需要对接，那A系统的负责人如何处理？BCDE随便哪个挂了是否需要存储，要不要重发？都是一大堆问题。系统之间的耦合性太强了，而MQ通过(推送-MQ-拉取)模型就很好的解决了这个问题，如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 - 削峰
像一般的电商平台，凌晨到傍晚下班前的订单量都是比较小的，但是一到了晚上7点到12点这段时间，浏览量和订单量都起来了。第二个，平时和节假日的订单量也不是一个重量级，那如何设置系统的并发量呢？按照平时的并发量，那肯定抗不过高峰期的，按照高峰期的并发量，又会平添很多成本。如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。 - 异步
再来看一个场景，A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。一般互联网类的企业，对于用户直接的 *** 作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了，爽！网站做得真好，真快！ - 延时(这个不是MQ的特性，rabbitMq具备这一特性)
有这样一个场景，一般的火车票或者机票，当下选中一个位置的时候，他会给你预占30分钟，30分钟后如果你没有支付的话他会把你订单设置为无效，恢复库存。那么问题来了，如何来判断订单30分钟后的一个状态？常规场景是定时器+扫库，大家都知道扫库是一个很耗时的 *** 作，这个定时器设置为多久支持一次呢？是否会引起数据库宕机？这些原因不可而知。好的是，rabbitMq中的死信(dead letter)就可以实现这个功能，生产者在生产的时候可以为数据指定一个过期时间，或者在rabbitMq的管理界面可以为一个队列设置一个过期时间(都存在时两者取时间较小的值)，当一个数据满足死信的要求时(1.队列未指定消费者或者消费者拒绝消费，2.数据过期，3)，即进入该队列绑定的死信队列进行二次消费，那很直白的就是将消息设置为30分钟过期，然后不指定消费者，在队列里呆满30分钟后，就进入队列绑定的死信队列进行二次消费完成消息阻塞功能（注意：死信队列的消息过期就消失了）
引入队列的缺点有：
- 1.系统可用性降低
原本只有A对B，现在A对MQ对B，多加入一个MQ，如果MQ挂了，你的系统也就呵呵了！ - 2.系统复杂度提高
消息重复消费？消息的执行顺序？消息丢失等等问题都要进行合理规划！ - 3.一致性问题
A系统放入队列就返回成功，如果BC执行成功，但是是D执行失败了呢？咋整，这数据就不一致了！
虽然如此，但是这些都是可以通过技术手段规避的，复杂度的提升，并不能代表我们不去使用一个这么多功能的系统，下面进入MQ正题，以下是他的官网和下载链接。
官网：https://www.rabbitmq.com/
下载：https://download.csdn.net/
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）