RocketMQ开发者沙龙

待询问的问题：

1. 安全
2. 插件
3. CHAS
4. 备机接管

暖场

1. 目前正在考虑多语言的支持，后续新增C++, PYTHON, NODE.JS等客户端.
2. OpenMessaging v1.0 Pre-Review版本即将发布

PS：主持人真的是技术出身，暖场略尴尬。

1. Apache RocketMQ 101 ——刘振东

问题场景

1. 异步、解耦
2. 削峰填谷
3. 排队引擎

Comment：我自己总结的大约是4种能力：异步解耦；削峰填谷；压力转移；任务分配。

基本概念

概念模型 Producer----Topic----Consumer

基本模型

存储模型

• Pub-Sub / Producer / Consumer
• Topic / MessageQueue
• CommitLog / ConsumerQueue/Offset
• Broker / Nameserver

mqadmin工具，可远程访问NameServer，查询集群状态等丰富的功能。

好用的mqadmin工具

NameServer保存的是所有的信息，那是否有一定上限？
回答：NameServer只存储broker的路由信息，不保存consumer offset。

最常用的功能：

1. 发送消息，查看消息在不在
2. Broker状态
3. 消费消息，查看还有多少消息

使用消息系统时容易碰到的问题

1. 幂等
   通过业务ID解决
2. 顺序
   分区有序，非严格有序
   顺序消息的扩容：
   停写：保证消息消费完成后再扩Queue
   不停写：成倍扩容可以保证哈希不会到错位的queue
3. 消费位点重置
   可以消费者在线实现位点重置
4. 补数
   黑科技：%RETRY%CLIENT可以指定消费者补数

特性

1. Schedule
   分级定时机制，时间轮特性，未发布

   
   
   时间轮

2. Batch
   通过Batch实现原子一致性

3. Filtered by Tag
   通过Tag进行消息过滤
   支持SQL语法

4. 事务

2. Sentinel

负责流量的控制，限流，熔断降级
通过令牌机制来进行流量控制

Hystrix VS Sentinel

• 设计理念不同
• 熔断概念不同
• 目标集不同

可集成到RocketMQ的客户端中

1. 引入Jar包

2. 增加代码
   客户端级别的削峰填谷

   
   
   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%的可用性要求

策略：

1. 先跑起来
   使用THRIFT实现简单的功能
   客户端最简化
   最小化用户功能
2. 迁移
   将应用逐步迁移到RocketMQ上
   Producer Proxy和Consumer Proxy支持数据的双写双读，同时从Kafka和RocketMQ上写数据读数据。

自己实现的功能：

1. 主备自动切换
2. BATCH的扩展，支持不同TOPIC不同QUEUE的写入
3. 百万TOPIC的支持：元数据管理的优化
4. 集成内部监控和部署工具
5. BUG-FIX

踩过的坑：

1. 读老数据：random IO导致。通过在备机做操作来实现。同步主备会有影响。
2. 删除过期数据导致IO飚高：默认保存72小时，默认凌晨4点删除。FILERESERVEDTIME, DELETEWHEN, DELETECOMMITLOGFILESINTERVAL, DELETECONSUMERQUEUEFILESINTERVAL.
   可通过设置多个删除时间点来缓解
3. 消息索引的建立可以放在备机上实现。

4. 事务消息

XA事务（两阶段提交）带来的问题：资源的阻塞
三阶段提交增加pre-commit和pre-rollback可以达到最终一致性。

XA、SAGA、TCC

RocketMQ的处理方式

关键点：

1. Half Topic。由Broker拦截，并保存事务消息到Half Topic
2. 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个小时，我的状态已经有点懵逼了……

干货满满，感谢。

讲师