[發(fā)明專利]分布式架構下的日志匯總查詢方法及裝置

在審

• 申請?zhí)枺?/td>: 202111397339.6
• 申請日: 2021-11-23
• 公開（公告）號: CN114090530A
• 公開（公告）日: 2022-02-25
• 發(fā)明（設計）人: 徐超
• 申請（專利權）人: 中國銀行股份有限公司
• 主分類號: G06F16/18
• 分類號: G06F16/18;G06F16/22;G06F16/2455
• 代理公司: 北京三友知識產權代理有限公司 11127
• 代理人: 湯在彥;沈珍珠

本發(fā)明公開了一種分布式架構下的日志匯總查詢方法及裝置，涉及物聯網技術領域，其中該方法包括：接收客戶端通過Kafka消息上送的交易日志信息；其中，交易日志信息包括全局日志流水ID和用戶ID；根據用戶ID確定交易日志信息應存儲的分庫編號和分表編號，將交易日志信息存儲在分布式數據庫中對應編號的分庫和分表；在接收到日志查詢請求時，根據日志查詢請求中的用戶ID，確定所要查詢的交易日志信息存儲的分庫編號和分表編號；根據日志查詢請求中的查詢條件，確定所要查詢的交易日志信息；從所要查詢的交易日志信息存儲的分庫編號和分表編號對應的分庫和分表，查詢交易日志信息。本發(fā)明可以提高查詢效率，保障查詢時效性。

技術領域

本發(fā)明涉及物聯網技術領域，尤其涉及一種分布式架構下的日志匯總查詢方法及裝置。

背景技術

本部分旨在為權利要求書中陳述的本發(fā)明實施例提供背景或上下文。此處的描述不因為包括在本部分中就承認是現有技術。

目前銀行系統(tǒng)一般為分布式業(yè)務系統(tǒng)，例如：轉賬業(yè)務和電票業(yè)務分屬不同的微服務，交易信息和日志信息也記錄在不同的數據庫。在實際業(yè)務中，銀行管理人員需要從業(yè)務類型、所屬機構進行日志信息統(tǒng)計，即以業(yè)務類型、機構信息、起止日期等維度進行日志數據聚合。現有分布式架構下，針對同一客戶的交易日志信息，需要從不同的微服務進行查詢，現有的一種方案為通過Dubbo服務接口聯機查詢日志信息，并且通過程序進行日志數據聚合，但是在數據量很大的時候，會嚴重影響銀行系統(tǒng)性能，分布式系統(tǒng)交易日志數據匯總的查詢效率較低；現有的另一種方案為各個微服務通過夜間批量，生成異步日志文件，用戶通過下載得到全量日志信息，但是通過夜間批量生成日志文件，日志查詢的時效性不高。

發(fā)明內容

本發(fā)明實施例提供一種分布式架構下的日志匯總查詢方法，用以提高日志數據匯總查詢的效率，保障日志數據匯總查詢的時效性，該方法包括：

接收客戶端通過Kafka消息上送的交易日志信息；其中，交易日志信息包括全局日志流水ID和用戶ID；全局日志流水ID為：根據Oracle數據庫序列號生成的交易日志信息的主鍵；

根據用戶ID確定交易日志信息應存儲的分庫編號和分表編號，將交易日志信息存儲在分布式數據庫中對應編號的分庫和分表；

在接收到日志查詢請求時，根據日志查詢請求中的用戶ID，確定所要查詢的交易日志信息存儲的分庫編號和分表編號；根據日志查詢請求中的查詢條件，確定所要查詢的交易日志信息；

從所要查詢的交易日志信息存儲的分庫編號和分表編號對應的分庫和分表，查詢交易日志信息。

本發(fā)明實施例還提供一種分布式架構下的日志匯總查詢裝置，用以提高日志數據匯總查詢的效率，保障日志數據匯總查詢的時效性，該裝置包括：

接收模塊，用于接收客戶端通過Kafka消息上送的交易日志信息；其中，交易日志信息包括全局日志流水ID和用戶ID；全局日志流水ID為：根據Oracle數據庫序列號生成的交易日志信息的主鍵；

存儲模塊，用于根據用戶ID確定交易日志信息應存儲的分庫編號和分表編號，將交易日志信息存儲在分布式數據庫中對應編號的分庫和分表；

確定模塊，用于在接收到日志查詢請求時，根據日志查詢請求中的用戶ID，確定所要查詢的交易日志信息存儲的分庫編號和分表編號；根據日志查詢請求中的查詢條件，確定所要查詢的交易日志信息；

查詢模塊，用于從所要查詢的交易日志信息存儲的分庫編號和分表編號對應的分庫和分表，查詢交易日志信息。

本發(fā)明實施例還提供一種計算機設備，包括存儲器、處理器及存儲在存儲器上并可在處理器上運行的計算機程序，所述處理器執(zhí)行所述計算機程序時實現上述分布式架構下的日志匯總查詢方法。