萬字好文：大報文問題實戰

導讀

大報文問題，在京東物流內較少出現，但每次出現往往是大事故，甚至導致上下游多個系統故障。大報文的背後，是不同商家業務體量不同，特別是B端業務的採購及銷售出庫單，一些頭部商家對京東系統支援業務複雜度及容量能力的要求越來越高。因此我們有必要把這個問題重視起來，從組織上根本上解決。

1 認識大報文問題

大報文問題，是指不同的系統通過網路進行資料互動時payload size過大導致的系統可用性下降問題。

對於大報文的產生方，過大的報文在序列化時消耗更多記憶體和CPU，在傳輸時(JSF/MQ)可能超過中介軟體的大小限制導致傳輸失敗；對於大報文的消費方，過大的報文在反序列化時會產生大物件，消耗更多的記憶體和CPU，容易觸發FullGC甚至OOM，而在處理過程中要遍歷的內容更多，造成響應變慢，如果涉及資料庫操作容易產生大事務、慢SQL，這些容易觸發超時，如果使用者端有重試機制，會進一步加重大報文消費方負載，嚴重時導致服務叢集整體不可用。

此外，由於大報文與小報文是在一個介面上完成的，使用相同的UMP key，它會導致監控失真，報警閾值無效。如果紀錄檔記錄了原始報文，也可能磁碟打滿和響應變慢。

在京東物流技術體系內，具體表現為：