本申請涉及互聯網技術領域，特別涉及一種交易請求處理方法、裝置以及分布式系統。

背景技術：

目前，互聯網交易中存在通過虛假交易使得某一特定產品的交易量大幅增加的情況。例如，通過將已成功交易的多個訂單的請求參數進行拼接模擬請求參數，并根據模擬的請求參數進行批量或者并發下單。但是，模擬的請求參數并不是根據產品的實際屬性生成的，這就存在請求參數與產品的實際屬性沖突(例如，產品庫存量小于請求參數中庫存量)的情況，進而導致無法處理的異常請求。

當大量的異常請求訪問業務服務器時，會大量耗費服務器的資源。因此，需要對異常請求進行識別，并對異常請求，以避免此情況。目前，主要通過交易頻率來判斷是否為異常請求，即如果接收到一個交易請求的頻率超過某一頻率閾值，則判斷該交易請求為異常請求。這種方式，存在將正常的交易請求判斷為異常請求的可能，導致正常的交易請求無法被處理，給用戶帶來不便。此外，這種方式可通過設定不同的發送頻率而繞開設定的頻率閾值。因此，目前的異常請求的識別準確較低。

技術實現要素：

本申請旨在至少在一定程度上解決上述技術問題。

為此，本申請的第一個目的在于提出一種交易請求處理方法，能夠提高異常請求的識別準確率，有效靈活地識別異常請求，且判定模型不易被破解。

本申請的第二個目的在于提出另一種交易請求處理方法。

本申請的第三個目的在于提出一種交易請求處理裝置。

本申請的第四個目的在于提出另一種交易請求處理裝置。

本申請第三個目的在于提出一種分布式系統。

為達上述目的，根據本申請第一方面實施例提出了一種交易請求處理方法，包括以下步驟：接收交易請求；提取所述交易請求中的請求參數；根據判定模型中的過濾條件匹配所述請求參數，其中，所述判定模型包括多個過濾條件，所述過濾條件是由從異常處理日志中提取的異常參數組合所生成的。

本申請實施例的交易請求處理方法，在接收到交易請求后，可提取交易請求中的請求參數，并根據由異常處理對應的請求參數組合生成的判定模型中的過濾條件匹配請求參數，如果匹配則拒絕該交易請求，由此，不但可以準確的判斷分布式服務系統是否存在惡意的提交交易請求的行為，并進行拒絕，且能夠有效防止把正常用戶的下單請求拒絕的情況，提高了異常請求的識別準確率，能夠有效靈活地識別異常請求，且判定模型不易被破解。

本申請第二方面實施例提供了另一種交易請求處理方法，包括以下步驟：獲取交易系統中的交易處理日志，并從所述交易日志中提取異常處理日志；從所述異常處理日志中提取各個異常處理對應的請求參數；將各異常處理對應的請求參數分別進行組合，以生成與每個異常處理分別對應的拼接參數；將所述拼接參數作為過濾條件加入異常請求的判定模型，以根據所述判定模型對接收到的交易請求進行參數匹配，以判斷所述交易請求是否為異常請求。

本申請實施例的交易請求處理方法，通過從交易系統的處理日志中提取異常處理日志，并進一步提取異常處理對應的請求參數，并分別進行組合生成與每個異常處理分別對應的拼接參數，作為過濾條件加入判定模型，由此，根據該判定模型判斷交易請求是否異常請求，不但可以準確的判斷分布式服務系統是否存在惡意的提交交易請求的行為，并進行拒絕，且能夠有效防止把正常用戶的下單請求拒絕的情況，提高了異常請求的識別準確率，能夠有效靈活地識別異常請求，且判定模型不易被破解。

本申請第三方面實施例提供了一種交易請求處理裝置，包括：接收模塊，用于接收交易請求；提取模塊，用于提取所述交易請求中的請求參數；匹配模塊，用于根據判定模型中的過濾條件匹配所述請求參數，其中，所述判定模型包括多個過濾條件，所述過濾條件是由從異常處理日志中提取的異常參數組合所生成的；拒絕模塊，用于如果所述請求參數與所述過濾條件匹配，則拒絕所述交易請求。

本申請實施例的交易請求處理裝置，在接收到交易請求后，可提取交易請求中的請求參數，并根據由異常處理對應的請求參數組合生成的判定模型中的過濾條件匹配請求參數，如果匹配則拒絕該交易請求，由此，不但可以準確的判斷分布式服務系統是否存在惡意的提交交易請求的行為，并進行拒絕，且能夠有效防止把正常用戶的下單請求拒絕的情況，提高了異常請求的識別準確率，能夠有效靈活地識別異常請求，且判定模型不易被破解。

本申請第四方面實施例提供了另一種交易請求處理裝置，包括：第一獲取模塊，用于獲取交易系統中的交易處理日志，并從所述交易日志中提取異常處理日志；提取模塊，用于從所述異常處理日志中提取各個異常處理對應的請求參數；生成模塊，用于將各異常處理對應的請求參數分別進行組合，以生成與每個異常處理分別對應的拼接參數；識別模塊，用于將所述拼接參數作為過濾條件加入異常請求的判定模型，以根據所述判定模型對接收到的交易請求進行參數匹配，以判斷所述交易請求是否為異常請求。

本申請實施例的交易請求處理裝置，通過從交易系統的處理日志中提取異常處理日志，并進一步提取異常處理對應的請求參數，并分別進行組合生成與每個異常處理分別對應的拼接參數，作為過濾條件加入判定模型，由此，根據該判定模型判斷交易請求是否異常請求，不但可以準確的判斷分布式服務系統是否存在惡意的提交交易請求的行為，并進行拒絕，且能夠有效防止把正常用戶的下單請求拒絕的情況，提高了異常請求的識別準確率，能夠有效靈活地識別異常請求，且判定模型不易被破解。

本申請第五方面實施例提供了一種分布式系統，包括：客戶端；以及多個分布式服務器，所述多個分布式服務器包括本申請第三方面實施例或第四方面實施例的交易請求處理裝置。

本申請實施例的分布式系統，在接收到客戶端的交易請求后，分布式服務器中的交易請求處理裝置可提取交易請求中的請求參數，并根據由異常處理對應的請求參數生的成判定模型中的過濾條件匹配該請求參數，以判斷是否為異常請求，并進行相應處理，由此，不但可以準確的判斷分布式服務系統是否存在惡意的提交交易請求的行為，并進行拒絕，且能夠有效防止把正常用戶的下單請求拒絕的情況，提高了分布式系統中異常請求的識別準確率，能夠有效靈活地識別異常請求，且判定模型不易被破解。

本申請的附加方面和優點將在下面的描述中部分給出，部分將從下面的描述中變得明顯，或通過本申請的實踐了解到。

附圖說明

本申請的上述和/或附加的方面和優點從結合下面附圖對實施例的描述中將變得明顯和容易理解，其中：

圖1為根據本申請一個實施例的交易請求處理方法的流程圖；

圖2為根據本申請一個實施例的建立判定模型過程的流程圖；

圖3為根據本申請另一個實施例的交易請求處理方法的流程圖；

圖4為根據本申請又一個實施例的交易請求處理方法的流程圖；

圖5為根據本申請另一個實施例的交易請求處理方法的流程圖；

圖6為根據本申請一個實施例的交易請求處理裝置的結構示意圖一；

圖7為根據本申請一個實施例的交易請求處理裝置的結構示意圖二；

圖8為根據本申請一個實施例的交易請求處理裝置的結構示意圖三；

圖9為根據本申請一個實施例的交易請求處理裝置的結構示意圖四；

圖10為根據本申請另一個實施例的交易請求處理裝置結構示意圖一；

圖11為根據本申請另一個實施例的交易請求處理裝置結構示意圖二；

圖12為根據本申請另一個實施例的交易請求處理裝置結構示意圖三。

具體實施方式

下面詳細描述本申請的實施例，所述實施例的示例在附圖中示出，其中自始至終相同或類似的標號表示相同或類似的元件或具有相同或類似功能的元件。下面通過參考附圖描述的實施例是示例性的，僅用于解釋本申請，而不能理解為對本申請的限制。

需要說明的是，本申請的實施例可應用于分布式交易系統中的分布式服務器中。

當前分布式系統中接收到的交易請求中可能會存在異常請求，例如，分布式交易系統中的虛假交易請求。舉例來說，虛假交易請求可以是根據真實用戶和真實商品數據參數拼接后生成，并批量并發執行的交易下單請求。為了能夠準確識別當前分布式系統接收到的異常請求，本申請提出一種交易請求處理方法、裝置以及分布式系統。

下面參考附圖描述根據本申請實施例的交易請求處理方法、裝置以及分布式系統。

圖1為根據本申請一個實施例的交易請求處理方法的流程圖。

如圖1所示，根據本申請實施例的交易請求處理方法，包括：

s101，接收交易請求。

分布式系統中的服務器可接收由客戶端發送的交易請求。

其中，分布式系統是互聯網主要的一種架構形式，分布式系統中包括大量的服務器集群。當客戶端向分布式系統提交交易請求時，分布式系統可按照預設的分配規則從服務器集群中選擇一個服務器，并將該交易請求發送至選擇的服務器進行處理。

s102，提取交易請求中的請求參數。

其中，交易請求中可包括用戶標識、交易對象標識、產品統一編號、客戶端標識、交易量等參數。

在本申請的一個實施例中，請求參數可包括以下至少之一：

用戶標識、交易對象標識、交易合約標識、產品統一編號、客戶端標識。

舉例來說，用戶標識可為用戶id(identification，身份標識)、帳號等。用戶標識可包括交易雙方用戶的用戶標識，如買家標識和賣家標識。

交易對象標識為交易對象名稱等。例如，商品名稱。

交易合約標識用于對交易過程中約定數據進行標識，如交易量、價格或者其他約定參數等。

產品統一編號，可為sku(stockkeepingunit，最小庫存量，即保存庫存控制的最小可用單位)id。

此處對交易對象標識和產品統一編號進行區別說明。交易對象標識是指交易對象的名稱等，例如某品牌的某款產品。而產品統一編號是用于對一個特定交易對象來說，具有不同屬 性的單品進行標識。舉例來說，對一種商品而言，當其品牌、型號、配置、等級、花色、包裝容量、單位、生產日期、保質期、用途、價格、產地等屬性與其他商品存在不同時，可稱為一個單品。

客戶端標識可為客戶端的ip(internetprotocol，網絡之間互聯的協議)地址、設備標識等。

s103，根據判定模型中的過濾條件匹配所述請求參數，其中，判定模型包括多個過濾條件，過濾條件是由從異常處理日志中提取的異常參數組合所生成的。

具體地，由于異常請求大多是是根據真實的交易數據中請求參數拼接生成。以在線購物流程為例，這些拼接而成的交易請求并非是從商品購買頁面中通過選擇商品屬性、數量等操作生成的，繞過了對商品庫存量、商品的銷售狀態(如是否上架等)進行校驗。因此，當對這些拼接而成的交易請求進行處理時，存在無法下單的情況，此時會在系統中生成該交易請求對應的異常處理日志。因此，可根據交易請求的處理日志提取出對應的異常請求，進而，將異常請求對的請求參數進行組合，并將組合后的拼接參數作為過濾條件加入判定模型。由此，經過對大量異常處理日志的分析處理，可得到大量過濾條件，這些過濾條件即組成了上述判定模型。

在本申請的實施例中，判定模型可預先建立。因此，本申請實施例的交易請求處理方法還可包括建立判定模型的過程。具體地，如圖2所示，建立判定模型可包括以下步驟：

s201，獲取交易系統中的交易處理日志，并從所述交易日志中提取異常處理日志。

在本申請的一個實施例中，可提取一段時間內(如一個月內或者一周內)交易系統中的交易處理日志。其中，交易系統可以是分布式系統中的服務器集群，還可以是分布式系統中任意一個服務器。由于在對交易請求進行處理時，異常交易請求會因參數錯誤而無法成功下單，此時該異常交易請求的處理日志中會生成異常處理日志。因此，可將交易系統的交易處理日志所包括的異常處理日志提取出來。

s202，從異常處理日志中提取各個異常處理對應的請求參數。

s203，將各異常處理對應的請求參數分別進行組合，以生成與每個異常處理分別對應的拼接參數。

其中，異常處理日志中包括請求參數、請求時間、處理狀態或處理結果等信息。

因此，對于每個異常處理，可分別提取其對應的請求參數，并進行組合，生成該異常處理對應的拼接參數。在本申請的一個實施例中，上述拼接參數可為異常請求的參數中一個或多個的組合。也就是說，可將異常請求中的參數按照預設組合規則進行組合生成拼接參數。

s204，將所述拼接參數作為過濾條件加入異常請求的判定模型，以建立所述判定模型。

由此，可通過大量的異常處理日志中的各個異常處理的請求參數拼接為多個過濾條件。 這些過濾條件即構成了異常請求的判定模型。

進而，在分布式系統接收到新的交易請求，并提取出交易請求的請求參數后，可根據判定模型中的過濾條件匹配所述請求參數。具體地，可包括：根據預設組合規則對所述請求參數進行組合；判斷所述判定模型中是否存在與組合后的請求參數一致的過濾條件；如果存在，則判斷所述請求參數與過濾條件匹配。

舉例來說，對于以下異常請求：

request:com.taobao.trade.face.dto.tradebuyquery@25d3f6cb[buynow＝true,userid＝2745295631,itemid＝21056795895,skuid＝0,quantity＝1ua＝anclient,ttid＝207200@tmall_android_4.2.2,apiname＝mtop.trade.buildorder,sid＝1c4ca622e7e772361ef6043bd0281f7d……]

上述異常請求中包括用戶id：userid＝2745295631，商品id：itemid＝21056795895，產品同一編號：skuid＝0，可將其中的用戶id和商品id的組合作為一個過濾條件(可用userid->itemid的形式表示)加入判定模型。即判定模型中的一個過濾條件為“userid＝2745295631->itemid＝21056795895”。

在提取出接收到的交易請求的請求參數后，可將請求參數中的userid和itemid進行組合，如果userid和itemid的組合與過濾條件“userid＝2745295631->itemid＝21056795895”一致，則判斷所述請求參數與過濾條件匹配。如果請求參數中不包括“userid＝2745295631”或者“itemid＝21056795895”中的任何一個，則可判斷所述請求參數與過濾條件不匹配。

同樣地，也可以將其中的用戶id和產品同一編號的組合作為一個過濾條件，即將userid＝2745295631->skuid＝0作為過濾條件。

s104，如果所述請求參數與過濾條件匹配，則拒絕所述交易請求。

如果所述請求參數與過濾條件匹配，則該請求參數對應的交易請求為異常請求，因此可拒絕該交易請求，能夠有效避免異常交易消耗系統資源。

由此，通過將根據異常請求的參數生成的過濾條件加入到判定模型中，可對具有相同參數的交易請求直接進行拒絕，能夠有效的靈活的識別異常請求。當大量異常請求提交到系統中時，能夠有效識別并拒絕，從而大大降低系統資源的消耗。此外，該判定模型是根據異常請求的參數作為判定邏輯，比較靈活，不容易破解，并且不會導致正常用戶的請求被拒絕。

本申請實施例的交易請求處理方法，在接收到交易請求后，可提取交易請求中的請求參數，并根據由異常處理對應的請求參數組合生成的判定模型中的過濾條件匹配請求參數，如果匹配則拒絕該交易請求，由此，不但可以準確的判斷分布式服務系統是否存在惡意的提交交易請求的行為，并進行拒絕，且能夠有效防止把正常用戶的下單請求拒絕的情況，提高了異常請求的識別準確率，能夠有效靈活地識別異常請求，且判定模型不易被破解。

在本申請的一個實施例中，可以在分布式系統中針對每個服務器單獨生成判定模型，并 存儲在各個服務器對應的獨立存儲器中。也就是說，各個服務器可根據各自處理的交易請求的日志提取出異常請求，并構建判定模型進行存儲。從而，分布式系統中的各個服務器均可根據各自對應的獨立存儲器中的判定模型對接收到的交易請求進行識別。

在本申請的另一個實施例中，分布式系統中的多個服務器可具有一個共享存儲器，上述判定模型可存儲在該共享存儲器中。各個服務器可將各自構建的過濾條件添加至共享存儲器中的判定模型中。由此，不同服務器生成的過濾條件可在分布式系統中各服務器之間共享，能夠更準確地識別整個分布式服務器的異常請求。

進一步地，如果所述請求參數與過濾條件不匹配，則處理所述交易請求。如果所述請求參數與過濾條件不匹配，則該請求參數對應的交易請求為正常交易請求，可進行交易處理。

在本申請的一個實施例中，在對交易請求的處理過程中，可根據處理日志將處理異常的請求不斷生成新的過濾條件，并加入判定模型中。圖3為根據本申請另一個實施例的交易請求處理方法的流程圖。

如圖3所示，根據本申請實施例的交易請求處理方法，包括：步驟s101-s104。

在本申請的一個實施例中，在步驟s104之后還可包括步驟s105-s109：

s105，如果所述請求參數與過濾條件不匹配，則處理所述交易請求。

s106，獲取所述交易請求的處理日志。

s107，判斷所述處理日志是否異常。

s108，如果所述處理日志異常，則記錄所述處理日志的出現次數。

s109，如果所述出現次數大于預設次數，則根據預設組合規則對所述交易請求中的請求參數進行組合以生成過濾條件，并添加至判定模型。

其中，s106-s109是可選的。

由此，可不斷根據新的異常請求中的參數拼接或組合生成過濾條件，添加至判定模型，能夠不斷更新判定模型，從而使異常請求難以找到規律繞過該判定模型中的過濾條件。

更近一步地，由于在分布式系統中存在大量的服務器集群，因此，用戶的兩次下單請求，幾乎不可能在短時間內命中同一臺服務器。如果多個同樣的請求參數的交易請求在預設時間內命中同一臺服務器，則可將該請求參數對應的交易請求判定為異常請求。

在本申請的一個實施例中，判定模型中還可包括與過濾條件對應的預設時間，如圖4所示，本申請的交易請求處理方法還可包括步驟s401和s402。

s401，記錄判定模型中的過濾條件的存活時間。

其中，過濾條件的存活時間為過濾條件從生成到當前計時時間之間的時間差。

s402，當判定模型中的過濾條件的存活時間達到對應的預設時間時，將過濾條件和與過濾條件對應的預設時間在判定模型中刪除。

舉例來說，存活時間可為1小時。

由此，本申請實施例的交易請求處理方法，當過濾條件的存活時間超過預時間時，可將該過濾條件在判定模型中刪除，從而能夠避免判定模型過度膨脹，提高識別效率。

應當理解，在過濾條件a在判定模型中被刪除之后，如果包含過濾條件a中的請求參數的交易請求在處理過程中再次被作為異常請求，則過濾條件a可再次被加入到判定模型中。由此，可隨著時間的推移動態調整判定模型，能夠維持異常請求的識別準確性和高效性的平衡。

本申請還提出另一種交易請求處理方法。

圖5為根據本申請另一個實施例的交易請求處理方法的流程圖。

如圖5所示，根據本申請實施例的交易請求處理方法，包括：

s501，獲取交易系統中的交易處理日志，并從所述交易日志中提取異常處理日志。

其中，交易系統可以是分布式系統中的服務器集群，還可以是分布式系統中任意一個服務器。其中，分布式系統是互聯網主要的一種架構形式，分布式系統中包括大量的服務器集群。當客戶端向分布式系統提交交易請求時，分布式系統可按照預設的分配規則從服務器集群中選擇一個服務器，并將該交易請求發送至選擇的服務器進行處理。

具體地，由于異常請求大多是是根據真實的交易數據中請求參數拼接生成。以在線購物流程為例，這些拼接而成的交易請求并非是從商品購買頁面中通過選擇商品屬性、數量等操作生成的，繞過了對商品庫存量、商品的銷售狀態(如是否上架等)進行校驗。因此，當對這些拼接而成的交易請求進行處理時，存在無法下單的情況，此時會在系統中生成該交易請求對應的異常處理日志。因此，可根據交易請求的處理日志提取出對應的異常請求，進而，將異常請求對的請求參數進行組合，并將組合后的拼接參數作為過濾條件加入判定模型。由此，經過對大量異常處理日志的分析處理，可得到大量過濾條件，這些過濾條件即組成了上述判定模型。

在本申請的一個實施例中，可提取一段時間內(如一個月內或者一周內)交易系統中的交易處理日志。由于在對交易請求進行處理時，異常交易請求會因參數錯誤而無法成功下單，此時該異常交易請求的處理日志中會生成異常處理日志。因此，可將交易系統的交易處理日志所包括的異常處理日志提取出來。

s502，從所述異常處理日志中提取各個異常處理對應的請求參數。

其中，異常處理日志中包括請求參數、請求時間、處理狀態或處理結果等信息。其中，請求參數可包括用戶標識、交易對象標識、產品統一編號、客戶端標識、交易量等參數。

舉例來說，用戶標識可為用戶id(identification，身份標識)、帳號等。用戶標識可包 括交易雙方用戶的用戶標識，如買家標識和賣家標識。

交易對象標識為交易對象名稱等。例如，商品名稱。

交易合約標識用于對交易過程中約定數據進行標識，如交易量、價格或者其他約定參數等。

產品統一編號，可為sku(stockkeepingunit，最小庫存量，即保存庫存控制的最小可用單位)id。

此處對交易對象標識和產品統一編號進行區別說明。交易對象標識是指交易對象的名稱等，例如某品牌的某款產品。而產品統一編號是用于對一個特定交易對象來說，具有不同屬性的單品進行標識。舉例來說，對一種商品而言，當其品牌、型號、配置、等級、花色、包裝容量、單位、生產日期、保質期、用途、價格、產地等屬性與其他商品存在不同時，可稱為一個單品。

客戶端標識可為客戶端的ip(internetprotocol，網絡之間互聯的協議)地址、設備標識等。

s503，將各異常處理對應的請求參數分別進行組合，以生成與每個異常處理分別對應的拼接參數。

也就是說，對于每個異常處理，可分別提取其對應的請求參數，并進行組合，生成該異常處理對應的拼接參數。在本申請的一個實施例中，上述拼接參數可為異常請求的參數中一個或多個的組合。也就是說，可將異常請求中的參數按照預設組合規則進行組合生成拼接參數。

s504，將所述拼接參數作為過濾條件加入異常請求的判定模型，以根據所述判定模型對接收到的交易請求進行參數匹配，以判斷所述交易請求是否為異常請求。

由此，可通過大量的異常處理日志中的各個異常處理的請求參數拼接為多個過濾條件。這些過濾條件即構成了異常請求的判定模型。

進而，在分布式系統接收到新的交易請求，并提取出交易請求的請求參數后，可根據判定模型中的過濾條件匹配所述請求參數，以判斷所述交易請求是否為異常請求。

具體地，根據所述判定模型對接收到的交易請求進行參數匹配，以判斷所述交易請求是否為異常請求，可包括：根據預設組合規則對所述請求參數進行組合；判斷所述判定模型中是否存在與組合后的請求參數一致的過濾條件；如果存在，則判斷所述交易請求為異常請求；如果不存在，則判斷該交易請求為非異常請求，可將交易請求提交至一個服務器，以對該交易請求進行處理。其中，如果交易請求為異常請求，則拒絕該異常請求，不進行處理。

在本申請的一個實施例中，在所述對所述交易請求進行處理之后，還包括：

獲取所述交易請求的處理日志；

判斷所述處理日志是否異常；

如果所述處理日志異常，則根據預設組合規則對所述交易請求中的請求參數進行組合以生成過濾條件，并添加至所述判定模型。

由此，可不斷根據新的異常請求中的參數拼接或組合生成過濾條件，添加至判定模型，能夠不斷更新判定模型，從而使異常請求難以找到規律繞過該判定模型中的過濾條件。

更近一步地，由于在分布式系統中存在大量的服務器集群，因此，用戶的兩次下單請求，幾乎不可能在短時間內命中同一臺服務器。如果多個同樣的請求參數的交易請求在預設時間內命中同一臺服務器，則可將該請求參數對應的交易請求判定為異常請求。

在本申請的一個實施例中，判定模型中還可包括與過濾條件對應的預設時間，如圖4所示，本申請的交易請求處理方法還可包括步驟s401和s402。

s401，記錄判定模型中的過濾條件的存活時間。

其中，過濾條件的存活時間為過濾條件從生成到當前計時時間之間的時間差。

s402，當判定模型中的過濾條件的存活時間達到對應的預設時間時，將過濾條件和與過濾條件對應的預設時間在判定模型中刪除。

舉例來說，存活時間可為1小時。

由此，本申請實施例的交易請求處理方法，當過濾條件的存活時間超過預時間時，可將該過濾條件在判定模型中刪除，從而能夠避免判定模型過度膨脹，提高識別效率。

應當理解，在過濾條件a在判定模型中被刪除之后，如果包含過濾條件a中的請求參數的交易請求在處理過程中再次被作為異常請求，則過濾條件a可再次被加入到判定模型中。由此，可隨著時間的推移動態調整判定模型，能夠維持異常請求的識別準確性和高效性的平衡。

與上述實施例提供的交易請求處理方法相對應，本申請還提出一種交易請求處理裝置。本申請中的交易請求處理裝置可應用于分布式系統中的分布式服務器中。

圖6為根據本申請一個實施例的交易請求處理裝置的結構示意圖一。

如圖6所示，根據本申請實施例的交易請求處理裝置，包括：接收模塊11、提取模塊12、匹配模塊13和拒絕模塊14。

具體地，接收模塊11用于接收交易請求。

接收模塊11可接收由客戶端發送至分布式服務器的交易請求。

其中，分布式系統是互聯網主要的一種架構形式，分布式系統中包括大量的服務器集群。當客戶端向分布式系統提交交易請求時，分布式系統可按照預設的分配規則從服務器集群中選擇一個服務器，并將該交易請求發送至選擇的服務器進行處理。

提取模塊12用于提取所述交易請求中的請求參數。

其中，交易請求中可包括用戶標識、交易對象標識、產品統一編號、客戶端標識、交易量等參數。

在本申請的一個實施例中，請求參數可包括以下至少之一：

用戶標識、交易對象標識、交易合約標識、產品統一編號、客戶端標識。

舉例來說，用戶標識可為用戶id(identification，身份標識)、帳號等。用戶標識可包括交易雙方用戶的用戶標識，如買家標識和賣家標識。

交易合約標識用于對交易過程中約定數據進行標識，如交易量、價格或者其他約定參數等。

交易對象標識為交易對象名稱等。例如，商品名稱。

產品統一編號，可為sku(stockkeepingunit，最小庫存量，即保存庫存控制的最小可用單位)id。

此處對交易對象標識和產品統一編號進行區別說明。交易對象標識是指交易對象的名稱等，例如某品牌的某款產品。而產品統一編號是用于對一個特定交易對象來說，具有不同屬性的單品進行標識。舉例來說，對一種商品而言，當其品牌、型號、配置、等級、花色、包裝容量、單位、生產日期、保質期、用途、價格、產地等屬性與其他商品存在不同時，可稱為一個單品。

客戶端標識可為客戶端的ip(internetprotocol，網絡之間互聯的協議)地址、設備標識等。

匹配模塊13用于根據判定模型中的過濾條件匹配所述請求參數，其中，判定模型包括多個過濾條件，過濾條件是由從異常處理日志中提取的異常參數組合所生成的。

具體地，由于異常請求大多是是根據真實的交易數據中請求參數拼接生成。以在線購物流程為例，這些拼接而成的交易請求并非是從商品購買頁面中通過選擇商品屬性、數量等操作生成的，繞過了對商品庫存量、商品的銷售狀態(如是否上架等)進行校驗。因此，當對這些拼接而成的交易請求進行處理時，存在無法下單的情況，此時會在系統中生成該交易請求對應的異常處理日志。因此，可根據交易請求的處理日志提取出對應的異常請求，進而，將異常請求對的請求參數進行組合，并將組合后的拼接參數作為過濾條件加入判定模型。由此，經過對大量異常處理日志的分析處理，可得到大量過濾條件，這些過濾條件即組成了上述判定模型。

在本申請的實施例中，判定模型可預先建立。因此，本申請實施例的交易請求處理方法還可包括建立判定模型的過程。具體地，圖7為根據本申請一個實施例的交易請求處理裝置的結構示意圖二。如圖7所示，本申請實施例的交易請求處理裝置還可包括建立模塊15。

其中，建立模塊15可具體用于執行圖2所示的步驟，具體請參見方法部分圖2所示實施例。

在本申請的一個實施例中，在分布式系統接收到新的交易請求，并提取出交易請求的請求參數后，匹配模塊13可用于：根據預設組合規則對所述請求參數進行組合；判斷所述判定模型中是否存在與組合后的請求參數一致的過濾條件；如果存在，則判斷所述請求參數與過濾條件匹配。

舉例來說，對于以下異常請求：

request:com.taobao.trade.face.dto.tradebuyquery@25d3f6cb[buynow＝true,userid＝2745295631,itemid＝21056795895,skuid＝0,quantity＝1ua＝anclient,ttid＝207200@tmall_android_4.2.2,apiname＝mtop.trade.buildorder,sid＝1c4ca622e7e772361ef6043bd0281f7d……]

上述異常請求中包括用戶id：userid＝2745295631，商品id：itemid＝21056795895，產品同一編號：skuid＝0，可將其中的用戶id和商品id的組合作為一個過濾條件(可用userid->itemid的形式表示)加入判定模型。即判定模型中的一個過濾條件為“userid＝2745295631->itemid＝21056795895”。

在提取出接收到的交易請求的請求參數后，可將請求參數中的userid和itemid進行組合，如果userid和itemid的組合與過濾條件“userid＝2745295631->itemid＝21056795895”一致，則判斷所述請求參數與過濾條件匹配。如果請求參數中不包括“userid＝2745295631”或者“itemid＝21056795895”中的任何一個，則可判斷所述請求參數與過濾條件不匹配。

同樣地，也可以將其中的用戶id和產品同一編號的組合作為一個過濾條件，即將userid＝2745295631->skuid＝0作為過濾條件。

拒絕模塊14用于如果所述請求參數與過濾條件匹配，則拒絕所述交易請求。

如果所述請求參數與過濾條件匹配，則該請求參數對應的交易請求為異常請求，因此拒絕模塊14可拒絕該交易請求，能夠有效避免異常交易消耗系統資源。

由此，通過將根據異常請求的參數生成的過濾條件加入到判定模型中，可對具有相同參數的交易請求直接進行拒絕，能夠有效的靈活的識別異常請求。當大量異常請求提交到系統中時，能夠有效識別并拒絕，從而大大降低系統資源的消耗。此外，該判定模型是根據異常請求的參數作為判定邏輯，比較靈活，不容易破解，并且不會導致正常用戶的請求被拒絕。

本申請實施例的交易請求處理裝置，在接收到交易請求后，可提取交易請求中的請求參數，并根據由異常處理對應的請求參數組合生成的判定模型中的過濾條件匹配請求參數，如果匹配則拒絕該交易請求，由此，不但可以準確的判斷分布式服務系統是否存在惡意的提交交易請求的行為，并進行拒絕，且能夠有效防止把正常用戶的下單請求拒絕的情況，提高了異常請求的識別準確率，能夠有效靈活地識別異常請求，且判定模型不易被破解。

在本申請的一個實施例中，可以在分布式系統中針對每個服務器單獨生成判定模型，并存儲在各個服務器對應的獨立存儲器中。也就是說，各個服務器可根據各自處理的交易請求的日志提取出異常請求，并構建判定模型進行存儲。從而，分布式系統中的各個服務器均可根據各自對應的獨立存儲器中的判定模型對接收到的交易請求進行識別。

在本申請的另一個實施例中，分布式系統中的多個服務器可具有一個共享存儲器，上述判定模型可存儲在該共享存儲器中。各個服務器可將各自構建的過濾條件添加至共享存儲器中的判定模型中。由此，不同服務器生成的過濾條件可在分布式系統中各服務器之間共享，能夠更準確地識別整個分布式服務器的異常請求。

在本申請的一個實施例中，在對交易請求的處理過程中，可根據處理日志將處理異常的請求不斷生成新的過濾條件，并加入判定模型中。圖8為根據本申請一個實施例的交易請求處理裝置的結構示意圖三。

如圖8所示，根據本申請實施例的交易請求處理裝置，包括：接收模塊11、提取模塊12、匹配模塊13、拒絕模塊14、處理模塊16、獲取模塊17、判斷模塊18和生成模塊19。

具體地，接收模塊11、提取模塊12、匹配模塊13和拒絕模塊14與圖6所示實施例中相同。

處理模塊16用于如果所述請求參數與過濾條件不匹配，則處理所述交易請求。

如果所述請求參數與過濾條件不匹配，則該請求參數對應的交易請求為正常交易請求，處理模塊16可進行交易處理。

獲取模塊17用于在處理所述交易請求之后，獲取所述交易請求的處理日志。

判斷模塊18用于判斷所述處理日志是否異常。

生成模塊19用于如果所述處理日志異常，則所述處理日志的出現次數，并在所述出現次數大于預設次數時，根據預設組合規則對所述交易請求中的請求參數進行組合以生成過濾條件，并添加至判定模型。

其中，獲取模塊17、判斷模塊18和生成模塊19是可選的。

由此，可不斷根據新的異常請求中的參數拼接或組合生成過濾條件，添加至判定模型，能夠不斷更新判定模型，從而使異常請求難以找到規律繞過該判定模型中的過濾條件。

更近一步地，由于在分布式系統中存在大量的服務器集群，因此，用戶的兩次下單請求，幾乎不可能在短時間內命中同一臺服務器。如果多個同樣的請求參數的交易請求在預設時間內命中同一臺服務器，則可將該請求參數對應的交易請求判定為異常請求。

在本申請的一個實施例中，判定模型中還可包括與過濾條件對應的預設時間，圖9為根據本申請一個實施例的交易請求處理裝置的結構示意圖四。

如圖9所示，根據本申請實施例的交易請求處理裝置，包括：接收模塊11、提取模塊 12、匹配模塊13、拒絕模塊14和處理模塊15、獲取模塊17、判斷模塊18、生成模塊19和刪除模塊110。

刪除模塊110用于記錄判定模型中的過濾條件的存活時間，當判定模型中的過濾條件的存活時間達到對應的預設時間時，將過濾條件和與過濾條件對應的預設時間在判定模型中刪除。

其中，過濾條件的存活時間為過濾條件從生成到當前計時時間之間的時間差。

由此，本申請實施例的交易請求處理方法，當過濾條件的存活時間超過預時間時，刪除模塊110可將該過濾條件在判定模型中刪除，從而能夠避免判定模型過度膨脹，提高識別效率。

應當理解，在過濾條件a在判定模型中被刪除之后，如果包含過濾條件a中的請求參數的交易請求在處理過程中再次被作為異常請求，則過濾條件a可再次被加入到判定模型中。由此，可隨著時間的推移動態調整判定模型，能夠維持異常請求的識別準確性和高效性的平衡。

本申請還提出另一種交易請求處理裝置。

圖10為根據本申請另一個實施例的交易請求處理裝置結構示意圖一。

如圖10所示，根據本申請實施例的交易請求處理裝置，包括：第一獲取模塊21、提取模塊22、生成模塊23和識別模塊24。

具體地，第一獲取模塊21用于獲取交易系統中的交易處理日志，并從所述交易日志中提取異常處理日志。

其中，交易系統可以是分布式系統中的服務器集群，還可以是分布式系統中任意一個服務器。其中，分布式系統是互聯網主要的一種架構形式，分布式系統中包括大量的服務器集群。當客戶端向分布式系統提交交易請求時，分布式系統可按照預設的分配規則從服務器集群中選擇一個服務器，并將該交易請求發送至選擇的服務器進行處理。

具體地，由于異常請求大多是是根據真實的交易數據中請求參數拼接生成。以在線購物流程為例，這些拼接而成的交易請求并非是從商品購買頁面中通過選擇商品屬性、數量等操作生成的，繞過了對商品庫存量、商品的銷售狀態(如是否上架等)進行校驗。因此，當對這些拼接而成的交易請求進行處理時，存在無法下單的情況，此時會在系統中生成該交易請求對應的異常處理日志。因此，可根據交易請求的處理日志提取出對應的異常請求，進而，將異常請求對的請求參數進行組合，并將組合后的拼接參數作為過濾條件加入判定模型。由此，經過對大量異常處理日志的分析處理，可得到大量過濾條件，這些過濾條件即組成了上述判定模型。

在本申請的一個實施例中，第一獲取模塊21可提取一段時間內(如一個月內或者一周內)交易系統中的交易處理日志。由于在對交易請求進行處理時，異常交易請求會因參數錯誤而無法成功下單，此時該異常交易請求的處理日志中會生成異常處理日志。因此，可將交易系統的交易處理日志所包括的異常處理日志提取出來。

提取模塊22用于從所述異常處理日志中提取各個異常處理對應的請求參數。

其中，異常處理日志中包括請求參數、請求時間、處理狀態或處理結果等信息。其中，請求參數可包括用戶標識、交易對象標識、產品統一編號、客戶端標識、交易量等參數。

舉例來說，用戶標識可為用戶id(identification，身份標識)、帳號等。用戶標識可包括交易雙方用戶的用戶標識，如買家標識和賣家標識。

交易對象標識為交易對象名稱等。例如，商品名稱。

交易合約標識用于對交易過程中約定數據進行標識，如交易量、價格或者其他約定參數等。

產品統一編號，可為sku(stockkeepingunit，最小庫存量，即保存庫存控制的最小可用單位)id。

此處對交易對象標識和產品統一編號進行區別說明。交易對象標識是指交易對象的名稱等，例如某品牌的某款產品。而產品統一編號是用于對一個特定交易對象來說，具有不同屬性的單品進行標識。舉例來說，對一種商品而言，當其品牌、型號、配置、等級、花色、包裝容量、單位、生產日期、保質期、用途、價格、產地等屬性與其他商品存在不同時，可稱為一個單品。

客戶端標識可為客戶端的ip(internetprotocol，網絡之間互聯的協議)地址、設備標識等。

生成模塊23用于將各異常處理對應的請求參數分別進行組合，以生成與每個異常處理分別對應的拼接參數。

也就是說，對于每個異常處理，生成模塊23可分別提取其對應的請求參數，并進行組合，生成該異常處理對應的拼接參數。在本申請的一個實施例中，上述拼接參數可為異常請求的參數中一個或多個的組合。也就是說，可將異常請求中的參數按照預設組合規則進行組合生成拼接參數。

識別模塊24用于將所述拼接參數作為過濾條件加入異常請求的判定模型，以根據所述判定模型對接收到的交易請求進行參數匹配，以判斷所述交易請求是否為異常請求。

由此，識別模塊24可通過大量的異常處理日志中的各個異常處理的請求參數拼接為多個過濾條件。這些過濾條件即構成了異常請求的判定模型。

進而，在分布式系統接收到新的交易請求，并提取出交易請求的請求參數后，識別模塊 24可根據判定模型中的過濾條件匹配所述請求參數，以判斷所述交易請求是否為異常請求。

在本申請的一個實施例中，識別模塊24可具體用于：根據預設組合規則對所述交易請求的請求參數進行組合；判斷所述判定模型中是否存在與組合后的交易請求參數一致的過濾條件；如果存在，則判斷所述交易請求為異常請求；如果不存在，則判斷該交易請求為非異常請求，可將交易請求提交至一個服務器，以對該交易請求進行處理。其中，如果交易請求為異常請求，則拒絕該異常請求，不進行處理。

圖11為根據本申請另一個實施例的交易請求處理裝置結構示意圖二。

如圖11所示，根據本申請實施例的交易請求處理裝置，包括：第一獲取模塊21、提取模塊22、生成模塊23、識別模塊24、第二獲取模塊25、判斷模塊26和添加模塊27。

其中，第一獲取模塊21、提取模塊22、生成模塊23和識別模塊24與圖10所示實施例相同。

第二獲取模塊25用于在所述對所述交易請求進行處理之后，獲取所述交易請求的處理日志。

判斷模塊26用于判斷所述處理日志是否異常。

添加模塊27用于在所述判斷模塊判斷所述處理日志異常時，根據預設組合規則對所述交易請求中的請求參數進行組合以生成過濾條件，并添加至所述判定模型。

由此，可不斷根據新的異常請求中的參數拼接或組合生成過濾條件，添加至判定模型，能夠不斷更新判定模型，從而使異常請求難以找到規律繞過該判定模型中的過濾條件。

更近一步地，由于在分布式系統中存在大量的服務器集群，因此，用戶的兩次下單請求，幾乎不可能在短時間內命中同一臺服務器。如果多個同樣的請求參數的交易請求在預設時間內命中同一臺服務器，則可將該請求參數對應的交易請求判定為異常請求。

在本申請的一個實施例中，判定模型中還可包括與過濾條件對應的預設時間。圖12為根據本申請另一個實施例的交易請求處理裝置結構示意圖三。

如圖12所示，根據本申請實施例的交易請求處理裝置，還可包括：

設置模塊28用于為所述判定模型中的每個過濾條件分別設置對應的預設時間。

其中，過濾條件的存活時間為過濾條件從生成到當前計時時間之間的時間差。

刪除模塊29用于當所述判定模型中的過濾條件的存活時間達到對應的預設時間時，將所述過濾條件和與所述過濾條件對應的預設時間在所述判定模型中刪除。

舉例來說，存活時間可為1小時。

由此，本申請實施例的交易請求處理方法，當過濾條件的存活時間超過預時間時，可將該過濾條件在判定模型中刪除，從而能夠避免判定模型過度膨脹，提高識別效率。

應當理解，在過濾條件a在判定模型中被刪除之后，如果包含過濾條件a中的請求參 數的交易請求在處理過程中再次被作為異常請求，則過濾條件a可再次被加入到判定模型中。由此，可隨著時間的推移動態調整判定模型，能夠維持異常請求的識別準確性和高效性的平衡。

與上述實施例提供的交易請求處理裝置相對應，本申請還提出一種分布式系統。

根據本申請一個實施例的分布式系統，包括：客戶端；以及多個分布式服務器，多個分布式服務器包括本申請任一實施例的交易請求處理裝置。

在本申請的一個實施例中，多個分布式服務器可具有共享存儲器，判定模型存儲在共享緩存中。

在本申請的另一個實施例中，多個分布式服務器分別具有對應的獨立存儲器，判定模型存儲在獨立緩存中。

本申請實施例的分布式系統，在接收到客戶端的交易請求后，分布式服務器中的交易請求處理裝置可提取交易請求中的請求參數，并根據由異常處理對應的請求參數生的成判定模型中的過濾條件匹配該請求參數，以判斷是否為異常請求，并進行相應處理，由此，不但可以準確的判斷分布式服務系統是否存在惡意的提交交易請求的行為，并進行拒絕，且能夠有效防止把正常用戶的下單請求拒絕的情況，提高了分布式系統中異常請求的識別準確率，能夠有效靈活地識別異常請求，且判定模型不易被破解。

流程圖中或在此以其他方式描述的任何過程或方法描述可以被理解為，表示包括一個或更多個用于實現特定邏輯功能或過程的步驟的可執行指令的代碼的模塊、片段或部分，并且本申請的優選實施方式的范圍包括另外的實現，其中可以不按所示出或討論的順序，包括根據所涉及的功能按基本同時的方式或按相反的順序，來執行功能，這應被本申請的實施例所屬技術領域的技術人員所理解。

在流程圖中表示或在此以其他方式描述的邏輯和/或步驟，例如，可以被認為是用于實現邏輯功能的可執行指令的定序列表，可以具體實現在任何計算機可讀介質中，以供指令執行系統、裝置或設備(如基于計算機的系統、包括處理器的系統或其他可以從指令執行系統、裝置或設備取指令并執行指令的系統)使用，或結合這些指令執行系統、裝置或設備而使用。就本說明書而言，"計算機可讀介質"可以是任何可以包含、存儲、通信、傳播或傳輸程序以供指令執行系統、裝置或設備或結合這些指令執行系統、裝置或設備而使用的裝置。計算機可讀介質的更具體的示例(非窮盡性列表)包括以下：具有一個或多個布線的電連接部(電子裝置)，便攜式計算機盤盒(磁裝置)，隨機存取存儲器(ram)，只讀存儲器(rom)，可擦除可編輯只讀存儲器(eprom或閃速存儲器)，光纖裝置，以及便攜式光盤只讀存儲 器(cdrom)。另外，計算機可讀介質甚至可以是可在其上打印所述程序的紙或其他合適的介質，因為可以例如通過對紙或其他介質進行光學掃描，接著進行編輯、解譯或必要時以其他合適方式進行處理來以電子方式獲得所述程序，然后將其存儲在計算機存儲器中。

應當理解，本申請的各部分可以用硬件、軟件、固件或它們的組合來實現。在上述實施方式中，多個步驟或方法可以用存儲在存儲器中且由合適的指令執行系統執行的軟件或固件來實現。例如，如果用硬件來實現，和在另一實施方式中一樣，可用本領域公知的下列技術中的任一項或他們的組合來實現：具有用于對數據信號實現邏輯功能的邏輯門電路的離散邏輯電路，具有合適的組合邏輯門電路的專用集成電路，可編程門陣列(pga)，現場可編程門陣列(fpga)等。

本技術領域的普通技術人員可以理解實現上述實施例方法攜帶的全部或部分步驟是可以通過程序來指令相關的硬件完成，所述的程序可以存儲于一種計算機可讀存儲介質中，該程序在執行時，包括方法實施例的步驟之一或其組合。

此外，在本申請各個實施例中的各功能單元可以集成在一個處理模塊中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個模塊中。上述集成的模塊既可以采用硬件的形式實現，也可以采用軟件功能模塊的形式實現。所述集成的模塊如果以軟件功能模塊的形式實現并作為獨立的產品銷售或使用時，也可以存儲在一個計算機可讀取存儲介質中。

上述提到的存儲介質可以是只讀存儲器，磁盤或光盤等。

在本說明書的描述中，參考術語“一個實施例”、“一些實施例”、“示例”、“具體示例”、或“一些示例”等的描述意指結合該實施例或示例描述的具體特征、結構、材料或者特點包含于本申請的至少一個實施例或示例中。在本說明書中，對上述術語的示意性表述不一定指的是相同的實施例或示例。而且，描述的具體特征、結構、材料或者特點可以在任何的一個或多個實施例或示例中以合適的方式結合。

盡管已經示出和描述了本申請的實施例，本領域的普通技術人員可以理解：在不脫離本申請的原理和宗旨的情況下可以對這些實施例進行多種變化、修改、替換和變型，本申請的范圍由權利要求及其等同限定。