万字好文：大报文问题实战

导读

大报文问题，在京东物流内较少出现，但每次出现往往是大事故，甚至导致上下游多个系统故障。大报文的背后，是不同商家业务体量不同，特别是B端业务的采购及销售出库单，一些头部商家对京东系统支持业务复杂度及容量能力的要求越来越高。因此我们有必要把这个问题重视起来，从组织上根本上解决。
1 认识大报文问题

大报文问题，是指不同的系统通过网络进行数据交互时payload size过大导致的系统可用性下降问题。

对于大报文的产生方，过大的报文在序列化时消耗更多内存和CPU，在传输时(JSF/MQ)可能超过中间件的大小限制导致传输失败；对于大报文的消费方，过大的报文在反序列化时会产生大对象，消耗更多的内存和CPU，容易触发FullGC甚至OOM，而在处理过程中要遍历的内容更多，造成响应变慢，如果涉及数据库操作容易产生大事务、慢SQL，这些容易触发超时，如果客户端有重试机制，会进一步加重大报文消费方负载，严重时导致服务集群整体不可用。
此外，由于大报文与小报文是在一个接口上完成的，使用相同的UMP key，它会导致监控失真，报警阈值无效。如果日志记录了原始报文，也可能磁盘打满和响应变慢。
在京东物流技术体系内，具体表现为：
大报文场景后果MQ的producer发送了大的Message由于JMQ对消息大小的限制，导致producer发送失败：消息未送达MQ consumer反序列化Message并处理计算时产生大对象，频繁FullGC，CPU使用率飙升JSF Consumer调用API时传入大入参值由于JSF Server对payload大小限制，导致服务端将报文抛弃：无法送达JSF Provider响应变慢，产生大对象，频繁FullGC，CPU使用率飙升，甚至OOM；请求处理超时JSF Provider返回值包含大对象由于JSF Consumer对payload大小限制，导致consumer无法获取响应JSF Consumer产生大对象，频繁FullGC，CPU使用率飙升，甚至OOM

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！