交易请求处理方法、装置以及分布式系统与流程

本申请涉及互联网技术领域，特别涉及一种交易请求处理方法、装置以及分布式系统。

背景技术：

目前，互联网交易中存在通过虚假交易使得某一特定产品的交易量大幅增加的情况。例如，通过将已成功交易的多个订单的请求参数进行拼接模拟请求参数，并根据模拟的请求参数进行批量或者并发下单。但是，模拟的请求参数并不是根据产品的实际属性生成的，这就存在请求参数与产品的实际属性冲突(例如，产品库存量小于请求参数中库存量)的情况，进而导致无法处理的异常请求。

当大量的异常请求访问业务服务器时，会大量耗费服务器的资源。因此，需要对异常请求进行识别，并对异常请求，以避免此情况。目前，主要通过交易频率来判断是否为异常请求，即如果接收到一个交易请求的频率超过某一频率阈值，则判断该交易请求为异常请求。这种方式，存在将正常的交易请求判断为异常请求的可能，导致正常的交易请求无法被处理，给用户带来不便。此外，这种方式可通过设定不同的发送频率而绕开设定的频率阈值。因此，目前的异常请求的识别准确较低。

技术实现要素：

本申请旨在至少在一定程度上解决上述技术问题。

为此，本申请的第一个目的在于提出一种交易请求处理方法，能够提高异常请求的识别准确率，有效灵活地识别异常请求，且判定模型不易被破解。

本申请的第二个目的在于提出另一种交易请求处理方法。

本申请的第三个目的在于提出一种交易请求处理装置。

本申请的第四个目的在于提出另一种交易请求处理装置。

本申请第三个目的在于提出一种分布式系统。

为达上述目的，根据本申请第一方面实施例提出了一种交易请求处理方法，包括以下步骤：接收交易请求；提取所述交易请求中的请求参数；根据判定模型中的过滤条件匹配所述请求参数，其中，所述判定模型包括多个过滤条件，所述过滤条件是由从异常处理日志中提取的异常参数组合所生成的。

本申请实施例的交易请求处理方法，在接收到交易请求后，可提取交易请求中的请求参数，并根据由异常处理对应的请求参数组合生成的判定模型中的过滤条件匹配请求参数，如果匹配则拒绝该交易请求，由此，不但可以准确的判断分布式服务系统是否存在恶意的提交交易请求的行为，并进行拒绝，且能够有效防止把正常用户的下单请求拒绝的情况，提高了异常请求的识别准确率，能够有效灵活地识别异常请求，且判定模型不易被破解。

本申请第二方面实施例提供了另一种交易请求处理方法，包括以下步骤：获取交易系统中的交易处理日志，并从所述交易日志中提取异常处理日志；从所述异常处理日志中提取各个异常处理对应的请求参数；将各异常处理对应的请求参数分别进行组合，以生成与每个异常处理分别对应的拼接参数；将所述拼接参数作为过滤条件加入异常请求的判定模型，以根据所述判定模型对接收到的交易请求进行参数匹配，以判断所述交易请求是否为异常请求。

本申请实施例的交易请求处理方法，通过从交易系统的处理日志中提取异常处理日志，并进一步提取异常处理对应的请求参数，并分别进行组合生成与每个异常处理分别对应的拼接参数，作为过滤条件加入判定模型，由此，根据该判定模型判断交易请求是否异常请求，不但可以准确的判断分布式服务系统是否存在恶意的提交交易请求的行为，并进行拒绝，且能够有效防止把正常用户的下单请求拒绝的情况，提高了异常请求的识别准确率，能够有效灵活地识别异常请求，且判定模型不易被破解。

本申请第三方面实施例提供了一种交易请求处理装置，包括：接收模块，用于接收交易请求；提取模块，用于提取所述交易请求中的请求参数；匹配模块，用于根据判定模型中的过滤条件匹配所述请求参数，其中，所述判定模型包括多个过滤条件，所述过滤条件是由从异常处理日志中提取的异常参数组合所生成的；拒绝模块，用于如果所述请求参数与所述过滤条件匹配，则拒绝所述交易请求。

本申请实施例的交易请求处理装置，在接收到交易请求后，可提取交易请求中的请求参数，并根据由异常处理对应的请求参数组合生成的判定模型中的过滤条件匹配请求参数，如果匹配则拒绝该交易请求，由此，不但可以准确的判断分布式服务系统是否存在恶意的提交交易请求的行为，并进行拒绝，且能够有效防止把正常用户的下单请求拒绝的情况，提高了异常请求的识别准确率，能够有效灵活地识别异常请求，且判定模型不易被破解。

本申请第四方面实施例提供了另一种交易请求处理装置，包括：第一获取模块，用于获取交易系统中的交易处理日志，并从所述交易日志中提取异常处理日志；提取模块，用于从所述异常处理日志中提取各个异常处理对应的请求参数；生成模块，用于将各异常处理对应的请求参数分别进行组合，以生成与每个异常处理分别对应的拼接参数；识别模块，用于将所述拼接参数作为过滤条件加入异常请求的判定模型，以根据所述判定模型对接收到的交易请求进行参数匹配，以判断所述交易请求是否为异常请求。

本申请实施例的交易请求处理装置，通过从交易系统的处理日志中提取异常处理日志，并进一步提取异常处理对应的请求参数，并分别进行组合生成与每个异常处理分别对应的拼接参数，作为过滤条件加入判定模型，由此，根据该判定模型判断交易请求是否异常请求，不但可以准确的判断分布式服务系统是否存在恶意的提交交易请求的行为，并进行拒绝，且能够有效防止把正常用户的下单请求拒绝的情况，提高了异常请求的识别准确率，能够有效灵活地识别异常请求，且判定模型不易被破解。

本申请第五方面实施例提供了一种分布式系统，包括：客户端；以及多个分布式服务器，所述多个分布式服务器包括本申请第三方面实施例或第四方面实施例的交易请求处理装置。

本申请实施例的分布式系统，在接收到客户端的交易请求后，分布式服务器中的交易请求处理装置可提取交易请求中的请求参数，并根据由异常处理对应的请求参数生的成判定模型中的过滤条件匹配该请求参数，以判断是否为异常请求，并进行相应处理，由此，不但可以准确的判断分布式服务系统是否存在恶意的提交交易请求的行为，并进行拒绝，且能够有效防止把正常用户的下单请求拒绝的情况，提高了分布式系统中异常请求的识别准确率，能够有效灵活地识别异常请求，且判定模型不易被破解。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图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)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本申请的实施例，本领域的普通技术人员可以理解：在不脱离本申请的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本申请的范围由权利要求及其等同限定。