[發明專利]一種數據傳輸方法和裝置

在審

• 申請號: 201811517801.X
• 申請日: 2018-12-12
• 公開（公告）號: CN111309492A
• 公開（公告）日: 2020-06-19
• 發明（設計）人: 楊凡
• 申請（專利權）人: 北京京東尚科信息技術有限公司;北京京東世紀貿易有限公司
• 主分類號: G06F9/54
• 分類號: G06F9/54;G06F16/25;G06Q30/06
• 代理公司: 中原信達知識產權代理有限責任公司 11219
• 代理人: 張一軍;李陽

本發明公開了一種數據傳輸方法和裝置，涉及計算機技術領域。該方法的一具體實施方式包括：分別接收以分頁傳輸方式傳輸的訂單報文和訂單打包報文；其中，所述訂單打包報文包括訂單包裹報文和/或訂單箱報文；根據所述訂單報文和訂單打包報文，分別組裝訂單數據對象和訂單打包數據對象；其中，所述訂單打包數據對象包括訂單包裹數據對象和/或訂單箱數據對象；將所述訂單數據對象和訂單打包數據對象保存到數據庫中。該實施方式能夠解決由于大批量數據傳輸而造成內存不能釋放的技術問題。

技術領域

本發明涉及計算機技術領域，尤其涉及一種數據傳輸方法和裝置。

背景技術

現今的跨系統、跨應用的數據傳輸中，大量使用了MQ(消息隊列)的異步傳輸方式，這種傳輸方式需要上下游根據業務需求事先定義好傳輸報文，生產者開發時按照報文格式組裝數據和發送報文，以進行數據傳輸，消費者也按照報文格式解析報文，以進行后續業務處理。

如庫房回傳發貨數據明細時，一個訂單會回傳大量的數據字段，例如：訂單主檔、訂單明細、打包的包裹數據、打包的箱數據、耗材信息等，需要將這些數據進行組合、拼裝保存到數據庫中。可以看出，在進行訂單發貨數據傳輸時，現有報文是一個大報文，所有字段都放在其中，通過一個MQ進行傳輸。

在實現本發明過程中，發明人發現現有技術中至少存在如下問題：

對于目前這種數據傳輸方式，數據量中、小時不會對系統性能造成影響，但當數據量增大時，報文也會增大，造成幾兆到幾十兆的報文傳輸。系統為了處理這些大數據量的報文，必然會產生大的數據對象，并且這種對象會一直處于內存中，在數據保存處理時，會造成內存不能釋放，CPU使用率居高不下的情況。

發明內容

有鑒于此，本發明實施例提供一種數據傳輸方法和裝置，以解決由于大批量數據傳輸而造成內存不能釋放的技術問題。

為實現上述目的，根據本發明實施例的一個方面，提供了一種數據傳輸方法，包括：

分別接收以分頁傳輸方式傳輸的訂單報文和訂單打包報文；其中，所述訂單打包報文包括訂單包裹報文和/或訂單箱報文；

根據所述訂單報文和訂單打包報文，分別組裝訂單數據對象和訂單打包數據對象；其中，所述訂單打包數據對象包括訂單包裹數據對象和/或訂單箱數據對象；

將所述訂單數據對象和訂單打包數據對象保存到數據庫中。

可選地，所述訂單報文包括訂單號、訂單類型、當前頁碼和總頁數；所述訂單包裹報文包括訂單號、包裹類型、當前頁碼和總頁數；所述訂單箱報文包括訂單號、箱類型、當前頁碼和總頁數。

可選地，在根據所述訂單報文和訂單打包報文，分別組裝訂單數據對象和訂單打包數據對象之前，還包括：

根據已接收到的訂單報文和訂單打包報文，分別生成key和value，并存儲在緩存中；其中，所述key包括訂單號、報文類型、當前頁碼和總頁數組，所述value為所述訂單報文或者訂單打包報文的接收時間，所述報文類型為訂單類型、包裹類型和箱類型中的一種。

可選地，根據所述訂單報文和訂單打包報文，分別組裝訂單數據對象和訂單打包數據對象，包括：

根據所述訂單報文和訂單打包報文分別生成key；

比對所述key與緩存中已存儲的key是否相同；若否，則將所述訂單報文組裝訂單數據對象，以及將所述訂單打包報文組裝成訂單打包數據對象，并將所述key及其對應的value存儲到緩存中；若是，則結束。

可選地，將所述訂單數據對象和訂單打包數據對象保存到數據庫中之后，還包括：

將所述訂單報文和訂單打包報文的報文類型、頁數數據和刪除狀態寫入任務表中；