Zacard's Notes

RocketMQ阅读笔记

为何选择rocketmq

选型时主要对比了kafka和rocketmq。两者还是存在较大差异的,kafka一开始的定位就是日志收集,对于订单、交易等可靠传输场景不能很好满足(消息丢失、消息重复消费等方面)。并且rocketmq是使用java编写的,相对于scala编写的kafka,我们有更大的定制与扩展的空间。

数据可靠性

  • rocketmq支持异步/同步刷盘,异步/同步复制
  • kafka异步刷盘,异步/同步复制

刷盘效率上应该是rocketmq更高。因为rocketmq的消息都写到一个文件中,而kafka的每个分区对应一个文件,rocketmq可以充分利用IO组commit机制批量传输数据。

性能对比

  • kafka单机协议TPS约在100w/s,消息大小为10字节
  • rocketmq单机写入TPS单实例约为7W/s,单机3个broker,可以跑到12w/s,消息大小为10字节

之所以kafka有如此高的TPS,是由于producer端会将多个小消息合并,批量发送至broker。rocketmq没有这做的原因:

  1. 由于使用java语言,如果producer端缓存过多消息,GC是个严重问题
  2. producer端调用发送消息接口,消息为发送到broker就返回,此时producer宕机会导致消息丢失
  3. producer通常为分布式部署,且每台机器都是多线程发送,单个producer产生的消息有限

单机支持的队列/分区数量

  • Kafka单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长。Kafka分区数无法过多的问题
  • rocketmq支持单机最高5w个队列,负载不会发送明显变化

队列/分区多的好处:

  1. 单机可以创建更多Topic,因为没有Topic都是有一批队列组成
  2. 消费者的集群规模和队列数成正比

消息投递实时性

  • kafka使用短轮询方式,实时性取决于轮询间隔时间,0.8以后支持长轮询
  • rockmq使用长轮询,同push方式实时性基本一致

消费失败重试

  • kafka不支持重试
  • rocketmq消费失败支持定时重试,每次重试间隔时间顺延

重试的场景比较适合依赖第三方的consumer,比较充值,consumer需要调用第三方运营商网关,充值失败可能是对方当前压力过大,稍后调用可能就会成功。

消息顺序

  • kafka支持消息顺序,但是在一台broker宕机后,就会产生消息乱序
  • rocketmq支持严格的消息顺序,当一台broker宕机后,发送消息会失败,但不会乱序

定时消息

  • kafka目前不支持定时消息
  • rocketmq支持定时消息

目前业务场景暂时用不到。

分布式事务消息

  • kafka目前不支持
  • rocketmq暂时没有开源事务消息

消息查询

  • kafka不支持消息查询
  • rocketmq支持根据消息表示查询,也可根据消息内容查询(发送消息时指定一个消息密钥,任意字符串,例如指定为订单编号)

这个对于消息定位非常有帮助。

消息回溯

  • kafka不支持
  • rocketmq可以按照时间回溯消息,精度毫秒

这个对于对账等功能比较有用

消息过滤

  • kafka不支持broker端过滤
  • rocketmq支持根据tag(相当于子主题)过滤

开发语言友好

rocketmq使用java,更友好。

开源社区活跃度

都比较活跃。

rocketmq消息存储

坚持原创技术分享,您的支持将鼓励我继续创作!

热评文章