一、消息中间件的使用场景
消息中间件的使用场景总结就是六个字：解耦、异步、削峰
1.解耦
如果我方系统A要与三方B系统进行数据对接，推送系统人员信息，通常我们会使用接口开发来进行。但是如果运维期间B系统进行了调整，或者推送过程中B系统网络进行了调整，又或者后续过程中我们需要推送信息到三方C系统中，这样的话就需要我们进行频繁的接口开发调整，还需要考虑接口推送消息失败的场景。
如果我们使用消息中间件进行消息推送，我们只需要按照一种约定的数据结构进行数据推送，其他三方系统从消息中间件取值消费就可以，即便是三方系统出现宕机或者其他调整，我们都可以正常进行数据推送。
总结：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。
2.异步
继续我们上述的消息推送业务，如果我们现在需要同时推送消息到BCD三个系统中，而BCD系统接收到消息后需要进行复杂的逻辑处理，以及读库写库处理。如果一个三方系统进行消息处理需要1s，那我们遍历推送完一次消息，就需要三秒。
而如果我们使用消息中间件，我们只需要推送到消息中间件，然后进行接口返回，可能只需要20ms，大大提升了用户体验。消息推送后BCD系统各自进行消息消费即可，不需要我们等待。
3.削峰
还是上述我们的应用场景，假设某一时间段内，每秒都有一条消息推送，如果我们使用接口进行推送，BCD三个系统处理完就需要三秒。这样会导致用户前端体验较差，而且系统后台一直处于阻塞状态，后续的消息推送接口一直在等待。
如果我们使用消息中间件，我们只需要将消息推送至消息中间件中，BCD系统对积压的消息进行相应的处理。
在上述高频发的消息时间段内，会在消息中间中产生消息积压，BCD系统在上述时间段外对积压消息进行相应的处理即可。
二、消息中间件的优缺点
消息中间件的优点其实就是他的使用场景。
消息中间件的缺点与优点也是相辅相成的，主要有以下三个
1.系统可用性降低
系统关联的中间件越多，越容易引发宕机问题。
如上述案例中的问题，原本进行消息推送我们只需要开发接口进行推送即可，引入消息中间件后就需要考虑消息中间件的高可用问题，如果消息中间件出现宕机问题，我们所有的消息推送都会失败。
2.系统复杂度提高
上述案例中，如果我们使用接口进行消息推送，我们只需要考虑接口超时以及接口推送消息失败的问题。但我们引入消息中间件后，就需要考虑消息中间件的维护，以及消息重复消费，消息丢失的问题。
3.一致性问题
上述案例中，如果我们使用接口进行消息推送，推送消息我们可以放在事务中处理，如果推送过程中出现异常，我们可以进行数据回滚，但我们引入消息中间件后，就需要考虑消息推送后，消费失败的问题，以及如果我们同时推送消息到BCD系统中，如何保证他们的事务一致性。
三、四种消息中间件的基本介绍
特性 ActiveMQ RabbitMQ RocketMQ Kafka
单机吞吐量 万级，比 RocketMQ、Kafka 低一个数量级 同 ActiveMQ 10 万级，支撑高吞吐 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响 topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性 ms 级 微秒级，这是 RabbitMQ 的一大特点，延迟最低 ms 级 延迟在 ms 级以内
可用性 高，基于主从架构实现高可用 同 ActiveMQ 非常高，分布式架构 非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性 有较低的概率丢失数据 基本不丢 经过参数优化配置，可以做到 0 丢失 同 RocketMQ
功能支持 MQ 领域的功能极其完备 基于 erlang 开发，并发能力很强，性能极好，延时很低 MQ 功能较为完善，还是分布式的，扩展性好 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用
其他 Apache软件基金会开发、起步较早，但没有经过大量吞吐场景验证，目前社区不是很活跃 开源，稳定，社区活跃度高 阿里出品，目前已交给Apache，但社区活跃度较低 Apache软件基金会开发、开源、高通吐量，社区活跃度高
1.ActiveMQ
1.1：Activemq 是什么
Activemq 是一种开源的，实现了JMS1.1规范的，面向消息(MOM)的中间件，为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通信。
1.2：Activemq 的作用及原理
Activemq 的作用就是系统之间进行通信，原理就是生产者生产消息， 把消息发送给activemq， Activemq 接收到消息， 然后查看有多少个消费者，
然后把消息转发给消费者， 此过程中生产者无需参与。 消费者接收到消息后做相应的处理和生产者没有任何关系。
1.3：Activemq 的通信方式
publish(发布)-subscribe(订阅)(发布-订阅方式)
发布/订阅方式用于多接收客户端的方式，作为发布订阅的方式，可能存在多个接收客户端，并且接收端客户端与发送客户端存在时间上的依赖。一个接收端只能接收他创建以后发送客户端发送的信息。
p2p(point-to-point)(点对点)
p2p的过程则理解起来比较简单。它好比是两个人打电话，这两个人是独享这一条通信链路的。一方发送消息，另外一方接收，就这么简单。在实际应用中因为有多个用户对使用p2p的链路，相互通信的双方是通过一个类似于队列的方式来进行交流。和前面pub-sub的区别在于一个topic有一个发送者和多个接收者，而在p2p里一个queue只有一个发送者和一个接收者。
1.4：Activemq 的消息持久化机制
JDBC： 持久化到数据库
AMQ ：日志文件（已基本不用）
KahaDB ： AMQ基础上改进，默认选择
LevelDB ：谷歌K/V数据库
在activemq.xml中查看默认的broker持久化机制。
1.5：Activemq 的消息确认机制
（1）AUTO_ACKNOWLEDGE = 1 自动确认
（2）CLIENT_ACKNOWLEDGE = 2 客户端手动确认
（3）DUPS_OK_ACKNOWLEDGE = 3 自动批量确认
（4）SESSION_TRANSACTED = 0 事务提交并确认
（5）INDIVIDUAL_ACKNOWLEDGE = 4 单条消息确认
前四种是JMS API中提供的客户端ACK_MODE。第五种是InforSuiteMQ自定义补充的一种ACK_MODE。
2.RabbitMQ
2.1：RabbitMQ是什么
RabbitMQ是一个由erlang语言编写的、开源的、在AMQP基础上完整的、可复用的企业消息系统。
2.2：RabbitMQ的作用及原理
基本概念
关键名称 说明
Channel（信道） 消息推送使用的通道
Producer（消息的生产者） 向消息队列发布消息的客户端应用程序
Consumer（消息的消费者） 从消息队列取得消息的客户端应用程序
Message（消息） 消息由消息头和消息体组成
Routing Key（路由键） 消息头的一个属性，用于标记消息的路由规则，决定了交换机的转发路径
Queue（消息队列） 用于存储生产者的消息
Exchange（交换器路由器） 提供Producer到Queue之间的匹配
Binding（绑定） 用于建立Exchange和Queue之间的关联
Binding Key（绑定键） Exchange与Queue的绑定关系，用于匹配Routing Key
Broker（服务主体） RabbitMQ Server，服务器实体
2.3：RabbitMQ的通信方式
2.3.1：简单队列
最简单的工作队列，其中一个消息生产者，一个消息消费者，一个队列。也称为点对点模式
2.3.2：工作队列模式
一个消息生产者，一个交换器，一个消息队列，多个消费者。同样也称为点对点模式
2.3.3：发布订阅模式
Pulish/Subscribe，无选择接收消息，一个消息生产者，一个交换机（交换机类型为fanout），多个消息队列，多个消费者
生产者只需把消息发送到交换机，绑定这个交换机的队列都会获得一份一样的数据。
2.3.4：路由模式
在发布/订阅模式的基础上，有选择的接收消息，也就是通过 routing 路由进行匹配条件是否满足接收消息。
2.3.5：主体模式
topics(主题)模式跟routing路由模式类似，只不过路由模式是指定固定的路由键 routingKey，而主题模式是可以模糊匹配路由键 routingKey，类似于SQL中 = 和 like 的关系。
2.3.6：RPC模式
与上面其他5种所不同之处，该模式是拥有请求/回复的。也就是有响应的，上面5种都没有。
RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的处理业务，处理完后然后在A服务器继续执行下去，把异步的消息以同步的方式执行。
2.4：RabbitMQ的消息持久化机制
Queue（消息队列）的持久化是通过durable=true来实现的。
Message（消息）的持久化 ，通过设置消息是持久化的标识。
Exchange（交换机）的持久化 。
2.5：RabbitMQ的消息确认机制
confirm机制：确认消息是否成功发送到Exchange
ack机制：确认消息是否被消费者成功消费
AcknowledgeMode.NONE：自动确认
AcknowledgeMode.AUTO：根据情况确认
AcknowledgeMode.MANUAL：手动确认
3.RocketMQ
3.1：RocketMQ是什么
RocketMQ是阿里开发的一款纯java、分布式、队列模型的开源消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。
3.2：RocketMQ的作用及原理
基本概念
关键名称 说明
Producer 消息生产者
Producer Group 生产者组
Consumer 消息消费者
Consumer Group 消费者组
Topic Topic用于将消息按主题做划分，Producer将消息发往指定的Topic，Consumer订阅该Topic就可以收到这条消息
Message 代表一条消息
Tag 标签可以被认为是对 Topic 进一步细化
Broker 负责接收并存储消息
Queue Topic和Queue是1对多的关系，一个Topic下可以包含多个Queue，主要用于负载均衡
Offset RocketMQ在存储消息时会为每个Topic下的每个Queue生成一个消息的索引文件，每个Queue都对应一个Offset记录当前Queue中消息条数。
NameServer NameServer可以看作是RocketMQ的注册中心
3.3：RocketMQ的通信方式
RocketMQ消息订阅有两种模式
一种是Push模式（MQPushConsumer），即MQServer主动向消费端推送
另外一种是Pull模式（MQPullConsumer），即消费端在需要时，主动到MQ Server拉取
但在具体实现时，Push和Pull模式本质都是采用消费端主动拉取的方式，即consumer轮询从broker拉取消息
集群模式和广播模式
集群模式：默认情况下我们都是使用的集群模式，也就是说消费者组收到消息后，只有其中的一台机器会接收到消息。
广播模式：消费者组内的每台机器都会收到这条消息。