rocketmq消息持久化到mysql_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面向高级用户。

或者先实现第一种，再实现第二种，覆盖初级与高级需求，最后再实现第二种，作为第一种模式的补充 。

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