做社交平台后端最绕不开的中间件就是消息队列。点赞、评论、私信、通知、动态分发每一类业务都在以不同量级冲击后端接口如果全走同步调用数据库和网关早晚被打穿。消息队列在这里的核心职责就三件事异步、削峰、解耦。这篇内容来自我给一个社区类App做消息链路重构时的选型实录会把社交平台真实场景下怎么挑队列、分区怎么设计、消费端怎么保证不丢不乱不漏一次性说清楚。适合正在做架构选型、准备改造消息链路或者想系统梳理消息队列实战经验的后端开发和架构工程师。1. 社交平台的消息队列选型先拆透业务场景选型翻车的案例我见过不少大多数不是因为中间件性能不够而是根本没想清楚自己要什么。所以在聊Kafka还是RocketMQ之前我建议先把社交平台的业务场景拆开看看消息队列到底在替后端扛哪些事。1.1 社交平台的消息流量到底长什么样社交平台的流量特征和普通电商、内部OA系统完全不是一回事。这里的时间线不是平的而是被一个个“热点事件”打穿。某个大V发一条动态短时间内会涌入百万级的转发、评论、点赞一场直播抽奖服务器可能在几十秒内收到平时几十倍的请求。这种突刺式流量如果全部打到数据库上再好的主从架构也会被拖到锁等待、连接耗尽。从消息类型上看社交平台大致可以分为几类实时互动消息私信、聊天消息、在线评论。这类消息对延迟敏感用户发出后如果几百毫秒不显示会明显感知到“卡顿”。事件通知类点赞、关注、收藏、评论通知。这类消息允许一定延迟但要有通知触达并且不能丢失。Feed流事件用户发帖、动态更新后需要把事件广播给粉丝列表的聚合服务用于刷新信息流。内部任务型消息内容审核、图片压缩、全文检索索引更新、排行榜增量计算。这类消息量级大但对实时性要求一般属于典型的异步任务。每一类消息对可靠性、延迟、吞吐的要求都不一样。如果把聊天消息和内容审核任务塞进同一个主题就会出现一个矛盾追求低延迟会牺牲吞吐追求吞吐会拖慢聊天体验。所以第一步不是选中间件而是把消息按特性划分优先级。1.2 消息队列要替后端扛住哪些事在社交平台里消息队列的价值可以用三个词概括异步、削峰、解耦。先说异步。用户点赞后后端真正要做的不是把“点赞成功”这个结果返回给用户就完了后面还有一串事情给内容作者生成通知、更新热度分、写粉丝聚合数据、刷新用户的时间线。这些操作全部同步做完用户会明显感觉到卡顿甚至因为某个依赖服务超时而导致整个请求失败。正确的做法是核心路径只做一个写库动作然后把后续事件丢给消息队列由下游消费者异步处理。再说削峰。社交平台的峰值流量极具破坏性但好消息是大多数峰值流量并不需要在当刻秒级完成。比如一条热点内容的评论量在几分钟内冲上十万但评论列表是按时间分页读取的晚几十毫秒写入并不会影响体验。消息队列在这里就像一个蓄水池生产端有多少先接多少消费端按照数据库能承受的速度慢慢消费把压力平摊到更长的时间窗口。最后是解耦。耦合是系统腐化的开始。如果内容发布服务直接去调用通知服务、推送服务、索引服务每一次新增下游服务都要改发布服务的代码。引入消息队列之后发布服务只需要发一条“内容已发布”的事件下游谁关心谁订阅发布方与订阅方互不知道对方的存在。后面哪怕下线一个消费服务也不会影响主链路。1.3 选型前先对齐的量化指标这里说的量化指标不只是CEO眼里那种“一个季度要做多少单量”而是技术视角下能直接指导选型的硬指标。建议在选型前拉一次会议把下面几个数字定下来峰值生产TPS比如某热点事件期间单机接口能接收到每秒多少请求其中有多少需要进队列。单条消息平均大小纯JSON事件也就几百字节如果里面嵌套了用户配置、评论快照可能到几KB这会直接影响网络带宽和磁盘占用。允许的最大消费延迟聊天消息要求秒级延迟内容审核可以接受分钟级延迟Feed流聚合通常要控制在10秒内。消息可丢失性点赞通知丢了用户无感但私信和交易消息丢了就是事故。所以千万不能一概而论要求“所有消息都不能丢”。消费端处理时长单个消息处理耗时会决定消费并发度处理1毫秒和处理500毫秒需要的消费者线程数差出两个数量级。把这些指标都对齐之后再去翻中间件文档你会发现选型已经不是“哪个热门选哪个”而是“哪个匹配选哪个”。2. 主流消息队列横向对比选型不是追新业界主流的消息队列就那么几个但每年都有新框架冒出来。我的建议是核心链路用成熟稳定的项目边缘场景再考虑新东西。社交平台这种对稳定性要求极高的业务没必要为追新买单。2.1 几类常见消息队列的定位差异我在选型时一般只看以下几类它们各自解决的问题有很清晰的边界Kafka是日志系统出身设计目标就是高频追加、顺序读写、海量堆积。它把消息组织成分区分区内部严格有序消费者按分区并行消费。吞吐量在同类产品里属于第一梯队而且生态非常丰富流处理、数据同步、日志采集都有现成方案。社交平台的Feed事件流、用户行为日志、指标上报用Kafka非常顺手。RocketMQ是电商业务背景下孵化出来的更偏向业务消息。它天生就有事务消息、延迟消息、消息轨迹、Tag过滤这些企业级功能。Java技术栈的团队用起来非常顺畅因为客户端的API风格和Spring生态契合度高。如果社交平台上有很多订单、任务、奖励这类需要最终一致性的业务RocketMQ的事务消息可以直接减少很多自研代码。RabbitMQ的特点是路由能力强基于Exchange和Binding的消息分发机制非常灵活也有死信队列、延迟插件。吞吐量相比前两者明显偏低但胜在简单、文档好、运维成熟。它更适合中小型系统、内部任务分发或者在已经有大量Erlang/AMQP基础设施的团队里使用。Pulsar走的是云原生路线存算分离、多租户、分层存储都做得很好。它解决了Kafka扩容时数据搬迁成本高的问题但整体运维门槛不低社区积累也没有那么深。如果你所在团队有专门的中间件团队且对跨地域复制、存储成本有很强烈的要求可以纳入考虑。Redis Stream不是完整意义的消息队列但胜在轻量。Redis本身就是社交平台缓存层的标配用它做简单任务队列、延迟队列都非常方便。缺点是消息堆积能力有限持久化和恢复机制不如专业MQ只能用在辅助场景。2.2 一张表看清关键差异下面这张表是我做选型时固定会对比的维度按照社交平台场景的优先级排序。用的时候建议再叠加上团队的技术栈和运维能力单看表格容易误判。维度KafkaRocketMQRabbitMQPulsarRedis Stream吞吐能力极高分区线性扩展高略低于Kafka中等高存算分离扩展灵活受Redis实例性能限制消息延迟毫秒到秒级取决于配置毫秒级业务场景通常够用低延迟毫秒级微秒级读取但堆积后延迟升高顺序消息分区内严格有序也有顺序消息支持但使用约束多单队列内保证顺序分区内有序单Stream内有序延迟消息官方不支持需自研内置18个延迟级别通过死信或插件实现社区方案不统一可用延迟Stream自研事务消息事务性幂等生产者非完整事务消息完善的事务消息支持有发布确认无事务消息有事务消息支持不支持消息回溯按偏移量或时间戳回溯按时间回溯较差支持按时间回溯有限运维复杂度高依赖ZooKeeper或KRaft中高依赖NameServer中高存算分离组件多低典型场景事件流、日志、Feed流业务消息、事务消息、通知系统内部路由、任务调度跨地域复制、多租户轻量级辅助任务看这张表的时候要特别注意“延迟消息”这一行。社交平台里很多业务需要延迟处理比如私信撤回后的延迟清理、用户被禁言后的定时解禁、活动结束后的奖励结算。RocketMQ内置延迟级别但粒度有限Kafka完全没有原生延迟消息所以不管选哪个都要提前想清楚延迟消息怎么做。2.3 社交平台场景下的选择逻辑结合我之前的选型结论可以分享一条比较务实的路径如果业务核心是事件流和Feed分发首选Kafka如果业务核心是大量需要事务保证的业务消息首选RocketMQ两者并不是完全互斥很多团队会同时部署两套。但在资源有限的情况下先上哪套要看主要矛盾在哪里。我之前重构的社区类App消息量最大的场景是动态发布后的Feed事件分发以及用户行为日志采集。这两类消息的特点是大吞吐、容忍秒级延迟、几乎不需要事务消息。所以我最后选了Kafka原因很直接单分区写入吞吐高后续扩容只需要增加分区和消费者实例。消息可以按时间戳回溯出问题时能把某段历史消息重新拉出来审计。对消费者组的支持成熟加机器就能提升消费速度运维动作简单。社区和周边生态强大Metrics接入、日志采集、流式计算都能无缝衔接。至于RocketMQ擅长的业务消息场景在我这次重构里占比不大。如果后续要做积分任务、现金奖励、领取礼包这类对最终一致性要求高的业务我会再单独评估上RocketMQ。这不是墙头草而是每个中间件都有自己的优势区间最忌讳指望一套队列吃遍所有场景。3. 核心架构设计分区、顺序、幂等、延迟消息一个都不能少选完中间件只是开始后面才是真正拉开差距的地方。我在核心链路重构过程中把大量的时间花在了分区设计、顺序保证、幂等消费、延迟消息这四个问题上。每一个问题都在线上真实咬过我所以我把它们单独拆出来讲。3.1 主题与分区数怎么定才能既扛峰值又省资源Kafka或RocketMQ的主题都由多个分区组成分区是并行度的天花板。生产端写入是从多个分区并行写的消费端每个分区同一时刻只能被一个消费者实例中的一个线程消费。所以分区数不能拍脑袋定它同时决定了生产吞吐和消费吞吐。先给一个经验公式分区数 max(期望生产TPS / 单分区生产TPS, 期望消费TPS / 单消费者线程TPS)举个例子假设Feed事件流峰值生产TPS是5万/秒单分区写入TPS大约能到1万到2万取决于消息大小和批量参数那么从生产端算至少需要3到5个分区。但如果消费端每条消息处理需要10毫秒一个消费者线程每秒只能吃100条5万TPS就需要500个消费者线程。假设每个消费者实例开20个线程那就是25个实例而每个线程需要有独立分区所以分区数至少要500个。很多架构师只按生产吞吐算分区结果消费端数据积压到爆。实际上消费端能力往往才是瓶颈。正确做法是先按消费端目标TPS和单线程处理能力算出最少分区数再往大留30%缓冲最后和生产端要求取较大值。分区数不能拍脑袋定的另一个原因是分区数会直接影响Broker的负载。分区太多会导致每个文件片段变多、网络线程增多、Controller的元数据压力变大。所以也不要无脑设个很大的数分区数应该和后续扩容节奏一起考虑。Kafka扩容分区只能增加新分区已有数据不会重新分布所以如果要保证某个key始终落到同一个分区还需要根据扩容后的分区数重新设计key。这个坑后面细说。3.2 局部顺序消息用分区键解决“谁先谁后”社交平台表面上看起来不太需要全局有序但局部有序其实无处不在。最典型的是私信场景同一个用户A和用户B之间的消息必须先发再收或者至少不能出现后一条先被处理的情况。如果顺序乱了可能会出现“撤回了一条消息”被先处理原本的消息后处理最终界面上还是把已撤回内容显示了出来。消息队列解决顺序问题的标准思路就是分区。同一个业务key的消息进同一个分区分区内消息按写入顺序存储消费者按顺序消费就能做到局部有序。Kafka里通过在发送消息时指定key来实现生产端对同一个key的hash结果不变所以会落入固定分区。但有两个细节容易踩。第一不要直接把广为人知的大数量字段当key。比如直接用用户ID的话如果一位超级大V有上千万粉丝他一个人发的消息可能占据某个分区的大量写入导致分区之间严重倾斜。更好的方式是在key前面加业务类型前缀比如“feed:user:12345”和“notify:user:12345”拆开或者把大用户的消息单独拆主题。第二消费端不能为追求吞吐而破坏分区内的顺序。常见的错误做法是一个分区给多个线程并发处理这样即使消息进了同一个分区处理顺序也会乱。如果必须提高吞吐那就开更多分区每个分区保持单线程消费而不是单分区多线程。要记住Kafka只保证了队列内的顺序不保证队列间的顺序消费端也必须保持“单分区内串行消费”才能真正拿到有序结果。3.3 消息不丢不重幂等与可靠投递的配合“至少一次投递”是所有消息队列默认的语义。这句话翻译成人话就是消息可能会重复但丢失的概率要尽可能低。所以消费端必须接受现实用幂等来兜底重复消息。我设计消息链路时固定会给每一条消息塞一个业务幂等号。比如点赞通知这条消息幂等号可以是“点赞行为ID”内容评论更新则可以用“评论ID内容ID”。消费端在处理前先拿幂等号查Redis或数据库唯一索引。如果已经处理过直接跳过如果没处理过就处理业务并且同步写入幂等记录。这个“先查再写”的过程必须和业务处理落在同一个事务里否则还是会重复。再配合Kafka生产端的幂等发送机制可以把消息丢失的概率压到极低。核心链路建议开启enable.idempotencetrue acksall min.insync.replicas2这三个配置组合起来的意思是生产者会为消息分配序列号Broker对重复序列号去重同时消息必须写进Leader和至少一个Follower才算成功。这样即使是Broker宕机只要ISR里还有节点消息就不会丢。消费端的重复消息兜底我推荐用“消费处理成功后再提交Offset”的策略。不要在拉取一批消息后就立刻自动提交否则消费者在业务处理期间挂掉重启后会跳过这批消息等于静默丢失。3.4 延迟消息的落地内置级别还是自研时间轮社交平台对延迟消息的需求很多用户发送验证码后5分钟过期、直播秒杀结束后10分钟结算、消息撤回后24小时清理附件。如果不做延迟消息这些逻辑要么靠数据库轮询要么靠定时任务扫描都很消耗资源和容易出问题。如果用的是RocketMQ可以直接用延迟消息功能但要注意它的延迟级别是固定的18个档位比如1s、5s、10s、30s、1m、2m……并不支持任意秒数。如果需求是“2分30秒后执行”就不得不选3分钟档然后自己再加补偿逻辑。Kafka没有原生延迟消息但可以在消息里带一个“期望执行时间”字段由消费端拉取后判断如果没到时间就放回一个本地延迟队列或者重新塞回原topic。更常见做法是自研一个时间轮延迟队列生产者把延迟消息打到Redis ZSetscore是期望执行时间消费端不断用zrangebyscore捞出到期消息发往下游。时间轮的好处是延迟精度可控、支持任意秒级坏处是需要自己维护线程和存储。我在实际项目中因为Kafka无法覆盖所有延迟档位最后用Redis ZSet做了补偿队列和主队列配合效果还不错。但请注意延迟队列只是“尽力延迟”不是绝对精确。如果某个消息到期后消费端刚好在重启延迟时间会被拉长。业务上能容忍这种误差就用如果误差不能超过100毫秒那就别指望消息队列得走定时任务加上状态机。4. 实战落地部署、客户端配置、监控告警与容量估算理论聊完进入实操。我会以Kafka为例把从集群部署到客户端接入的完整过程走一遍。核心配置和代码都是可以直接套用然后按业务调整的。4.1 集群部署与Broker关键参数Kafka集群我建议最少3个Broker节点生产环境不要用单节点也别用2节点。2节点遇到网络分区时很难选举出新的Leader反而容易出现脑裂问题。如果机器资源有限可以先上3节点后续按分区和流量横向扩到5、7台。以下是一份经过线上验证的server.properties关键配置broker.id0 listenersPLAINTEXT://0.0.0.0:9092 log.dirs/data/kafka-logs num.partitions24 default.replication.factor3 min.insync.replicas2 offsets.topic.replication.factor3 transaction.state.log.replication.factor3 transaction.state.log.min.isr2 log.retention.hours72 log.segment.bytes1073741824 log.retention.check.interval.ms300000 auto.create.topics.enablefalse参数解释一下min.insync.replicas2配合生产端acksall保证写入时至少有一半副本在场不会出现“消息写进Leader但Follower全挂”的假成功。offsets.topic.replication.factor3是给消费位点Topic设置的副本数。这个Topic很多人会忽略一旦它的副本不够消费端提交偏移时会大量报错。log.retention.hours72表示消息保留3天。消息保留时间不是越长越好越久磁盘占用越高同时消费端如果不小心从最早位置开始重新消费还可能触发长时间的重放。社交平台里一般保留3天到7天就够用了。auto.create.topics.enablefalse务必关掉。不关的话生产端一个笔误就会创建出一个分区数默认为1的主题后续想改分区还要做数据迁移非常被动。部署时还要注意Kafka的数据目录不要放在系统盘和日志盘共用的一块盘上。消息写入是顺序IO密集型的如果和系统日志抢磁盘IO调度会变得很难看延迟很快会上去。4.2 生产端配置从参数调优到发送补偿生产端接入其实没那么难难的是在各种异常下都能保证消息不丢。Java客户端最基础的一个发送示例Properties props new Properties(); props.put(bootstrap.servers, mq-1:9092,mq-2:9092,mq-3:9092); props.put(acks, all); props.put(enable.idempotence, true); props.put(linger.ms, 5); props.put(batch.size, 32768); props.put(max.in.flight.requests.per.connection, 5); props.put(retries, Integer.MAX_VALUE); props.put(key.serializer, org.apache.kafka.common.serialization.StringSerializer); props.put(value.serializer, org.apache.kafka.common.serialization.StringSerializer); KafkaProducerString, String producer new KafkaProducer(props); producer.send(new ProducerRecord(feed-event, userId.toString(), eventJson), (meta, ex) - { if (ex ! null) { // 这里的关键不要只打日志要把消息保存到本地失败队列 saveToFallbackQueue(eventJson); } });几个参数仔细说linger.ms5不是“每条消息等5毫秒再发”而是“在5毫秒窗口内等待更多消息凑成一个批次”。这个值可以显著提升吞吐。代价是单条消息延迟增加最多5毫秒对社交平台大多数业务来说完全无感。batch.size32768是生产者攒批的缓冲区上限。如果消息平均1KB一满批大概能装30多条。这个值设大可以提升吞吐但也会增加内存占用需要按客户端机器内存调整。max.in.flight.requests.per.connection5在开启幂等后可以设到5因为幂等机制能保证重试时不会乱序。如果是未开启幂等的旧集群这里必须保持1否则重试可能导致消息乱序。生产端最容易犯的错是发送成功后就不管了。很多团队只调了producer.send(...)没处理Callback里的异常一旦Broker短暂不可用消息就静默丢掉。我习惯的做法是在主链路发送失败时写入一个本地Kafka失败消息表由后台任务定时扫描表并重新投递。这样即使客户端完全不可用数据也能在恢复后补发。4.3 消费端配置手动Offset、批量消费与幂等处理消费端比生产端更容易出问题。比如消费者挂了之后重启从哪儿开始消费处理业务时抛异常该不该提交偏移一批消息里有一半处理失败是整批重试还是逐个跳过。这些都是线上必遇到的问题。先上一段核心消费代码props.put(group.id, feed-consumer-group); props.put(enable.auto.commit, false); props.put(max.poll.records, 500); props.put(session.timeout.ms, 10000); props.put(max.poll.interval.ms, 300000); while (true) { ConsumerRecordsString, String records consumer.poll(Duration.ofMillis(200)); for (ConsumerRecordString, String record : records) { String event record.value(); String bizId extractBizId(event); // 1. 幂等判断处理前查Redis/DB if (duplicateService.isProcessed(bizId)) { continue; } try { // 2. 真正的业务处理比如刷新Feed聚合数据 processEvent(event); // 3. 业务成功后再写幂等标记 duplicateService.markProcessed(bizId); } catch (Exception e) { // 4. 记录失败原因保留原始消息准备重试或进入死信 retryService.record(record, e); } } // 5. 全部处理完之后同步提交Offset consumer.commitSync(); }这里有几个细节值得展开第一enable.auto.commitfalse是为了避免在业务处理成功前就提交位移。万一消费者处理到一半崩溃AutoCommit可能已经更新了偏移这批消息就再也拉不到了。手动提交虽然代码量多一点但可以把“消费进度”的控制权完全握在自己手里。第二max.poll.interval.ms要设置得比单批消息的最坏处理时间更长。如果处理500条消息超过5分钟消费者会认为当前实例失去活性触发再均衡并且重复消费。这个参数很多新手忽略结果就是“消息明明处理完了为什么还会重复收到”。第三批量消费时不要一条消息失败就中断整批处理。更稳妥的做法是单条try-catch失败消息记录到本地或Redis重试队列成功的消息正常提交偏移。否则一条脏数据卡住整批会让后面的消息全部积压。4.4 监控指标体系与积压告警消息队列的监控我认为比业务指标监控更重要因为问题往往先出在积累的量上然后才表现为接口超时。至少需要盯住以下指标消费组Lag当前消费位点和最新生产位点之间的差值。Lag持续增长就是积压在成倍扩大必须及时告警。生产TPS和消费TPS两者对比能判断生产侧或消费侧哪一边出了问题。Broker磁盘使用率设置80%告警90%立即处理因为磁盘写满会导致消息写入失败严重时直接宕机。消费者活跃实例数如果消费者死掉一半Lag会立刻上涨但很多团队不会第一时间发现。查Lag最简单的方式是命令kafka-consumer-groups.sh --bootstrap-server mq-1:9092 --describe --group feed-consumer-group这个命令会输出每个分区的当前偏移、最新偏移、Lag。监控系统里可以把这些指标定时捞出来推到PrometheusGrafana里按分组展示。告警阈值建议设两个级别Lag超过1万持续5分钟发Warning超过5万持续10分钟发Pager。具体数值要根据业务量调整但原则是“不能让积压超过消费端的承载能力”。4.5 容量估算实例支撑10亿级日消息量的配置计算这部分很多人懒得做结果集群上线没两个月就要扩容。我给出一个可复用的估算过程。假设一个中等规模的社交平台每日产生10亿条事件消息平均每条消息1KB。日高峰集中在两个小时峰值为平均值的10倍。思路如下日均消息10亿扣除深夜8小时低谷有效生产时间按16小时算平均每小时约6250万条每秒约1.7万条。高峰集中在2小时峰值为平均的10倍就是每秒17万条。生产端按每分区每秒2万条估算至少需要17万 / 2万 9个分区保险起见取12到16个分区。消费端假设每条消息处理5毫秒单线程每秒处理200条。要消化17万TPS需要约850个消费线程。单实例开50个线程的话需要17个消费者实例而分区数要大于等于线程数所以分区数至少要850个这里要重新算因为消费端才是瓶颈。上面的对比可能会让人困惑生产端只需要十几个分区但消费端却要求几百个分区怎么解实际上这就是Kafka容量设计里的关键点如果消费端的吞吐要求远大于生产端要么提高单线程处理速度要么把批量消费优化到极致要么增加分区数但不用增加Broker数量一个Broker可以承载很多副本。更合理的做法是先用消费目标算出理论上限然后压测单线程处理能力。如果发现消费处理耗时要到50毫秒就要考虑改消费逻辑、加Redis缓存、优化数据库查询把耗时压到5毫秒以内。否则为了堆线程数而设1000个分区会让Broker的元数据和文件句柄压力巨大得不偿失。存储方面每日10亿条、每条1KB原始数据量为1TB。三副本就是3TB。保留3天就是9TB。如果一台Broker分配2TB数据盘至少需要5台Broker再加上系统盘、日志盘和缓冲余量6到7台比较稳。这个估算方法的价值在于它不会让你被“网络上的性能数据”牵着走。真正上线前做一次全链路压测将生产流量从1倍慢慢拉到峰值测试实际单分区吞吐和消费线程能力用实测数据反过来校正分区数和机器数才是靠谱的。5. 典型故障排查与避坑实录消息队列的问题往往不像应用故障那么直观经常是“线上看起来没挂但是数据越来越不对劲”。这一节我会把各个项目里踩过、听过、处理过的典型问题集中整理成速查表并给出排查思路。5.1 消息积压暴增先别急着扩分区积压是最常见的故障。现象是消费者组的Lag不断上涨消息从产生到消费的时间越来越长下游数据延迟严重。很多人第一反应是“加消费者实例”但加完发现Lag没降或者降了一点又开始涨。症结通常不在消费实例数量而在这几个地方单条消息处理耗时长让线程卡在一个慢接口或慢SQL上。看消费端日志往往能看到频繁的超时或锁等待。消费逻辑里出现了串行操作比如一个事务里做了多次数据库写。吞吐上限不是消费线程数决定的而是数据库连接池决定的。分区数不够消费者实例加了也没用因为每个分区同一时刻只能被一个实例消费分区数就是并发上限。排查步骤我建议先做三件事看消费端日志有没有慢操作、看下游数据库的慢查询和锁等待、看Lag是不是均匀分布在多个分区。如果Lag集中在少数几个分区很可能是热点key导致某些分区消费速度骤慢。如果Lag均匀上涨再检查消费线程数和分区数是否匹配。扩容分区时还要注意一个坑Kafka只对新增分区生效已写入旧分区的消息不会自动分散到新分区。就算你把主题扩容到100个分区旧分区里的积压消息依然由原来的消费线程处理不会因为新增分区而“分担”出去。所以如果已经积压优先优化消费端而不是先扩分区。5.2 重复消费与乱序常见成因和兜底方案重复消费几乎是必然发生的只是概率大小区别。最典型的触发场景有两个消费者处理完消息后未提交Offset进程就挂了或者消费者组发生再均衡未提交的分区被分配给其他实例从头重新消费旧数据。处理重复的唯一正道就是幂等。请检查每个消费处理逻辑如果是写数据库给业务表加一个“消息幂等号”唯一索引。如果是发通知用幂等号做Redis SetNx或者先查再发。如果是刷新缓存直接覆盖写入天然幂等。乱序问题则复杂一些。乱序一般出现在“重试”场景。例如某个分区内有三条消息ABCD如果B处理失败被放回重试队列A和C、D里面可能有新消息已经先处理完了导致B晚来的消息被跳过业务上就出现了乱序。在要求顺序的业务里我的建议是不要在消费端把失败消息异步重试而是用阻塞重试加退避策略。比如A失败后先让当前消费者线程Sleep一小段时间再重试重试超过5次就进死信队列。进程重启和网络抖动导致的重试可以接受但绝不能把消息丢到另一个独立线程去处理否则顺序一定会乱。5.3 从数据丢失到延迟抖动几个容易被忽略的细节消息丢失的案子里有相当一部分不是Broker坏了而是配置没到位。我整理几个高频细节生产端acks0这代表发送后不等Broker确认吞吐高但消息随时可能丢。社交平台核心链路千万不要这么配。消费端开启AutoCommit且max.poll.interval.ms太小处理一批消息还没结束就被判定为超时触发再均衡旧分区被重新消费看起来像“重复”极端情况下消息被重复处理多次后还没来得及提交就被跳过导致丢失。Topic自动创建打开一个笔误创建了分区数不对的主题后续扩容和流量治理都会变得很麻烦。Broker磁盘写满没有监控磁盘水位直到Leader写入失败才发现问题。磁盘水位监控必须是最高优先级。消息过大超出默认限制Kafka单条消息默认最大1MB如果业务塞了图片URL、评论全文和用户快照很容易超过。要么调整message.max.bytes要么把大对象放到外部存储只把引用发到消息队列否则消费者拉取也会被拖慢。延迟抖动的排查也常被误判。有时看到消费者某个批次处理特别慢以为是因为使用了消息队列导致的其实是因为消费端在下游查了某个慢数据库。所以监控里不能只看MQ的指标要接全链路Trace从生产者发出、进队列、消费处理、下游调用串起来看。否则很容易断言“消息队列延迟高”最后发现是应用层自己在排队。为了更直观我把这些问题和排查路径整理成了一张速查表日常值班时可以直接对照问题现象可能原因快速排查处理建议消费组Lag持续上涨消费线程处理慢、消费者实例不足、分区数不够查看消费端日志、下游慢SQL对比消费TPS与生产TPS先优化消费逻辑再扩容实例或调整分区消息重复处理未提交Offset、消费组再均衡看消息里的幂等号是否已存在统一实现消费幂等提交Offset必须在业务成功后消息顺序错乱分区内多线程消费、失败消息异步重试检查消费线程模型和重试策略单分区单线程消费失败消息阻塞重试或进死信消息丢失acks0、自动提交Offset、Broker故障查看生产者日志、Broker多副本状态、消费组Offset开启幂等、配置acksall、min.insync.replicas2消息延迟升高网络抖动、批量配置过大、消费端下游阻塞检查生产端请求延迟指标和消费端链路Trace调整linger.ms、batch.size优化下游依赖磁盘被写满保留时间过长、消息量增长快查看磁盘使用率与Topic消息总量缩短retention、扩容磁盘或做分层存储这套表不需要背但建议团队里维护成云文档每次出问题就追加一条。消息队列的故障大多不是单点原因而是多个因素叠加出来的记录得越多下次定位越快。最后再分享一点个人体会选型这件事真正决定成败的不是对比表格里的性能数字而是团队能不能把选定的中间件运营好。Kafka也好RocketMQ也好都有各自的坑但只要把分区设计、幂等消费、监控告警这三条主线做扎实绝大多数问题都能在现场被拦下来。真的不要图省事跳过容量评估和全链路压测消息队列给业务带来的复杂度通常会在上线后的第一个大流量日集中爆发。我从那次重构学到的就是永远用实际压测去验证你的架构设计压不出来问题才算真正稳了。