RocketMq消息队列服务化方案
一、rocketMq目前设计
1. 目前已有功能概况
-
架构模式
RocketMQ 与大部分消息中间件 样，采用发布订阅模式，基本的参与组件主要包括
消息发送者、消息服务器（消息存储）、消息消费、路由发现 -
顺序消息
支持严格有序 -
消息过滤
支持消息过滤，从broker端或者从消费者端过滤，推荐从broker端过滤 -
消息存储
持久化存储，性能极高 -
消息高可用性
broker双主双从及以上的集群可以满足消息可靠性要求极高的场合 -
消息到达（消费）低延迟
使用长轮询模式实时推送，能做到低延迟 -
确保消息必须被消费一次
支持至少消费一次，但是有重复消费的可能，需要手动去重或者让消息消费幂等 -
回溯消息
支持毫秒级精度的向前或者向后回溯 -
消息堆积
使用磁盘存储，默认保存3天 -
定时消息
不支持任意粒度的定时，支持固定粒度的定时任务（基本可以满足所有定时需求） -
消息重试机制
支持消息重试
2. rocketMq 简单架构
-
物理部署
avatar
-
消息消费与发布
image.png
二、企业级消息队列服务化实现方式
1. 使用HTTP推送方式
- 实现方式：消息队列服务方封装生产者和消费者，消息的生产依赖服务调用方调用网络接口，消息的消费由服务方直接使用http请求推送
- 优点：实现简单
- 缺点：效率不高，依赖网络请求，功能选择也依赖API，不灵活。无法根据消费能力控制消息发送速度。
2. 使用HTTP主动拉取方式
1.实现方式：消息队列服务方封装生产者和消费者，消息的生产通过服务调用方调用网络接口，消息的消费由服务调用者主动调用接口拉取消息。（需要做积压管理）
2.优点：相比HTTP推送性能更高，分散网络压力，服务调用方可以根据消费能力自己控制消费速度
3.缺点：服务调用方需要不停的调用接口来监控是否有消息到达。服务方实现较为困难
3. 使用SDK方式
- 实现方式：使用SDK封装二次开发消费者与生产者，把SDK提供给需要使用的服务
- 优点：使用rocketMq内部已经实现的消息通信，使用者可以任意使用rocketMQ已有的功能进行消息生产、消费
- 缺点： 需要封装SDK，初期可能开发工作量较大，使用消息队列较麻烦，对于只是简单使用消息队列的项目来说较为麻烦（需要引入SDK以及需要懂得简单的RocketMQ操作）
4. 使用基于RocketMq的开源
（也属于SDK的一种实现方式）
滴滴基于RocketMq的开源项目DDMQ
低延迟高吞吐：毫秒级延迟，单机百万条消息吞吐。
丰富的消息类型：具备实时消息、延时消息和分布式事务消息。
海量消息存储，支持消息回溯消费：支持 RocketMQ 和 Kafka 作为实时消息的存储引擎，使用 RocksDB 作为延时消息的存储引擎。
秒级延时消息：支持单条消息设置精确到秒级的延迟时间，提供普通延时消息和循环延时消息。
多语言客户端：提供了主流开发语言 SDK，包括 PHP、Java、Go、C/C++ 与 Python，在 API 上保持着最易使用的 High Level 形式。
多种消费方式：支持通过 Thrift RPC 拉取、HTTP 推送和第三方存储直写的方式消费消息。
支持灵活的消息过滤和转换功能：通过使用 Groovy 脚本在服务端进行消息体的转换和过滤，能够有效减少客户端和服务器的数据传输量，减轻客户端处理消息的负载。
统一的 Web 控制台：方便用户管理 Topic 等资源，通过控制台可以实现配置生产和消费的限流值、消费方式、Groovy 脚本、启停消费与重置消费进度等功能。
完善的监控配套：提供模块的健康检查和消息堆积告警功能。
依赖如下：
- 64位操作系统，Linux / Unix / Mac
- 64位JDK 1.8+
- Maven 3.2.x.
- MySQL 5.7.x
- Tomcat 7/8/9
- Zookeeper 3.4.x
优点 ：基于SDK实现方式，SDK已有开源且有web控制台页面。功能基本已经完善。无需开发，调试部署可以满足生产需求
缺点 ：目前版本v1.0，2019年1月发布。虽然使用的是原生的RocketMq-4.2.0，但是网上教程较少，遇到问题解决较为麻烦，需要时间熟悉源码。
三、各个模式具备的功能
| 功能 | 1. Http推送消费模式 | 2. Http拉取消费模式 | 3. SDK模式 | 模式比较 |
|---|---|---|---|---|
| 顺序消息 | 不支持 | 支持 | 支持 | 3>2>1 |
| 消息过滤 | 支持 | 支持 | 支持 | 1=2=3 |
| 消息持久化 | 支持 | 支持 | 支持 | 1=2=3 |
| 高可用 | 高 | 高 | 超高 | 3>2>1 |
| 消息低延迟 | 一般 | 较低 | 低延迟 | 3>2>1 |
| 消息延迟因素 | 依赖网络/机器性能 | 依赖接口/网络性能 | 长连接基本无依赖 | 3>2>1 |
| 消息重试 | 发送http返回失败重试 | 消费者手动塞回队列重试 | 消费失败重试 | 3>1>2 |
| 定时消息 | 不支持 | 支持 | 支持 | 3>2>1 |
| 广播模式 | 支持，需 指定群发地址 | 不支持 | 支持 | 3>1>2 |
| 分析 | 比较 |
|---|---|
| 实现难度 | 2>3>1 |
| 预计工时（单人） | 1. 预计8天 2. 预计10~15天 3.预计10~15天 |
四、建议
建议先实现第一种HTTP推送消费模式，然后再拓展兼容第二种HTTP拉取消费模式，最后再实现第三种，开发SDK面向高级用户。
或者先实现第一种，再实现第二种，覆盖初级与高级需求，最后再实现第二种，作为第一种模式的补充 。
如果不打算从零开始建设服务化消息队列，可以使用第四种方案
