Kafka 消息太大怎么处理？只调 max.request.size 够吗？
本文目录
面试怎么回答
我会先测序列化后和压缩前后的大小，区分单条记录、批次和请求。只调 Producer 不够，还要核对 Topic、Broker、复制及消费侧配置和内存。优先减少载荷，必要时选择分片或对象存储引用；分片需有消息身份和完整性校验，引用要保证对象先可读、版本固定且保留期覆盖回放。最终用真实大小分布测试吞吐、失败重试与恢复。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Producer 报消息过大，调高 max.request.size 后，下一次又被 Broker 拒绝；限制全部放宽后，消费者开始频繁 GC。这类故障说明：大消息不是一个参数的问题，而是一份载荷沿整条链路传递的成本问题。
大消息需要端到端核对字节限制与资源成本；能发送只是起点，拆分或对象引用还要设计完整性。
先量清楚：到底哪个东西太大？
业务对象大小、序列化后的记录大小、压缩前后批次大小，以及一次请求大小，并不是同一个数字。JSON 字段、消息头和序列化格式也会增加载荷。
先记录失败点、异常类型、序列化结果大小和批次情况，再判断限制。不能拿压缩文件的大小去解释解压后的内存，也不能只测一条记录就估计并发消费的峰值。
本文参照 Kafka 4.0 配置语义，具体有效值仍要检查客户端、Topic 和 Broker。升级版本或更换客户端后，应重新核对，而不是把旧配置表永久沿用。
Producer 的上限只管其中一段
max.request.size 限制请求大小，也实际约束最大未压缩记录批次。Broker 有自己的批次接收限制；启用压缩时，服务端对应限制与客户端的计量位置可能不同。
Broker 的 message.max.bytes 和 Topic 的 max.message.bytes 都需要关注，但不要把它们与应用对象大小当成完全相同的量。
batch.size 是常规批次组织的参数，不是“增大后自动把一条业务消息拆成多个可独立消费的小消息”。只调它，不能替代对单条超大载荷的设计。
消费侧限制也不是绝对的内存天花板
max.partition.fetch.bytes 控制按分区抓取的大小，fetch.max.bytes 约束抓取响应规模。但为保证消费者能向前推进，首个非空分区的首个记录批次过大时，可能仍被返回。
所以“配置只取这么多，堆内存就不可能超过这么多”并不成立。多个分区、并发抓取、解压、反序列化及业务对象展开，都可能继续放大内存。
复制链路和下游写入也要一并核对。能被 Leader 接收，不代表整条业务链路已经具备稳定吞吐。
一个典型场景：小样本压缩得很好，线上却撑不住
比如为了传递完整详情，消息中塞入大量长文本。最初只调 Producer，Broker 继续拒绝；随后放宽接收限制，消费端却频繁 GC，处理延迟上升。
根因是端到端载荷预算缺失。旧测试使用重复内容很多、容易压缩的小样本，只验证发送成功，没有测真实内容分布、解压后对象和并发峰值。
改进应统计大小分位数及极端值，用接近真实的载荷做链路压测，并为超限记录设计明确处理路径。不能只把所有参数同步乘十，就宣称问题已经解决。
三种方案，各有自己的代价
第一是收缩载荷：只发送变更字段、必要上下文或规范化后的结构。要先确认消费者是否确实需要完整对象，避免把无用内容跨多个副本和系统反复传输。
第二是应用层分片。分片必须包含逻辑消息 ID、片序号、总片数和完整性校验，并设计缺片超时、重复片、乱序和重放处理。只切字符串，没有重组协议，不是完整方案。
第三是外置对象，消息只携带引用、版本、长度和校验信息。这样可以减轻 Kafka 载荷，但把读取依赖转移到了对象存储，必须管理权限、可用性与保留期。
这三种方式没有通用赢家。低延迟读取、小消息高频流与偶发超大对象，约束不同，应按真实消费路径选择。
对象引用方案，不能只发一个临时链接
应先确保目标对象写入完成且消费者可读，再发送引用。引用最好能固定内容版本，不要让同一个路径被覆盖后，历史消息读到另一份内容。
对象保留时间至少要覆盖约定的消息回放和恢复需求。消息还在，链接已经过期或对象被清理，回放就无法重建原结果。
上传成功而消息发送失败，会留下孤立对象；消息发送结果未知后重试，又可能重复通知。需要用业务身份、校验和及受控清理机制处理，而不是假设两个系统天然原子提交。
最后，消费者也应限制下载大小和解析资源，不能因为载荷离开 Kafka，就失去对它的约束。