1、什么是消息队列？
消息队列是在消息的传输过程中保存消息的容器，用于接收消息并以文件的方式存储，一个队列的消息可以同时被多个消息消费者消费。分布式消息服务DMS则是分布式的队列系统，消息队列中的消息分布存储，且每条消息存储多个副本，以实现高可用性。
消息队列具有如下属性：
- 消息顺序
普通队列支持“分区有序”和“全局队列”两种模式，ActiveMQ和Kafka均为分区有序。
分区有序的队列通过分布式处理，支持更高的并发，但由于队列的分布式特性，DMS无法保证能够以接收消息的精确顺序进行消费。如果用户要求保持顺序，建议在每条消息中放置排序信息，以便在收到消息时对消息重新排序。
全局有序的队列对消息消费遵循先入先出规则（FIFO），适用于对消费顺序要求较高的场景。 - 至少一次传递
在极少数情况下，当用户接收或删除消息时，存储消息副本的服务器之一可能不可用。如果出现这种情况，则该不可用服务器上的消息副本将不会被删除，并且在接收消息时可能会再次获得该消息副本。
这被称为“至少一次传递”，因此，用户的应用程序应该设计为幂等的应用程序（如果应用程序多次处理同一条消息，则不得受到不利影响）。 - 消息较少时单次消费不能获取指定数量的消息
从消息队列中消费消息时，DMS每次从部分消息存储分区中读取消息并返回给消费者，如果队列中的消息数比较少，则单次消费可能会少于指定条数，但多次消费最终可获取全部消息。
2、ActiveMQ的消息传递模式
- P2P（点对点）即采用点对点的方式发送消息。P2P模型是基于队列的，消息生产者发送消息到队列，消息消费者从队列中接收消息。
消息可以被同步或异步的发送和接收，每个消息只会给一个Consumer传送一次。 -
Pub/Sub（发布/订阅，Publish/Subscribe）发布-订阅模型定义了如何向一个内容节点发布和订阅消息，这个内容节点称为topic(主题)。主题可以认为是消息传递的中介，消息发布者将消息发布到某个主题，而消息订阅者则从主题订阅消息。主题使得消息的订阅者与消息的发布者互相保持独立，不需要进行接触即可保证消息的传递，发布-订阅模型在消息的一对多广播时采用。
发送到topic的任何消息都将自动传递给所有订阅者。接收方式（同步和异步）与P2P域相同。
image.png
3、中间件的分类
- 基于远程过程调用 (Remote Procedure Call, RPC)的中间件。
- 基于对象请求代理 (Object Request Broker, ORB) 的中间件。
- 面向消息的中间件或基于MOM的中间件。
4、面向消息的中间件 (Message-Oriented Middleware, MOM)
消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。
image.png
5、什么是jms?
JMS即Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。
6、JMS消息传送模式
image.png
- 客户端 A、C 和 D之间的消息传送说明了点对点模式(P2P)。客户端使用此模式向队列目的地发送一条消息，只有一个接收者能够从该目的地获得该消息。访问该目的地的其他任何接收者都不能获得该消息。
- 客户端 B、E 和 F之间的消息传送说明了发布/订阅模式(publish-subscribe)。客户端使用此广播模式向主题目的地发送一条消息，任意数量的使用方订户都可以从该目的地检索此消息。每个订户都获得此消息的一个副本。
7、JMS 消息传送对象
MS 消息传送的对象在编程域中基本保持不变：连接工厂、连接、会话、生成方、使用方、消息和目的地。
image.png
8、MQ (Message Queue)应用场景？
- 异步通信
有些业务不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 - 解耦
降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 - 冗余
有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 - 扩展性
消息队列解耦了处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可，不需要改变代码、调节参数，便于分布式扩容。 - 过载保护
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 - 可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。 - 顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。 - 缓冲
在任何重要的系统中，都会有需要不同处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度，以调节系统响应时间。 - 数据流处理
分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析，通过消息队列完成此类数据收集是最好的选择。
9、ActiveMQ简单案例
消息生产者：
//创建session会话
ConnectionFactory factory = new ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
Connection connection = factory.createConnection();
connection.start();
Session session = connection.createSession(Boolean.TRUE, Session.AUTO_ACKNOWLEDGE);
//创建一个消息队列 session.createQueue("jms.test.topic")--P2P模式
Destination destination = session.createTopic("jms.test.topic");
//创建消息生产者
MessageProducer producer = session.createProducer(destination);
//消息持久化
producer.setDeliveryMode(DeliveryMode.PERSISTENT);
for (int i = 0; i < messageNum; i++)
producer.send(session.createTextMessage("Message Producer:" + i));
session.commit(); //提交会话
消息消费者：
//创建session会话
ConnectionFactory factory = new ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
Connection connection = factory.createConnection();
connection.start();
Session session = connection.createSession(Boolean.TRUE, Session.AUTO_ACKNOWLEDGE);
//创建一个消息队列 session.createQueue("jms.test.topic")--P2P模式
Destination destination = session.createTopic("jms.test.topic");
//创建消息消费者
MessageConsumer consumer = session.createConsumer(destination);
while (true) {
TextMessage message = (TextMessage) consumer.receive();
if (message != null) System.out.println("Message Consumer:"+message.getText());
else break;
}
session.commit();
10、ActiveMQ的消息存储机制
- KahaDB：默认存储方式，基于文件的快速存储消息。
- AMQ：是可靠持久性和高性能索引的事务日志组合，当消息吞吐量是应用程序的主要需求时，该存储是最佳选择。
- JDBC：选择关系型数据库，但它在性能上绝对不优于上述消息存储实现。
- 内存存储：内存消息存储器将所有持久消息保存在内存中。在仅存储有限数量Message的情况下，内存消息存储会很有用，因为Message通常会被快速消耗。在activema.xml中将 broker 元素上的persistent属性设置为false即可。
11、ActiveMQ的部署模式
- 默认的单机部署（kahadb）
- 共享存储主从模式(基于数据库)
image.png
- 共享存储主从模式(基于文件系统)
image.png
- 基于zookeeper的主从
12、消息中间件的组成
- Broker：消息服务器，作为server提供消息核心服务；
- Producer：消息生产者，业务的发起方，负责生产消息传输给broker；
- Consumer：消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理；
- Topic：主题/发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播；
- Queue：队列/PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收；
- Message：消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输；
13、消息中间件的优势
- 系统解耦
交互系统之间没有直接的调用关系，只是通过消息传输，系统侵入性不强，耦合度低。 - 提高系统响应时间
通过MQ架构设计，可将紧急重要（需立刻响应）的业务放到该调用方法中，响应要求不高的使用消息队列，放到MQ队列中，供消费者处理。 - 为大数据处理架构提供服务
通过消息作为整合，大数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能支持。 - Java消息服务JMS
Java消息服务（Java Message Service，JMS）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
JMS中的P2P和Pub/Sub消息模式：点对点（point to point，queue）与发布订阅（publish/subscribe，topic）。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)。
14、消息中间件常用协议
- AMQP协议
AMQP（Advanced Message Queuing Protocol），一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件限制。
优点：可靠、通用 - MQTT协议
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器的通信协议。
优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统 - STOMP协议
STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。
优点：命令模式（非topic\queue模式） - XMPP协议
XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测，适用于服务器之间的准即时操作。核心是基于XML流传输。
优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大 - 其他基于TCP/IP自定义的协议
有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP/IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。
15、常见消息中间件MQ介绍
- RocketMQ
阿里系下开源的一款分布式、队列模型的消息中间件，是参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。
具有以下特点：
1）能够保证严格的消息顺序
2）提供针对消息的过滤功能
3）提供丰富的消息拉取模式
4）高效的订阅者水平扩展能力
5）实时的消息订阅机制
6）亿级消息堆积能力 - RabbitMQ
使用Erlang编写的一个开源的消息队列，本身支持很多协议：AMQP，XMPP,，SMTP，STOMP，它是重量级的，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持，多用于进行企业级的ESB整合。 - ActiveMQ
ActiveMQ是Apache所提供的一个开源的消息系统，完全采用Java来实现，因此，它能很好地支持J2EE提出的JMS（Java Message Service,即Java消息服务）规范。JMS是一组Java应用程序接口，它提供消息的创建、发送、读取等一系列服务。JMS提供了一组公共应用程序接口和响应的语法，类似于Java数据库的统一访问接口JDBC,它是一种与厂商无关的API，使得Java程序能够与不同厂商的消息组件很好地进行通信。 - Kafka
Apache下的一个子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统，具有以下特性：
快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；
高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；
高堆积：支持topic下消费者较长时间离线，消息堆积量大；
完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；
支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。 - Redis
使用C语言开发的一个Key-Value的NoSQL数据库，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
16、消息的ACK机制
ACK机制：消息的Ackownledge确认机制，为了保证消息不丢失，消息队列提供了消息Acknowledge机制，当Consumer确认消息已经被消费处理，发送一个ACK给消息队列，此时消息队列便可以删除这个消息了。如果Consumer宕机/关闭，没有发送ACK，消息队列将认为这个消息没有被处理，会将这个消息重新发送给其他的Consumer重新消费处理。