什么是消息中间件
消息（Message）是指在应用间传送的数据。消息可以非常简单，比如至包含文本字符串、JSON等，当然了，也可以很复杂，比如内嵌对象。
消息队列中间件（Message Queue Middleware，简称 MQ）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。
目前开源的消息中间件有很多，比较主流的有RabbitMQ、Kafka、ActiveMQ、RocketMQ等
消息中间件的分类
推消息模型（PUSH）
消息生产者将消息发送给消息传递服务，消息传递服务又将消息推给消息消费者。
拉消息模型(PULL)
消费者请求消息服务请求消息，消息生产者从消息中间件拉此消息。
两者的区别：
模型 |
push |
pull |
服务端 |
消息存储 处理请求 保存推送轨迹 保存订阅关系 消费者负载均衡 集中式 |
消息存储 处理请求 分布式 |
客户端 |
处理响应和请求 |
处理响应和请求 保存pull状态，如拉取位置的偏移量offset 异常情况下的消息暂存 |
实时性 |
较好，收到数据后可立即发送给客户端 |
取决于pull的时间间隔 |
消费者故障 |
消费者故障情况下，服务端堆积消息，重复推送耗费资源 保存推送轨迹压力很大 |
消费者故障，对服务端无影响 |
其他 |
对消息推送有更多控制，能实现多样化的推送机制，当消费者数量增多的时候，推送压力大，性能天花板，消费者处理能力差异，导致堆积消息 |
需要在客户端实现消息过滤，浪费资源 需要在不同客户端之间协调，做负载均衡 |
消息中间件的应用场景
l可恢复性
譬如跨机房数据复制
l异步通信
用户注册发邮件和短信
l流量削峰
诸如大促、秒杀活动等
另也可用于性能压测
l顺序保证
比如在支付系统中，处理顺序就很重要
l解耦
例如：电商系统中用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口；这时若订单系统故障，则库存系统就会失败，从而导致订单失败，同时也出现耦合度高，使用消息中间件；下单系统和库存系统可以单独分开设计，做到应用解耦。
l日志收集
计算PV、用户行为分析
RocketMQ简介
阿里的消息中间有很长的历史，从2007年的notify到2010年的Napoli，2011年升级后改为MetaQ，然后到2012年开始做RocketMQ，RocketMQ使用Java语言开发，于2016年开源。第一代的Notify主要使用了推模型，解决了事务消息；第二代的MetaQ主要使用了拉模型，解决了顺序消息和海量堆积的问题。RocketMQ基于长轮询的拉取方式，兼有两者的优点。
目前RocketMQ已经成为Apache顶级项目。在阿里内部，RocketMQ很好地服务了集团大大小小上千个应用，在每年的双11当天，有万亿级消息通过RocketMQ流转（在2017年双11当天，RocketMQ流转的线上消息达到了万亿级，峰值TPS达到5600万），在阿里大中台上也发挥了一定的作用。
RocketMQ的特点
l是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点
lProducer、Consumer、队列都可以分布式
l能够保证严格的消息顺序
l提供丰富的消息拉取模式
l高效的订阅者水平扩展能力
l实时的消息订阅机制
l亿级消息堆积能力
l较少的依赖
RocketMQ物理部署结构
如上图所示， RocketMQ的部署结构有以下特点：
lName Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
lBroker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。
lProducer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
lConsumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。
RocketMQ逻辑部署结构
如上图所示，RocketMQ的逻辑部署结构有Producer和Consumer两个特点。
Producer Group
用来表示一个发送消息应用，一个Producer Group下包含多个Producer实例，可以是多台机器，也可以是一台机器的多个进程，或者一个进程的多个Producer对象。一个Producer Group可以发送多个Topic消息，Producer Group作用如下：
1. 标识一类Producer
2. 可以通过运维工具查询这个发送消息应用下有多个Producer实例
3. 发送分布式事务消息时，如果Producer中途意外宕机，Broker会主动回调Producer Group内的任意一台机器来确认事务状态。
Consumer Group
用来表示一个消费消息应用，一个Consumer Group下包含多个Consumer实例，可以是多台机器，也可以是多个进程，或者是一个进程的多个Consumer对象。一个Consumer Group下的多个Consumer以均摊方式消费消息，如果设置为广播方式，那么这个Consumer Group下的每个实例都消费全量数据。
常用RocketMQ集群模式
n单master模式
也就是只有一个master节点，称不上是集群，一旦这个master节点宕机，那么整个服务就不可用，适合个人学习使用。
n多Master模式
多个master节点组成集群，单个master节点宕机或者重启对应用没有影响。
【优点】所有模式中性能最高
【缺点】单个master节点宕机期间，未被消费的消息在节点恢复之前不可用，消息的实时性就受到影响。
注意：使用同步刷盘可以保证消息不丢失，同时Topic相对应的queue应该分布在集群中各个节点，而不是只在某各节点上，否则，该节点宕机会对订阅该topic的应用造成影响。
n多Master多slave异步复制模式
在多master模式的基础上，每个master节点都有至少一个对应的slave。master
节点可读可写，但是slave只能读不能写，类似于mysql的主备模式。
【优点】在master宕机时，消费者可以从slave读取消息，消息的实时性不会受影响，性能几乎和多master一样。
【缺点】使用异步复制的同步方式有可能会有消息丢失的问题。
n多Master多Slave同步复制双写模式
同多 master多slave异步复制模式类似，区别在于master和slave之间的数据同步方式。
【优点】同步双写的同步模式能保证数据不丢失。
【缺点】发送单个消息RT会略长，性能相比异步复制低10%左右。
【刷盘策略】同步刷盘和异步刷盘（指的是节点自身数据是同步还是异步存储）
【同步方式】同步双写和异步复制（指的一组master和slave之间数据的同步）
注意：要保证数据可靠，需采用同步刷盘和同步双写的方式，但性能会较其他方式低
集群模式总结
单Master无Slave（脆弱）
单master多Slave（单点故障就瘫痪，开源版本无主备切换功能）
多Master无Slave（无单点故障，prod环境常用）
多Master和Slave（无单点故障）