消息队列作为互联网互联网项目的一个可选中间件，被很多的项目、产品采用。就算你没用过，肯定也多少了解一些，因为它是现代面试八股文必考科目之一。
消息队列这个很形象，就是把消息推到一个队列中，然后再到这个队列里读，是不是就这么简单。
图片
听说消息队列最有用的功能是异步和解耦，而什么消峰填谷、分布式事务都是锦上添花而已。
常用的消息队列
RocketMQ
RocketMQ 是阿里巴巴开发，现在已经是 Apache 软件基金会的顶级项目。RocketMQ 是用 Java 开发，很多使用 Java 技术栈的公司都用 RocketMQ 作为消息队列。我们就主要使用 RocketMQ 作为消息队列服务。
RabbitMQ
RabbitMQ 是一个开源的消息代理软件，它采用了高级消息队列协议（AMQP），用于在分布式系统中实现异步通信和消息传递，采用 Erlang 语言开发。最开始学习消息队列就是用的 RabbitMQ。
Apache Kafka
pache Kafka 是一个分布式流处理平台，最初由 LinkedIn 开发，并于2011年开源，之后成为 Apache 软件基金会的顶级项目。Kafka 旨在处理实时数据流，具有高吞吐量、低延迟和高可靠性的特点，广泛应用于日志收集、流处理、数据集成等场景。
ActiveMQ
Apache ActiveMQ 是一个开源的消息代理和集成模式服务器，由 Apache 软件基金会开发。ActiveMQ 在形式上和 RabbitMQ 比较像，ActiveMQ 也是用 Java 开发的。
除此之外，其实 Redis 也可以做消息队列。
消息队列的应用场景
消息队列最厉害的地方并不是采用的技术有多厉害，而是它的应用场景，只要把它加到某些应用场景中，有很多问题都可以迎刃而解。所以说，它厉害在思想上。
异步处理和解耦
说到异步就离不开解耦，说到解耦又脱离不了异步。
什么是异步呢？假设有个系统需要处理一个长流程，最常见的例子就是下单场景，用户下单购买商品，后台服务要在这个下单行为发生后做一系列的事情，要减库存、加到用户已购买列表中、发通知、跟踪订单进度等。
这一系列的动作如果全都同步来做，那响应时间会比较久，而且一旦其中某个环节失败，将会更加麻烦。
所以针对类似的场景，就有了异步处理的思路，在同步响应中只把最重要的动作完成，剩下的都可以异步处理，比如购买行为，收钱和减库存是最重要的，这两个成功了就算是购买成功了，剩下的通知、跟踪进度都可以稍后进行，也就是异步处理。
说到此，解耦也就出现了，收钱和减库存可以是一个线程来做，或者一个单独的服务来做，发通知又可以是另一个线程或者另一个服务来做，这样一来，两个动作、两个功能就解耦了，发通知的服务挂了不会影响真正的购买行为，而等到发通知服务启动后，可以再处理历史数据也没问题。
这个场景下，用到消息队列再合适不过。而且听说，这个场景才是消息队列有价值的地方，也是消息队列思想的灵魂所在。
流量削峰
流量削峰是在高并发情况下，通过消息队列将大量请求排队处理，避免系统在短时间内被大量请求压垮。
假设一个系统本来日常只支持1万并发，但是某个时候突然有大量的用户进来，流量超过了系统所能承受的最大值，如果不加以控制，那等待系统的只有崩溃。
这种情况下，系统可以将处理不了的请求暂时放到消息队列中，然后在系统所能支持的并发下依次处理队列中的请求。这样一来，系统既不会崩溃，也能将请求都一一处理掉。
当然了，如果没有消息队列，本身系统也可以采取其他的处理措施，比如直接将请求丢弃，或者返回一个固定值。比如某些抢购场景，本来就有数量限制，只有最先进来的请求才能抢到，后面不管再进来多少都抢不到，那后面多余的请求就没必要处理。
日志处理
很多公司都有专门的日志查看平台，例如 Kibana，公司内所有项目都会归集到统一的地方，通过界面点点按钮就能看到不同项目的日志了。
这背后的原理就是将用户行为日志发送到消息队列，再由专门的日志处理服务进行分析和处理。自从 Kafka 一出来，再用消息队列传输日志就好像被它垄断了。没办法，谁让人家在这方面有特长呢。
分布式事务
分布式事务通俗来说就是要么都成功，要么都不成功。
还是拿订单系统为例，在订单创建后，通过消息队列通知库存系统进行库存扣减，以保证数据的一致性。
下图是 RocketMQ 中关于分布式事务的流程图，我们之前的项目中一直用这种方式做分布式事务处理。
图片
这是有些消息队列本身支持的特性，只有本地事务完全成功执行后，才会最终投递消息，否则消费者是看不到这个消息的。
延时任务
比如我们在 12306买票，预订后锁票，有30分钟时间用来付款，这30分钟内，其他人是没办法看到这张票的。如果30分钟内未付款，那这张票就不属于你了。
这种场景就是延时任务的经典场景，每一个预订都会有自己的一个任务，这种任务和系统定时在某时某刻的定时任务是完全不一样的。
就是因为每一个预订都有一个任务，总不能来一个任务就给系统加一个定时任务吧，这不现实。所以这种场景下，用延时队列就最合适了，有些消息队列是支持的。
在消息生产者投递消息时，给消息一个延迟时间，只有到了规定的延迟时间后，这个消息才能被消费者消费掉。
最后
消息队列最厉害的地方在于它的思想，而不在于它使用的具体技术。
消息队列的应用场景众多，但是这么多应用场景中我觉得异步和解耦才是最重要的能力，你觉得呢？
