CN102347851B

CN102347851B - 事件处理方法及服务器

Info

Publication number: CN102347851B
Application number: CN201010243880.7A
Authority: CN
Inventors: 蔡学镛
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd
Priority date: 2010-07-29
Filing date: 2010-07-29
Publication date: 2014-04-09
Anticipated expiration: 2030-07-29
Also published as: HK1163967A1; CN102347851A

Abstract

本发明公开了一种事件处理方法及服务器，所述方法包括：根据若干基础事件携带的事件标识，获取属于同一状态机实例的基础事件；将属于同一状态机实例的基础事件按照时间戳的指示顺序输入所述状态机实例；若当前输入的基础事件无法使所述状态机实例从当前状态迁移，则判断所述基础事件是否为所述当前状态允许的乱序事件；若判断结果为是，则保存所述基础事件至缓存，若判断结果为否，则输出报警。本发明实施例可以保存允许的乱序事件，以防止由于时间戳的不准确而导致误报警的发生；由于后续可以直接利用保存的基础事件进行状态迁移，而无需对该状态机实例重新进行状态迁移，因此减轻了系统服务器的处理负担。

Description

事件处理方法及服务器

技术领域

本申请涉及网络技术领域，尤其涉及一种事件处理方法及服务器。

背景技术

基于互联网实现各种业务功能时，会产生海量的基础事件(Base Event)，包括各种销售数据、业务数据、系统之间的交互数据等，这些基础事件反映了业务功能的片面信息。多个有关联的基础事件形成一种事件模式，以支付宝(www.alipay.com)的担保交易为例，担保交易为一种事件模式，这个事件模式下包含了相互关联的具有先后产生次序的五个基础事件，分别为创建交易、买家付款到中间机构、卖家发货、买家收货和中间机构付款到卖家；在担保交易这种事件模式，每一笔交易都会产生相应的基础事件，属于同一笔交易的基础事件组成一个复合事件，也即是每种事件模式都会有若干复合事件。在接到基础事件后，可以根据基础事件的事件信息确定其所属的事件模式，并根据事件标识将该基础事件对应到其所属的复合事件。

发明人在对现有技术的研究过程中发现，现有技术中大型的互联网站在实现业务功能时，采用分布式服务器系统，服务器系统中包含若干相互协作的服务器，因此属于同一事件模式的同一复合事件中的基础事件可能由不同的服务器触发产生，为了区别这些基础事件的产生时间，在每个基础事件内写入时间戳，根据时间戳可以对基础事件进行排序。但是由于服务器之间的时钟通常不一致，即使经过服务器时钟的同步联调后，服务器之间仍然会有时间差，由此导致写入基础事件中的时间戳不准确，使得基础事件的排序发生混乱；后续，当根据乱序的基础事件进行复合事件处理时，仍以担保交易为例，当属于同一复合事件的创建交易这一基础事件的时间戳晚于买家付款到中间机构这一基础事件时，由于系统将根据时间戳的指示先于创建交易这一基础事件，而收到买家付款到中介机构这一基础事件，从而导致系统错误报警，并需要重新对复合事件进行处理，由此增加了系统服务器的处理负担。

发明内容

本申请实施例的目的是提供一种事件处理方法及服务器，以解决现有技术中发生乱序的基础事件导致错误报警，增加系统服务器处理负担的问题。

为解决上述技术问题，本申请实施例提供了一种复合事件处理方法，是这样实现的：

一种事件处理方法，所述方法包括：

根据若干基础事件携带的事件标识，获取属于同一状态机实例的基础事件，所述状态机实例为按照所述基础事件所属的事件模式定义的状态机所创建的实例，属于同一状态机实例的基础事件具有相同的事件标识；

将属于同一状态机实例的基础事件按照时间戳的指示顺序输入所述状态机实例；

若当前输入的基础事件无法使所述状态机实例从当前状态迁移，则判断所述基础事件是否为所述当前状态允许的乱序事件；

若判断结果为是，则保存所述基础事件至缓存，若判断结果为否，则输出报警。

为解决上述技术问题，本申请实施例还提供了一种事件处理服务器，是这样实现的：

一种事件处理服务器，包括：

获取单元，用于根据若干基础事件携带的事件标识，获取属于同一状态机实例的基础事件，所述状态机实例为按照所述基础事件所属的事件模式定义的状态机所创建的实例，属于同一状态机实例的基础事件具有相同的事件标识；

输入单元，用于将属于同一状态机实例的基础事件按照时间戳的指示顺序输入所述状态机实例；

状态判断单元，用于判断当前输入的基础事件是否能使所述状态机实例从当前状态迁移；

乱序判断单元，用于当所述状态判断单元的判断结果为否时，判断所述基础事件是否为所述当前状态允许的乱序事件；

保存单元，用于当所述乱序判断单元的判断结果为是时，保存所述基础事件至缓存；

报警单元，用于当所述乱序判断单元的判断结果为否时，输出报警。

可见，本申请实施例中根据若干基础事件携带的事件标识，获取属于同一状态机实例的基础事件，将属于同一状态机实例的基础事件按照时间戳的指示顺序输入状态机实例，若当前输入的基础事件无法使状态机实例从当前状态迁移，则判断该基础事件是否为当前状态允许的乱序事件，若判断结果为是，则保存该基础事件至缓存，若判断结果为否，则输出报警。本申请实施例中当所输入的基础事件无法使状态机实例从当前状态迁移时，并不直接输出报警信息，而是在该基础事件为所允许的乱序事件时，对其进行保存，以防止由于时间戳的不准确而导致误报警的发生；由于后续可以直接利用保存的基础事件进行状态迁移，而无需对该状态机实例重新进行状态迁移，因此减轻了系统服务器的处理负担。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请事件处理方法的第一实施例流程图；

图2A为本申请事件处理方法的第二实施例流程图；

图2B为本申请一种应用实例中担保交易的事件模式状态机定义示意图；

图3为本申请事件处理服务器的第一实施例框图；

图4为本申请事件处理服务器的第二实施例框图。

具体实施方式

本申请实施例提供一种事件处理方法及服务器，其中对于无法使状态机迁移的基础事件，并不直接输出报警，而是判断该基础事件为允许的乱序事件后保存该基础事件，后续可以在迁移到新状态后，判断保存的基础事件是否可以使状态机迁移。

为了使本技术领域的人员更好地理解本申请实施例中的技术方案，并使本申请实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例中技术方案作进一步详细的说明。

参见图1，为本申请事件处理方法的第一实施例流程图：

步骤101：根据若干基础事件携带的事件标识，获取属于同一状态机实例的基础事件。

事件模式是对一系列相互关联的基础事件的总称，每种事件模式都包含了顺序执行的多个基础事件。以支付宝的担保交易为例，担保交易是一种需要关心是否发货的事件模式，担保交易包括的基础事件有创建交易、买家付款到中间机构、卖家发货、买家收货和中间机构付款到卖家。

本申请实施例中，为每种事件模式定义一个状态机，这个状态机中包含了若干迁移状态，从初始状态开始，该事件模式包含的顺序执行的每个基础事件都对应一个迁移状态，以一个包含三个基础事件的事件模式A为例，假设基础事件的执行顺序应为基础事件1、基础事件2、基础事件3，则从初始状态开始，应顺序执行基础事件1，相应的从初始状态迁移到状态1，然后执行基础事件2，相应的从状态1迁移到状态2，最后执行基础事件3，相应的从状态2迁移到结束状态。

由于不同的事件模式对应不同的状态机，同一状态机又对应不同的状态机实例，因此本申请实施例中每个基础事件都携带有事件标识，该事件标识可以用于识别该基础事件所属的某个事件模式所定义的状态机下的某个状态机实例。仍然以担保交易这个事件模式为例，在该事件模式定义的状态机下，可能需要处理不同用户的若干笔交易，则为每个用户的每笔交易都按照状态机的定义创建一个状态机实例，属于同一个状态机实例的基础事件都具有相同的事件标识，这个事件标识应可以唯一识别一笔交易，例如使用交易序号作为事件标识。

步骤102：将属于同一状态机实例的基础事件按照时间戳的指示顺序输入该状态机实例。

每个基础事件在发生时，都由服务器按照当前时钟为基础事件写入时间戳，以表示该基础事件的发生时间。当根据基础事件的事件标识识别出属于同一状态机实例的基础事件，将这些基础事件按照时间戳的指示顺序排列，形成事件队列，并将事件队列中的基础事件顺序输入状态机中，看状态机是否会进行状态迁移并最终输出复合事件。

步骤103：判断当前输入的基础事件是否能使该状态机实例从当前状态迁移，若是，则执行步骤107；否则，执行步骤104。

首先，定位到该状态机实例所迁移的当前状态，然后可以根据基础事件的事件类型判断状态机实例是否能够从当前状态顺序迁移到下一状态，基础事件的事件类型就是指当前事件模式下所定义的状态机中每个状态的名称。

步骤104：判断基础事件是否为当前状态允许的乱序事件，若是，则执行步骤105；否则，执行步骤106。

当所输入的基础事件无法使状态机从当前状态迁移到下一个状态时，并不直接输出报警，而是判断该基础事件是否为允许的乱序事件。例如，对于属于同一状态机实例的基础事件，由于时间戳的不准确可能造成后发生的基础事件提前到来，因此该提前到来的基础事件就是允许的乱序事件。

本申请实施例中，预先设置了状态机中每个状态允许的乱序事件，并以状态为索引进行保存，因此在接收到基础事件并且该基础事件无法使当前状态迁移时，就查找该当前状态允许的乱序事件，判断该基础事件是否为允许的乱序事件。

步骤105：保存该基础事件至缓存，结束当前流程。

当输入的基础事件虽然不能使得状态机实例迁移到下一状态，但是该基础事件为允许的乱序事件时，则保存该乱序事件至缓存，后续在迁移到新的状态后，可以尝试保存的基础事件能否使状态机实例从新状态进行迁移。

步骤106：输出报警，结束当前流程。

步骤107：从当前状态迁移到下一状态，结束当前流程。

当所输入的基础事件可以使状态机从当前状态迁移到下一个状态时，则顺序迁移至下一个状态即可，后续可以继续从事件队列中输入下一个基础事件。

由上述实施例可见，本申请实施例中当所输入的基础事件无法使状态机实例从当前状态迁移时，并不直接输出报警信息，而是在该基础事件为所允许的乱序事件时，对其进行保存，以防止由于时间戳的不准确而导致误报警的发生。

参见图2A，为本申请事件处理方法的第二实施例流程图，该实施例示出本申请基于状态机实例进行事件处理的详细过程：

步骤201：预先定义每个事件模式的状态机，以及所述状态机中每个状态允许的乱序事件。

参见图2B为，为一种担保交易的事件模式状态机定义示意图：

其中，担保交易包括的基础事件有基础事件1(创建交易)、基础事件2(买家付款到中间机构)、基础事件3(卖家发货)、基础事件4(买家收货)和基础事件5(中间机构付款到卖家)；相应的，担保交易的状态机中包含了六个状态，分别为状态1(初始状态)、状态2(等待买家付款)、状态3(等待卖家送货)、状态4(等待买家收货)、状态5(等待向卖家付款)和状态6(结束状态)。

结合图2B，描述该状态机的完整状态迁移过程：

初始，状态机处于状态1；

接收到基础事件1(创建交易，ET-CREATE)后状态变迁，进入状态2(等待买家付款)，此时记录当前的状态为状态2；

接收到基础事件2(买家付款到中间机构，ET-BUYER-TO-ALIPAY)后状态变迁，进入状态3(等待卖家送货)，此时记录当前的状态为状态3；

接收到基础事件3(卖家发货ET-SELLER-SHIP)后状态变迁，进入状态4(等待买家收货)，此时记录当前的状态为状态4；

接收到基础事件4(买家收货，ET-BUYER-RECEIVE)后状态变迁，进入状态5(等待向卖家付款)，此时记录当前的状态为状态5；

接收到基础事件5(中间机构付款到卖家，ET-ALIPAY-TO-SELLER)后状态变迁，进入状态6(结束状态)，此时记录当前的状态为状态6；当进入状态6(结束状态)时，表示找到一个复合事件。

由于本申请实施例中状态机可以随着基础事件进行状态迁移，这个过程中只需要记录当前所迁移到的状态即可，无需记录所有基础事件信息。

本申请实施例中，由于按照时间戳排列的基础事件可能不准确，因此对于根据每个事件模式定义的状态机，可以预先定义该状态机中某些状态允许的乱序事件，例如，对于状态2(等待买家收货)，可以定义允许的乱序事件为基础事件3(卖家发货ET-SELLER-SHIP)。

步骤202：根据若干基础事件携带的事件标识，获取属于同一状态机实例的基础事件。

由于不同的事件模式对应不同的状态机，同一状态机又对应不同的状态机实例，因此本申请实施例中每个基础事件都携带有事件标识，该事件标识可以用于识别该基础事件所属的某个事件模式的某个状态机，属于同一状态机实例的基础事件具有相同的事件标识。

步骤203：将属于同一状态机实例的基础事件按照时间戳的指示顺序输入该状态机实例。

步骤204：判断当前输入的基础事件是否能使该状态机实例从当前状态迁移，若是，则执行步骤208；否则，执行步骤205。

步骤205：判断基础事件是否为当前状态允许的乱序事件，若是，则执行步骤206；否则，执行步骤207。

当所输入的基础事件无法使状态机从当前状态迁移到下一个状态时，并不直接输出报警，而是判断该基础事件是否为预先定义的当前状态所允许的乱序事件。

步骤206：保存该基础事件至缓存，并返回步骤203。

步骤207：输出报警，结束当前流程。

步骤208：从当前状态迁移到下一状态。

当所输入的基础事件可以使状态机从当前状态迁移到下一个状态时，则顺序迁移至下一个状态即可。

步骤209：判断迁移后的状态是否为结束状态，若是，则执行步骤213；否则，执行步骤210。

步骤210：判断是否能从缓存中读取到保存的基础事件，若是，则执行步骤211；否则，返回步骤203。

步骤211：从缓存中读取保存的基础事件。

当状态机实例迁移到新的状态后，且缓存中有保存的基础事件时，则读取这些基础事件，用于尝试这些提前到来的允许的乱序事件是否能使状态机实例从当前新的状态迁移。

步骤212：判断读取的基础事件是否从当前状态迁移，若是，则返回步骤208；否则，返回步骤203。

步骤213：输出复合事件，结束当前流程。

当迁移后的状态为结束状态时，说明输入该状态机实例的基础事件使该状态机实例完成所有状态迁移，相应的输出复合事件。

由上述实施例可见，本申请实施例中当所输入的基础事件无法使状态机实例从当前状态迁移时，并不直接输出报警信息，而是在该基础事件为所允许的乱序事件时，对其进行保存，以防止由于时间戳的不准确而导致误报警的发生；由于后续可以直接利用保存的基础事件进行状态迁移，而无需对该状态机实例重新进行状态迁移，因此减轻了系统服务器的处理负担。

与本申请复合事件处理方法的实施例相对应，本申请还提供了复合事件处理服务器的实施例。

参见图3，为本申请复合事件处理服务器的第一实施例框图：

该服务器包括：获取单元310、输入单元320、状态判断单元330、乱序判断单元340、保存单元350和报警单元360。

其中，获取单元310，用于根据若干基础事件携带的事件标识，获取属于同一状态机实例的基础事件，所述状态机实例为按照所述基础事件所属的事件模式定义的状态机所创建的实例，属于同一状态机实例的基础事件具有相同的事件标识；

输入单元320，用于将属于同一状态机实例的基础事件按照时间戳的指示顺序输入所述状态机实例；

状态判断单元330，用于判断当前输入的基础事件是否能使所述状态机实例从当前状态迁移；

乱序判断单元340，用于当所述状态判断单元330的判断结果为否时，判断所述基础事件是否为所述当前状态允许的乱序事件；

保存单元350，用于当所述乱序判断单元340的判断结果为是时，保存所述基础事件至缓存；

报警单元360，用于当所述乱序判断单元340的判断结果为否时，输出报警。

参见图4，为本申请复合事件处理服务器的第二实施例框图：

该服务器包括：预设单元411、获取单元412、输入单元413、状态判断单元414、迁移单元415、读取单元416、乱序判断单元417、执行单元418、保存单元419和报警单元420。

其中，预设单元411，用于预先定义每个事件模式的状态机，以及所述状态机中每个状态允许的乱序事件；

获取单元412，用于根据若干基础事件携带的事件标识，获取属于同一状态机实例的基础事件，所述状态机实例为按照所述基础事件所属的事件模式定义的状态机所创建的实例，属于同一状态机实例的基础事件具有相同的事件标识；

输入单元413，用于将属于同一状态机实例的基础事件按照时间戳的指示顺序输入所述状态机实例；

状态判断单元414，用于判断当前输入的基础事件是否能使所述状态机实例从当前状态迁移；

乱序判断单元417，用于当所述状态判断单元414的判断结果为否时，判断所述基础事件是否为所述当前状态允许的乱序事件；

保存单元419，用于当所述乱序判断单元417的判断结果为是时，保存所述基础事件至缓存；

报警单元420，用于当所述乱序判断单元417的判断结果为否时，输出报警；

迁移单元415，用于当所述状态判断单元414的判断结果为是时，迁移到下一状态，并将所述下一状态作为所述状态机实例的当前状态；

读取单元416，用于从所述缓存中读取保存的基础事件；

所述状态判断单元414，还用于判断所述读取单元416读取的基础事件是否能从当前状态迁移；

所述迁移单元415，还用于当所述状态判断单元414的判断结果为是时，迁移到下一状态；

所述乱序判断单元417，还用于当所述状态判断单元414的判断结果为否时，返回所述输入单元413的功能；

所述状态判断单元414，还用于判断所述下一状态是否为所述状态机实例的结束状态；

执行单元418，用于当所述状态判断单元414的判断结果为是时，输出复合事件，当所述状态判断单元414的判断结果为否时，返回所述读取单元416的功能；

所述报警单元420，还用于当所述缓存中的基础事件的保存时长超过预设的阈值时，输出报警。

通过以上的实施方式的描述可知，本申请实施例中根据若干基础事件携带的事件标识，获取属于同一状态机实例的基础事件，将属于同一状态机实例的基础事件按照时间戳的指示顺序输入状态机实例，若当前输入的基础事件无法使状态机实例从当前状态迁移，则判断该基础事件是否为当前状态允许的乱序事件，若判断结果为是，则保存该基础事件至缓存，若判断结果为否，则输出报警。本申请实施例中当所输入的基础事件无法使状态机实例从当前状态迁移时，并不直接输出报警信息，而是在该基础事件为所允许的乱序事件时，对其进行保存，以防止由于时间戳的不准确而导致误报警的发生；由于后续可以直接利用保存的基础事件进行状态迁移，而无需对该状态机实例重新进行状态迁移，因此减轻了系统服务器的处理负担。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims

1.一种事件处理方法，其特征在于，所述方法包括：

预先定义每个事件模式的状态机，以及所述状态机中每个状态允许的乱序事件；

2.根据权利要求1所述的方法，其特征在于，还包括：

若当前输入的基础事件能够使所述状态机实例从当前状态迁移，则迁移到下一状态，并将所述下一状态作为所述状态机实例的当前状态；

从所述缓存中读取保存的基础事件后，判断所述读取的基础事件是否能从当前状态迁移；

若判断结果为是，则迁移到下一状态，若判断结果为否，则返回将属于同一状态机实例的基础事件按照时间戳的指示顺序输入所述状态机实例的步骤。

3.根据权利要求2所述的方法，其特征在于，所述迁移到下一状态后，还包括：

判断所述下一状态是否为所述状态机实例的结束状态，若判断结果为是，则输出复合事件；若判断结果为否，则执行所述从缓存中读取保存的基础事件的步骤。

4.根据权利要求1所述的方法，其特征在于，还包括：

当所述缓存中的基础事件的保存时长超过预设的阈值时，输出报警。

5.一种事件处理服务器，其特征在于，包括：

预设单元，用于预先定义每个事件模式的状态机，以及所述状态机中每个状态允许的乱序事件；

6.根据权利要求5所述的服务器，其特征在于，还包括：

迁移单元，用于当所述状态判断单元的判断结果为是时，迁移到下一状态，并将所述下一状态作为所述状态机实例的当前状态；

读取单元，用于从所述缓存中读取保存的基础事件；

所述状态判断单元，还用于判断所述读取单元读取的基础事件是否能从当前状态迁移；

所述迁移单元，还用于当所述状态判断单元的判断结果为是时，迁移到下一状态；

所述乱序判断单元，还用于当所述状态判断单元的判断结果为否时，返回所述输入单元的功能。

7.根据权利要求6所述的服务器，其特征在于，所述状态判断单元，还用于判断所述下一状态是否为所述状态机实例的结束状态；

执行单元，用于当所述状态判断单元的判断结果为是时，输出复合事件，当所述状态判断单元的判断结果为否时，返回所述读取单元的功能。

8.根据权利要求5所述的服务器，其特征在于，所述报警单元，还用于当所述缓存中的基础事件的保存时长超过预设的阈值时，输出报警。