RocketMq消息队列服务化方案

一、rocketMq目前设计

1. 目前已有功能概况

• 架构模式
  RocketMQ 与大部分消息中间件 样，采用发布订阅模式，基本的参与组件主要包括
  消息发送者、消息服务器（消息存储）、消息消费、路由发现
• 顺序消息
  支持严格有序
• 消息过滤
  支持消息过滤，从broker端或者从消费者端过滤，推荐从broker端过滤
• 消息存储
  持久化存储，性能极高
• 消息高可用性
  broker双主双从及以上的集群可以满足消息可靠性要求极高的场合
• 消息到达（消费）低延迟
  使用长轮询模式实时推送，能做到低延迟
• 确保消息必须被消费一次
  支持至少消费一次，但是有重复消费的可能，需要手动去重或者让消息消费幂等
• 回溯消息
  支持毫秒级精度的向前或者向后回溯
• 消息堆积
  使用磁盘存储，默认保存3天
• 定时消息
  不支持任意粒度的定时，支持固定粒度的定时任务（基本可以满足所有定时需求）
• 消息重试机制
  支持消息重试

2. rocketMq 简单架构

• 物理部署
  avatar
• 消息消费与发布
  image.png

二、企业级消息队列服务化实现方式

1. 使用HTTP推送方式

1. 实现方式：消息队列服务方封装生产者和消费者，消息的生产依赖服务调用方调用网络接口，消息的消费由服务方直接使用http请求推送
2. 优点：实现简单
3. 缺点：效率不高，依赖网络请求，功能选择也依赖API，不灵活。无法根据消费能力控制消息发送速度。

2. 使用HTTP主动拉取方式

1.实现方式：消息队列服务方封装生产者和消费者，消息的生产通过服务调用方调用网络接口，消息的消费由服务调用者主动调用接口拉取消息。（需要做积压管理）
2.优点：相比HTTP推送性能更高，分散网络压力，服务调用方可以根据消费能力自己控制消费速度
3.缺点：服务调用方需要不停的调用接口来监控是否有消息到达。服务方实现较为困难

3. 使用SDK方式

1. 实现方式：使用SDK封装二次开发消费者与生产者，把SDK提供给需要使用的服务
2. 优点：使用rocketMq内部已经实现的消息通信，使用者可以任意使用rocketMQ已有的功能进行消息生产、消费
3. 缺点： 需要封装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面向高级用户。
或者先实现第一种，再实现第二种，覆盖初级与高级需求，最后再实现第二种，作为第一种模式的补充 。

如果不打算从零开始建设服务化消息队列，可以使用第四种方案