本發(fā)明涉及數(shù)據(jù)分析處理技術領域，尤其涉及一種消息處理的方法及裝置。

背景技術：

目前，當用戶使用各種軟件時，在用戶發(fā)起請求、解析請求和服務器反饋請求等過程中，難免會遇到一些問題，例如，出現(xiàn)數(shù)據(jù)庫查詢失敗、用戶輸入導致腳本出錯和網(wǎng)絡問題等突發(fā)情況，對于這些突發(fā)情況，軟件一般會利用日志去記錄下這個突發(fā)過程，也就是說，記錄得到了錯誤日志，基于錯誤日志對記錄的錯誤做出相應的錯誤處理。

錯誤日志準確來說是軟件用來記錄運行時出錯消息的文本文件，編程人員和維護人員等可以利用錯誤日志對系統(tǒng)進行調試和維護?，F(xiàn)有技術中，公司一般有許多不同的項目，各個項目的負責人各自獲取自己的錯誤日志，然后各自進行處理，實現(xiàn)對各自項目系統(tǒng)進行調試和維護。

發(fā)明人經(jīng)過研究發(fā)現(xiàn)，采用現(xiàn)有技術的方式，導致各個項目采集和處理錯誤日志具有個性化，各個項目之間沒有相關性，并不具有統(tǒng)一規(guī)范性，不便于管理，此時急需能夠統(tǒng)一規(guī)范地采集各個項目錯誤日志進行分發(fā)處理的方法。

技術實現(xiàn)要素：

為了解決現(xiàn)有技術問題，本發(fā)明提供一種消息處理的方法及裝置,從而可以統(tǒng)一規(guī)范地采集各個項目錯誤日志，實現(xiàn)錯誤日志的分發(fā)處理。

第一方面，本發(fā)明實施例提供了一種消息處理的方法，應用于消息處理系統(tǒng)，該方法包括：

通過統(tǒng)一接口，接收客戶端發(fā)送的目標錯誤日志消息；所述目標錯誤日志消息符合所述統(tǒng)一接口的預設消息協(xié)議規(guī)范，所述預設消息協(xié)議規(guī)范的字段包括所述統(tǒng)一接口的標識字段；

根據(jù)隊列與交換機的綁定關系，將所述目標錯誤日志消息存儲至相應的消息隊列中；

從所述消息隊列中，獲得所述目標錯誤日志消息；

根據(jù)所述統(tǒng)一接口的標識字段，從數(shù)據(jù)庫中獲取所述目標錯誤日志消息對應的目標處理器；

向所述目標處理器發(fā)送所述目標錯誤日志消息，以便所述目標處理器處理所述目標錯誤日志消息。

優(yōu)選的，所述根據(jù)隊列與交換機的綁定關系，將所述目標錯誤日志消息存儲至相應的消息隊列中，包括：

將所述目標錯誤日志消息序列化；

根據(jù)所述隊列與交換機的綁定關系，將序列化的目標錯誤日志消息存儲至所述相應的消息隊列中。

優(yōu)選的，所述從所述消息隊列中，獲得所述目標錯誤日志消息，包括：

從所述消息隊列中，獲取所述序列化的目標錯誤日志消息；

將所述序列化的目標錯誤日志消息反序列化，獲得所述目標錯誤日志消息。

優(yōu)選的，還包括：

根據(jù)所述統(tǒng)一接口的標識字段，從數(shù)據(jù)庫中獲取所述目標錯誤日志消息對應的報警條件；

若所述目標錯誤日志消息滿足所述報警條件，通知報警器進行報警。

優(yōu)選的，在所述目標錯誤日志消息處理完成后，還包括：

向所述客戶端反饋處理結果。

優(yōu)選的，所述反饋處理結果的形式包括：短消息發(fā)送形式和/或郵件發(fā)送形式。

優(yōu)選的，在所述目標錯誤日志消息處理完成后，還包括：

剔除所述相應的消息隊列中的所述目標錯誤日志消息。

優(yōu)選的，所述統(tǒng)一接口是服務器利用php語言提供的。

優(yōu)選的，還包括：

監(jiān)控所述消息處理系統(tǒng)中各個程序的運行狀態(tài)。

第二方面，本發(fā)明實施例提供了一種消息處理的裝置，配置于消息處理系統(tǒng)，該裝置包括：

第一接收單元，用于通過統(tǒng)一接口，接收客戶端發(fā)送的目標錯誤日志消息；所述目標錯誤日志消息符合所述統(tǒng)一接口的預設消息協(xié)議規(guī)范，所述預設消息協(xié)議規(guī)范的字段包括所述統(tǒng)一接口的標識字段；

存儲單元，用于根據(jù)隊列與交換機的綁定關系，將所述目標錯誤日志消息存儲至相應的消息隊列中；

獲得單元，用于從所述消息隊列中，獲得所述目標錯誤日志消息；

第一獲取單元，用于根據(jù)所述統(tǒng)一接口的標識字段，從數(shù)據(jù)庫中獲取所述目標錯誤日志消息對應的目標處理器；

第一發(fā)送單元，用于向所述目標處理器發(fā)送所述目標錯誤日志消息，以便所述目標處理器處理所述目標錯誤日志消息。

與現(xiàn)有技術相比，本發(fā)明至少具有以下優(yōu)點：

采用本發(fā)明實施例的技術方案，首先根據(jù)服務器提供的預先設置了消息協(xié)議規(guī)范統(tǒng)一接口，統(tǒng)一規(guī)范地接收客戶端發(fā)送的目標錯誤日志消息并儲至相應的消息隊列中；接著根據(jù)所述目標錯誤日志消息攜帶的統(tǒng)一接口的標識，從數(shù)據(jù)庫中得到所述目標錯誤日志消息對應的目標處理器；最后向所述目標處理器發(fā)送所述目標錯誤日志消息，后續(xù)所述目標處理器處理所述目標錯誤日志消息。由此可見，通過預設消息協(xié)議規(guī)范的統(tǒng)一接口，實現(xiàn)了統(tǒng)一規(guī)范的收集不同項目的錯誤日志消息，而且根據(jù)統(tǒng)一接口的標識找到錯誤日志消息對應的處理器，實現(xiàn)不同項目的錯誤日志的分發(fā)處理。

附圖說明

為了更清楚地說明本申請實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請中記載的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其它的附圖。

圖1為本發(fā)明實施例中一種應用場景所涉及的系統(tǒng)框架示意圖；

圖2為本發(fā)明實施例提供的一種消息處理的方法的流程示意圖；

圖3為本發(fā)明實施例提供的另一種消息處理的方法的流程示意圖；

圖4為本發(fā)明實施例提供的一種消息處理的裝置的結構示意圖。

具體實施方式

為了使本技術領域的人員更好地理解本發(fā)明方案，下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅是本發(fā)明一部分實施例，而不是全部的實施例。基于本發(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

發(fā)明人經(jīng)過研究發(fā)現(xiàn)，現(xiàn)有技術中，許多不同的項目的負責人各自獲取自己的錯誤日志，然后各自進行處理，實現(xiàn)對各自項目系統(tǒng)進行調試和維護。例如，m公司開發(fā)有a、b和c三個項目，a項目負責人只獲取a項目的錯誤日志進行處理，b項目負責人只獲取b項目的錯誤日志進行處理，c項目負責人只獲取c項目的錯誤日志進行處理，a、b和c三個項目的錯誤日志的采集和處理具有個性化，a、b和c三個項目之間沒有相關性，并不具有統(tǒng)一規(guī)范性，不便于m公司統(tǒng)一整體管理a、b和c三個項目，此時就需要一種能夠統(tǒng)一規(guī)范地采集各個項目錯誤日志進行分發(fā)處理的方法。

為了解決這一問題，在本發(fā)明實施例中，首先根據(jù)服務器提供的預先設置了消息協(xié)議規(guī)范統(tǒng)一接口，統(tǒng)一規(guī)范地接收客戶端發(fā)送的目標錯誤日志消息并儲至相應的消息隊列中；接著根據(jù)所述目標錯誤日志消息攜帶的統(tǒng)一接口的標識，從數(shù)據(jù)庫中得到所述目標錯誤日志消息對應的目標處理器；最后向所述目標處理器發(fā)送所述目標錯誤日志消息，后續(xù)所述目標處理器處理所述目標錯誤日志消息。由此可見，通過預設消息協(xié)議規(guī)范的統(tǒng)一接口，實現(xiàn)了統(tǒng)一規(guī)范的收集不同項目的錯誤日志消息，而且根據(jù)統(tǒng)一接口的標識找到錯誤日志消息對應的處理器，實現(xiàn)不同項目的錯誤日志的分發(fā)處理。

舉例來說，本發(fā)明實施例的場景之一，可以是應用到如圖1所示的場景中。該場景中包括客戶端101、消息處理系統(tǒng)102、數(shù)據(jù)庫103、目標處理器104。消息處理系統(tǒng)102通過統(tǒng)一接口，接收客戶端102發(fā)送的目標錯誤日志消息；所述目標錯誤日志消息符合所述統(tǒng)一接口的預設消息協(xié)議規(guī)范，所述預設消息協(xié)議規(guī)范的字段包括所述統(tǒng)一接口的標識字段；根據(jù)隊列與交換機的綁定關系，消息處理系統(tǒng)102將所述目標錯誤日志消息存儲至相應的消息隊列中；消息處理系統(tǒng)102從所述消息隊列中，獲得所述目標錯誤日志消息；根據(jù)所述統(tǒng)一接口的標識字段，消息處理系統(tǒng)102從數(shù)據(jù)庫103中獲取所述目標錯誤日志消息對應的目標處理器104；消息處理系統(tǒng)102向所述目標處理器104發(fā)送所述目標錯誤日志消息，以便所述目標處理器104處理所述目標錯誤日志消息。

可以理解的是，在上述應用場景中，雖然將本發(fā)明實施方式的動作描述由消息處理系統(tǒng)102執(zhí)行。本發(fā)明在執(zhí)行主體方面不受限制，只要執(zhí)行了本發(fā)明實施方式所公開的動作即可。

可以理解的是，上述場景僅是本發(fā)明實施例提供的一個場景示例，本發(fā)明實施例并不限于此場景。

下面結合附圖，通過實施例來詳細說明本發(fā)明實施例中消息處理的方法及裝置的具體實現(xiàn)方式。

示例性方法

參見圖2，示出了本發(fā)明實施例中一種消息處理的方法的流程示意圖。在本實施例中，所述方法例如可以包括以下步驟：

步驟201：通過統(tǒng)一接口，接收客戶端發(fā)送的目標錯誤日志消息；所述目標錯誤日志消息符合所述統(tǒng)一接口的預設消息協(xié)議規(guī)范，所述預設消息協(xié)議規(guī)范的字段包括所述統(tǒng)一接口的標識字段。

實際應用中，所述消息處理系統(tǒng)一般可以包括服務器、消息隊列服務器和消息訂閱服務器，所述消息隊列服務器包括交換機，所述消息訂閱服務器包括消息分發(fā)處理器。因此，步驟201是指當用戶通過客戶端向服務器發(fā)起請求失敗時，日志記錄此次失敗的過程，即，獲得原始錯誤日志消息，由于服務器提供了統(tǒng)一接口，用于接收錯誤日志消息，該統(tǒng)一接口預先設置了消息協(xié)議規(guī)范，所述預設消息協(xié)議規(guī)范的字段包括所述統(tǒng)一接口的標識字段。因此，客戶端先將原始錯誤日志消息轉化為符合所述統(tǒng)一接口的預設消息協(xié)議規(guī)范的目標錯誤日志消息，然后將目標錯誤日志消息通過統(tǒng)一接口發(fā)送給服務器。其中，所述統(tǒng)一接口的標識字段用于后續(xù)找到該目標錯誤日志消息對應的處理器和報警條件。

php(英文全稱：hypertextpreprocessor，中文：超文本預處理器)語言是一種通用開源腳本語言，該語言吸收了c語言、java和perl的特點，利于學習，使用廣泛，主要適用于web開發(fā)領域，因此，在本實施例中，所述統(tǒng)一接口可以是服務器利用php語言開發(fā)提供的。

其中，所述預設消息協(xié)議規(guī)范的字段具體可以包括：統(tǒng)一接口標識(api_short)、統(tǒng)一接口完整url(req_url)、統(tǒng)一接口請求參數(shù)(req_params)、統(tǒng)一接口返回錯誤碼(err_code)、出錯時間(err_time)，返回結果是否為空(data_empty)和客戶端標識(client_ip)等字段。

步驟202：根據(jù)隊列與交換機的綁定關系，將所述目標錯誤日志消息存儲至相應的消息隊列中。

在服務器接收獲取到客戶端發(fā)送的目標錯誤日志消息之后，服務器會將所述目標錯誤日志消息發(fā)送至所述消息隊列服務器，根據(jù)預先建立的隊列與交換機綁定關系routingkey標識，存儲至所述消息隊列服務器的相應的消息隊列中。其中，所述交換機是消息隊列服務器的一個組成部分。存儲相應的消息隊列的過程為：目標錯誤日志消息被提交給交換機會攜帶routingkey標識，交換機依據(jù)攜帶的routingkey標識把目標錯誤日志消息分發(fā)到與該routingkey標識綁定的隊列。

在實際應用中，服務器若直接傳輸并存儲所述目標錯誤日志消息至消息隊列服務器的相應的消息隊列中，會占用較大的傳輸資源和存儲空間資源，為了節(jié)省傳輸資源和存儲空間資源，提高傳輸速度和存儲速度，可以將所述目標錯誤日志消息序列化后再傳輸存儲。在本實施例的一些實施方式中，所述步驟202，例如可以包括：將所述目標錯誤日志消息序列化；根據(jù)所述隊列與交換機的綁定關系，將序列化的目標錯誤日志消息存儲至所述相應的消息隊列中。

其中，所述序列化包括以下步驟：

步驟a：依據(jù)序列化工具protobuf語法規(guī)范定義一個.proto后綴的消息文件；

步驟b：通過php關于protobuf的第三方擴展生成包含序列化與反序列化程序的文件；

步驟c：調用所述文件的序列化方法進行序列化。

步驟203：從所述消息隊列中，獲得所述目標錯誤日志消息。

同理可知，所述步驟202具體是將序列化的目標錯誤日志消息存儲至相應的消息隊列中，那么，在本實施例中步驟203是指消息訂閱服務器從消息隊列服務器的相應的消息隊列中直接獲取到的是序列后的目標錯誤日志消息，需要將其反序列化，即，所述步驟203，例如可以包括：從所述消息隊列中，獲取所述序列化的目標錯誤日志消息；將所述序列化的目標錯誤日志消息反序列化，獲得所述目標錯誤日志消息。

其中，所述序列化包括以下步驟：

步驟d：依據(jù)序列化工具protobuf語法規(guī)范定義一個.proto后綴的消息文件；

步驟e：通過php關于protobuf的第三方擴展生成包含序列化與反序列化程序的文件；

步驟f：調用所述文件的反序列化方法進行反序列化。

步驟204：根據(jù)所述統(tǒng)一接口的標識字段，從數(shù)據(jù)庫中獲取所述目標錯誤日志消息對應的目標處理器。

需要說明的是，在數(shù)據(jù)庫中預先配置有所述目標錯誤日志消息對應的目標處理器，所述目標錯誤日志消息對應的目標處理器可能是只有一個，也可能有多個。從數(shù)據(jù)庫中獲取所述目標錯誤日志消息對應的目標處理器的方式是消息訂閱服務器遍歷數(shù)據(jù)庫中配置的所有處理器。

還需要說明的是，可能出現(xiàn)基于所述統(tǒng)一接口的標識字段，無法在數(shù)據(jù)庫中獲取到所述目標錯誤日志消息對應的目標處理器的情況，也就是說，數(shù)據(jù)庫沒有預先配置對應的處理器，此時，直接向預設默認的處理器發(fā)送所述目標錯誤日志消息，利用所述預設默認的處理器處理所述目標錯誤日志消息。

步驟205：向所述目標處理器發(fā)送所述目標錯誤日志消息，以便所述目標處理器處理所述目標錯誤日志消息。

在實際應用中，所述步驟205是指消息訂閱服務器通過消息分發(fā)處理器將所述目標錯誤日志消息發(fā)送給所述目標處理器。

需要說明的是，數(shù)據(jù)庫中還預先配置有所述目標錯誤日志消息對應的報警條件，便于在運行出錯時進行報警。該報警條件中報警閾值可以是根據(jù)環(huán)比閾值靈活設置的，當消息訂閱服務器獲取到目標錯誤日志消息時，可以遍歷數(shù)據(jù)庫獲得對應的配置的報警條件，進而判斷是否要報警。在本實施例的一些實施方式中，例如還可以包括：根據(jù)所述統(tǒng)一接口的標識字段，從數(shù)據(jù)庫中獲取所述目標錯誤日志消息對應的報警條件；若所述目標錯誤日志消息滿足所述報警條件，通知報警器進行報警。

還需要說明的是，可能出現(xiàn)基于所述統(tǒng)一接口的標識字段，無法在數(shù)據(jù)庫中獲取到所述目標錯誤日志消息對應的報警條件的情況，也就是說，數(shù)據(jù)庫沒有預先配置對應的報警條件，此時，根據(jù)預設默認的報警條件來判斷是否需要通知報警器進行報警。

其中，報警的方式可以是短消息形式通知報警器進行報警，也可以是郵件形式通知報警器進行報警，還可以是短消息和郵件兩種形式共同通知報警器進行報警。

需要說明的是，為了編程人員和維護人員等能夠及時了解錯誤日志消息所對應的錯誤的處理情況，在消息處理完成后需要反饋處理結果。因此，在本實施例的一些實施方式中，在所述目標錯誤日志消息處理完成后，例如還可以包括：向所述客戶端反饋處理結果。其中，所述反饋處理結果的形式包括：短消息發(fā)送形式和/或郵件發(fā)送形式。

由于錯誤日志消息不是批量而是逐一從消息隊列服務器的隊列中獲取的，在已被獲取的目標錯誤日志消息未處理完成之前消息訂閱服務器不會再次獲取下一個錯誤日志消息，因此，為了處理自動進行下一個錯誤日志消息的處理，在消息處理完成后需要在所述目標錯誤日志消息處理完成后從隊列中剔除目標錯誤日志消息。在本實施例的一些實施方式中，在所述目標錯誤日志消息處理完成后，例如還可以包括：剔除所述相應的消息隊列中的所述目標錯誤日志消息。

需要說明的是，在整個錯誤日志消息處理的過程中，可以監(jiān)控整個消息處理系統(tǒng)的運行狀態(tài)，以便于了解系統(tǒng)的運行情況。因此，在本實施例的一些實施方式中，例如還可以包括：監(jiān)控所述消息處理系統(tǒng)中各個程序的運行狀態(tài)。

通過本實施例提供的各種實施方式，首先根據(jù)服務器提供的預先設置了消息協(xié)議規(guī)范統(tǒng)一接口，統(tǒng)一規(guī)范地接收客戶端發(fā)送的目標錯誤日志消息并儲至相應的消息隊列中；接著根據(jù)所述目標錯誤日志消息攜帶的統(tǒng)一接口的標識，從數(shù)據(jù)庫中得到所述目標錯誤日志消息對應的目標處理器；最后向所述目標處理器發(fā)送所述目標錯誤日志消息，后續(xù)所述目標處理器處理所述目標錯誤日志消息。由此可見，通過預設消息協(xié)議規(guī)范的統(tǒng)一接口，實現(xiàn)了統(tǒng)一規(guī)范的收集不同項目的錯誤日志消息，而且根據(jù)統(tǒng)一接口的標識找到錯誤日志消息對應的處理器，實現(xiàn)不同項目的錯誤日志的分發(fā)處理。

下面通過另一實施例來詳細說明在實際應用中消息處理的方法的具體實現(xiàn)方式。

參見圖3，示出了本發(fā)明實施例中另一種消息處理的方法的流程示意圖。在本實施例中，所述方法例如可以包括以下步驟：

步驟301：客戶端將原始錯誤日志消息轉化為目標錯誤日志消息，目標錯誤日志消息符合服務器提供的統(tǒng)一接口的預設消息協(xié)議規(guī)范，預設消息協(xié)議規(guī)范的字段包括統(tǒng)一接口的標識字段。

步驟302：客戶端通過統(tǒng)一接口向服務器發(fā)送目標錯誤日志消息。

步驟303：服務器將接收到的目標錯誤日志消息進行序列化并發(fā)送給消息隊列服務器。

步驟304：消息隊列服務器根據(jù)隊列與交換機的綁定關系，將序列化的目標錯誤日志消息存儲至相應的消息隊列中。

步驟305：消息訂閱服務器從消息隊列中獲取序列化的目標錯誤日志消息。

步驟306：消息訂閱服務器將序列化的目標錯誤日志消息進行反序列化，獲得目標錯誤日志消息。

步驟307：消息訂閱服務器根據(jù)所述統(tǒng)一接口的標識字段，判斷數(shù)據(jù)庫中是否有目標錯誤日志消息對應的報警條件；若是，進入步驟308；如否，進入步驟309。

步驟308：判斷目標錯誤日志消息是否滿足報警條件，若是，進入步驟310。

步驟309：判斷目標錯誤日志消息滿足預設默認的報警條件，若是，進入步驟310。

步驟310：通知報警器進行報警。

步驟311：消息訂閱服務器根據(jù)所述統(tǒng)一接口的標識字段，判斷數(shù)據(jù)庫中是否有目標錯誤日志消息對應的目標處理器；若是，進入步驟312，若否，進入步驟313。

步驟312：消息訂閱服務器通過消息分發(fā)處理器向所述目標處理器發(fā)送所述目標錯誤日志消息，以便所述目標處理器處理所述目標錯誤日志消息。

步驟313：利用所述預設默認的處理器處理所述目標錯誤日志消息。

步驟314：消息訂閱服務器剔除所述相應的消息隊列中的所述目標錯誤日志消息。

步驟315：消息訂閱服務器以短消息和/或郵件形式向所述客戶端反饋處理結果。

通過本實施例提供的各種實施方式，首先根據(jù)服務器提供的預先設置了消息協(xié)議規(guī)范統(tǒng)一接口，統(tǒng)一規(guī)范地接收客戶端發(fā)送的目標錯誤日志消息并儲至相應的消息隊列中；接著根據(jù)所述目標錯誤日志消息攜帶的統(tǒng)一接口的標識，從數(shù)據(jù)庫中得到所述目標錯誤日志消息對應的目標處理器；最后向所述目標處理器發(fā)送所述目標錯誤日志消息，后續(xù)所述目標處理器處理所述目標錯誤日志消息。由此可見，通過預設消息協(xié)議規(guī)范的統(tǒng)一接口，實現(xiàn)了統(tǒng)一規(guī)范的收集不同項目的錯誤日志消息，而且根據(jù)統(tǒng)一接口的標識找到錯誤日志消息對應的處理器，實現(xiàn)不同項目的錯誤日志的分發(fā)處理。

示例性設備

參見圖4，示出了本發(fā)明實施例中一種消息處理的裝置的結構示意圖。在本實施例中，所述裝置例如具體可以包括：

第一接收單元401，用于通過統(tǒng)一接口，接收客戶端發(fā)送的目標錯誤日志消息；所述目標錯誤日志消息符合所述統(tǒng)一接口的預設消息協(xié)議規(guī)范，所述預設消息協(xié)議規(guī)范的字段包括所述統(tǒng)一接口的標識字段；

存儲單元402，用于根據(jù)隊列與交換機的綁定關系，將所述目標錯誤日志消息存儲至相應的消息隊列中；

獲得單元403，用于從所述消息隊列中，獲得所述目標錯誤日志消息；

第一獲取單元404，用于根據(jù)所述統(tǒng)一接口的標識字段，從數(shù)據(jù)庫中獲取所述目標錯誤日志消息對應的目標處理器；

第一發(fā)送單元405，用于向所述目標處理器發(fā)送所述目標錯誤日志消息，以便所述目標處理器處理所述目標錯誤日志消息。

可選的，所述存儲單元402包括序列化子單元和存儲子單元；

所述序列化子單元，用于將所述目標錯誤日志消息序列化；

所述存儲子單元，根據(jù)隊列與交換機的綁定關系，將序列化的目標錯誤日志消息存儲至相應的消息隊列中。

可選的，所述獲得單元403包括獲取子單元和反序列化獲得子單元；

所述獲取子單元，用于從所述消息隊列中，獲取所述序列化的目標錯誤日志消息；

所述反序列化獲得子單元，用于將所述序列化的目標錯誤日志消息反序列化，獲得所述目標錯誤日志消息。

可選的，還包括：

第二獲取單元，用于根據(jù)所述統(tǒng)一接口的標識字段，從數(shù)據(jù)庫中獲取所述目標錯誤日志消息對應的報警條件；

報警單元，用于若所述目標錯誤日志消息滿足所述報警條件，通知報警器進行報警。

可選的，還包括：

第二發(fā)送單元，用于向所述客戶端反饋處理結果。

可選的，所述反饋處理結果的形式包括：短消息發(fā)送形式和/或郵件發(fā)送形式。

可選的，還包括：

剔除單元，用于剔除所述相應的消息隊列中的所述目標錯誤日志消息。

可選的，所述統(tǒng)一接口是服務器利用php語言提供的。

可選的，還包括：

監(jiān)控單元，用于監(jiān)控所述消息處理系統(tǒng)中各個程序的運行狀態(tài)。

通過本實施例提供的各種實施方式，首先根據(jù)服務器提供的預先設置了消息協(xié)議規(guī)范統(tǒng)一接口，統(tǒng)一規(guī)范地接收客戶端發(fā)送的目標錯誤日志消息并儲至相應的消息隊列中；接著根據(jù)所述目標錯誤日志消息攜帶的統(tǒng)一接口的標識，從數(shù)據(jù)庫中得到所述目標錯誤日志消息對應的目標處理器；最后向所述目標處理器發(fā)送所述目標錯誤日志消息，后續(xù)所述目標處理器處理所述目標錯誤日志消息。由此可見，通過預設消息協(xié)議規(guī)范的統(tǒng)一接口，實現(xiàn)了統(tǒng)一規(guī)范的收集不同項目的錯誤日志消息，而且根據(jù)統(tǒng)一接口的標識找到錯誤日志消息對應的處理器，實現(xiàn)不同項目的錯誤日志的分發(fā)處理。

需要說明的是，在本文中，諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。

以上所述，僅是本發(fā)明的較佳實施例而已，并非對本發(fā)明作任何形式上的限制。雖然本發(fā)明已以較佳實施例揭露如上，然而并非用以限定本發(fā)明。任何熟悉本領域的技術人員，在不脫離本發(fā)明技術方案范圍情況下，都可利用上述揭示的方法和技術內(nèi)容對本發(fā)明技術方案做出許多可能的變動和修飾，或修改為等同變化的等效實施例。因此，凡是未脫離本發(fā)明技術方案的內(nèi)容，依據(jù)本發(fā)明的技術實質對以上實施例所做的任何簡單修改、等同變化及修飾，均仍屬于本發(fā)明技術方案保護的范圍內(nèi)。