批量發貨的啓示

以前遇到過一個問題，批量發貨一次性發貨的訂單數不能超過8000條。超過8000條，系統就會報錯。採用的方法是異步推送發貨數據到消息組件，後臺任務腳本從消息組件解析發貨數據，調用發貨接口來完成發貨操做。

8000條的訂單發貨數據大約是300KB左右，遠遠小於前端對文件的限制：1MB。 到底是什麼緣由致使了這個限制呢？

起初，一直覺得是前端或代理作了限制，然而經過在入口和關鍵位置打印相應消息，發現是一次性寫入消息組件的內容超過長度限制致使消息組件報錯了。

想到的第一個解決方案是： 以 N 條發貨數據切分發貨的訂單數，分紅若干組發送。嘗試 N = 200，500，1000，2000, 3000, 4000,5000,6000, 發現狀況時好時壞，有時能夠成功，有時又會致使超時。不穩定。

因而，查看推送消息的接口代碼，發現現有使用的方法是 push 單次推送，還有一個批量推送消息的 bulkPush 。諮詢相關開發同窗，瞭解這個在批量推送消息時性能更佳，能減小創建TCP鏈接的次數。因而嘗試使用這個方法解決問題。發現速度確實更快了，但是接收端的數據內容有點怪異，彷佛所有變成了單個數據，而不是以前的JSON結構的數據。敏感的我想到，極可能是數據結構的問題，須要將原來的數據做爲列表的一個元素來傳遞。也就是說，以前使用 push 方法的參數是對象的列表，那麼使用 bulkPush 的參數必須是對象的列表的列表，才能讓接收端得到的是相同結構的JSON數據。

將 push(expressArray) 更改成 bulkPush([expressArray]) 後，問題解決，8000 條很快就發送出去了，而且接收端也正常解析到了相應數據。可支持到 20000條數據，差很少是 800KB 左右，接近前端的文件限制。

總結：

(1) 遇到任何問題，打斷點或看日誌，肯定是入口以前的問題，仍是程序中的問題；

(2) 批量傳輸數據，一般是要切分紅多個批次傳輸的，避免一次性寫入數據超過長度限制而報錯；

(3) 批量傳輸數據，適宜採用批量接口，切忌單個循環傳輸數據；一般的模式是異步併發地傳輸；

(4) 若從原來的單個推送接口切換到批量推送接口，注意接收端的數據是否保持一致。