一种关联事件处理方法及装置与流程

本申请涉及网络应用技术领域，尤其涉及一种关联事件处理方法及装置。

背景技术：

网络技术的发展，不仅实现了设备之间的资源共享，也使得设备之间的协作变得更容易实现。在互联网时代，一台设备只要具备互联网接入功能，就能够方便地与接入互联网的任意设备进行通信，进一步实现各种协作功能。

任意形式的设备协作，都需要基于消息交互完成，在一些应用场景下，消息交互有一定的顺序要求，如果没有按照顺序要求进行处理，就可能导致系统运行错误。

例如，存在消息a和消息b，消息b用于请求执行某事件，消息b用于请求撤销该事件，从发送方的角度，处理逻辑自然是先发送消息a再发送消息b。正常情况下，接收方也应该按照先a后b的顺序接收消息并依次处理，然而,中间通信环节的不确定性却导致了消息乱序现象的客观存在。根据现有技术的处理方式，接收方如果在接收到基本事件请求之前接收到了相应的撤销请求，首先会由于基本事件不存在而导致撤销事件无法执行，进而还会导致基本事件正常执行而没有撤销，造成预期功能无法正常实现。尽管在有些情况下可以利用错误反馈机制来提示发送方重发请求，然而重发操作不仅会导致设备资源及网络资源的浪费，也给用户增加了额外的操作以及等待时间。事实上，在一些时效性要求较高的应用场景，即便重发请求可能也无法及时起到相应的作用。

技术实现要素：

针对上述技术问题，本申请提供一种关联事件处理方法及装置，以减少消息重发机制所导致的各种问题，技术方案如下：

根据本申请的第一方面，提供一种关联事件处理方法，应用于事件处理侧，相互关联的基本事件及其撤销事件共用同一事件组标识，该方法包括：

接收事件请求侧针对目标事件的处理请求消息，所述目标事件包括基本事件或撤销事件；

根据所述目标事件的组标识，判断是否已接收过所述组标识对应的事件处理请求消息；

如果未接收过所述组标识对应的事件处理请求消息，则在所述目标事件为基本事件的情况下，执行所述目标事件的处理操作；在所述目标事件为撤销事件的情况下，不向事件请求侧反馈针对所述目标事件的处理失败消息；

如果已接收过所述组标识对应的事件处理请求消息，则进一步判断是否处理过所述组标识对应的基本事件，如果已处理过且所述目标事件为撤销事件，则执行所述目标事件的处理操作；如果未处理过且所述目标事件为基本事件，则不执行所述目标事件的处理操作。

根据本申请的第二方面，提供一种关联事件处理装置，应用于事件处理侧，相互关联的基本事件及其撤销事件共用同一事件组标识，该装置包括：

消息接收模块，用于接收事件请求侧针对目标事件的处理请求消息，所述目标事件包括基本事件或撤销事件；

第一判断模块，用于根据所述目标事件的组标识，判断是否已接收过所述组标识对应的事件处理请求消息；

第二判断模块，用于判断是否处理过所述组标识对应的基本事件；

第三判断模块，用于判断所述目标事件的类型；

第一执行模块，用于在未接收过所述组标识对应的事件处理请求消息、且所述目标事件为基本事件的情况下，执行所述目标事件的处理操作；

第二执行模块，用于在未接收过所述组标识对应的事件处理请求消息、且所述目标事件为撤销事件的情况下，不向事件请求侧反馈针对所述目标事件的处理失败消息；

第三执行模块，用于在已接收过所述组标识对应的事件处理请求消息、已处理过所述组标识对应的基本事件、且所述目标事件为撤销事件的情况下，执行所述目标事件的处理操作；

第四执行模块，用于在已接收过所述组标识对应的事件处理请求消息、未处理过所述组标识对应的基本事件、且所述目标事件为基本事件的情况下，不执行所述目标事件的处理操作。

本申请实施例所提供的技术方案，对于相互关联的基本事件及其撤销事件共用同一事件组标识，事件处理侧接收到请求消息后，首先根据组标识判断是否曾经接收到过该组的其他事件请求，然后结合已接收的事件类型和当前的事件类型判断是否出现乱序现象，并在出现乱序的情况下做出正确的处理并及时反馈给事件请求侧，避免消息重发所导致的各种问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

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

图1是本申请的关联事件处理系统的结构示意图；

图2是本申请的关联事件处理方法的第一种流程示意图；

图3是本申请的关联事件处理方法的第二种流程示意图；

图4是本申请的关联事件处理装置的第一种结构示意图；

图5是本申请的关联事件处理装置的第二种结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

本申请方案用于处理具有依赖关系的关联事件，假设存在事件x和事件y，其中y的作用是撤销x的执行结果，处理逻辑上看，y的执行需要以x的执行为前提，则事件x和事件y构成一组关联事件。例如，事件x为发布某条信息、事件y为撤回上述信息，事件x为对某账户进行扣款、事件y为撤回上述扣款，等等。为描述方便，在本申请中，将同一组关联事件中的x称为基本事件，y称为撤销事件。

本申请方案的运行架构示意如图1所示，包括事件请求侧设备10和事件处理侧设备20。其中事件请求侧设备10是基本事件及撤销事件的请求发起方，事件处理侧设备20是基本事件及撤销事件的实际执行方，两侧设备可通过各种形式的网络实现通信连接，请求侧设备10通过发送事件处理请求消息指示处理侧设备20处理相应事件。根据具体应用场景的不同，两侧设备的具体形式既可以是服务器设备也可以是客户端设备，本申请对此并不需要进行限定。为描述方便，在本申请后文中将分别以“事件请求侧”和“事件处理侧”的简称对方案进行说明。

本申请方案的设计目的是：事件处理侧能够识别出关联事件的乱序情况，在出现乱序的情况下做出正确的处理并及时反馈给事件请求侧，避免事件请求侧重发请求消息。同时还要保证在关联事件顺序正常时的处理方式不受影响。为满足上述需求，本申请提供一种关联事件处理方法，参见图2所示，该方法可以包括以下步骤：

s101，接收事件请求侧针对目标事件的处理请求消息；

s102，根据目标事件的组标识，判断是否已接收过组标识对应的事件处理请求消息，如果否则执行s103、是则执行s106；

s103，判断目标事件的类型，如果为基本事件则执行s105、如果为撤销事件则执行s105；

s104，执行目标事件(具体为基本事件)的处理操作；

s105，不向事件请求侧反馈针对目标事件(具体为撤销事件)的处理失败消息；

s106，判断是否处理过组标识对应的基本事件，如果是则执行s107，否则执行s110；

s107，判断目标事件的类型，如果为撤销事件则执行s109；

s109，执行目标事件(具体为撤销事件)的处理操作；

s110，判断目标事件的类型，如果为基本事件则执行s111；

s111，不执行目标事件(具体为基本事件)的处理操作

上述的关联事件处理方法，应用于事件处理侧设备，在s101，事件处理侧设备从通信接口接收事件处理请求消息，在本申请中，将当前接收到的请求消息所请求处理的事件统称为目标事件，根据本申请的实际应用场景，一个目标事件既可能是基本事件也可能是撤销事件，事件处理侧能够根据事件处理请求消息中所携带的信息直接区分出请求的处理的事件类型。

图2所示的方法流程中，除s101之外的其他步骤可按功能分为两大类：判断类步骤和执行类步骤，其中判断类步骤用于识别事件请求消息的顺序/乱序情况，执行类步骤则用于根据识别结果执行相应的处理方式，以确保预期功能的正常实现。

首先对本申请方法中的判断类步骤进行说明，图2所示的方法流程中涉及的判断类步骤包括s102、s103、s106、s107和s110，下面分别进行说明：

s102的作用是判断是否首次接收到某个事件组的事件处理请求消息。

在本申请中，将针对同一事件主体的基本事件及其撤销事件定义为一个关联事件组，例如针对同一笔订单的确认操作及取消操作、针对同一笔款项的收 款及退款操作、等等。不同的事件主体对应不同的事件组，对于任意事件而言，除了具有自身的事件标识之外，还具有一个组标识，如果两个事件的组标识相同，则说明这两个事件针对的是同一事件主体。

事件处理侧在接收到一个事件处理请求后，会提取该请求事件的组标识，并且判断在此之前是否有接收到具有同样组标识的事件处理请求，如果否则说明是首次接收到该组事件的处理请求，是则说明不是首次接收。当然，无论判断结果如何，事件处理侧都需要对当前事件的组标识进行记录，以用于后续判断。在本申请中，对于组标识的具体记录及判断方式不需要进行限定。

s106的作用是在已确定不是首次接收到某个事件组的消息后，进一步判断之前接收到的消息类型。

在本申请中，可以通过查询基本事件的处理记录，判断之前收到的本组消息类型。由于事件处理请求消息的接收和事件处理都是在事件处理侧本地完成，这里可以认为消息接收和事件处理之间是没有延迟的。因此，对于任意的事件组，如果无法查询到基本事件的处理记录，说明之前接收的消息是撤销事件处理请求消息，反之如果能够查询到基本事件的处理记录，说明之前接收到过基本事件处理请求消息并且已处理。

s103、s107和s110都是对当前目标事件类型的判断，可以根据事件处理请求消息中所携带的信息直接确定请求处理的事件类型，这里不再详细说明。

下面对本申请方法中的执行类步骤进行说明，图2所示的方法流程中涉及的执行类步骤包括s104、s105、s108、s109、s111和s112，下面分别进行说明：

s104，由判断过程可知，当前目标事件为基本事件，且之前没有接收过同组事件的处理请求，该分支为正常顺序，按照正常方式处理该目标事件(具体为基本事件)即可，一般而言，这里所说的正常处理方式还应包括判断是否能够处理、以及在本地完成处理后向事件请求侧反馈处理结果等必要操作，本申请不再展开说明。

s105，由判断过程可知，当前目标事件为撤销事件，但是之前却没有接收 过同组事件的处理请求，说明出现了乱序，此时撤销无法成功执行，但是并不需要事件请求侧反馈表明“撤销失败”的消息。

在实际应用中，“撤销失败”是导致事件请求侧重发撤销请求消息的主要原因(无论是自动触发还是用户手动触发)，而本申请通过阻止发送“撤销失败”消息的方式，正是为了避免对方重发撤销请求消息。

在具体实施时，事件处理侧仍然可以根据当前的请求消息执行一次撤销操作，但是根据判断逻辑可知，该撤销操作是无法成功的，因此这里可以直接将处理方式设置为不执行撤销操作，从而减少事件处理侧的资源浪费。

在本申请的一种具体实施方式中，还可以直接向事件请求侧反馈针对当前撤销事件的处理成功消息，可以理解的是，本步骤并没有实际完成“撤销”处理，根据本申请的完整执行逻辑，为保证预期功能的正常实现，如果本步骤分支被触发，则后续接收到事件处理请求消息后，必然会触发s111分支，所以该“撤销成功”消息相当于在保证预期功能的正常实现的情况下提前发送，从而减少对方的实际等待响应时间。

s109，由判断过程可知，当前目标事件为撤销事件，之前接收过同组事件的处理请求、且已经处理过同组的基本事件，该分支为正常顺序，按照正常方式处理该目标事件(具体为撤销事件)即可，一般而言，这里所说的正常处理方式还应包括判断是否能够处理、以及在本地完成处理后向事件请求侧反馈处理结果等必要操作，本申请不再展开说明。

s111，由判断过程可知，当前目标事件为基本事件，但是之前曾经接收过同组的撤销请求，说明出现了乱序。考虑到撤销事件是基本事件的反向事件，这里采用处理的方式是：不对当前的基本事件进行处理，这种做法相当于“抵消”了之前没有处理的撤销事件，从结果上看，与“先基本再撤销”的预期结果一致。当然满足后续查询等需求，在实际做记录时，仍然可以按照“基本事件已处理”、“撤销事件已处理的”的方式进行记录。

可见，本申请方案利用s105与s111的配合，能够在出现消息乱序时保证预期功能的正常实现，而且通过阻止发送撤销事件失败消息的方式，可以减少 事件请求侧重发请求消息的情况发生，从而减少资源浪费、降低对用户使用感受的影响。另外，“抵消”的处理方式并不会导致更久的延迟，事实上，如果在整个过程中只有基本事件处理请求消息出现延迟，则乱序过程的处理时间并不会高于正常顺序过程的处理时间，这也进一步降低了因超时而导致事件请求侧重发请求消息的可能性。

结合图2可以发现，在上述方案中，有两个判断分支并没有涉及到，这是因为在一些系统中，会结合应用需求、网络状况等因素，对事件请求消息交互机制进行设置，使得在同一事件组中仅允许1次基本事件请求及1次撤销事件请求，也就是说，对于事件处理侧而言，同一事件组的事件请求消息接收顺序只存在两种情况：基本事件请求消息→撤销事件请求消息(正常顺序)、撤销事件处理请求消息→基本事件处理请求消息(乱序)，这样两个留空分支所对应的情况实际是不会出现的，因此仅通过s104、s105、s109和s111四个执行步骤即可覆盖所有的情形：

情形a，先收到基本事件处理请求消息，再收到撤销事件处理请求消息：

先执行s104分支，正常处理基本事件；

再执行s109分支，正常处理撤销事件。

情形b，先收到撤销事件处理请求消息，再收到基本事件处理请求消息：

先执行s105分支，撤销事件未处理；

再执行s111分支，抵消之前未处理的撤销事件。

如果系统没有对同一事件组中的事件数量进行限制，则事件处理侧接收到的处理请求消息顺序则会更为复杂，例如可能多次接收到基本事件处理请求消息或撤销事件处理请求消息。针对这种情况，只需在上述方案的基础上，补充s108及s112的处理方式即可保证预期功能的正常实现，如图3所示，补充后的处理方式如下：

s108，由判断过程可知，当前目标事件为基本事件，之前接收过同组事件的处理请求、且已经处理过同组的基本事件，该分支相当于重复接收了针对同一事件本体的基本事件处理请求，属于非正常情况。处理方式可以是正常去执 行该基本事件的处理操作，但是由于之前已经成功处理过一次，因此本次执行不会成功，也就是不会产生新的基本事件处理结果。

s112，由判断过程可知，当前目标事件为撤销事件，之前接收过同组事件的处理请求、但未处理过同组的基本事件，也就是说之前曾经接到过同组的撤销事件处理请求，相当于重复接收了针对同一事件本体的撤销事件处理请求，属于非正常情况。处理方式可以是正常去执行该撤销事件的处理操作，但是由于未收到过同组基本事件的处理请求，或基本事件被抵消而未执行，因此本次执行不会成功，也就是不会产生新的撤销事件处理结果。

可以看出，补充的s108及s112仅是从逻辑上对方法流程做了完善，实际上并不会产生实际效果，因此如果从简化处理的角度考虑，这里也可以直接将s108的处理方式设置为不执行该基本事件的处理操作、将s112的处理方式设置为不执行该撤销事件的处理操作，从而降低事件处理侧的资源消耗。

这里需要说明的是，由于存在重复接收到撤销事件处理请求的可能，因此在执行s109时，按照正常的处理方式，会先判断目标事件的同组基本事件是否已被撤销，如果未被撤销，则进一步执行该基本事件的撤销操作。如果已被撤销，说明当前需要处理的一个重复的撤销事件，撤销操作不会成功，如果从简化处理的角度考虑，这里也可以直接将处理方式设置为不执行该撤销事件的处理操作，从而降低事件处理侧的资源消耗。

下面结合几种可能出现的具体情形，对完善后的处理流程进行说明：

前述的情形a及情形b不再重复说明

情形c，连续收到两次基本事件处理请求消息：

先执行s104分支，正常处理基本事件；

再执行s108分支，重复的基本事件不产生实际效果。

情形d，连续收到两次撤销事件处理请求消息：

先执行s105分支，撤销事件未处理；

再执行s112分支，重复的撤销事件不产生实际效果。

情形e，先收到基本事件处理请求消息，再收到撤销事件处理请求消息，再 收到基本事件处理请求消息：

先执行s104分支，正常处理基本事件；

再执行s109分支，正常处理撤销事件；

再执行s108分支，重复的基本事件不产生实际效果。

情形f，先收到撤销事件处理请求消息，再收到基本事件处理请求消息，再收到撤销事件处理请求消息：

先执行s105分支，撤销事件未处理；

再执行s111分支，抵消之前未处理的撤销事件；

再执行s112分支，重复的撤销事件不产生实际效果。

更为复杂的消息顺序情形，在这里不做一一穷举。可见，即便没有对同一事件组中的事件数量进行限制，应用本申请方案依然可以对可能出现的各种情形做出符合预期的正确处理。另外，根据前面实施例的介绍，在s111以“抵消”的方式执行基本事件及其撤销事件之后，无论是否生成基本事件的处理记录，都不会影响最终的处理结果，举例说明：在执行过一次“抵消”操作后，后续又收到了同组的基本事件处理请求消息，如果之前生成了处理记录则执行s108，如果之前未生成处理记录则执行s111，本次基本事件请求均不会产生实际效果。类似地，如果后续又收到了同组的撤销事件处理请求消息，则根据之前是否生成处理记录，可能会触发s109或s112，而无论触发哪个分支，撤销事件均不会产生实际效果。

相应于上述方法实施例，本申请还提供一种应用于事件处理侧的关联事件处理装置，参见图4所示，该装置可以包括：

消息接收模块210，用于接收事件请求侧针对目标事件的处理请求消息；

第一判断模块221，用于根据目标事件的组标识，判断是否已接收过组标识对应的事件处理请求消息；

第二判断模块222，用于判断是否处理过组标识对应的基本事件；

第三判断模块223，用于判断目标事件的类型；

第一执行模块231，用于在未接收过组标识对应的事件处理请求消息、且目 标事件为基本事件的情况下，执行目标事件的处理操作；

第二执行模块232，用于在未接收过组标识对应的事件处理请求消息、且目标事件为撤销事件的情况下，不向事件请求侧反馈针对目标事件的处理失败消息；

第三执行模块233，用于在已接收过组标识对应的事件处理请求消息、已处理过组标识对应的基本事件、且目标事件为撤销事件的情况下，执行目标事件的处理操作；

第四执行模块234，用于在已接收过组标识对应的事件处理请求消息、未处理过组标识对应的基本事件、且目标事件为基本事件的情况下，不执行目标事件的处理操作。

在本申请的一种具体实施方式中，第二执行模块可以具体用于：向事件请求侧反馈针对当前撤销事件的处理成功消息。

在本申请的一种具体实施方式中，第二执行模块可以具体用于：

不执行目标事件的处理操作；

或

执行目标事件的处理操作失败后，不向事件请求侧反馈针对目标事件的处理失败消息。

参见图5所示，在本申请的一种具体实施方式中，上述装置还可以包括第五执行模块235，用于在已接收过组标识对应的事件处理请求消息、已处理过组标识对应的基本事件、且目标事件为基本事件的情况下，不执行目标事件的处理操作。

在本申请的一种具体实施方式中，上述装置还可以包括第六执行模块236，用于在已接收过组标识对应的事件处理请求消息、未处理过组标识对应的基本事件、且目标事件为撤销事件的情况下，不执行目标事件的处理操作。

可以理解的是，第五执行模块235与第六执行模块236作为两种功能独立的模块，既可以如图5所示同时配置在装置中，也可以分别单独配置在装置中，因此图5所示的结构不应理解为对本申请方案的限定。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。