字节跳动消息队列架构演进：从Kafka兼容到存储计算分离的高并发实践

走进字节的消息队列体系是我这几年研究高并发中间件时收获最大的一段经历。我一直觉得消息队列是分布式系统里最“皮实”又最“娇贵”的一层平时安安静静在业务和数据之间做缓冲一旦流量洪峰来了或者消费端出了点小故障它立刻成为整个架构的焦点。字节跳动作为典型的超大规模互联网公司每天要处理的消息量级、Topic数量、跨机房容灾场景都不是教科书上那套简单的Kafka用法能覆盖的。这篇内容我想完整拆解一下字节跳动消息队列的架构演进、核心设计思路以及在真实业务中反复踩过的坑特别是网上大家问得最多的重复消费、消息堆积、顺序性这些问题。如果你是做后端开发、中间件运维或者正在设计高吞吐数据链路这篇文章应该能给你一些非常实在的参考。字节跳动内部的消息队列并不是一开始就有自研体系的。早期业务规模还没有现在这么夸张的时候社区版的Kafka基本够用但随着业务线越来越多从推荐、搜索、广告到直播、电商、支付每个团队都在用MQ问题就接踵而至——集群规模暴涨、运维成本高企、跨机房同步困难很多问题已经到了不能靠“多搭几套集群”来解决的程度。后面他们逐步演进出了自己的消息队列体系外面能看到的是字节云上开放的BMQ内部实际上还有多套配套的消息基础设施。1. 字节跳动的消息队列演进与整体架构思路1.1 为什么超大规模业务需要自研消息队列回答这个问题得先看懂消息队列在字节的业务里到底承担什么角色。字节的核心业务形态决定了它几乎所有在线服务都极度依赖异步化和削峰填谷。比如你在信息流产品里刷到一个内容这个动作会同步触发曝光上报、行为日志、特征计算、实时推荐模型更新、广告计费等一长串操作。如果这些操作全部走同步调用请求延迟会到什么程度可能你刷一个页面后端要等下游十几个系统全部返回才算完成这根本不可能。所以消息队列在这里面承担的是“异步总线”的角色所有非关键路径的操作都丢到消息队列里下游各自消费互不阻塞。这种模式下业务对消息队列的要求就不是“能不能用”那么简单了而是要在极高吞吐下保持稳定、在大规模Topic数量下保持性能、在跨机房容灾下保持一致性。社区版Kafka在千级Topic以下表现还行但字节的业务到了万级、十万级Topic规模时Kafka的短板会非常明显分区越多控制器和元数据管理的压力越大文件句柄、内存占用都会跟着上去最后变成整个集群的瓶颈。还有一点很重要Kafka的存储和计算是耦合的分区所在节点既负责存储也负责服务读写请求扩容和缩容的时候就要做数据搬迁这个过程既慢又容易影响在线读写。对字节这种一天到晚都在做活动、做扩容的体量来说这种架构弹性太差。我记得有个数据可以说明问题字节内部很多核心链路的Topic峰值TPS是百万级起步部分大促场景会冲到千万级。这种数字下任何一个环节的设计不合理都会被放大成事故。比如ack机制、刷盘策略、页缓存管理、网络模型任何一个细节出了偏差代价都是直接的业务受损。所以自研这条路本质上不是炫技而是业务体量倒逼出来的必然选择。1.2 从Kafka兼容到存储计算分离自研BMQ的演进逻辑字节的消息队列体系最开始的路线非常务实做一个Kafka兼容的消息队列也就是BMQ。这个选择很聪明因为Kafka生态太成熟了客户端、监控、大数据生态都围绕Kafka建立起来了如果自研一套完全不同的协议客户端的改造成本能把业务团队逼疯。BMQ的定位就是客户端走Kafka协议服务端是全新实现这样业务的接入成本几乎为零同时服务端可以按字节自己的场景去优化。BMQ的架构核心是存储计算分离。传统Kafka一个broker节点既存数据又服务读写BMQ则把存储层拆出来用了一套分布式的日志存储系统来存放消息数据计算层只做协议解析、消费协调、流控这些事。这个设计带来的直接好处是扩容不再需要搬迁数据。计算节点不够了加节点就行存储容量不够了扩展存储集群就行。两边的弹性是独立控制的对一个频繁需要扩容的大规模系统来说这个优势太关键了。我在实际给业务团队做技术方案评审的时候经常被问到“Kafka到底能不能支撑几万Topic”这种问题。说实话如果用自建的Kafka几万Topic不是不能跑但你的运维团队会很痛苦。控制器要管理几万个分区的元数据leader切换、ISR收缩、副本同步这些操作的频率会非常高任何一个环节不稳定都可能引发雪崩。BMQ这种存储计算分离方案就没有这个问题因为它的控制面和数据面是解耦的Topic的管理成本和实际的数据存储成本被拆开了海量Topic场景下才能保持稳定的性能表现。这一点我觉得是字节消息队列整个架构体系里最具代表性的一笔。2. 消息队列核心机制拆解从生产到消费的完整链路2.1 生产端高吞吐写入背后的分区与批量策略很多人在使用消息队列时拿到就直接用不太关心生产端的写入链路会怎样影响整体性能。真实场景里生产端的效率很大程度上决定了整个消息队列系统能不能扛住洪峰。字节的消息队列生产端设计里有几个细节很有意思。分区策略是第一个关键点。消息队列的分区概念本质上就是一个并行度的划分分区数越多消费并行度越高但同时也会带来更多的元数据和存储开销。字节的业务里分区策略默认是按消息的key做哈希保证同一个key的消息进入同一个分区。为什么这个很重要因为很多业务场景下同一个用户、同一个订单、同一个设备产生的多条消息是有顺序关系的如果它们分散到了不同分区消费端看到的顺序就乱了。但如果你不分青红皂白所有消息都用同一个key那所有消息都进同一个分区又会导致热点和并行度下降。这里就需要业务根据自己的语义来选key我们实际调优的时候经常碰到因为乱用key导致单个分区堆积的情况后面我专门写一次这个问题。批量发送是另一个关键点。单条消息发送的网络往返开销非常大尤其是TPS很高的时候如果一条条地发网络开销和系统调用都会成为瓶颈。生产端常规的做法是攒一批消息再统一发送攒批的条件通常是两个攒够一定条数或者到了时间阈值。字节这边的实现思路类似但对时间阈值的设置非常敏感——阈值太大会增加消息延迟阈值太小又攒不了多少。线上我们一般会根据业务场景调整这个值日志类场景对延迟不敏感阈值可以放大到几十甚至上百毫秒但交易、支付这类场景延迟直接影响用户体验阈值就要压到几毫秒甚至更低。这里面没有绝对正确的参数只有适合场景的参数。生产端的发送确认机制也值得单独拿出来说。大多数消息队列支持多种确认级别比如发完不管、leader写入确认、全部副本写入确认。确认级别越高数据越安全但延迟也越大。字节的核心业务基本都是最高级别确认因为数据丢不起。但很多非核心业务比如行为日志、监控上报这类延迟极其敏感的就会用更低级别的确认来换吞吐。这块没有统一答案需要根据数据的重要性来权衡。2.2 服务端存储结构、刷盘策略与副本同步的设计原则如果说生产端的优化是“锦上添花”服务端的存储设计就是“雪中送炭”。消息队列本质上一个系统要实现的是写入消息、保存消息、按顺序消费消息。这三个诉求写起来都很简单但要在极高吞吐下同时满足每个细节都需要精心设计。存储结构上顺序写是关键中的关键。机械硬盘或者SSD的顺序写性能远高于随机写消息队列的消息追加写入天然就是顺序的所以存储引擎的核心就是尽量把随机读写转化为顺序读写。Kafka的segment文件设计就是这个思路——一个Topic的分区对应一个目录目录里是一组有序的segment文件新消息直接追加到当前活跃的segment文件末尾。这样写路径非常短刷盘压力也小。我在字节的消息队列服务端实现里看到了类似的设计哲学但是做了更多针对海量Topic的优化。比如多个小Topic的消息会合并存储在同一个底层日志段里而不是每个Topic单独建文件否则十万个Topic就意味着十万个文件句柄这个开销是操作系统层面扛不住的。刷盘策略是最常被低估的一环。很多人以为刷盘越频繁越安全但磁盘写入频率是有物理上限的。消息队列常见的刷盘方式有三种完全异步刷盘、每N条消息刷盘、定时刷盘。完全异步速度最快但宕机丢数据定时刷盘则是通过时间窗口来权衡。字节的做法通常是在内存中维护一个缓冲达到一定容量或时间后再批量刷盘同时通过副本机制来保证单点故障时不丢数据。也就是说单机刷盘策略可以适当激进一些因为可靠性由副本机制兜底刷盘只负责性能。副本同步机制是消息队列可靠性的最底层保障。一条消息写入leader副本之后要等到足够多的follower副本同步完成才能向生产端返回“写入成功”。这个过程中涉及一个同步副本集合的概念——ISR。如果某个副本同步太慢或者断开了就会被踢出ISR等它重新跟上再拉回来。这里有个隐性风险如果leader副本所在机器宕机了而ISR里只剩它自己那消息就可能丢失。怎么办只能从ISR里选一个副本作为新的leader但ISR里没有其他副本可选系统只能允许一定程度的不可用来保证不丢数据。所以很多消息队列的参数配置都有“牺牲可用性换取一致性”或者反过来“牺牲一致性换取可用性”的选择这个度必须结合业务场景来判断。3. 业务落地实战消息队列使用中最容易踩的坑3.1 重复消费问题如何系统性地解决重复消费是消息队列里被问得最多的问题。我看热搜词里也有这个说明大家对它真的很头疼。先说结论消息队列本身只能保证“至少一次”投递也就是消息不丢但可能重复。真正要做到“恰好一次”必须由消费端配合做幂等处理。为什么消息会重复大概率出在消费端。举个例子你从一个消息队列里拉了一批消息处理了一些还没提交offset进程突然宕机或者网络断开了。等恢复之后消息队列会把之前没提交的这批消息重新发给你于是你没有处理完的那条消息就被消费了两次。客服端重试也是同一个道理下游接口超时后重发而下游可能已经成功处理了。本质上要解决重复消费就要做到“即使消费了两次业务结果也是一样的”。幂等性设计的核心思路有几种。第一种是唯一键去重。每一条消息里都带一个唯一的业务ID消费的时候先查一下这个ID是不是已经处理过了处理过就直接跳过。这个方案简单直接难点在于“查一下”这个动作必须是原子的否则两个并发请求同时查到不存在就都去处理了。所以通常要配合数据库唯一索引或者Redis的SETNX命令来做。第二种是状态机校验。如果业务对象本身有明确的状态流转那消费时可以先检查当前状态是不是允许执行这个操作。比如订单已经从“待支付”变成了“已支付”那再收到“支付成功”的消息时直接忽略即可。第三种是悲观或乐观锁配合。更新数据时带上版本号版本不对就说明已经被改过了直接丢弃。三种方案没有绝对的优劣取决于业务形态但我的体会是最稳妥的往往是组合拳唯一键加状态机校验一起上双保险。还有一个必须提醒的地方不要指望消息队列帮你把重复消息过滤掉这是不可能完成的任务。消息队列的重试机制、ack机制、failover机制本身就是以“可能重复”为前提设计的。你在设计系统的时候从一开始就要把“消费方的代码天然要能容忍重复”作为基本假设这样后面线上出问题时你会轻松很多。3.2 顺序消息与延迟消息的几种现实实现顺序性是消息队列里另一个让人头疼的点。严格来说如果你在Kafka或者BMQ里面设置了相同的key那么同一分区内的消息就是有序的消费端也能按顺序处理。但问题在于当你的消息没有被正确地设置key或者你的消费逻辑里用到了并发消费、多线程处理顺序就容易被打破。比如一个典型的电商下单场景用户下了一笔订单然后取消了订单。这两条消息如果都进同一个分区并且消费端单线程处理那顺序一定是“下单”在前“取消”在后。但是如果消费端做了多线程并发哪怕消息在同一个分区里顺序正确处理时也可能出现先处理了取消、再处理下单的情况。这就非常灾难了。所以如果你对顺序性有硬性要求消费端最好使用单线程消费或者用key做一致性哈希让同一个业务实体的消息始终落到同一个处理线程上。另一个细节是消费端处理失败会触发重试重试可能会导致排序错乱所以顺序消费场景下一定要谨慎使用失败重试或者在重试的时候也保持同一分区的顺序。延迟消息在字节的内部使用也非常频繁。比如订单超时未支付自动关闭、直播预约提醒这些场景都需要“延迟一段时间再投递”。消息队列本身不天然支持延迟常见的实现方式有三种第一种是用时间轮实现消息在服务端按时间排序到时间点再投递给消费者第二种是用分级队列实现第1秒进第一级第5秒移到第二级第10秒再移到第三级用RabbitMQ官方插件的方式来实现第三种是用一个专门的延迟消息Topic让你的应用自己去定时扫描。字节的消息队列对延迟消息的支持做得相对完善但我的建议仍然是延迟消息的数量不宜过大过大的延迟消息堆积会严重消耗服务端的内存和扫描资源。能用定时任务解决的就不要丢给消息队列。3.3 消息堆积从发现到解决的完整排查链路消息堆积是所有消息队列使用者都会遇到的问题。简单来说生产端的写入速度远远大于消费端的处理速度消息就会在队列里积压消费延迟会越来越大。轻微的堆积只是让下游的数据时效性变差严重的堆积会直接把磁盘写满甚至导致消息过期丢失。排查消息堆积我最常用的路径是从三个方向同时看看是否分区不均衡看消费端是否有异常看下游依赖是否变慢。分区不均衡是我遇到最多的场景。正常情况下一个Topic有多个分区多个消费实例分别消费不同的分区。但如果某个分区的消息特别多——比如某些热点key导致的——那负责这个分区的消费实例就会很忙其他实例却很闲。这种情况下整个消费者组的TPS上不去堆积会越来越明显。排查方式上我一般用消息队列控制台查看每个分区的消费延迟如果发现某一个分区的Lag特别大那就是分区热点问题。解决方案往往是调整key策略把热点key打散或者增加分区数并调整路由。消费端异常也很好排查通常就是看消费者的日志和监控。比如消费线程阻塞、连接池耗尽、RPC超时、数据库连接打满这些都会导致消费速度骤降。线上经常出现的一种情况是消费端下游的数据库或者外部接口变慢了消费线程都卡在等待响应上导致整体消费速度下降。这种情况光扩容消费端实例是没有用的因为它不是消费端自身的问题而是依赖的问题。正确姿势是先恢复下游依赖的性能再进行消费积压的追赶。还有一个很容易被忽略的点消息体过大导致的消费慢。有些团队喜欢把大对象整个塞进消息里一个消息几十KB甚至几百KB这样序列化和反序列化的成本都很高消费速度自然上不去。我的经验是消息队列里只传关键信息大数据不要走MQ让它走对象存储消息里存个引用地址就行。这个习惯能帮你避免大量不必要的性能问题。4. 常见问题速查与实操过程经验记录4.1 线上排查工具与关键监控指标排查消息队列问题第一步是确保你有一块好用的“仪表盘”。不要等出了问题才临时去看日志那会非常被动。我在实际运维中的习惯是提前把核心指标都铺到监控大盘上一旦出问题先看大盘缩小范围再决定要不要看日志。关键监控指标我分成三类第一类是生产端指标生产TPS、生产成功率、生产平均耗时、生产P99耗时。任何一项出现明显波动优先看生产端的代码是不是有异常分支比如某个批次的序列化失败导致重试风暴。第二类是存储端指标消息积压量、磁盘读写速率、磁盘使用率、刷盘耗时。磁盘使用率是最容易触发事故的指标消息队列集群的磁盘一定要预留充足的空闲空间否则一旦写满整个集群都可能进入只读保护业务直接受损。第三类是消费端指标消费TPS、消费延迟Lag、消费失败次数、消费者线程活跃数。消费Lag是最直观的健康度指标我建议直接对消费Lag做告警监控而不是等业务反馈说数据延迟了再去查。好的监控是排查问题的基础。很多刚入门的同学上来就查日志效率非常低。经验丰富的运维老手通常是这样做的监控大盘看全局确认方向后再针对性打印关键日志比如消费端拉取消息的耗时日志、重试日志、死信日志。这里有个独家习惯在所有消费逻辑入口和出口打印日志带上消息ID、业务主键、处理耗时。消息ID是全链路排查的“身份证”没有它下游反馈说某一条消息处理失败了你都无从定位。4.2 几次真实场景下的踩坑记录我第一次在字节生态里接触到大规模消息队列实操时就踩过一个经典的“顺序消费与重试”冲突的坑。当时有一个订单状态同步的场景业务方为了保证顺序所有消息都用同一个key消费端也是单线程逐条处理。听起来很完美对吧但实际上因为下游接口偶发超时消费端配置了失败重试重试的时候就导致了顺序错乱。原因很简单消息A处理失败进入重试队列但消息A后面的消息B已经接着处理了。等A重试成功时B就已经在它前面写入了数据库。最后我们把方案改成了“失败消息立即停止当前分区消费等重试成功后再继续消费下一条”虽然吞吐量降了一些但顺序性得到了严格保证。这里没有银弹就是根据业务需求做的取舍。还有一次消息堆积事故让我印象特别深。起因是某个团队上线了一个新功能给消息里加了一个新的业务字段但他们忘了消息Queue中的消费者和生产者是解耦的。新版本的生产者上线后消息体变大了消费者用的老版本反序列化直接报错消费线程全部卡死。这种问题极其隐蔽因为生产者看起来一切正常消息也都在正常写入就是消费端Lag一直在涨。排查了很久才定位到是消息体不兼容导致的。从那以后我养成一个习惯消息体结构变更必须提前做好兼容性设计字段只加不减类型不可随意改变上线时生产者和消费者要配套发布最好先在灰度环境验证。另外一个高频问题就是消费者端的线程池参数。很多人直接用默认配置消费线程数设置得太少导致单条消息处理耗时稍长消费TPS就跟不上了。这时候如果下游依赖有抖动很快就会演变成堆积。我的参数配置思路是消费线程数按“单条消息处理耗时 × 目标TPS”来估算再留 30% 到 50% 的冗余。同时要打开消费端动态线程池的开关让它能够在积压时自动扩容。不要等到堆积已经影响到线上业务了再手动重启扩容那个过程太痛苦了。4.3 消息队列选型与实战扩展思考聊了这么多字节的消息队列实践最后说说消息队列的选型思路。如果你的业务也是高并发、海量Topic、强一致性和跨机房容灾这些诉求那你在自建消息队列和云上托管消息队列之间做选择的时候核心要算清楚账人力成本、运维成本、稳定性和弹性扩张能力。自建Kafka集群最直接的优势是掌控力强可以按业务场景去调整服务端参数缺点也很鲜明它要求团队有足够强的中间件运维能力而且要操心磁盘、网络、节点故障这些基础设施问题。云上的托管消息队列则把这部分成本吃掉了通常还自带监控告警和自动扩缩容对大多数业务来说是很划算的选择。字节向云上开放的BMQ实际上就是把内部大规模验证过的方案产品化让外部团队也能用到这种级别的基础设施。对中小团队来说与其三天两头忙着修Kafka集群不如用好托管服务把精力放在自己的业务逻辑上。还有一个扩展思考是消息队列和事件驱动架构的结合。字节业务里大量服务之间的通信已经不是传统的RPC调用而是通过事件来驱动的。一条消息可以同时被多个订阅方消费每个订阅方拿到的都是同一条事件各自做各自的事情。这种模式让系统之间的耦合度大幅降低新增一个订阅方不打扰现有的生产者和其他订阅方。如果你正在设计一套微服务架构我非常建议你认真考虑一下这种基于消息队列的事件驱动模型。它学起来有一定的门槛但上手之后带来的灵活性和扩展性会远超想象。最后再分享一个我在实际运维中特别坚持的小习惯每一条核心消息都要设计好消息ID和链路追踪。线上任何问题只要你能拿到完整的消息链路日志定位问题的效率会提升一个数量级。消息队列本身是一把非常锋利的刀用得好它能帮你扛住海量请求用不好它也能在半夜把你叫起来处理事故。多看看架构设计背后的为什么多积累真实场景下的排查经验慢慢你会发现消息队列其实并不复杂复杂的是业务场景的千变万化。