目录
一、商业版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天的长延迟消息开发内部流转逻辑。
