不积跬步，无以至千里；不积小流，无以成江海。
码字不易，点赞再看。
消息队列 在互联网技术存储方面使用如此广泛，最经典的使用场景无外乎 异步、削峰、解耦。
异步
平时我们场景里有很多步骤都是在一个流程里面需要做完的，就比如说我的订单系统吧，如果我们的业务简单，用户下单付款成功后，流程就走完了。
但是后来产品经理要求加个 积分系统，ok 问题不大，流程里多200ms去做这件事情。
接着又有产品经理要求加 消息通知，加吧，流程里又多了100ms做这件事。
再后来产品经理又要求加 优惠券系统， 行吧，咬着牙加上，又多了100ms干这件事情。
再后来。。。。
像这样：
随着需求的提出，这里的耗时越来越严重，什么垃圾系统，严重影响了用户体验，用户都流失了。
其实我们发现上面的众多流程可以 同步做，你支付成功后，推送消息的时候，我也可以同时发优惠券，加积分的对吧。这里就用到了 异步
像这样子最多就用100ms
解藕
一个订单流程，扣积分，扣优惠券，发消息，扣库存。。。等等这么多业务就要调用这么多的接口，每加一个你要调用一个接口 然后还要重新发布系统。
而且真的全部都写在一起的话，不单单是耦合这一个问题，出问题排查也麻烦，流程里面随便一个地方出问题搞不好会影响到其他的点。
如果这样做：当你把支付成功的消息告诉别的系统，他们收到了去处理就好了，你只用走完自己的流程，把自己的消息发出去，那后面要接入什么系统简单，直接订阅你发送的支付成功消息即可。这样即使新加的系统出现问题也不会影响主流程。是不是很赞!
当然这样有可能会涉及到 分布式事务，后续继续介绍。
削峰
拿个接触最多的秒杀例子，平时流量很低，但是你要到活动时间 00 ：00 的时候流量疯狂怼进来，你的服务器，Redis，MySQL 各自的承受能力都不一样，全部流量照单全收肯定有问题啊，直接就打挂了
简单点，把请求放到队列里面，然后至于每秒消费多少请求，就看自己的服务器处理能力，你能处理5000QPS你就消费这么多，可能会比正常的慢一点，但是不至于打挂服务器，等流量高峰下去了，你的服务也就没压力了。
你看淘宝双十一这么多流量瞬间涌进去，他有时候是不是会慢一点，但是人家没挂啊，或者降级给你个友好的提示页面。
主流MQ
目前在市面上比较主流的消息队列中间件主要有，Kafka、ActiveMQ、RabbitMQ、RocketMQ 等这几种。
弄张网图做个比较：
单从 吞吐量 后两个已经完爆前两个，所以现在用的最多的也是后两个。
从部署方式来谈前两者也是大不如后面两个 天然分布式架构，都是 高可用 的分布式架构，而且数据多个副本的数据也能做到0丢失。
比如 某星出绯闻了，没点高吞吐的中间件拿什么推 等着拖挂服务器 拎包走人吗
谈一谈 redis 充当MQ
对于那些只有一组消费者的消息队列，使用 Redis 就可以非常轻松的搞定。Redis 的消息队列虽不是专业的消息队列，它没有非常多的高级特性，没有 ack 保证，如果对消息的可靠性有着极致的追求，那么它就不适合使用。请慎重选择。
Redis 的 list(列表) 数据结构常用来作为异步消息队列使用，使用 rpush/lpush 操作入队列，使用 lpop / rpop 来出队列。
客户端是通过队列的 pop 操作来获取消息，然后进行处理。处理完了再接着获取消息，再进行处理。如此循环往复，这便是作为队列消费者的客户端的生命周期。
可是如果队列空了，客户端就会陷入 pop 的死循环，不停地 pop，没有数据，接着再 pop，又没有数据。这就是浪费生命的空轮询。空轮询不但拉高了客户端的 CPU，redis 的 QPS 也会被拉高，如果这样空轮询的客户端有几十来个，Redis 的慢查询可能会显著增多。
那么有没有办法解决这个问题呢？ 使用 blpop/brpop。
这两个指令的前缀字符b代表的是blocking，也就是 阻塞读。
阻塞读在队列没有数据的时候，会立即进入休眠状态，一旦数据到来，则立刻醒过来。消息的延迟几乎为零。用blpop/brpop替代前面的lpop/rpop。
点关注 不迷路
以上就是这篇的全部内容，能看到这里的都是 人才 。
如果你从本篇内容有收获，求 点赞，求 关注，求 转发 ，让更多的人学习到。
如果本文有任何错误，请批评指教，不胜感激 ！
