目录
什么是消息队列
消息队列（message queue）可以看成一个存放消息的容器，当我们需要使用消息的时候，就从容器中取出消息使用。队列Queue是一种先进先出的结构，所以消息是按顺序消费的。消息队列是分布式系统中的重要组件之一，使用它主要是为了通过异步处理来提高系统性能和削峰、降低系统耦合性。
消息队列的优势：
1、通过异步处理提高系统性能（减少响应时间）
同步和异步的概念：
- 同步：按顺序执行，一般用来保证数据的一致性；
- 异步：不保证同步，一个异步程序的执行不一定按照原有的序列顺序执行
在同步中穿插异步，往往是同步的部分全部顺序执行完以后，再自由地去执行异步的部分
流程对比：
- 无MQ：客户端发送请求——服务端请求数据库——数据库返回结果给服务端——客户端接收响应
- 有MQ：客户端发送请求——服务端发送消息给消息队列——客户端接收响应
- 只要给MQ发送完消息就立刻响应，等系统调用MQ消息的时候才会有数据库操作（系统对消息进行消费）
所以，有消息队列的情况下，响应时间会大大减少。
但是，在后续系统对消息进行消费（consume）的过程中，业务校验、写数据库等操作有失败的可能。因此使用MQ进行异步处理的时候，需要适当修改业务流程。比如：用户在提交订单之后，订单数据写入消息队列，不能立即返回用户订单提交成功。需要订单consumer进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信的方式通知用户订单成功，以免交易纠纷。这就类似我们平时手机订火车票和电影票。
所以，响应时间大大减少，响应内容可能会有所改变。
2、削峰限流
短时间内高并发产生的用户请求过多，会造成业务系统压力过大。如果把这些事务消息存入消息队列，那么消息就会海量地存储在消息队列，系统的压力转化为消息队列的压力，业务系统可以慢慢消化这些事务，避免系统崩溃的问题。
应用举例：
在电子商务的一些秒杀、促销活动中，合理使用消息队列可以有效抵御促销活动刚开始大量订单涌入对系统的冲击。
3、降低系统耦合性
耦合性：
如果模块之间没有直接调用，那么新增或者修改该模块就对其他模块影响较小，这样系统的可扩展性肯定会更好一些。
消息队列降低耦合性的原理：
生产者（客户端）发送消息到消息队列中去，消费者（服务端）处理消息，需要消费的系统直接去消息队列取消息进行消费，而不需要和其他系统有耦合
发布-订阅模式：
生产者发布消息，一个或多个消费者订阅消息，两者之间没有直接耦合。生产者把消息发送到分布式消息队列即结束对消息的处理，消费者从分布式消息队列获取消息后进行后续处理，并不需要知道消息从何而来。
新增业务只要对该类消息感兴趣，就可以订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。
注意：
- 为了避免消息队列服务器宕机造成消息丢失，成功发送到消息队列的消息依然会存储在生产者服务器上，等消息真正被消费者处理后才删除消息。在消息队列宕机后，生产者服务器会选择分布式消息队列服务器集群中的其他服务器发布消息。
- 不要认为消息队列只能利用发布-订阅模式工作，只是在解耦这个特定业务环境下是使用发布-订阅模式的。除了发布-订阅模式，还有点对点订阅模式（一个消息只有一个消费者），比较常用的是发布-订阅模式。另外，这两种消息模型是 JMS 提供的，AMQP 协议还提供了 5 种消息模型。
使用消息队列带来的一些问题
- 系统可用性在某种程度上降低：
加入MQ之前，不用考虑消息丢失或者MQ挂掉等等的情况，但是引入MQ之后就需要去考虑了
- 系统复杂性提高：
加入MQ之后，需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等
- 一致性问题：
消息队列带来的异步确实可以提高系统响应速度。但是，万一消息真正的消费者并没有正确消费消息，就会导致数据不一致的情况
JMS和AMQP
JMS
JMS（JAVA Message Service）是java的消息服务，JMS的客户端之间可以通过JMS服务进行异步的消息传输。JMS API是一个消息服务的标准或者说是规范，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。
两种消息模式
- 点到点（P2P）模型
使用队列（Queue）作为消息通信载体，满足生产者与消费者模式。一条消息只能被一个消费者使用，未被消费的消息在队列中保留直到被消费或超时。比如：生产者发送100条消息，两个消费者来消费。一般情况下两个消费者会按照消息发送的顺序各自消费一半（也就是你一个我一个的消费）
- 发布/订阅（Pub/Sub）模型
使用主题（Topic）作为消息通信载体，类似于广播模式。发布者发布一条消息，该消息通过主题传递给所有的订阅者，在一条消息广播之后才订阅的用户则是收不到该条消息的。
五种不同的消息正文格式
- StreamMessage —— Java原始值的数据流
- MapMessage —— 一套键值对
- TextMessage —— 一个字符串对象
- ObjectMessage —— 一个序列化的 Java对象
- BytesMessage —— 一个字节的数据流
AMQP
AMQP（Advanced Message Queuing Protocol），一个提供统一消息服务的应用层标准：高级消息队列协议（二进制应用层协议），是应用层协议的一个开放标准，为面向消息的中间件设计，兼容 JMS。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。
区别
- JMS是javaAPI，AMQP是个协议
- JMS不跨语言和平台，AMQP跨语言跨平台
- JMS支持两种消息模型（P2P、Pub/Sub）；AMQP支持五种（①direct exchange；②fanout exchange；③topic change；④headers exchange；⑤system exchange。但是后四种和JMS的pub/sub模型没有太大差别，仅是在路由机制上做了更详细的划分）
- JMS支持上面提到的五种消息正文格式，AMQP仅支持byte[]二进制（序列化）
常见的消息队列对比
ActiveMQ（JMS）、RabbitMQ（AMQP） 、RocketMQ 、Kafka
- 吞吐量
万级的 ActiveMQ 和 RabbitMQ 吞吐量要比十万级甚至是百万级的 RocketMQ 和 Kafka 低一个数量级。（ActiveMQ 的性能最差）
- 可用性
都可以实现高可用。
ActiveMQ 和 RabbitMQ 都是基于主从架构实现高可用性。
RocketMQ 基于分布式架构。 kafka 也是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用。
- 时效性
RabbitMQ 基于erlang开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。其他三个都是 ms 级。
- 功能支持
除了 Kafka，其他三个功能都较为完备。 Kafka 功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准。
- 消息丢失
ActiveMQ 和 RabbitMQ 丢失的可能性非常低， RocketMQ 和 Kafka 理论上不会丢失。
总结：
- 目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用。
- RabbitMQ 在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ，但是由于它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。
- RocketMQ 阿里出品，Java 系开源项目，有阿里巴巴的实际业务场景的实战考验。但是接口这块不是按照标准 JMS 规范走的，有些系统要迁移需要修改大量代码。如果公司有技术实力用RocketMQ 挺好的
- Kafka 仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时 kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量。kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集。
- 如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列中，RabbitMQ 一定是首选。如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，几乎是全世界这个领域的事实性规范。
474
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
