RocketMQ消息队列

一、RocketMQ简介

1.1、介绍

RocketMQ是一款分布式、队列模型的消息中间件，由Metaq3.X版本改名而来，RocketMQ并不遵循包括JMS规范在内的任何规范，但是参考了各种规范不同类产品的设计思想，自己有一套自定义的机制，简单来说就是使用订阅主题的方式去发送和接收任务，但是支持集群和广播两种消息模式。开源项目地址：https://github.com/apache/rocketmq
具有以下特点：
1、能够保证严格的消息顺序
2、提供丰富的消息拉取模式
3、高效的订阅者水平扩展能力
4、实时的消息订阅机制
5、亿级消息堆积能力
选用理由：
1、强调集群无单点，可扩展，任意一点高可用，水平可扩展。
2、海量消息堆积能力，消息堆积后，写入低延迟。
3、支持上万个队列。
4、消息失败重试机制。
5、消息可查询。
6、开源社区活跃。
7、成熟度（历经多次天猫双十一海量消息考验）

1.2、专业术语

1、Producer
消息生产者，负责产生消息，一般由业务系统负责产生消息。
2、Consumer
消息消费者，负责消费消息，一般是后台系统负责异步消费。
3、Push Consumer
Consumer 的一种，应用通常向 Consumer 对象注册一个 Listener 接口，一旦收到消息，Consumer 对象立刻回调 Listener 接口方法。
4、Pull Consumer
Consumer 的一种，应用通常主动调用 Consumer 的拉消息方法从 Broker 拉消息，主动权由应用控制。
5、Producer Group
一类 Producer 的集合名称，这类 Producer 通常发送一类消息，且发送逻辑一致。
6、Consumer Group
一类 Consumer 的集合名称，这类 Consumer 通常消费一类消息，且消费逻辑一致。
7、Broker
消息中转角色，负责存储消息，转发消息，一般也称为 Server。在 JMS 规范中称为 Provider。
8、广播消费
一条消息被多个 Consumer 消费，即使返些 Consumer 属于同一个 Consumer Group，消息也会被 Consumer Group 中的每个 Consumer 都消费一次，广播消费中的 Consumer Group 概念可以认为在消息划分方面无意义。
在 CORBA Notification 规范中，消费方式都属于广播消费。
在 JMS 规范中，相当于 JMS publish/subscribe model
9、集群消费
一个 Consumer Group 中的 Consumer 实例平均分摊消费消息。例如某个 Topic 有 9 条消息，其中一个Consumer Group 有 3 个实例（可能是 3 个进程，或者 3 台机器），那么每个实例只消费其中的 3 条消息。
在 CORBA Notification 规范中，无此消费方式。
在 JMS 规范中，JMS point-to-point model 与之类似，但是 RocketMQ 的集群消费功能大等于 PTP 模型。
因为 RocketMQ 单个 Consumer Group 内的消费者类似于 PTP，但是一个 Topic/Queue 可以被多个 Consumer Group 消费。
10、顺序消息
消费消息的顺序要同収送消息的顺序一致，在 RocketMQ 中，主要挃的是尿部顺序，即一类消息为满足顺序性，必须 Producer 单线程顺序収送，丏収送到同一个队列，返样 Consumer 就可以挄照 Producer 发送的顺序去消费消息。
11、普通顺序消息
顺序消息的一种，正常情冴下可以保证完全的顺序消息，但是一旦収生通信异常，Broker 重启，由亍队列总数収生发化，哈希叏模后定位的队列会发化，产生短暂的消息顺序丌一致。如果业务能容忍在集群异常情冴（如某个 Broker 宕机戒者重启）下，消息短暂的乱序，使用普通顺序方式比较合适。
12、严格顺序消息
顺序消息的一种，无论正常异常情况都能保证顺序，但是牺牲了分布式 Failover 特性，即 Broker 集群中只要有一台机器丌可用，则整个集群都丌可用，服务可用性大大降低。
如果服务器部署为同步双写模式，此缺陷可通过备机自劢切换为主避免，丌过仍然会存在几分钟的服务丌可用。（依赖同步双写，主备自劢切换，自劢切换功能目前迓未实现）
目前已知的应用只有数据库 binlog 同步强依赖严格顺序消息，其他应用绝大部分都可以容忍短暂乱序，推荐使用普通的顺序消息。
13、Message Queue
在 RocketMQ 中，所有消息队列都是持丽化，长度无限的数据结构，所谓长度无限是挃队列中的每个存储单元都是定长，访问其中的存储单元使用 Offset 来访问，offset 为 java long 类型，64 位，理论上在 100年内不会溢出，所以认为是长度无限，另外队列中只保存最近几天的数据，之前的数据会按照过期时间来删除。
也可以认为 Message Queue 是一个长度无限的数组，offset 就是下标。

1.3、关键概念

1.3.1、主题与标签

主题Topic：第一级消息类型，书的标题；
标签Tags：第二级消息类型，书的目录，可以基于Tag做简单的消息过滤，通常这已经可以满足90%的需求了，如果有更复杂的过滤场景，就需要使用rocketmq-filtersrv组件了。
例如，主题是订单交易，那么标签可以是订单交易-创建、订单交易-付款、订单交易-完成。
通过查看源码就可以发现：一个主题在MQ上默认会有4个Queue队列来存储该主题上的消息，Queue的数量也可以在创建主题时指定。这也是为什么，当MQ采用双Master集群方式时，如果向MQ发送100条消息，其中52条在BrokerA上，48条在BrokerB上。因为4条发给A，4条发给B…依次循环下去，最后4条是发给了A，所以A比B多存储了4条消息。

1.3.2、群组

生产组：用于消息的发送的群组，官方推荐：一个生产组理应发送的是同一主题的消息，消息子类型再使用Tags来区分；
消费组：用于消息的订阅处理的群组，官方推荐：一个消费组理应消费的是同一主题的消息，再使用Tags在Broker做消息过滤。
生产组和消费组极大地方便了扩缩机器、增减处理能力等，同时只有群组名相同才会被认为是一个集群组的，RocketMQ默认情况下采用集群消费模式，所以消息每次只会随机的发给每个消费群组中的一员，这也体现了RocketMQ集群无单点、水平可扩展、任意一点高可用、支持负载均衡等特点。

1.4、RocketMQ核心模块

rocketmq-broker：接受生产者发来的消息并存储（通过调用rocketmq-store），消费者从这里取得消息。
rocketmq-client：提供发送、接受消息的客户端API。
rocketmq-namesrv：NameServer，类似于Zookeeper，这里保存着消息的TopicName，队列等运行时的元信息。
rocketmq-common：通用的一些类，方法，数据结构等。
rocketmq-remoting：基于Netty4的client/server + fastjson序列化 + 自定义二进制协议。
rocketmq-store：消息、索引存储等。
rocketmq-filtersrv：消息过滤器Server，需要注意的是，要实现这种过滤，需要上传代码到MQ！【一般而言，我们利用Tag足以满足大部分的过滤需求，如果更灵活更复杂的过滤需求，可以考虑filtersrv组件】。
rocketmq-tools：命令行工具。

二、RocketMQ示例

参考博文：
RocketMQ部署–双master方式
原文链接