RocketMQ开发者沙龙-20180901
RocketMQ开发者沙龙
待询问的问题：
- 安全
- 插件
- CHAS
- 备机接管
暖场
- 目前正在考虑多语言的支持，后续新增C++, PYTHON, NODE.JS等客户端.
- OpenMessaging v1.0 Pre-Review版本即将发布
PS：主持人真的是技术出身，暖场略尴尬。
1. Apache RocketMQ 101 ——刘振东
问题场景
- 异步、解耦
- 削峰填谷
- 排队引擎
Comment：我自己总结的大约是4种能力：异步解耦；削峰填谷；压力转移；任务分配。
基本概念
概念模型 Producer----Topic----Consumer
基本模型
存储模型
- Pub-Sub / Producer / Consumer
- Topic / MessageQueue
- CommitLog / ConsumerQueue/Offset
- Broker / Nameserver
mqadmin工具，可远程访问NameServer，查询集群状态等丰富的功能。
好用的mqadmin工具
NameServer保存的是所有的信息，那是否有一定上限？
回答：NameServer只存储broker的路由信息，不保存consumer offset。
最常用的功能：
- 发送消息，查看消息在不在
- Broker状态
- 消费消息，查看还有多少消息
使用消息系统时容易碰到的问题
- 幂等
通过业务ID解决 - 顺序
分区有序，非严格有序
顺序消息的扩容：
停写：保证消息消费完成后再扩Queue
不停写：成倍扩容可以保证哈希不会到错位的queue - 消费位点重置
可以消费者在线实现位点重置 - 补数
黑科技：%RETRY%CLIENT可以指定消费者补数
特性
-
Schedule
分级定时机制，时间轮特性，未发布
时间轮
-
Batch
通过Batch实现原子一致性 -
Filtered by Tag
通过Tag进行消息过滤
支持SQL语法 -
事务
2. Sentinel
负责流量的控制，限流，熔断降级
通过令牌机制来进行流量控制
Hystrix VS Sentinel
- 设计理念不同
- 熔断概念不同
- 目标集不同
可集成到RocketMQ的客户端中
- 引入Jar包
-
增加代码
客户端级别的削峰填谷
RocketMQ的客户端监控
客户端的流控
3. 通过RMQ构建企业级别的消息平台
STAGE 0. 各个应用使用各自的消息队列
STAGE 1. TOPIC数量增加导致Kafka无法承载，设置Producer-Proxy来解决Kafka 0.8的bug
STAGE 2. 调研选择一个MQ引擎
STAGE 2
STAGE 3. 数据迁移、功能迭代优化、服务化
消息平台架构很完整
平台架构
当时使用RocketMQ面临的挑战
- 多语言支持
- 研发人员少
- 无源码阅读
- 时间紧张
- 99.995%的可用性要求
策略：
- 先跑起来
使用THRIFT实现简单的功能
客户端最简化
最小化用户功能 - 迁移
将应用逐步迁移到RocketMQ上
Producer Proxy和Consumer Proxy支持数据的双写双读，同时从Kafka和RocketMQ上写数据读数据。
自己实现的功能：
- 主备自动切换
- BATCH的扩展，支持不同TOPIC不同QUEUE的写入
- 百万TOPIC的支持：元数据管理的优化
- 集成内部监控和部署工具
- BUG-FIX
踩过的坑：
- 读老数据：random IO导致。通过在备机做操作来实现。同步主备会有影响。
- 删除过期数据导致IO飚高：默认保存72小时，默认凌晨4点删除。FILERESERVEDTIME, DELETEWHEN, DELETECOMMITLOGFILESINTERVAL, DELETECONSUMERQUEUEFILESINTERVAL.
可通过设置多个删除时间点来缓解 - 消息索引的建立可以放在备机上实现。
4. 事务消息
XA事务（两阶段提交）带来的问题：资源的阻塞
三阶段提交增加pre-commit和pre-rollback可以达到最终一致性。
XA、SAGA、TCC
RocketMQ的处理方式
关键点：
- Half Topic。由Broker拦截，并保存事务消息到Half Topic
- Op Topic：状态消息的偏移量，服务端启动扫描half和op topic的差异，判断half topic里的消息是否需要投递到真实的user topic中。
生产者最佳实践
消费者及broker的最佳实践
5. MQTT Bridge for Apache RocketMQ
核心问题：可用性、实时性、可靠性
可用性
服务发现问题：使用DNS server进行bridge的注册
快速故障恢复：通过无状态+共享存储实现
实时性
通过解耦消费者的ack实现
高可靠
消息存储实现。
bridge模型
6. 流处理
- RMQ + STORM
- RMQ + SPARK
- RMQ + FLINK
-
RMQ + AVRO
一个使用flink与rmq结合的案例
话说听到这里已经听了3个小时，我的状态已经有点懵逼了……
干货满满，感谢。
讲师
