RocketMq介绍

Posted 2020-10-08

RocketMq是什么
1、是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。
2、Producer、Consumer、队列都可以分布式
3、Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer消费方式有两种：广播消费和集群消费。
4、能够保证严格的消息顺序
5、提供丰富的消息拉取模式、高效的订阅者水平扩展能力、实时的消息订阅机制、亿级消息堆积能力、较少的依赖

RocketMQ物理部署

 

RocketMQ部署

1、NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
2、Broker分为Master与Slave，Master与Slave是一对多关系，Master与Slave的对应关系通过指定相同的BrokerName，
不同的BrokerId来定义，BrokerId 为0表示Master，>0表示Slave。Master也可以部署多个。
每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server
3、Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，
并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。
4、Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，
并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，
也可以从Slave订阅消息，订阅规则由Broker配置决定。

 

RocketMQ存储特点 

Consumer消费消息过程，使用了零拷贝原理使用mmap + write方式
优点：即使频繁调用，使用小块文件传输，效率也很高
缺点：不能很好的利用DMA方式，会比sendfile多消耗CPU，
内存安全性控制复杂，需要避免JVM Crash问题。

 

RocketMQ存储目录 

|--abort
|--checkpoint
|--config
| |--consumerOffset.json
| |--consumerOffset.json.bak
| |--delayOffset.json
| |--delayOffset.json.bak
| |--subscriptionGroup.json
| |--subscriptionGroup.json.bak
| |--topics.json
| `--topics.json.bak
|--commitlog
`--consumequeue

 

RocketMQ数据可靠性

1). Broker 正常关闭
2). Broker 异常 Crash
3). OS Crash
4). 机器掉电，但是能立即恢复供电情冴。
5). 机器无法开机（可能是 cpu、主板、内存等关键设备损坏）
6). 磁盘设备损坏。

(1)、 (2)、 (3)、 (4)四种情况都属于硬件资源可立即恢复情冴，RocketMQ 在这四种情况下能保证消息不丢，
或者丢失少量数据（依赖刷盘方式是同步还是异步）。(5)、 (6)属于单点故障，无法恢复，一旦发生，在此单点上的消息全部丢失。
RocketMQ 在这两种情况下，通过异步复制，可保证 99%的消息不丢，但是仍然会有极少量的消息可能丢失。
通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，
例如与 Money 相关的应用。目前RocketMQ 从 3.0 版本开始支持同步双写。

 

RocketMQ关键特性
1、单机支持1万以上持久化队列。
所有数据单独存储到一个Commit Log，完全顺序写，随机读。
对最终用户展现的队列实际只存储消息在Commit Log的位置信息，并且串行方式刷盘。
好处：
队列轻量化，单个队列数据量非常少。
对磁盘的访问串行化，避免磁盘竟争，不会因为队列增加导致IOWAIT增高。
2、刷盘策略
RocketMQ的所有消息都是持久化的，先写入系统PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，访问时，直接从内存读取。
两种刷盘方式：
异步刷盘
同步刷盘
3、消息查询
按照MessageId查询消息
按照MessageKey查询消息
4、服务器消息过滤
5、长轮询Pull
RocketMQ的Consumer都是从Broker拉消息来消费，但是为了能做到实时收消息，RocketMQ使用长轮询方式，可以保证消息实时性同Push方式一致
6、顺序消息
7、事务消息
8、发送消息负载均衡
9、订阅消息负载均衡
10、单队列并行消费
11、发送定时消息
12、消息消费失败，定时重试
13、 HA，同步双写/异步复制

选用理由：
·强调集群无单点，可扩展，任意一点高可用，水平可扩展。
·海量消息堆积能力，消息堆积后，写入低延迟。
·支持上万个队列
·消息失败重试机制
·消息可查询
·开源社区活跃
·成熟度（经过双十一考验）