[發明專利]系統數據對賬方法及裝置、存儲介質、電子設備

在審

• 申請號: 201711083845.1
• 申請日: 2017-11-07
• 公開（公告）號: CN107729553A
• 公開（公告）日: 2018-02-23
• 發明（設計）人: 吳武桓;郭見偉
• 申請（專利權）人: 北京京東金融科技控股有限公司
• 主分類號: G06F17/30
• 分類號: G06F17/30;G06F9/54;G06Q40/00
• 代理公司: 北京律智知識產權代理有限公司11438
• 代理人: 王輝,闞梓瑄

技術領域

本公開涉及數據處理技術領域，具體而言，涉及一種系統數據對賬方法、系統數據對賬裝置、計算機可讀存儲介質以及電子設備。

背景技術

系統數據對賬是指對兩個系統對相同批次賬單進行核對校驗以發現不一致數據及單邊數據；由于系統對賬往往是面對海量級數據，因此對賬的時間復雜度較高，較高的時間復雜度導致了系統對賬成為了系統性能的瓶頸。

目前大部分系統數據的對賬方式都是先將對方系統數據入庫臨時表，然后再將本地數據庫中的數據與臨時表中的數據進行比對。對比方式可以包括以下兩種：一種是，通過批量循環本地數據庫中的數據表，然后對相同單號逐次從臨時表中查找對比，再將對比后對不一致的數據和單邊數據進行打標處理，然后遍歷臨時表以及本地數據庫獲取打標異常數據；另一種是，通過關聯原始數據表進行聯合對比，再將對比后對不一致的數據和單邊數據進行打標處理，然后遍歷臨時表以及本地數據庫獲取打標異常數據。

但是，上述兩種比對方法強依賴于數據庫。由于系統對賬需要對數據庫進行頻繁的查詢和更新操作且數據庫的連接數量有限，；因此，海量數據的對賬對數據庫的壓力非常高且很容易占滿數據庫連接，造成數據庫服務中止，且海量數據的入庫造成數據庫資源的浪費；進一步的，上述兩種對比方法對數據使用雙重循環，因此時間復雜度很高，對賬時效較差。

因此，需要提供一種的系統數據對賬方法及裝置。

需要說明的是，在上述背景技術部分公開的信息僅用于加強對本公開的背景的理解，因此可以包括不構成對本領域普通技術人員已知的現有技術的信息。

發明內容

本公開的目的在于提供一種系統數據對賬方法、系統數據對賬裝置、計算機可讀存儲介質以及電子設備，進而至少在一定程度上克服由于相關技術的限制和缺陷而導致的一個或者多個問題。

根據本公開的一個方面，提供一種系統數據對賬方法，包括：

接收對賬服務器發送的對賬請求，響應所述對賬請求并獲取第一待對賬數據；

將所述第一待對賬數據進行轉化得到與所述第一待對賬數據關聯的HashMap；

將所述HashMap存儲至Redis集群以使所述對賬服務器從所述Redis集群中獲取所述HashMap并計算所述HashMap與本地數據庫中的第二待對賬數據的差異性。

在本公開的一種示例性實施例中，在將所述HashMap存儲至Redis集群之后，所述系統數據對賬方法還包括：

判斷所述HashMap是否存儲成功；

在判斷所述HashMap存儲成功后，向所述對賬服務器發送MQ消息以使所述對賬服務器根據所述MQ消息處理對賬流程。

在本公開的一種示例性實施例中，將所述第一待對賬數據進行轉化得到與所述第一待對賬數據關聯的HashMap包括：

對所述第一待對賬數據的時間信息進行降維處理以得到與所述第一待對賬數據關聯的HashMap。

根據本公開的一個方面，提供一種系統數據對賬方法，包括：

監聽一MQ消息并在監聽到所述MQ消息后，開啟多個分布式任務并利用各所述分布式任務遍歷第三待對賬數據；

根據所述第三待對賬數據的數據單號從Redis集群中獲取與所述數據單號關聯的HashMap數據；

計算所述第三待對賬數據與所述HashMap數據的差異性。

在本公開的一種示例性實施例中，利用各所述分布式任務遍歷第三待對賬數據包括：

為各所述分布式任務配置一取值長度并根據各所述取值長度查詢所述第三待對賬數據以鎖定對應長度的對賬數據。

在本公開的一種示例性實施例中，計算所述第三待對賬數據與所述HashMap數據的差異性包括：

判斷所述第三待對賬數據與所述HashMap數據是否一致；

在判斷所述第三待對賬數據與所述HashMap數據不一致時，將所述數據單號對應的第三待對賬數據以及所述HashMap數據存儲至本地數據庫中。

在本公開的一種示例性實施例中，在計算所述第三待對賬數據與所述HashMap數據的差異性之前，所述系統數據對賬方法還包括：

刪除所述HashMap數據中與所述數據單號對應的數據節點。

在本公開的一種示例性實施例中，在根據所述第三待對賬數據的數據單號從Redis集群中獲取與所述數據單號關聯的HashMap數據之前，所述系統數據對賬方法還包括：

根據所述第三待對賬數據的數據單號判斷所述HashMap數據中是否存在與所述數據單號對應的數據單號；