滴滴基于RocketMQ架构演变调研

业务问题

据滴滴介绍2014年使用的Kafka-0.8.2,一个核心业务在使用Kafka的时候,出现了集群数据写入抖动非常严重的情况,经常会有数据写失败。

• 随着业务增长,Topic的数据增多,集群负载增大,性能下降
• 有个文件读写锁bug,会导致副本重新复制,复制的时候有大量的读,我们存储盘用的是机械盘,导致磁盘IO过大,影响写入

发展历程

滴滴初期MQ现状

初期,公司内部没有专门的团队维护消息队列服务,所以消息队列使用方式较多,五花八门很凌乱:

  • 主要以Kafka为主,有的业务直连的,也有通过独立的服务转发消息的
  • 有一些团队业务用RocketMQ
  • 有部分团队业务Redis的list
  • 少数业务非主流的beanstalkkd。

因为以上原因,导致的结果就是,比较混乱,无法维护,资源使用也很浪费。以下图表示业务基本使用情况

滴滴基于RocketMQ架构演变调研_第1张图片 

Kafka前置Proxy服务

Kafka在滴滴属于重度使用,一个topic涉及到的下游业务也就非常多,没办法一次性直接替换Kafka,只能分步骤进行。首先解决业务生产失败问题,为Kafka集群前置增加一个Proxy

滴滴基于RocketMQ架构演变调研_第2张图片

 

利用codis作为缓存,解决了Kafka不定期写入失败的问题,如上图。当后面的Kafka出现不可写入的时候,我们就会先把数据写入到codis中,然后延时进行重试,直到写成功为止。 

Proxy新增消息引擎RocketMQ

滴滴基于RocketMQ架构演变调研_第3张图片

 

为了支持多语言环境、解决一些迁移和某些业务的特殊需求,新增RocketMQ作为消息引擎,业务端只跟代理层Proxy交互。中间的消息引擎,负责消息的核心存储。后续主要围绕三个方向做深度开发

  • 消息队列统一,其他队列迁移到统一消息队列平台上。
  • 功能迭代和成本性能上的优化。
  • 服务化,业务直接通过管理平台来申请资源,申请审批成功后就可以使用。

 滴滴MQ架构

 滴滴基于RocketMQ架构演变调研_第4张图片

以上是滴滴当前消息队列系统架构,他具有以下特点:

  • 支持7种语言客户端
  • 其他服务逐步统一迁移到存储引擎RocketMQ上
  • 支持多协议,例如HTTP协议RESTfu
  • 利用groovy脚本功能可以转存消息到Redis、Hbase和HDFS上
  • 与实时计算平台对接,例如Flink,Spark,Storm
  • 使用topic要申请审批通过才可使用,填写信息为:Topic,填写各种信息,包括身份信息,消息的峰值流量,消息大小,消息格式等等
  • 运维控制台,主要负责我们集群的管理,自动化部署,流量调度,状态显示之类的功能。最后所有运维和用户操作会影响线上的配置,都会通过ZooKeeper进行同步

为什么选择RocketMQ

通过Kafka与RocketMQ进行性能测试比较,结果如下:

  • Kafka吞吐受Topic数量的影响特别明显,单机器partitions数量超过2000,超过了越多性能越低。RocketMQ吞吐量比Kafka低30~40%,但不受单机partitions分片数量影响,吞吐性能基本保持稳定不变
  • 延迟性比较,同步刷盘方面Kafka延时比RocketMQ高

 

博客引用地址:https://www.cnblogs.com/lizherui/p/12660853.html

你可能感兴趣的:(滴滴基于RocketMQ架构演变调研)