延迟队列商业版RocketMQ和Pulsar的对比

目录

一、商业版RocketMQ和Pulsar的基本对比

二、核心差异

三、使用倾向

三、RocketMQ使用注意问题

---

一、商业版RocketMQ和Pulsar的基本对比

系统	实现原理	使用限制	成本	业务支持及使用	监控报警	容灾高可用	自动扩缩容（弹性）	鉴权	schema管理	数据留存	消费幂等
商业版RocketMQ	和开源RocketMQ内置18个不同周期的延迟队列，最小1s，最大2h,采用对每个队列数据轮训检测的方式消费不同。商业版延迟消息使用类Mysql存储，持久到磁盘，官网显示最大延迟7天，阿里沟通支持最大三十天的任意延迟。	同一时刻不要大量数据同时到期	计算费用有按量付费(按照时间付费/h)和包年包月两种费用。 4k为一条消息的基本计数，16k的延迟消息（高级消息），没秒发送10条则对应16/4*5*10= 200TPS 存储按量收费：存储空间×存储单价×存储时常 开启公网访问，按带宽计算公网访问费用，仅收取下行带宽费用 Dashboard和监控报警功能不收费 2000 TPS = 1300 4000 TPS= 2200 6000 TPS = 3100 TPS 包含流入和流出的TPS，可调整比值	Java Go 支持php Python C++ 等	云监控，Dashboard和监控报警功能不收费	本身支持多AZ，在创建的时候无感知 专业版和标准版在容灾方面的区别，都是多AZ容灾，RTO不一样	专业版支持流量预留，存储按量收费，无上限（标准版不支持流量预留，超过流量直接限流） 实例配置支持升降配	Ram鉴权，只支持控制台及Open Api的调用权限控制，无法控制Topic粒度的读写控制	不支持	在实例维度做留存，和是否消费无关	发送时消息重复 消费时消息重复 负载均衡时消息重复（包括但不限于网络抖动、Broker重启以及消费者应用重启）
Pulsar	内存索引+磁盘存储。支持无限期的延迟	数据量过大内存占用较高	EC2成本 8c16G300G * 3 = 2754	Java Go Python C++ 等	自搭建（prometheus+ grafana+pluto）	ec2三AZ部署	通过Ansible 进行集群扩容	JWT鉴权，支持NameSpace及Topic粒度的读写控制	支持	在队列维度做留存，和是否消费有关，由ttl和Retention决定	ACK信息的持久化1s一次，在服务出问题或者抖动情况下可能造成ACK信息的丢失，并且在生产消费的时候一样存在消息重复，和RocketMQ行为基本一致。

二、核心差异

• 硬件资源占用差异：RocketMQ 延迟消息持久到磁盘，内存占用受数据量影响较小，Pulsar内存占用和延迟消息数据量有关。
• 功能差异：RocketMQ支持消息轨迹，Pulsar不支持。
• 功能差异：RocketMQ对消息类型做了明确区分，指定队列只能生产消费指定类型的消息
• 运维效率差异：RocketMQ在扩所容方面效率更高，
• 成本差异：RocketMQ早期更节约成本。后期Pulsar更节约成本。
• 权限控制差异：Pulsar可以更方便的做namespace粒度的资源读写权限控制，RocketMQ基于ram做操作权限控制，但无法进行做Topic粒度的资源控制。
• 日志留存管理差异：pulsar对日志留存有更细的控制粒度，RocketMQ只支持实例级别。
• 功能差异：Pulsar支持schema的管理，RocketMQ不支持。

三、使用倾向

RocketMQ在稳定性、运维效率及早期成本有一定优势，优先推荐商业版RocketMQ

四、RocketMQ使用注意问题

• RocketMQ精度支持QPS极限情况是实例的读QPS限制。
• RocketMQ延迟时间默认是7天，这是服务端限制，出现超过7天的延迟会报错。想提升延迟时间的最大支持需要阿里方评估支持。
• 使用RocketMQ需要修改延迟队列方面的读写代码， 并且对超过7天的长延迟消息开发内部流转逻辑。