什么是消息队列
消息队列（Message Queue）,从广义上讲是一种消息队列服务中间件，提供一套完整的信息生产、传递、消费的软件系统，如图所示：
消息队列锁涵盖的功能远不止与队列，其本质是两个进程传递信息的一种方法。两个进程可以分布在同一台机器上，也可以分布在不同的机器上。
众所周知，进程通信可以通过RPC（Remote Procedure Call，远程过程调用）进行，那么我们为什么要用消息队列来传递服务呢？
下面我们以春节订火车票为例进行说明。
春节准备买车票回家过年，我们会打开12306进行如下操作：
1）输入车票信息，发送订票请求，输入起点，终点，发车时间等等
2）单机预定按钮，12306APP开始转圈，与此同时全国可能会有几亿人在进行相同的操作。
3）3s后，应用告诉你订票失败
4）你修改车次信息，重新发送订票请求，有过了3s，订票成功。
下面我们以一张流程图来更直观的体现以上操作：
12306在处理上面请求逻辑时，会遇到以下挑战：
（1）今天这个车次只售出4000张票，而实际有30万人发送了订票请求，如果逐一请求处理，那么90%以上的人都将要耗时3s来等待，怎么办？
（2）下游有20个系统需要在订票成功后进行通知，如果逐一调，用这些系统的接口进行通知，而其中一个通知任务执行失败，那么已经通知成功的任务会怎么样？
（3）12306APP架构会不断调整，当数据结构发生变化时，下游20个系统都随着一起变化吗？
以上只是随机列举了一些常见问题，如何才能优雅地处理呢？
答案是：消息队列！
为什么需要消息队列
削峰填谷
业务系统在超高并发场景中，由于后端服务来不及同步处理过多，过快的请求，可能导致请求堵塞，严重时可能由于高负荷拖垮Web服务器。
我们都希望流量像直线一样一直比较平稳，这样我们的系统也会更加稳定，但是实际的流量会随着时间不短变化，像12306这样的APP流量大的难以想象，而一年中不同的时间段，其流量也不同，为了能支持最高峰流量，我们通常才去短平快的方式--直接扩容服务器，增加服务端的吞吐量。
优点是显而易见的，短时间内吞吐量增加了好几倍，甚至数十倍。缺点也十分明显，流量低峰期服务器相对较闲。
如何平衡平时的空闲与节假日的超高峰呢？我们想到消息对列（Apache RocketMQ,Apache Kafka），也是目前业界比较常用的手段。利用消息队列扭转处理订票请求，告知用户30min内会告诉他订票结果。优缺点明显：性能提升了，但是我们作为业务开发人员，还要维护一个消息队列服务，人手完全不够。消息中间件呼之欲出。
程序间解耦
不同的业务端在联合开发功能时，常常由于排期不同、人员调配不方便等原因导致项目延期。其实，根本原因是业务耦合过度。
加入消息队列后，不同的业务端之间开发，联调，上线彼此完全不依赖，也就是说系统解耦了。
异步处理
处理订票请求是一个漫长的过程，需要检查预定的车次是否有预定数量的票，下单扣库存，更新缓存等一系列操作。这些耗时的操作，我们可以通过使用消息队列的方式，把提交请求成功的消息告诉用户。然后异步处理这些耗时的操作，保证30min内能把处理的结果通过短信推送给用户，否则系统处理多久，用户就会等多久。
数据的最终一致性
我们通过银行转账的案例来进行说明：
如果通信失败，如何保证转账成功呢，常用的手段就是消息队列。消息系统的优点：
（1）免去了用户A多次重试的复杂逻辑
（2）免去了用户B处理多次重试请求的压力
（3）即时用户B的服务不可用，业务也不受影响
常见的消息队列
| 消息队列名字 | Apache ActiveMQ | Apache Kafka | Apache RocketMQ | Apache Pulsar |
| 产生时间 | 2007 | 2012 | 2017 | 2018 |
| 贡献公司 | Apache | LinkedIn | alibaba | yahoo |
| 当时流行MQ | JMS | ActiveMQ | Kafka, ActiveMQ | RocketMQ, Kafka |
| 特性 |
(1) 支持协议众多:AMQP,STOMP,MQTT,JMS
(2) 消息是持久化的JDBC
|
（1）超高写入速率
（2）end-to-end 耗时毫秒级
|
（1）亿万级消息支持
（2）万级TOPIC数量支持
（3）end-to-end耗时毫秒级
|
（1）存储计算分离
（2）支持SQL数据查询
|
| 管理后台 | 自带 | 独立部署 | 独立部署 | 无 |
| 多语言客户端 | 支持 | 支持 |
Java
C++
Python
Go
c#
|
Java
C++
Python
Go
|
| 数据流支持 | 不支持 | 支持 | 支持 | 支持 |
| 消息丢失 | 理论上不会丢失 | 理论上不会丢失 | 理论上不会丢失 | 理论上不会丢失 |
| 文档完备性 | 好 | 极好 | 极好 | 社区不断完善中 |
| 商业公司实践 | 国内部分企业 | LinkedIn | alibaba | yahoo,tencet,zhilian |
| 容错 | 无重试机制 | 无重试机制 | 支持重试，死信消息 | 支持重试，死信消息 |
| 顺序消息 | 支持 | 支持 | 支持 | 支持 |
| 定时消息 | 不支持 | 不支持 | 支持 | 支持 |
| 事务消息 | 不支持 | 支持 | 支持 | 支持 |
| 消息轨迹 | 不支持 | 不支持 | 支持 | 自己简单实现 |
| 消息查询 | 数据库查询 | 不支持 | 支持 | 支持SQL |
| 重放消息 | 不清楚 | 暂停重放 | 实时重放 | 支持 |
| 宕机 | 自动切换 | 自动选主 | 手动重启 | 自动切换 |
