RocketMQ 在网易云音乐的实践

RocketMQ 在网易云音乐的实践

本文作者:蒋星韬,网易云音乐服务端开发工程师。


RocketMQ 在网易云音乐的实践

云音乐线上场景众多,比如直播、评论、广告,各个业务线都会有消息场景比如发奖券,也会有延迟消息和事务消息场景,以及大数据做埋点数据、数据清洗、离线处理等。


云音乐线上 RocketMQ topic 为 1 万+/天,QPS 流量峰值为150万/s,日消息量千亿级别。为了支撑庞大的数据规模和场景,除了搭建开源RocketMQ集群,我们也做了监控的完善和工具体验。监控完善主要包括对整个集群的容量、状态、水位进行健康状态的监控,针对消息的发送和消费提供流量、延迟、失败、耗时等监控指标。基于以上监控指标,还需搭建一套业务巡检体系,以实现线上告警。


另外,我们也提供改了一些工具帮助业务方提升使用 RocketMQ 的体验,比如数据迁移和同步消息路由的组件,提供稳定性保障的限流能力、降级能力以及动态参数干预的预案能力。当线上业务方发现消费不符合预期时,需要提供查询帮助其快速定位,以及提供死信处理工具等。


RocketMQ 在网易云音乐的实践

云音乐目前有三个机房,每个机房部署了一套 RocketMQ 集群,除了 Manesrv、 HA 等基础组件,还有自研或开源改造的组件,比如 monitor 组件、告警巡检组件、降级维稳组件等。


每个机房里有一套平台化的管控组件,管控端包含提工单、上下线、查数据、订阅问题,还包括一套消息路平台和数据库。

RocketMQ 在网易云音乐的实践

网易云音乐拥有多个流量入口,不同业务的数据和流量需要做隔离,每个租户下都是一套独立的业务线。而物理隔离成本过高,因此我们实现了逻辑隔离。各个业务之间流量不互通,逻辑上无法相互调用,且租户下所有 topic 名字一致,中台只需要切换租户名,无需改动任何其配置、代码,即可直接上线。


所有 topic 都在一个物理集群内,每个租户有自己的一套逻辑集群,逻辑集群内有自己的 topic,不同逻辑集群之间的 topic 同名,实现了多租户隔离。

RocketMQ 在网易云音乐的实践

随着云音乐的业务愈发庞大,业务方提出了更多需求。比如异地多活,消息需要在多个机房消费,比如通用埋点数据,需要将多个产品的数据汇总到机场的数据处理集群做离线处理,比如架构升级,不同单元间的流量能够动态调度。


基于以上需求,消息路由需要实现以下几个功能:

① 跨机房消息复制。

② 流量去重:消息路由在复制时不可避免会有失败,因此必然有内部的重试,可能会导致有消息重复;此外,双向路由必然需要提供双向复制,而两边 topic 名字一样,复制时会导致错乱,因此需要有标签来实现流量重。

③ 数据迁移任务。

④ 监控完善,进度可控。

RocketMQ 在网易云音乐的实践

云音乐的消息路由实现方案如上图所示。


首先,在管控平台会维护一套路由任务元数据表,业务方可以提工单或者通过其他方式申请路由任务,支持任意机房的任意两个 topic 之间做消息路由。任务提交之后,消息路由集群会定时同步管控端上的消息路由任务的状态,同时将消息发送到目标 topic 。路由任务能够自行上报监控数据、消费延迟、堆积监控报表等,可在管控端进行查看。

RocketMQ 在网易云音乐的实践

云音乐的数据处理任务包括埋点、trace,大多使用Flink。但由于开源方向没有与我们的需求非常匹配的 connector ,因此我们封装实现了自己的 RocketMQ Flink connector。

RocketMQ 在网易云音乐的实践

因为内部封装了接口和集群配置,RocketMQ 作为 Flink 的 source 和 sink 需要有数据源的配置。我们对数据源做了封装,比如 connector 如何解析元数据,从而正确地连接数据源、读写消息。


大数据任务的特点为测试环境与线上数据会混在一起,多环境都有接入需求,因此我们设计了一套元数据,使得 connect 能够连接多环境且能够处理多环境里面流量标、环境标等标签的过滤。


Flink有自己的 checkpoint 机制,只有在做 checkpoint 时才会将 consumer offset 提交给 broker ,同时需要对 consumer offset 进行管理,否则消费位