本發(fā)明屬于銀行日志運行技術(shù)領(lǐng)域,尤其涉及一種日志運行方法及系統(tǒng)、客戶端和服務(wù)器。
背景技術(shù):
金證現(xiàn)有中間件KCBP擁有獨立的日志模塊,日志也是支持異步寫入及按不同日志級別異步寫入等屬性。但在多線程或多進程運行的情況下,由于KCBP日志模塊異步寫入的日志順序會出現(xiàn)雜亂無章的狀態(tài),且日志前置節(jié)點中的信息也無法標(biāo)記日志是屬于什么機構(gòu)或者哪個柜員操作,使得在生產(chǎn)維護及平時開發(fā)調(diào)試過程中閱讀日志、追蹤BUG變得十分困難。
故,有必要提出一種新的技術(shù)方案,以解決上述技術(shù)問題。
技術(shù)實現(xiàn)要素:
鑒于此,本發(fā)明實施例提供一種日志運行方法及系統(tǒng)、客戶端和服務(wù)器,以解決現(xiàn)有日志模塊異步寫入日志時會出現(xiàn)雜亂無章的問題。
本發(fā)明實施例的第一方面,提供一種日志運行的方法,方法包括服務(wù)器執(zhí)行的如下步驟:
接收客戶端發(fā)送的日志信息,所述日志信息包括日志ID和類型ID;所述類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個;
將所述日志信息分別存儲在與所述類型ID相對應(yīng)的配置文檔中,并將所述日志信息緩存在消息隊列中;
依據(jù)所述消息隊列,采用多個服務(wù)線程分別對每一所述配置文檔中存儲的所述日志信息進行分類,形成與所述類型ID相對應(yīng)的至少一個分類文件;
基于至少一個分類文件形成日志文件,并將所述日志文件發(fā)送給所述客戶端。
本發(fā)明實施例的第二方面,提供一種日志運行的方法,方法包括客戶端執(zhí)行的如下步驟:
生成日志信息,所述日志信息包括日志ID和類型ID;所述類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個;
將所述日志信息發(fā)送給服務(wù)器;
接收所述服務(wù)器發(fā)送的日志文件;所述日志文件包括至少一個分類文件,每一所述分類文件由一服務(wù)線程對基于所述類型ID形成的配置文檔中的日志信息進行分類處理形成的;
顯示所述日志文件。
本發(fā)明實施例的第三方面,提供一種服務(wù)器,所述服務(wù)器包括:
第一接收模塊,用于接收客戶端發(fā)送的日志信息,所述日志信息包括日志ID和類型ID;所述類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個;
緩存模塊,用于將所述日志信息分別存儲在與所述類型ID相對應(yīng)的配置文檔中,并將所述日志信息緩存在消息隊列中;
處理模塊,用于依據(jù)所述消息隊列,采用多個服務(wù)線程分別對每一所述配置文檔中存儲的所述日志信息進行分類,形成與所述類型ID相對應(yīng)的至少一個分類文件;
第一發(fā)送模塊,用于基于至少一個分類文件形成日志文件,并將所述日志文件發(fā)送給所述客戶端。
本發(fā)明實施例的第四方面,提供一種客戶端,客戶端包括:
生成模塊,用于生成日志信息,所述日志信息包括日志ID和類型ID;所述類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個;
第二發(fā)送模塊,用于將所述日志信息發(fā)送給服務(wù)器;
第二接收模塊,用于接收所述服務(wù)器發(fā)送的日志文件;所述日志文件包括至少一個分類文件,每一所述分類文件由一服務(wù)線程對基于所述類型ID形成的配置文檔中的日志信息進行分類處理形成的;
顯示模塊,用于顯示所述日志文件。
本發(fā)明實施例的第五方面,提供一種日志運行方法,其特征在于,包括如下步驟:
客戶端生成日志信息,并將所述日志信息發(fā)送給服務(wù)器;所述日志信息包括日志ID和類型ID;所述類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個;
服務(wù)器接收所述日志信息,將所述日志信息分別存儲在與所述類型ID相對應(yīng)的配置文檔中,并將所述日志信息緩存在消息隊列中;
服務(wù)器依據(jù)所述消息隊列,采用多個服務(wù)線程分別對每一所述配置文檔中存儲的所述日志信息進行分類,形成與所述類型ID相對應(yīng)的至少一個分類文件;
服務(wù)器基于至少一個分類文件形成日志文件,并將所述日志文件發(fā)送給所述客戶端;
客戶端接收并顯示所述日志文件。
本發(fā)明實施例的第六方面,提供一種日志運行系統(tǒng),其特征在于,包括客戶端和服務(wù)器;
所述客戶端,用于生成日志信息,并將所述日志信息發(fā)送給服務(wù)器;所述日志信息包括日志ID和類型ID;所述類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個;
所述服務(wù)器,用于接收所述日志信息,將所述日志信息分別存儲在與所述類型ID相對應(yīng)的配置文檔中,并將所述日志信息緩存在消息隊列中;
所述服務(wù)器,用于依據(jù)所述消息隊列,采用多個服務(wù)線程分別對每一所述配置文檔中存儲的所述日志信息進行分類,形成與所述類型ID相對應(yīng)的至少一個分類文件;
所述服務(wù)器,用于基于至少一個分類文件形成日志文件,并將所述日志文件發(fā)送給所述客戶端;
所述客戶端,用于接收并顯示所述日志文件。
本發(fā)明實施例與現(xiàn)有技術(shù)相比存在的有益效果是:本發(fā)明實施例根據(jù)類型ID將所有日志信息分別存儲在與類型ID相對應(yīng)的配置文檔中,再采用多個服務(wù)線程對消息隊列中緩存的日志信息進行處理,可使每一服務(wù)線程只需對一配置文檔中的日志信息進行分類處理,從而有序呈現(xiàn)相應(yīng)的日志文件。而且,該類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個,在基于類型ID將文件信息進行分類時,可實現(xiàn)一維或多維分類,日志信息分類更靈活。
附圖說明
為了更清楚地說明本發(fā)明實施例中的技術(shù)方案,下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹,顯而易見地,下面描述中的附圖僅僅是本發(fā)明的一些實施例,對于本領(lǐng)域普通技術(shù)人員來講,在不付出創(chuàng)造性勞動性的前提下,還可以根據(jù)這些附圖獲得其他的附圖。
圖1是本發(fā)明實施例一提供的日志運行方法的實現(xiàn)流程圖;
圖2是本發(fā)明實施例一提供的日志運行方法的實現(xiàn)流程圖二;
圖3是本發(fā)明實施例二提供的日志運行方法的實現(xiàn)流程圖;
圖4是本發(fā)明實施例二提供的日志運行方法的實現(xiàn)流程圖二;
圖5是本發(fā)明實施例三提供的服務(wù)器的結(jié)構(gòu)框圖;
圖6是本發(fā)明實施例四提供的客戶端的結(jié)構(gòu)框圖;
圖7是本發(fā)明實施例五提供的日志運行方法的實現(xiàn)流程圖;
圖8是本發(fā)明實施例六提供的日志運行系統(tǒng)的示意框圖。
具體實施方式
為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白,以下結(jié)合附圖及實施例,對本發(fā)明進行詳細(xì)說明。應(yīng)當(dāng)理解,此處所描述的具體實施例僅僅用以解釋本發(fā)明,并不用于限定本發(fā)明。
本發(fā)明實施例提供一種日志運行的方法。為了說明本發(fā)明所提供的的方法,下面通過具體實施例來進行說明。
實施例一
圖1示出了本發(fā)明實施例一提供的日志運行方法的實現(xiàn)流程圖。如圖1所示,該日志運行方法包括服務(wù)器執(zhí)行的如下步驟:
S101:接收客戶端發(fā)送的日志信息,日志信息包括日志ID和類型ID;類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個。
其中,服務(wù)器接收客戶端發(fā)送的日志信息,客戶端包括但不限于電腦客戶端和移動客戶端。日志信息是指用戶在客戶端進行交易時相應(yīng)產(chǎn)生的文件和/或數(shù)據(jù),包括日志ID和類型ID。日志ID是唯一的,用來唯一確定該日志的身份,類型ID用于將日志進行分類。
服務(wù)器將日志信息發(fā)送給服務(wù)器時,可通過TCP長連接、UPD、管道通訊等通訊傳輸協(xié)議。
客戶端為異步連接模塊,采用是LINUX、WINDOWS原生的系統(tǒng)API支持,協(xié)議支持TCP長連接、UPD、管道通訊等通訊傳輸協(xié)議,通訊傳輸協(xié)議的選擇需與服務(wù)端匹配。
S102:將日志信息分別存儲在與類型ID相對應(yīng)的配置文檔中,并將日志信息緩存在消息隊列中。
其中,配置文檔包括公共日志文件、理財日志文件和投資日志文件。每次在客戶端發(fā)生交易時都會產(chǎn)生相應(yīng)的日志信息,服務(wù)器按照時間先后順序接收這些日志信息并將日志信息緩存在消息隊列中以待下一步處理。
S103:依據(jù)消息隊列,采用多個服務(wù)線程分別對每一配置文檔中存儲的日志信息進行分類,形成與類型ID相對應(yīng)的至少一個分類文件。
在S102中服務(wù)器已經(jīng)將接收到的日志信息緩存到消息隊列中。根據(jù)服務(wù)器的性能預(yù)設(shè)多個服務(wù)線程可處理的消息隊列的長度。依據(jù)消息隊列,多個服務(wù)線程可同時對每一配置文檔中存儲的日志信息進行處理,以形成與類型ID相對應(yīng)的至少一個分類文件。
S104:基于至少一個分類文件形成日志文件,并將日志文件發(fā)送給客戶端。
基于至少一個分類文件形成日志文件,服務(wù)器將得到的日志文件發(fā)送給客戶端。
本實施例所提供的日志運行方法中,根據(jù)類型ID將所有日志信息分別存儲在與類型ID相對應(yīng)的配置文檔中,在采用多個服務(wù)線程對消息隊列中緩存的日志信息進行處理,可使每一服務(wù)線程只需對一配置文檔中的日志信息進行分類處理,從而有序呈現(xiàn)相應(yīng)的日志文件,以避免傳統(tǒng)方式處理后日志文件呈現(xiàn)雜亂無章的狀況。而且,該類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個,在基于類型ID將文件信息進行分類時,可實現(xiàn)一維或多維分類,日志信息分類更靈活。
圖2示出了本發(fā)明實施例一提供的日志運行方法的實現(xiàn)流程圖二。如圖2所示,該日志運行方法還包括:
S105:接收客戶端發(fā)送的的日志查詢指令,日志查詢指令包括至少一個類型ID。
其中,日志查詢指令可為類型ID中的多個ID,根據(jù)多個ID查詢有利于縮小查找范圍,快速找到所需日志并進行相應(yīng)處理,該處理包括閱讀或者修復(fù)。
S106:根據(jù)查詢指令調(diào)用日志文件生成查詢結(jié)果文件。
根據(jù)查詢指令調(diào)用日志文件的相關(guān)信息生成查詢結(jié)果。例如,接收到的查詢指令為類型ID中的柜員ID,根據(jù)該柜員ID調(diào)用日志文件中與該ID相關(guān)的信息,讀取該相關(guān)信息生成查詢結(jié)果,該查詢結(jié)果中包括在此柜員處進行交易的所有客戶的信息。
S107:將查詢結(jié)果文件發(fā)送到客戶端。
本實施例通過查詢輸入任一類型ID,即可獲知所需了解日志文件的查詢結(jié)果文件,從而了解任一交易時間、機構(gòu)、系統(tǒng)、業(yè)務(wù)、柜員進行處理時的相關(guān)日志文件的查詢結(jié)果文件。
實施例二
圖3示出了本發(fā)明實施例二提供的日志運行方法的實現(xiàn)流程圖。如圖3所示,該日志運行方法包括客戶端執(zhí)行的如下步驟:
S201:生成日志信息,日志信息包括日志ID和類型ID;類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個。
其中,日志信息是指用戶在客戶端進行交易時相應(yīng)產(chǎn)生的文件和/或數(shù)據(jù),包括日志ID和類型ID。日志ID是唯一的,用來唯一確定該日志的身份,類型ID用于將日志進行分類。用戶在客戶端進行交易時,生成日志信息,日志信息包括日志ID和類型ID。
S202:將日志信息發(fā)送給服務(wù)器。
客戶端將S101中生成的日志信息發(fā)送給服務(wù)器。
S203:接收服務(wù)器發(fā)送的日志文件;日志文件包括至少一個分類文件,每一分類文件由一服務(wù)線程對基于類型ID形成的配置文檔中的日志信息進行分類處理形成的。
客戶端接收服務(wù)器發(fā)送過來的日志文件,日志文件包括至少一個分類文件,即日志文件括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個。交易時間是指用戶在客戶端進行交易時生成交易日志的時間,ID是指身份識別序列號。每一分類文件由一服務(wù)線程對基于類型ID形成的配置文檔中的日志信息進行分類處理形成的。
S204:顯示日志文件。
在客戶端顯示日志文件的內(nèi)容。
本實施例所提供的日志運行方法中,通過客戶端與服務(wù)器的配合,根據(jù)類型ID將所有日志信息分別存儲在與類型ID相對應(yīng)的配置文檔中,在采用多個服務(wù)線程對消息隊列中緩存的日志信息進行處理,可使每一服務(wù)線程只需對一配置文檔中的日志信息進行分類處理,從而有序呈現(xiàn)相應(yīng)的日志文件,以避免傳統(tǒng)方式處理后日志文件呈現(xiàn)雜亂無章的狀況。而且,該類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個,在基于類型ID將文件信息進行分類時,可實現(xiàn)一維或多維分類,日志信息分類更靈活。
圖4示出了本發(fā)明實施例二提供的日志運行方法的實現(xiàn)流程圖二。如圖4所示,該日志運行方法還包括:
S205:接收用戶輸入的日志查詢指令,日志查詢指令包括至少一個類型ID。
客戶端接收用戶輸入的日志查詢指令,日志查詢指令包括至少一個類型ID,即至少包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的一個。相關(guān)人員可在客戶端輸入一個或多個類型ID進行查詢操作。
S206:將日志查詢指令發(fā)送給服務(wù)器。
相關(guān)人員可在客戶端輸入一個或多個類型ID進行查詢操作時,客戶端接收到日志查詢指令并將日志查詢指令發(fā)送給服務(wù)器。
S207:接收服務(wù)器發(fā)送的與日志查詢指令相對應(yīng)的查詢結(jié)果文件。
客戶端接收服務(wù)器發(fā)送的與日志查詢指令相對應(yīng)的查詢結(jié)果文件,接收方式通常采用讀取的方式。
S208:顯示查詢結(jié)果文件。
本實施例通過在客戶端輸入任一類型ID進行查詢,即可獲知所需了解日志文件的查詢結(jié)果文件,從而了解任一交易時間、機構(gòu)、系統(tǒng)、業(yè)務(wù)、柜員進行處理時的相關(guān)日志文件的查詢結(jié)果文件??筛鶕?jù)查詢結(jié)果文件進行生產(chǎn)維護或者追蹤開發(fā)調(diào)試過程中的BUG。
實施例三
對應(yīng)于上文實施例一的日志運行方法,圖3示出了本發(fā)明實施例三提供的服務(wù)器的結(jié)構(gòu)框圖,詳述如下:
參考圖5,該服務(wù)器包括:
第一接收模塊31,用于接收客戶端發(fā)送的日志信息,日志信息包括日志ID和類型ID;類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個。
緩存模塊32,用于將日志信息分別存儲在與類型ID相對應(yīng)的配置文檔中,并將日志信息緩存在消息隊列中。
處理模塊33,用于依據(jù)消息隊列,采用多個服務(wù)線程分別對每一配置文檔中存儲的日志信息進行分類,形成與類型ID相對應(yīng)的至少一個分類文件。
第一發(fā)送模塊34,用于基于至少一個分類文件形成日志文件,并將日志文件發(fā)送給客戶端。
可選地,服務(wù)器還包括:
第一接收模塊31,還用于接收客戶端發(fā)送的的日志查詢指令,日志查詢指令包括至少一個類型ID。
調(diào)用模塊35,用于根據(jù)查詢指令調(diào)用日志文件生成查詢結(jié)果文件。
第一發(fā)送模塊34,還用于將查詢結(jié)果文件發(fā)送到客戶端。
實施例四
對應(yīng)于上文實施例二的日志運行方法,圖4示出了本發(fā)明實施例四提供的客戶端的結(jié)構(gòu)框圖,詳述如下:
參考圖6,該客戶端包括:
生成模塊41,用于生成日志信息,日志信息包括日志ID和類型ID;類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個。
第二發(fā)送模塊42,用于將日志信息發(fā)送給服務(wù)器。
第二接收模塊43,用于接收服務(wù)器發(fā)送的日志文件;日志文件包括至少一個分類文件,每一分類文件由一服務(wù)線程對基于類型ID形成的配置文檔中的日志信息進行分類處理形成的。
顯示模塊44,用于顯示日志文件。
可選地,客戶端還包括:
第二接收模塊43,還用于接收用戶輸入的日志查詢指令,日志查詢指令包括至少一個類型ID。
第二發(fā)送模塊42,還用于將日志查詢指令發(fā)送給服務(wù)器。
第二接收模塊43,還用于接收服務(wù)器發(fā)送的與日志查詢指令相對應(yīng)的查詢結(jié)果文件。
顯示模塊44,還用于顯示查詢結(jié)果文件。
實施例五
圖7示出了本發(fā)明實施例五提供的日志運行方法的實現(xiàn)流程圖。如圖7所示,該日志運行方法包括如下步驟:
S501:接客戶端生成日志信息,并將日志信息發(fā)送給服務(wù)器。日志信息包括日志ID和類型ID。類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個。
S502:服務(wù)器接收日志信息,將日志信息分別存儲在與類型ID相對應(yīng)的配置文檔中,并將日志信息緩存在消息隊列中。
S503:服務(wù)器依據(jù)消息隊列,采用多個服務(wù)線程分別對每一配置文檔中存儲的日志信息進行分類,形成與類型ID相對應(yīng)的至少一個分類文件。
S504:服務(wù)器基于至少一個分類文件形成日志文件,并將日志文件發(fā)送給客戶端。
S505:客戶端接收并顯示日志文件。
實施例六
圖8示出了本發(fā)明實施例六提供的日志運行系統(tǒng)的示意框圖。如圖8所示,該日志日志運行系統(tǒng),其特征在于,包括客戶端和服務(wù)器。
客戶端61,用于生成日志信息,并將日志信息發(fā)送給服務(wù)器。日志信息包括日志ID和類型ID。類型ID包括交易時間、系統(tǒng)ID、業(yè)務(wù)ID、機構(gòu)ID和柜員ID中的至少一個。
服務(wù)器62,用于接收日志信息,將日志信息分別存儲在與類型ID相對應(yīng)的配置文檔中,并將日志信息緩存在消息隊列中。
服務(wù)器62,用于依據(jù)消息隊列,采用多個服務(wù)線程分別對每一配置文檔中存儲的日志信息進行分類,形成與類型ID相對應(yīng)的至少一個分類文件。
服務(wù)器62,用于基于至少一個分類文件形成日志文件,并將日志文件發(fā)送給客戶端。
客戶端61,用于接收并顯示日志文件。
在本發(fā)明所提供的實施例中,應(yīng)該理解到,所揭露的裝置和方法,可以通過其它的方式實現(xiàn)。例如,以上所描述的系統(tǒng)實施例僅僅是示意性的,例如,所述單元或單元的劃分,僅僅為一種邏輯功能劃分,實際實現(xiàn)時可以有另外的劃分方式,例如多個單元或組件可以結(jié)合或者可以集成到另一個系統(tǒng),或一些特征可以忽略,或不執(zhí)行。另一點,所顯示或討論的相互之間的耦合或直接耦合或通訊連接可以是通過一些接口,裝置或單元的間接耦合或通訊連接,可以是電性,機械或其它的形式。
所述作為分離部件說明的單元可以是或者也可以不是物理上分開的,作為單元顯示的部件可以是或者也可以不是物理單元,即可以位于一個地方,或者也可以分布到多個網(wǎng)絡(luò)單元上??梢愿鶕?jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。
另外,在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中,也可以是各個單元單獨物理存在,也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現(xiàn),也可以采用軟件功能單元的形式實現(xiàn)。
所述集成的單元如果以軟件功能單元的形式實現(xiàn)并作為獨立的產(chǎn)品銷售或使用時,可以存儲在一個計算機可讀取存儲介質(zhì)中。基于這樣的理解,本發(fā)明實施例的技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻的部分或者該技術(shù)方案的全部或部分可以以軟件產(chǎn)品的形式體現(xiàn)出來,該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)中,包括若干指令用以使得一臺計算機設(shè)備(可以是個人計算機,服務(wù)器,或者網(wǎng)絡(luò)設(shè)備等)或處理器(processor)執(zhí)行本發(fā)明實施例各個實施例所述方法的全部或部分步驟。而前述的存儲介質(zhì)包括:U盤、移動硬盤、只讀存儲器(ROM,Read-Only Memory)、隨機存取存儲器(RAM,Random Access Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。
以上所述實施例僅用以說明本發(fā)明的技術(shù)方案,而非對其限制;盡管參照前述實施例對本發(fā)明進行了詳細(xì)的說明,本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解:其依然可以對前述各實施例所記載的技術(shù)方案進行修改,或者對其中部分技術(shù)特征進行等同替換;而這些修改或者替換,并不使相應(yīng)技術(shù)方案的本質(zhì)脫離本發(fā)明各實施例技術(shù)方案的精神和范圍,均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。