一、RocketMQ介绍
- 队列:FIFO先进先出
- 作用:异步、解耦、削峰
- 副作用:可用性降低、复杂度提高、消息一致性问题
- 几大MQ产品比较,Rocket相对来说,高吞吐,高性能,高可用,功能全面
- Rocket只支持Java语言,开源版本不如云上版
- 阿里巴巴开源,2016年捐给Apache,有商业版
二、快速实战
1. 安装简单,见官网,需JDK环境
// Start Name Server
nohup sh bin/mqnamesrv &
tail -f ~/logs/rocketmqlogs/namesrv.log
// Start Broker
nohup sh bin/mqbroker -n localhost:9876 &
tail -f ~/logs/rocketmqlogs/broker.log
// 开两个窗口测试下消息推送与消费,默认发1000条
export NAMESRV_ADDR=localhost:9876
// 生产
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer
// 消费
sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer
// Shutdown Servers
sh bin/mqshutdown broker
sh bin/mqshutdown namesrv
注意:nameserver与broker预设jvm内存是4G和8G,若是虚拟机,可能需要调整下内存设置。另外,仔细观察其他jvm默认参数,发现nameServer使用的是CMS垃圾收集器,而Broker使用的是G1垃圾收集器。
2. 集群搭建
- 准备三台服务器
- 配置集群
- 启动namesrv 类似注册中心
- 启动mqbroker 实际处理消息
- 启动borker slave 从节点
- 使用tools.sh 工具测试集群
3. rocket-console
- 图形化管理界面 默认8080端口
4. 消息发送方式:
- 单向发送,吞吐量最好
- 同步发送(等待mq返回)
- 异步发送(定义回调函数,处理消息成功或失败)
- client与broker有双向交互
5. 接受消息方式:
- 主动拉取(消费者拉)
- 被动推送(broker推),类似Rabbitmq监听
三、七种消息样例
1. 基本样例
- 最基本简单单向消息发送
Message message = new Message("TopicTest", "TagA", "Hello RocketMQ".getBytes());
// 关键点就是使用producer.sendOneWay方式来发送消息,这个方法没有返回值,也没有回调。
// 就是只管把消息发出去就行了
producer.sendOneway(message);
- 消费者可以通过拉或推模式,对消息进行消费
2. 顺序消息
- 注意,保证的是消息局部有序,而非全局有序
- 局部就是指在同一个Queue中
- 要想保证消息是局部有序的,必须在整个消息发送过程加以控制
- 默认情况,消息发送方以轮询方式将消息分发到不同Queue
- 而消费者消费时,同时会从多个Queue上拉消息
- 此时要想有序,就必须消息发送到同一个Queue才可行
- 因此,只有让Broker中只有一个队列,才可以保证消息的顺序
- 消费者端,要想保证有序,也需按照队列一个个取,即取完一个队列后,取下一个队列
- Rocket内部有提供通过锁队列方式保证一个个队列来取
3. 广播消息
- 消费者集群状态下,每一条消息只会被同一个组的消费者中的一个实例消费
- 而广播消息,则会将消息发给所有订阅了对应主题的消息费者,无论是否是同一个消费组
4. 延迟消息
- 效果就是调用发送消息后,消息并不会立即送出
- 延迟时间在开源版本中提供了18个级别设置,不支持自定义时间
- 18个级别分别是1s 5s ... 30m 1h 2h
- 商业化版本中支持自定义设置延迟时间
- 开源版本要想时间,需自己修改源码
5. 批量消息
- 多条消息合成一个批量消息,一次发出
- 可减少网络IO,提升吞吐量
- 消息实际最大限制约为4M
- 批量消息,必须有相同TOPIC,不能是延迟消息与事务消息等限制
6. 过滤消息
- 大多情况可通过消息的tag来快速过滤消息
- 官方建议一般一个应用就用一个TOPIC
- 应用中不同业务,就用TAG来区分
- 实际业务中,若遇到复杂场景,此时可通过SQL表达式来对消息进行过滤
- SQL语句是按照SQL92标准执行
- SQL中可使用的参数包括TAG和生产者中加入的属性
- 只有推模式的消费者可使用SQL过滤,拉不支持
- 思考:此过滤是在Broker进行的还是Consumer?
7. 事务消息(有特殊的功能,相对复杂)
- 是Rocket中非常有特色的功能
- 原理:保证本地事务与消息发送两个操作的原子性
- 主义:只保证消息发送者的本地事务与发消息两个操作的原子性,与消费者无关
- 消息事务的3个状态:提交、回滚、未知
- 对应对应消息会被消费者消费到、丢弃、事务状态回查
- 默认单个消息回查15次,若超过,则消息将丢弃
- 事务消息的关键在于:会先发一个half半消息
- half消息对消费者不可见
- 再通过一系列事务检查机制,将half消息放入目标Topic或丢弃
- 总而言之:事务消息只保证了分布式事务的一半
- 即便如此,对与复杂的分布式事务场景,Rocket提供的这套消息事务机制也是业内目前最佳的消息事务解决方案
四、ACL权限控制(用的少,作为了解)
- 主要是对Topic资源级别的访问控制
- 可配置accesskey secretkey 白名单等
- 控制Topic的发布和订阅权限
五、消息轨迹跟踪
- RocketMQ4.5版本后提供
- 用于详细记录消息各个处理环节的日志
- 可通过内部提供的API,将消息轨迹信息存入我们设计的存储介质中
六、关于SpringCloudStream
- 一个统一的消息驱动框架
- 目的是想要以一个统一的编程模型来对接所有的MQ消息中间件产品
- 官方支持RabbitMq,Kafaka及AWS的一款MQ
- RocketMQ由产商阿里团队自行维护支持
- 更新较慢,且存在较多BUG及版本依赖问题,文档较少
- 顾对与Rocket来说Stream目前并不是一个很好的集成方案,若想使用,需慎重