滴滴出行基于RocketMQ的企业级消息队列服务构建实践

滴滴出行基于RocketMQ构建企业级消息队列服务的实践 本文主要介绍了滴滴出行为什么选择RocketMQ作为出行业务的消息队列解决方案，以及如何构建自己的消息队列服务。滴滴出行的消息技术选型经历了从混乱到规范的过程。 首先，滴滴出行的消息队列服务曾经非常混乱。公司内部没有专门的团队维护消息队列服务，导致消息队列使用方式较多，主要以Kafka为主，有业务直连的，也有通过独立的服务转发消息的。另外有一些团队也会用RocketMQ、Redis的list，甚至会用比较非主流的beanstalkkd。这种混乱的使用方式导致了无法维护、资源使用浪费等问题。 其次，滴滴出行弃用Kafka的主要原因是Kafka在使用过程中出现了集群数据写入抖动非常严重的情况，经常会有数据写失败。主要有两点原因：随着业务增长，Topic的数据增多，集群负载增大，性能下降；Kafka0.8.2版本有个bug，会导致副本重新复制，复制的时候有大量的读，影响写入。 为了解决这些问题，滴滴出行决定做自己的消息队列服务。首先需要解决业务方消息生产失败的问题。他们使用了代理层和codis作为缓存，解决了Kafka不定期写入失败的问题。然后，经过一系列的调研和测试之后，滴滴出行决定采用RocketMQ。为了支持多语言环境、解决一些迁移和某些业务的特殊需求，他们又在消费侧加上了一个代理服务。 滴滴出行的消息队列服务架构主要包括三个方向：迁移，把之前提到的所有五花八门的队列环境，全部迁移到RocketMQ上；功能迭代和成本性能上的优化；服务化，业务直接通过平台界面来申请资源，申请到之后直接使用。目前，滴滴出行的消息队列服务架构已经形成了一个核心框架，业务端只跟代理层交互。中间的消息引擎，负责消息的核心存储。 滴滴出行基于RocketMQ构建企业级消息队列服务的实践，对于企业级消息队列服务的构建提供了有价值的经验和借鉴。