事件处理方法及服务器 【技术领域】
本申请涉及网络技术领域， 尤其涉及一种事件处理方法及服务器。背景技术 基于互联网实现各种业务功能时， 会产生海量的基础事件 (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、 小型计算机、 大型计算机、 包括以上任何系统或设备的 分布式计算环境等等。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述， 例如程序 模块。 一般地， 程序模块包括执行特定任务或实现特定抽象数据类型的例程、 程序、 对象、 组 件、 数据结构等等。也可以在分布式计算环境中实践本申请， 在这些分布式计算环境中， 由 通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中， 程序模块可以 位于包括存储设备在内的本地和远程计算机存储介质中。 虽然通过实施例描绘了本申请， 本领域普通技术人员知道， 本申请有许多变形和 变化而不脱离本申请的精神， 希望所附的权利要求包括这些变形和变化而不脱离本申请的 精神。