CN116264605A - 事件处理方法、设备及系统、程序产品及存储介质 - Google Patents

Abstract

本申请涉及数据处理技术领域，提供一种事件处理方法、设备及系统、程序产品及存储介质。其中，事件处理方法应用于事件处理设备，具体包括：在当前事件被触发后，从事件处理设备的存储空间中获取与当前事件的事件类型对应的当前副本事件，每种类型的事件在存储空间中至多保存一个副本事件，该副本事件的事件信息根据该类型事件的事件信息确定；利用当前事件的事件信息更新当前副本事件的事件信息。在该方法中，由于每种类型的事件在事件处理设备的存储空间中至多保存一个副本事件，从而即使事件处理设备中产生了大量的事件，也不会占用太多的存储空间，因此显著降低了对事件处理设备的性能需求，并且有利于事件处理设备的正常工作。

Description

事件处理方法、设备及系统、程序产品及存储介质

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种事件处理方法、设备及系统、程序产品及存储介质。

背景技术

目前，在很多室内室外场景中都部署有网络摄像头，这些摄像头在工作过程中会触发很多事件(例如，检测到画面中有移动的物体)，摄像头会将触发的所有事件都缓存于本地，并在适当的时候将其发送给关注这些事件的用户(例如，可以是手机上安装有特定APP的用户)，以使用户获知这些事件的发生，从而采取相应的措施。

从而，一旦触发的事件数量过多，缓存这些事件将消耗大量的存储资源，然而，多数摄像头均属于嵌入式设备，其内部的存储资源十分有限，难以满足缓存大量事件的需求，或者，即使能够满足需求，也可能导致摄像头的其他功能无法正常运行。

发明内容

本申请实施例的目的在于提供一种事件处理方法、设备及系统、程序产品及存储介质，以改善上述至少部分技术问题。

为实现上述目的，本申请提供如下技术方案：

第一方面，本申请实施例提供一种事件处理方法，应用于事件处理设备，所述方法包括：在所述事件处理设备中的当前事件被触发后，从所述事件处理设备的存储空间中获取与所述当前事件的事件类型对应的当前副本事件；其中，每种类型的事件在所述存储空间中至多保存一个副本事件，该副本事件的事件信息根据该类型事件的事件信息确定；利用所述当前事件的事件信息更新所述当前副本事件的事件信息。

在上述方法中，由于每种类型的事件在事件处理设备(例如，网络摄像头)的存储空间中至多保存一个副本事件，从而即使事件处理设备中触发了大量的事件，也不会占用太多的存储空间，因此显著降低了对事件处理设备的性能需求，并且有利于事件处理设备的正常工作。

此外，由于副本事件的事件信息会根据最新的事件信息不断更新，从而可以确保最新的事件不会丢失。

在第一方面的一种实现方式中，所述副本事件的事件信息包括以下至少一项：事件类型，表示所述副本事件的种类；事件数据，表示所述副本事件的附加数据；最新触发时间，表示所述副本事件最近一次触发的时刻；重复次数，表示所述副本事件重复发生的次数；开始时间，表示所述副本事件开始的时刻；结束时间，表示所述副本事件结束的时刻；发送标记，表示所述副本事件是否已经发送；结束标记，表示所述副本事件是否已经结束。

在上述实现方式中，列出了副本事件可能包含的事件信息，副本事件的事件信息并不是某一个同类型的普通事件的事件信息的简单复制，而是若干个同类型的普通事件进行事件信息融合的结果，副本事件具体要包含哪些事件信息可以根据业务需求确定。

在第一方面的一种实现方式中，所述从所述事件处理设备的存储空间中获取与所述当前事件的事件类型对应的当前副本事件，包括：根据所述当前事件的事件类型从所述存储空间中查找所述当前副本事件；若查找所述当前副本事件成功，则获得所述当前副本事件；若查找所述当前副本事件失败，则在所述存储空间中创建所述当前副本事件；其中，若查找所述当前副本事件失败，则所述利用所述当前事件的事件信息更新所述当前副本事件的事件信息，包括：利用所述当前事件的事件信息初始化所述当前副本事件的事件信息。

在上述实现方式中，只有某种类型的事件被实际触发后，才为其创建副本事件，从而可以避免存储空间浪费。但也可以提前为每种类型的事件都创建好副本，此时查询副本事件可以认为总是能够成功查询。

在第一方面的一种实现方式中，所述方法还包括：根据所述副本事件的事件信息确定所述存储空间中尚未发送的副本事件；其中，所述尚未发送的副本事件是指其尚未被所述事件处理设备成功发送给事件接收设备的副本事件；根据所述尚未发送的副本事件的事件信息生成事件通知消息，并向所述事件接收设备发送所述事件通知消息；其中，成功发送所述事件通知消息表明所述尚未发送的副本事件已经被所述事件处理设备发送。

在上述实现方式中，由于是基于副本事件而非单个事件本来生成并发送事件通知消息，而每种类型的事件仅对应一个副本事件，因此显著改善了因事件数量过多而造成发送延时的情况。

在第一方面的一种实现方式中，所述副本事件的事件信息包括发送标记，所述根据所述副本事件的事件信息确定所述存储空间中尚未发送的副本事件，包括：将所述存储空间中发送标记为第一数值的副本事件确定为所述尚未发送的副本事件；其中，所述存储空间中发送标记为第二数值的副本事件为已经发送的副本事件，所述存储空间中的副本事件的事件信息初始化时，其中的发送标记被设置为所述第一数值；所述方法还包括：将新发送的副本事件的发送标记设置为所述第二数值。

在上述实现方式中，通过在事件信息中增加发送标记这一信息项，便于快速准确地判断副本事件是否已经被发送。

在第一方面的一种实现方式中，所述副本事件的事件信息包括结束时间和/或结束标记，所述方法还包括：根据所述副本事件的事件信息确定所述存储空间中已经结束的副本事件；若所述副本事件的事件信息包括结束时间，则设置所述已经结束的副本事件的结束时间；若所述副本事件的事件信息包括结束标记，则将所述已经结束的副本事件的结束标记设置为第四数值；其中，所述存储空间中束标记为第三数值的副本事件为尚未结束的副本事件，所述存储空间中的副本事件的事件信息初始化时，其中的结束标记被设置为所述第三数值。

在上述实现方式中，在发送副本事件已经结束时，可以为其设置合理的结束时间，使得副本事件能够持续一个时间段(事件副本的开始时间可以在其事件信息初始化时设置)，和/或，可以通过在事件信息中增加结束标记这一信息项，便于快速准确地判断副本事件是否已经结束。

在第一方面的一种实现方式中，所述副本事件的事件信息包括最新触发时间，所述根据所述副本事件的事件信息确定所述存储空间中的已经结束的副本事件，包括：将所述存储空间中预期结束时间已经被当前时间超过的副本事件确定为所述已经结束的副本事件；其中，所述副本事件的预期结束时间为：所述副本事件的最新触发时间加上所述副本事件的预期持续时间；所述设置所述已经结束的副本事件的结束时间，包括：将所述已经结束的副本事件的结束时间设置为所述已经结束的副本事件的预期结束时间。

在上述实现方式中，通过比较当前时间和副本事件的预期结束时间，可以快速准确地判断副本事件是否已经结束。

在第一方面的一种实现方式中，所述副本事件的事件信息包括最新触发时间和/或事件数据，所述利用所述当前事件的事件信息更新所述当前副本事件的事件信息，包括：若根据所述当前副本事件的事件信息确定所述当前副本事件尚未被发送，则利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据；若根据所述当前副本事件的事件信息确定所述当前副本事件已经被发送，则利用所述当前事件的事件信息初始化所述当前副本事件的事件信息。

在上述实现方式中，若当前副本事件尚未发送，则表明该事件的事件信息还没有通知服务器，所以可以只是更新当前副本事件的某些事件信息(例如，最新触发时间、事件数据)；若当前副本事件已经发送，则表明该事件的信息已经通知了服务器，从而可以利用当前事件的事件信息重新初始化当前副本事件的事件信息，相当于开始了一个新的副本事件。

进一步的，若当前事件还带有事件数据(例如，触发事件的图片、对事件的文字描述)，则还可以对当前副本事件的事件数据进行更新。注意，虽然更新后，当前副本事件中原始的事件数据被覆盖掉，但对于很多应用场景而言，这并不意味着事件丢失，例如，对于移动侦测事件(检测到画面中存在移动的物体)，用户并不关心到底哪一帧出现了移动物体，只要有移动物体出现时，对其进行了通知即可。

在第一方面的一种实现方式中，所述副本事件的事件信息包括发送标记，若所述当前副本事件的发送标记为第一数值，则确定所述当前副本事件尚未被发送，若所述发送标记为第二数值，则确定所述当前副本事件已经被发送；其中，所述发送标记在所述当前副本事件初始化时被设置为所述第一数值，且在所述当前副本事件被所述事件处理设备发送后被设置为所述第二数值。

在上述实现方式中，利用发送标记的值，可以快速准确地判断当前副本事件是否已经被发送。

在第一方面的一种实现方式中，所述副本事件的事件信息包括重复次数，所述利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据，包括：若根据所述当前副本事件的事件信息确定所述前副本事件尚未结束，则利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据；若根据所述当前副本事件的事件信息确定所述前副本事件已经结束，则将所述当前副本事件的重复次数累加1，并利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据；其中，所述重复次数在所述当前副本事件初始化时被设置为1。

在上述实现方式中，若当前副本事件尚未结束，则只需更新当前副本事件的某些事件信息(例如，最新触发时间、事件数据)；若当前副本事件已经结束，则除了要更新当前副本事件的某些事件信息，还需将当前副本事件的重复次数累加1，表明经历了一次事件的开始和结束，但需注意，此时并不需要初始化当前副本事件，因为当前副本事件并未发送。

在第一方面的一种实现方式中，所述副本事件的事件信息包括结束标记，若所述当前副本事件的结束标记为第三数值，则确定所述前副本事件尚未结束，若所述结束标记为第四数值，则确定所述前副本事件已经结束；其中，所述结束标记在所述当前副本事件初始化时被设置为所述第三数值，且在所述当前副本事件的预期结束时间到来后被设置为所述第四数值。

在上述实现方式中，利用结束标记的值，均可以快速准确地判断前副本事件是否已经结束。

在第一方面的一种实现方式中，所述方法还包括：根据所述副本事件的事件信息确定所述存储空间中已经发送的副本事件；其中，所述已经发送的副本事件是指其对应的事件通知消息已经被所述事件处理设备成功发送给事件接收设备的副本事件；销毁所述已经发送的副本事件。

在上述实现方式中，通过销毁已发送的副本事件，使得存储空间中被其占据的存储区域能够重新分配给其他副本事件或者用于其他用途，从而提高了存储资源的利用率。

第二方面，本申请实施例提供一种事件处理装置，包括：副本事件获取模块，用于在所述事件处理设备中的当前事件被触发后，从所述事件处理设备的存储空间中获取与所述当前事件的事件类型对应的当前副本事件；其中，每种类型的事件在所述存储空间中至多保存一个副本事件，该副本事件的事件信息根据该类型事件的事件信息确定；事件信息更新模块，用于利用所述当前事件的事件信息更新所述当前副本事件的事件信息。

第三方面，本申请实施例提供一种计算机程序产品，包括计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第五方面，本申请实施例提供一种事件处理设备，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。

第六方面，本申请实施例提供一种事件处理系统，包括：事件接收设备至少一台第五方面提供事件处理设备，所述事件接收设备用于接收并处理所述事件处理设备根据尚未发送的副本事件中的事件信息生成事件通知消息。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的事件处理方法的一种应用场景；

图2示出了本申请实施例提供的事件处理方法的流程；

图3示出了本申请实施例提供的事件发送线程可能的执行流程；

图4示出了本申请实施例提供的事件销毁线程可能的执行流程；

图5示出了本申请实施例提供的事件结束计时线程可能的执行流程；

图6示出了本申请实施例提供的事件触发线程可能的执行流程；

图7示出了本申请实施例提供的事件处理装置可能包含的功能模块；

图8示出了本申请实施例提供的事件处理设备的可能的结构。

具体实施方式

图1示出了本申请实施例提供的事件处理方法的一种应用场景，该场景所要实现的功能是实时的将网络摄像头触发的某些事件(例如，检测到画面中有移动的物体)通知手机APP，以使APP的用户能够获知这些事件的发生，以便采取相应的措施。

参照图1，该场景采用发布/订阅架构来实现上述功能，其参与方包括手机110、服务器120以及摄像头130，其中，服务器120包括注册服务器和发布服务器，二者可以是两台服务器，也可以是同一台服务器中集成了注册和发布两项功能，而摄像头130则可以有一台或多台。这些参与方的工作过程简述如下：

过程1～2：手机110上的APP作为订阅者，通过互联网向注册服务器进行注册，注册参数包括APP的Token、欲订阅的摄像头ID、通讯相关信息等。其中，Token可以是APP的唯一标记，每次安装APP都产生一个不同的Token，而ID则是摄像头130的唯一标记。

摄像头130内部处理过程：摄像头130在工作过程中会根据其内置的逻辑触发事件(例如，检测到画面中有移动的物体，则触发移动侦测事件)，摄像头130会将触发的事件放入内存中的缓冲区内，摄像头130中的发送线程根据和发布服务器的交互逻辑对缓冲区中的事件进行发送。

过程3～4：摄像头130作为发布者，向发布服务器发布通知消息，消息中携带摄像头ID、事件信息等。

服务器120内部处理过程：发布服务器根据消息中携带摄像头ID，从注册服务器处获取订阅了此ID的所有订阅者的Token以及通讯信息。

过程5～6：发布服务器根据通讯信息向订阅了此ID的所有订阅者发布通知消息，消息中携带事件信息等。

然而，发明人长期研究发现，图1中的架构在工作过程中存在以下问题：一旦摄像头130在短时间内触发的事件数量过多，而发送线程不能及时地发送这些事件，将导致缓冲区中积累的事件越来越多，然而，摄像头130很可能属于嵌入式设备，其内存十分有限，难以满足缓存大量事件的需求，或者，即使能够满足需求，也可能导致摄像头130的其他功能无法正常运行。进一步的，若摄像头130的发送线程按照事件触发的顺序排队发送事件，则在事件积累多以后，新触发的事件可能会等上很久才发送，导致手机APP上无法实时获得事件通知。

针对上述技术问题，可能采取的应对方案包括：

(1)控制摄像头130触发事件的频率，使其不要在短时间内产生大量事件。

(2)对存储事件的缓冲区大小进行限制，若事件的数量超过了缓冲区所能容纳的事件总量，则将新来的事件丢弃掉。

然而，方案(1)实施起来难度较大，事件触发的频率有时是和APP的业务需求绑定的，并不能随意进行调整。另外，方案(1)也不能彻底解决事件发送延时的问题，例如，若摄像头130和发布服务器之间的网络环境不佳，导致通知消息频繁发送失败，则即使事件触发频率不高，仍然可能产生事件积累，进而导致发送延时。方案(2)中缓冲区大小的设置难以把握，若缓冲区设置得较小，则事件丢失严重，从而也无法对APP进行通知，若缓冲区设置得较大，则会导致内存占用较高，可能影响摄像头130的其他功能的运行。总之，方案(1)和(2)并不能很好地解决上述技术问题。

本申请实施例提供的事件处理方法(包含其可能的各种实现方式)，可以、但不限于应用在图1中的摄像头130中，有利于改善事件大量触发时对内存占用过高、事件发送延时、事件丢失等问题，显著提升了摄像头130的事件处理性能。

需要指出，本申请实施例新提出的技术方案，以及上面提到的种种技术问题，都应视为发明人在现有技术的基础上所作出的贡献，而不应视为现有技术中业已存在的内容。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

术语“第一”、“第二”等仅用于将一个实体或者操作与另一个实体或操作区分开来，而不能理解为指示或暗示相对重要性，也不能理解为要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

图2示出了本申请实施例提供的一种事件处理方法的流程。该方法可以但不限于由图8中的事件处理设备执行，关于该事件处理设备可能的结构可以参考后文关于图8的阐述。参照图2，事件处理方法包括：

步骤S210：在事件处理设备中的当前事件被触发后，从事件处理设备的存储空间中获取与当前事件的事件类型对应的当前副本事件。

事件处理设备泛指能够触发事件并对事件进行处理的电子设备，例如，事件处理设备可以是摄像头(比如，摄像头130)、可穿戴设备、机器人等。

在事件处理设备中，事件可以理解为一种数据对象，该数据对象描述了事件处理设备外部或内部发生的某种现象，事件触发可以理解为事件处理设备在探测到事件处理设备外部或内部发生的某种现象后，生成相应的事件的过程，而事件处理可以理解为对事件进行的一种或多种操作，例如存储、发送等操作。

例如，事件处理设备是摄像头，若摄像头检测到画面中有移动的物体，则触发移动侦测事件；若摄像头检测到画面中有行人，则触发人形事件；若摄像头检测到画面中有物体进入某一预先划定的区域，则触发区域入侵事件；若摄像头检测到画面中有物体离开某一预先划定的区域，则触发越界检测事件；若摄像头启动，则触发设备上线事件；若摄像头关闭，则触发设备下线事件，等等。

事件处理设备可以按照既定的逻辑不断地触发事件，对于每个触发的事件都会执行本申请实施例提供的事件处理方法，为便于阐述，不妨以其中的当前事件为例，当前事件可以理解为事件处理设备触发的任意一个事件，并不具有特殊性。当前事件的触发可以在步骤S210中执行，也可以在步骤S210开始执行之前就执行，对于前一种情况，触发事件和处理事件(指执行步骤S210～S220)的可能是同一个实体，例如事件触发线程，对于后一种情况，触发事件和处理事件的可能是两个不同的实体，例如事件触发线程和事件处理线程。

每个事件都有自身的事件信息，事件信息可以理解为事件的属性，例如可以包括以下一项或多项事件信息：

事件类型：代表事件的种类，比如，前面例子中提到的移动侦测事件、区域入侵事件，严格来说是指移动侦测类事件、区域入侵类事件；

触发时间：代表事件产生的时刻；

事件数据：与事件有关的一些附加数据，比如触发事件的图片、对事件的文字描述等信息。

副本事件是一种特殊的事件，其可以理解为针对每一个类型的事件设置的一种数据对象，副本事件也有自己的事件信息，副本事件的事件信息根据和其同类型的普通事件(指实际触发的事件，后文类似之处不再重复解释)的事件信息确定。

例如，副本事件可以包括以下一项或多项事件信息：

事件类型：代表副本事件的种类；

事件数据：代表副本事件的附加数据；

最新触发时间：代表副本事件最近一次触发的时刻；

重复次数：代表副本事件重复发生的次数；其中，副本事件从开始到结束为发生一次；

开始时间：代表副本事件的开始时刻；

结束时间：代表副本事件的结束时刻；

发送标记：取值为第一数值(例如，false)或第二数值(例如，true)，第一数值表示副本事件尚未发送给事件接收设备，第二数值表示副本事件已经发送给事件接收设备；

结束标记：取值为第三数值(例如，false)或第四数值(例如，true)，第三数值表示副本事件尚未结束，第四数值表示副本事件已经结束。

副本事件中具体要包含哪些事件信息可以根据业务需求确定，例如，若副本事件中的信息最终要发送给手机APP，则可以根据手机APP的需求来确定。

可以看出，副本事件的事件信息并不是某一个同类型的普通事件的事件信息的简单复制，而是若干个同类型的普通事件进行事件信息融合的结果，或者副本事件也可以看作是若干个同类型的普通事件按照某种特定规则进行合并的产物，合并规则取决于业务需求，即合并后副本事件中的信息足以代替普通事件执行特定的业务。

例如，对于副本事件，其与普通事件的一个显著区别是事件信息中可能包含开始时间和结束时间，即副本事件可能会持续一个时段，而普通事件的事件信息中则只有触发时间，这项信息只是一个时刻而非时段。在副本事件中，通过将一个时刻扩展一个时段，一方面便于将连续触发的普通事件进行合并(后文会给出具体例子)，从而节约存储空间，另一方面也是出于一些业务上的考虑，比如，在将副本事件发送给手机APP后，手机APP可以根据副本事件的开始时间和结束时间截取相应的摄像头采集的视频供用户观察分析。

又例如，对于副本事件的重复次数，由于是一项统计信息，因此也是单一的普通事件所不具备的信息。

每种类型的事件在事件处理设备的存储空间中至多保存一个对应的副本事件。其中，事件处理设备的存储空间(后文有时简称存储空间)可以是事件处理设备中安装的易失性和/或非易失性的存储器，例如事件处理设备的内存。所谓在存储空间中保存副本事件，实际上就是保存副本事件的事件信息，例如，这些事件信息可以保存为字段的形式。

上述“至多保存一个副本事件”中的“至多”可以这样理解：从逻辑上讲，针对每种类型的事件在事件处理设备的存储空间中都可以创建一个对应的副本事件，例如针对移动侦测事件可以创建一个移动侦测副本事件，针对区域入侵事件可以创建一个区域入侵副本事件，然而这些副本事件并不是在任何条件下一定都同时存在于存储空间中。例如，若移动侦测事件从未触发过，则可以暂时不创建此类副本事件，待确实有移动侦测事件触发后，再为其创建对应的副本事件，以节约存储空间；又例如，若移动侦测事件曾经触发过，为其创建了对应的副本事件，但之后移动侦测事件很久没有再次触发，为节约存储空间，可以将该副本事件占用的存储空间回收，等等。

在步骤S210中，将当前事件的事件类型对应的副本事件称为当前副本事件，为获取当前副本事件，可以根据当前事件的事件类型从事件处理设备的存储空间中进行查找。例如，若在副本事件的事件信息中包含事件类型，从而，遍历存储空间中的副本事件，若某一副本事件的事件类型和当前事件的事件类型一致，则说明该副本事件就是当前副本事件。

当然，即使在某些实现方式中，副本事件的事件信息不包含事件类型，也可以从存储空间中查找当前副本事件。例如，若每种类型的副本事件都保存在存储空间中固定的地址处，且该存储地址与事件类型的关系已知，则根据当前事件的事件类型，就可以定位到当前副本事件在存储空间中的存储地址。

上面介绍的都是查找当前副本事件成功的情况，此时直接从存储空间中获得当前副本事件即可，对于查找当前副本事件失败的情况，意味着存储空间中目前还未保存有当前副本事件，从而可以在存储空间中创建当前副本事件，从结果上看也是获得了当前副本事件。

所谓创建副本事件，可以理解为在存储空间中确定出一片用于保存副本事件的存储区域。例如，这片存储区域可以在创建副本事件时向存储空间的管理者申请，其中，存储空间的管理者可以是事件处理设备的操作系统，也可以是操作系统中运行的存储管理程序等。又例如，在创建副本事件时，存储空间中已经有一片提前申请的存储区域(比如，被销毁的副本事件原来保存的区域，关于副本事件的销毁详见后文)，则可以直接将要创建的副本事件和这片存储区域关联起来。

在一种实现方式中，可以在事件处理设备的存储空间中提前(比如，在第一个事件触发之前)为每种已知类型的事件都创建一个副本事件，这样一来，如果副本事件不被销毁(关于副本事件的销毁详见后文)，则查找当前副本事件必然会成功(排除其他导致查找失败的外界因素)。在另一种实现方式中，则先不创建任何副本事件，只有当某种类型的事件确实被触发后，才会创建该类型事件对应的副本事件，这种实现方式下才有可能出现查找当前副本事件失败的情况。其中，前一种实现方式的处理逻辑比较简单，后一种实现方式则比较节约存储空间，比如对于哪些从未触发过任何事件的事件类型，则不会在存储空间中为其创建副本事件。

步骤S220：利用当前事件的事件信息更新当前副本事件的事件信息。

若当前副本事件是在步骤S210中才创建的，则步骤S220可以理解为是在利用当前事件的事件信息初始化当前副本事件的事件信息，在当前副本事件刚创建时，其各项事件信息可能是无意义的值或特定值(例如，全0)，所谓初始化就是基于当前事件的事件信息给当前副本事件的各项事件信息赋予有意义的值。在后文中，有时也将副本事件的事件信息的初始化简称为副本事件的初始化。

例如，若副本事件的事件信息包括上面提到的全部信息项，则初始化操作可以包括：将当前副本事件的事件类型设置为当前事件的事件类型，将当前副本事件的事件数据设置为当前事件的事件数据，将当前副本事件的最新触发时间设置当前事件的触发时间，将当前副本事件的重复次数设置为1(因为初始化意味着当前副本事件已经开始，即发生了1次)，将当前副本事件的开始时间设置为当前事件的触发时间，将当前副本事件的发送标记设置为第一数值，将当前副本事件的结束标记设置为第三数值，而对于当前副本事件的结束时间可以不设置(因为此时尚无法确定事件何时结束)，维持其原来的值(比如0)，也可以先暂时设置为当前副本事件的预期结束时间，必要时可进行更改(见后文例子)。其中，预期结束时间可以是当前副本事件的最新触发时间与当前副本事件的预期持续时间(可以是一个默认值，比如15s、30s)之和。

若当前副本事件不是在步骤S210中才创建的，比如直接就能够从存储空间中查找到当前副本事件，则步骤S220就是狭义上的信息更新，即利用当前事件的事件信息，结合特定的规则，更新当前副本事件目前的事件信息，得到当前副本事件新的事件信息，或者说将当前事件的事件信息也融合到了当前副本事件中，使得当前副本事件的事件信息能够跟随新触发的事件发生一定的变化。例如，可以利用当前事件的触发时间更新当前副本事件的最新触发时间，等等。关于上述特定的规则，后文还会详细阐述，此处暂不展开。

注意，由于初始化当前副本事件的事件信息和更新当前副本事件的事件信息本质上都是给构成当前副本事件的各个信息项进行赋值，所以将二者统称为利用当前事件的事件信息更新当前副本事件的事件信息也是可以的。

简单总结图2中的方法，在该方法中，由于每种类型的事件在事件处理设备的存储空间中至多保存一个副本事件，该副本事件可以认为在某种程度上融合了这一类事件的事件信息，从而即使事件处理设备中触发了大量的事件，也不会发生事件积累，即不会占用太多的存储空间，因此显著降低了对事件处理设备的性能需求，并且有利于事件处理设备的正常工作。

进一步的，在一些实现方式中，可以将副本事件发送给关注此事件人、程序或设备(例如，手机APP)，由于副本事件仅仅是一个特殊的事件(虽然其事件信息可能和普通事件不同)，因此副本事件的总数量是较少的(通常事件类型不会太多)，并不存在排队发送的问题，从而可以极大地改善事件发送延时的问题，提高事件通知过程的实时性。

此外，由于副本事件的事件信息会根据最新的事件信息不断更新(初始化也可视为一种更新)，即其中总是包含了最新触发的事件的事件信息，可以有效避免最新触发的事件被丢失的问题。

需要注意，本申请实施例提供的事件处理方法及其可能的实现方式虽然能够解决图1场景中的技术问题，但不代表该事件处理方法仅能用于图1中的场景。例如，在本申请实施例提供的事件处理方法中，事件处理设备可以只是存储副本事件，而不对外发送副本事件，或者，即使对外发送副本事件，也不一定要采用图1中的发布/订阅架构。

在一些实现方式中，可以利用四个线程来配合实现上述事件处理方法，分别是事件发送线程、事件销毁线程、事件结束计时线程以及事件触发线程，其可能的执行流程分别如图3～图6所示，这些流程中的步骤都可以由事件处理设备执行，后文不再特别说明。

事件发送线程主要负责向事件接收设备(例如，图1中的服务器120)发送副本事件。在一些场景中，事件处理设备需要将副本事件发送给其他设备，例如图1中的服务器120，这样的设备统称为事件接收设备。

参照图3，事件发送线程可以有固定的工作频率，即图3中的步骤S310～S370可以按照此频率每隔一段时间执行一次，但每次执行时也不一定会执行步骤S310～S370中的全部步骤，或者，事件发送线程的工作频率也可以不是固定的。

步骤S310：判断事件处理设备当前是否允许发送副本事件。

若事件处理设备当前允许发送副本事件，则执行步骤S320，若事件处理设备当前不允许发送副本事件，则流程结束。不过需要注意，如前所述，步骤S310～S370的步骤是定期重复执行的，所以流程结束并不意味着发送线程终止执行，对于后文中其他导致流程结束的情况，如无特殊说明的，均可类似理解，不再重复说明。由于发送事件涉及和事件接收设备交互，所以事件处理设备很可能并非任何时候都可以发送副本事件，例如，对于不同的服务器平台，允许事件处理设备发送事件的频率可能是不同的。从而，在事件处理设备本地，可以根据对接的服务器平台，制定相应的规则，用于判断当前是否允许向服务器平台发送副本事件，使得实际发送事件的频率不超过与服务器约定的发送频率。例如，某服务器平台每10s内最多接收单台事件处理设备发送的3个副本事件，则事件处理设备可以统计最近10s内已经发送的副本事件的数量，若小于3个，则允许当前继续发送副本事件，若已经达到3个，则不允许当前继续发送副本事件；或者，事件处理设备可以将事件发送线程直接设置为每10s唤醒3次，每次至多仅能发送一个副本事件，等等。

若事件处理设备总是可以发送副本事件，例如，事件处理设备本身触发事件的频率较低，则也可以省略步骤S310。

步骤S320：判断事件处理设备的存储空间中是否保存有副本事件。

若存储空间中保存有副本事件，则获取所有保存的副本事件，并执行步骤S330，若存储空间中没有保存副本事件，则流程结束。若存储空间中保存有多个副本事件，则步骤S330～S370可以理解为是针对其中每个副本事件都要执行的步骤。

例如，若副本事件仅在同类型的普通事件被实际触发后才创建，则可能发送线程启动后的一段时间还没有触发事件，存储空间中也就没有相应的副本事件。

若能够事先确定事件处理设备的存储空间中保存有副本事件，则步骤S320的判断可以省略，直接获取存储空间中保存的副本事件即可。例如，事先为每种类型的事件都创建好副本事件，再启动发送线程，此时存储空间中必然保存有副本事件。

步骤S330：判断副本事件是否尚未发送。

若副本事件尚未发送，则执行步骤S340；若副本事件已经发送，则该事件本次的发送流程结束，但对于步骤S320中得到的其他副本事件，则可以进一步判断。

可以通过副本事件的事件信息来判断副本事件的发送状态。例如，若副本事件的事件信息中包括发送标记，则可以通过检测存储空间中的副本事件的发送标记的取值来判断副本事件是否已经发送：若发送标记为第一数值，则确定副本事件尚未被发送，若发送标记为第二数值，则确定副本事件已经被发送。其中，发送标记在存储空间中的副本事件初始化时被设置为第一数值，且在副本事件被事件处理设备发送后被设置为第二数值(步骤S370)。

虽然通过设置发送标记，可以快速准确地判断出副本事件是否已经被发送，但这也并非判断副本事件是否已经被发送的唯一方式。例如，也可以在副本事件的事件信息中增加一项发送时间，发送时间在副本事件初始化时被设置为一个极大值(比如，若干年之后的时间)，且在副本事件被事件处理设备发送时被设置为当时的时间，则若当前时间尚未超过副本事件的发送时间，可以确定副本事件尚未发送，若当前时间已经超过副本事件的发送时间，可以确定副本事件已经发送。

步骤S340：向事件接收设备发送副本事件。

可以根据尚未发送的副本事件的事件信息生成事件通知消息，并向事件接收设备发送事件通知消息，即将副本事件发送给事件接收设备可以指向事件接收设备发送副本事件对应的事件通知消息。至于事件接收设备收到事件通知消息后如何处理，则不限定，例如，在图1中，发布服务器可以进一步将副本事件以消息的形式通知作为订阅者的手机APP。

事件通知消息可以包含副本事件的全部或部分的事件信息，例如，若副本事件的事件信息包括事件类型、事件数据、最新触发时间、重复次数、开始时间、结束时间、发送标记以及结束标记，则事件通知消息中可以包含事件类型、事件数据、最新触发时间、重复次数、开始时间以及结束时间，其发送标记和结束标记是在事件处理设备本地做判断用的，可以不必发送给事件接收设备。

其中，在副本事件尚未结束时，其结束时间可能是未知的(根据后文内容可知，可以推断副本事件的预期结束时间，但不确保在此时间副本事件一定会结束)，但由于发送副本事件后，该事件的信息已经通知了事件接收设备，相当于该事件已经结束了，所以在事件通知消息中可以将结束时间字段设置为当前时间。

步骤S350：判断副本事件是否发送成功。

若副本事件发送成功，则执行步骤S370；若副本事件发送失败，则执行步骤S360。其中，副本事件发送是否成功可以理解为其对应的事件通知消息是否发送成功，只有确定了副本事件发送成功，该副本事件才能视为已经发送的副本事件，否则该副本事件仍视为尚未发送的副本事件。

例如，根据事件接收设备的返回结果可以获知副本事件是否发送成功，或者，有时因为网络原因，副本事件发不出去，事件处理设备也可以自己判断出发送失败。

步骤S360：进行发送副本事件的重试。

所谓重试，可以理解为跳转到步骤S340重新执行，以提高副本事件发送成功的概率，避免偶然因素造成的发送失败。可选的，重试次数可以设置上限，例如3次、5次等，若重试次数已经达到上限却仍然未能发送成功，则表明该事件本次发送失败，可以结束该事件本次的发送流程，但不影响其他副本事件是否发送成功。

步骤S360是可选的，首次发送失败时完全可以不进行重试，直接结束该事件本次的发送流程。

步骤S370：将副本事件中的发送标记设置为第二数值。

若成功发送副本事件，表明尚未发送的副本事件此时已经转变成了已经发送的副本事件，从而可以同步地改变存储空间中的副本事件中的发送标记，以实时标明副本事件的发送状态。

副本事件的发送状态除了可能在步骤S330中使用，也可能在事件销毁线程的步骤S420、事件触发线程的步骤S640中使用，详见后文阐述。步骤S370是可选的，如果不通过发送标记判断副本事件是否已经发送，则可以不执行步骤S370。

发送线程的各步骤的执行顺序不限于从S310～S370，例如也可以把步骤S310移动到S330后面执行，等等。

事件销毁线程主要负责销毁事件处理设备的存储空间中的副本事件。参照图4，事件销毁线程可以有固定的工作频率，即图4中的步骤S410～S430可以按照此频率每隔一段时间执行一次，但每次执行时也不一定会执行步骤S410～S430中的全部步骤，或者，事件销毁线程的工作频率也可以不是固定的。

步骤S410：判断事件处理设备的存储空间中是否保存有副本事件。

若存储空间中保存有副本事件，则获取所有保存的副本事件，并执行步骤S420，若存储空间中没有保存副本事件，则流程结束。若存储空间中保存有多个副本事件，则步骤S420～S430可以理解为是针对其中每个副本事件都要执行的步骤。若能够事先确定事件处理设备的存储空间中保存有副本事件，则步骤S420中的判断可以省略，直接获取存储空间中保存的副本事件即可。

步骤S420：判断副本事件是否已经发送。

若副本事件已经发送，则执行步骤S430；若副本事件尚未发送，则该事件本次的销毁流程结束，但对于步骤S410中得到的其他副本事件，则可以进一步判断。

例如，若副本事件的事件信息中包括发送标记，则可以通过检测存储空间中的副本事件的发送标记的取值来判断副本事件是否已经发送：若发送标记为第一数值，则确定副本事件尚未被发送，若发送标记为第二数值，则确定副本事件已经被发送。

步骤S410～S420和图3中的步骤S320～S330是类似的(判断副本事件是否已经发送和判断副本事件是否尚未发送是互补的)，在阐述时未提及之处，也可以参考步骤S320～S330的相关内容。

步骤S430：销毁副本事件。

对于已经发送的副本事件，相当于其包含的事件信息已经通知了服务器，至少在执行步骤S430的这个时刻看来，该副本事件已经没有必要再保存在存储空间中，从而可以将销毁掉，即解除该副本事件对其目前占据的存储区域的占用，使得这片存储区域可以被重新分配给其他副本事件使用或者用于其他用途，从而提高了存储资源的利用率。副本事件被销毁后，可以认为其不再存在于存储空间中。

其中，“销毁”可以通过多种操作实现：例如，回收存储空间中被已经发送的副本事件占据的区域，所谓“回收”，就是将存储区域的使用权交还给存储空间的管理者(例如，事件处理设备的操作系统或者存储管理程序)，若要再次使用这片存储区域需重新向存储空间的管理者申请；又例如，清空存储空间中被已经发送的副本事件占据的区域，所谓“清空”，就是将存储区域中的数据无效化(例如，全部置0)，但不用将存储区域的使用权交还给存储空间的管理者。

相较而言，“回收”是一种更彻底的销毁行为，对于存储空间的管理者来说，“回收”使得其可以管理的存储区域更多了，从而在存储区域的分配上也更加灵活，但无论是向管理者申请存储区域还是将存储区域交还给管理者都会带来一定的开销；而“清空”实际上销毁的只是存储区域中的数据，并不涉及和存储空间的管理者之间的交互，因此也就不会产生相应的开销，但“清空”后的存储区域由于其控制权不在管理者手中，因此在分配上显得不够灵活。

当前，也不排除通过“回收”和“清空”之外的方式进行事件销毁，例如，可以在副本事件的事件信息中或者存储空间的管理者处增加一项销毁标识，来表明副本事件是否已经被销毁，一旦某个副本事件的销毁标识被设置，表明该副本事件所在的存储区域中的数据可视为无效的，该存储区域可以用于其他用途。

进一步的，由于每种类型的事件在存储空间中至多保存一个副本事件，若某类型的副本事件刚刚发送就被销毁，之后很快又触发了同类型的普通事件，此时需要重新创建该类型的副本事件，这将使得之前进行的销毁行为显得多余。

例如，若副本事件是通过“回收”的方式销毁的，则刚刚回收了存储区域，很快又要为新创建的副本事件申请存储区域，不如直接保留原来的存储区域；若副本事件是通过“清空”的方式销毁的，则刚刚将存储区域中的数据清空，又要为存储区域中的数据赋值(初始化新创建的副本事件)，不如直接给已发送的副本事件的信息项赋值。

为改善上述问题，也可以在副本事件发送后等上一段时间，若没有同类型的普通事件触发，表明该副本事件占据的存储区域确实不大可能被继续使用了，此时再将其销毁更加合理。

例如，可以在副本事件的事件信息中增加一项发送时间，发送时间在副本事件初始化时设置为一个极大值(比如，若干年之后的时间)，发送时间在副本事件被事件处理设备发送时被设置为当时的时间，事件销毁线程按照固定的频率工作，在步骤S420和S430之间还可增设一项判断：判断当前时间和副本事件的发送时间之差是否大于某一时间阈值(正数)，若大于时间阈值才执行步骤S430，否则暂时不销毁该副本事件。对于某个副本事件，若其被发送以后，在时间阈值之内又触发了同类型的普通事件，则该副本事件会被重新初始化(详见步骤S540)，导致发送时间被设置为极大值，从而当前时间和发送时间之差为负数，不可能大于时间阈值，该副本事件也不会被销毁。

事件销毁线程是可选的，即也可以不销毁存储空间中的副本事件。

事件结束计时线程主要负责记录事件的结束。参照图5，事件结束计时线程可以有固定的工作频率，即图5中的步骤S510～S530可以按照此频率每隔一段时间执行一次，但每次执行时也不一定会执行步骤S510～S530中的全部步骤，或者，事件结束计时线程的工作频率也可以不是固定的。

步骤S510：判断事件处理设备的存储空间中是否保存有副本事件。

若存储空间中保存有副本事件，则获取所有保存的副本事件，并执行步骤S520，若存储空间中没有保存副本事件，则流程结束。若存储空间中保存有多个副本事件，则步骤S520～S530可以理解为是针对其中每个副本事件都要执行的步骤。若能够事先确定事件处理设备的存储空间中保存有副本事件，则步骤S510中的判断可以省略，直接获取存储空间中保存的副本事件即可。

步骤S520：判断副本事件是否已经结束。

若副本事件已经结束，则执行步骤S530；若副本事件尚未结束，则该事件本次的结束计时流程结束，但对于步骤S510中得到的其他副本事件，则可以进一步判断。

可以通过副本事件的事件信息来判断副本事件的结束状态。例如，若当前时间(指执行到步骤S520时的时间)尚未超过副本事件的预期结束时间，则确定副本事件尚未结束，若当前时间已经超过副本事件的预期结束时间，则确定副本事件已经结束。其中，副本事件的预期结束时间＝副本事件的最新触发时间+副本事件的预期持续时间。

预期结束时间表示当前推定的副本事件的结束时间，但并不一定是副本事件真实的结束时间，只有在预期结束时间到来时它才是副本事件真实的结束时间(若当前时间已经超过预期结束时间，表明预期结束时间必然到来了)，在预期结束时间未到来时它有可能发生变化，因为并不能提前预知副本事件会持续多久。预期持续时间表示每触发一次同类型的普通事件，副本事件所能够持续的时间，预期持续时间可以取默认值，例如10s、15s等。

为了更好地理解预期结束时间的计算公式，下面简单说明副本事件的开始时间、结束时间、预期结束时间、最新触发时间以及预期持续时间的关系：

如前所述，普通事件对应的仅仅是一个时刻(触发时间)，而副本事件对应的则是一个时段(从开始时间到结束时间)，副本事件持续的时段是基于同类型的普通事件的触发时间，并结合特定的规则进行扩展得到。该特定的规则可以是：

在导致副本事件初始化(例如，后文将要阐述的步骤S630、S650)的普通事件A被触发时，得到副本事件的开始时间和最新触发时间，均为是事件A的触发时间，此时副本事件的预期结束时间A＝事件A的触发时间+副本事件的预期持续时间，若在预期结束时间A到来之前再无同类型的普通事件触发，则副本事件的结束时间就是预期结束时间A。若在预期结束时间A到来之前又有同类型的普通事件B触发，则表明副本事件还在持续，将副本事件的最新触发时间更新为事件B的触发时间，此时副本事件的预期结束时间B＝事件B的触发时间+副本事件的预期持续时间，若在预期结束时间B到来之前再无同类型的普通事件触发，则副本事件的结束时间就是预期结束时间B。若在预期结束时间B到来之前又有同类型的普通事件C触发，则表明副本事件还在持续，将副本事件的最新触发时间更新为事件C的触发时间，此时副本事件的预期结束时间C＝事件C的触发时间+副本事件的预期持续时间，以此类推。注意，以上字母A、B、C仅为区分不同时刻触发的事件，并不具有特殊含义。

例如，副本事件的预期持续时间为15s，上述事件A在第0s触发，则副本事件的开始时间和最新触发时间均为第0s，预期结束时间为第15s，假设到第10s时，又触发了上述事件B，则副本事件的最新触发时间为第10s，副本事件的预期结束时间则要从第10s开始重新累计满15s，即变成第25s，假设到第25s时，并未触发新的同类型事件，则副本事件的结束时间就是第25s，副本事件总共持续了25s。

上述规则概括来说就是：对于在较短的间隔时间内(不超过预期持续时间)连续触发的普通事件，都将其视为同一个副本事件的多次触发，或者也可以认为这些普通事件被合并成了一个副本事件，相应的事件信息也要融合。

在上述判断副本事件是否结束的方法中，涉及三项和副本事件有关的信息：最新触发时间、预期结束时间和预期持续时间，其中最新触发时间属于副本事件的事件信息，而预期结束时间和预期持续时间则不一定属于副本事件的事件信息，即无需将其保存在副本事件占据的存储区域中，其原因在于，副本事件的预期结束时间可以只是一个临时变量，仅在判断副本事件是否结束时临时计算一下，当前副本事件的预期持续时间则可以只是一个常数。当然，也不排除将这两项信息或者其中的一项信息作为当前副本事件的事件信息。

应当理解，利用副本事件的事件信息来判断副本事件是否结束还存在其他方法，例如，仅在确认副本事件被发送后才认为其已经结束，期间无论同类型的普通事件的触发时间间隔了多久，都认为副本事件还在持续，等等。

步骤S530：将副本事件的结束时间设置为副本事件的预期结束时间，并将副本事件的结束标志设置为第四数值。

如果步骤S520中采用的是当前时间和副本事件的预期结束时间之间的关系来判断副本事件是否结束，则根据上面阐述的预期结束时间的含义，在步骤S530中可以将副本事件的结束时间设置为副本事件的预期结束时间。但如果步骤S520中采用的其他方式来判断副本事件是否结束，则可以将副本事件的结束时间设置为其他值，例如副本事件被发送的时间，等等。

副本事件的结束标志是一项表征副本事件是否结束的事件信息，若存储空间中的副本事件的结束标记为第三数值，则表明副本事件尚未结束，若存储空间中的副本事件的结束标记为第四数值，则表明副本事件已经结束。其中，存储空间中的副本事件的结束标记在副本事件的事件信息初始化时(例如，后文将要阐述的步骤S630、S650)被设置为第三数值，而在步骤S530中被设置为第四数值，副本事件的结束标志可以在步骤S660中被使用，用于快速准确地判断副本事件是否已经结束，详见后文阐述，但结束标志只是副本事件的一项可选事件信息，即使没有这项信息，在步骤S660中也可以用其他方法判断副本事件是否已经结束。

在一些实现方式中，副本事件的结束时间只有在步骤S530中才设置，其他时候一直维持副本事件初始化时的值(例如，0)。但在另一些实现方式中，也可以在副本事件的最新触发时间更新时(包括初始化时，即可以是后文将要阐述的步骤S630、S650、S680)，利用更新后的最新触发时间计算副本事件的预期结束时间，并将副本事件的结束时间设置为计算出的预期结束时间，即结束时间总是保持目前推定出的值，此时步骤S530中不必再设置副本事件的结束时间。

可以理解的，若副本事件的事件信息中不包含结束标志，则步骤S530中也不需要对其进行设置，若副本事件的事件信息中不包含结束时间，则步骤S530中也不需要对其进行设置，总之，在不同的实现方式中，步骤S530中的两项设置操作可以全部执行，可以只执行其中一项，也可以全都不执行。事件触发线程主要负责触发事件，并根据触发的事件对副本事件的事件信息进行更新。参照图6，事件发送线程可以按照事件的触发频率工作，即图6中的步骤S610～S680可以每触发一次事件就执行一次，当然每次执行时也不一定会执行步骤S610～S680中的全部步骤。下面，以前文提到的当前事件被触发时的情况为例，对步骤S610～S680进行介绍，当前事件对应的副本事件为当前副本事件。

步骤S610：触发当前事件。

触发事件的方式前文已经介绍，不再重复阐述。注意，步骤S610是可选的，例如，也可以由另一个单独的线程负责触发事件，并通知事件触发线程执行后续的步骤S620～S680。

步骤S620：判断当前事件是否为新事件。

若当前事件是新事件，则执行步骤S630；若当前事件不是新事件，则从事件处理设备的存储空间中获取当前副本事件，并执行步骤S640。

步骤S620中的“新事件”是指该类型事件的副本事件目前不存在于事件处理设备的存储空间中。换句话说，如果能从存储空间中查找到当前事件对应的副本事件(当前副本事件)，则说明当前事件不是新事件，若不能从存储空间中查找到当前副本事件，则说明当前事件是新事件。查找的方法在阐述步骤S210时已经介绍，不再重复阐述。

导致当前事件是新事件有两种可能，一种是当前事件此前从未触发过，一种是当前事件此前曾经触发过，并且其在存储空间中也曾经有过对应的副本事件，但该副本事件后来被销毁。当然，若某些实现方式中不设置事件销毁线程，则没有第二种可能。

步骤S630：在事件处理设备的存储空间中创建当前副本事件，并初始化当前副本事件的事件信息。

步骤S630在介绍步骤S210时已经介绍。例如，当前副本事件的初始化可以包括以下操作：将当前副本事件的事件类型设置为当前事件的事件类型，将当前副本事件的事件数据设置为当前事件的事件数据，将当前副本事件的最新触发时间设置当前事件的触发时间，将当前副本事件的重复次数设置为1，将当前副本事件的开始时间设置为当前事件的触发时间，将当前副本事件的发送标记设置为第一数值(表示尚未发送)，将当前副本事件的结束标记设置为第三数值(表示尚未结束)，而对于当前副本事件的结束时间可以不设置，维持其原来的值(比如0)，也可以先暂时设置为当前副本事件的预期结束时间。

应当理解，在不同的实现方式中，根据副本事件所包含的事件信息的不同，上述初始化操作可以全部执行，也可以只执行其中的一部分。例如，若事件信息中不包含结束标记，自然也就无需对其进行赋值了。

注意，步骤S630中的创建当前副本事件是可选的，若事先在存储空间中为每种类型的事件都创建好了相应的副本事件，并且也不设置事件销毁线程，则可以无需创建当前副本事件，直接对其进行初始化。

步骤S630执行完毕之后，可以结束流程，如图6所示，当然也可以继续执行步骤S640、S660、S680(此时当前副本事件必然尚未发送也尚未结束)，使得整个对当前事件的处理流程得到简化。

步骤S640：判断当前副本事件是否已经发送。

若当前副本事件已经发送，则执行步骤S650；若当前副本事件尚未发送，则执行步骤S660。对于设置有事件发送线程的情况，由于事件发送线程会在每个副本事件成功发送后更新其发送标记(步骤S370)，因此在步骤S640中可以直接根据发送标记的值判断当前副本事件是否已经发送，若其取值为第一数值，则表明当前副本事件尚未发送，若其取值为第二数值，则表明当前副本事件已经发送。当然，即使没有发送标记也可以采用其他方式判断当前副本事件是否已经发送，可以参考步骤S330。

关于步骤S640引出的两个分支可以这样理解：若当前副本事件尚未发送，则表明该事件的事件信息还没有通知服务器，所以可以只是更新当前副本事件的某些事件信息(例如，步骤S670中的重复次数、步骤S680中最新触发时间、事件数据)；若当前副本事件已经发送，则表明该事件的信息已经通知了服务器，等价于该事件已经结束，从而可以利用当前事件的事件信息重新初始化当前副本事件的事件信息，相当于开始了一个新的副本事件。

步骤S650：初始化当前副本事件的事件信息。

步骤S650中的初始化操作和步骤S630中的初始化操作是类似的，不再重复阐述。但步骤S650的初始化和步骤S630略有不同，在步骤S630中的初始化之前，由于当前副本事件刚刚创建，所以当前副本事件的各项事件信息的取值可以是没有明确的物理意义的(比如，全部置0)，而在步骤S650中的初始化之前，由于当前副本事件已经存在了一段时间，所以当前副本事件的各项事件信息的取值是有明确的物理意义的，只不过初始化时可将这些取值视为无效的，重新对其进行赋值，当然，如果有的取值无需重新赋值，比如事件类型，也可以跳过。

步骤S650表明，当前副本事件虽然已经被发送，但只要其未被销毁，其所占据的存储区域仍可以用于保存同类型的新副本事件，即提高了存储空间的利用率。

步骤S640、S650都是可选的，例如，有可能事件处理设备并不需要向外发送副本事件。

步骤S650执行完毕之后，可以结束流程，如图6所示，当然也可以继续执行步骤S660、S680(此时当前副本事件必然尚未结束)，使得整个对当前事件的处理流程得到简化。

步骤S660：判断当前副本事件是否已经结束。

若当前副本事件已经结束，则执行步骤S670；若当前副本事件尚未结束，则执行步骤S680。

可以通过当前副本事件的事件信息来判断当前副本事件的结束状态。下面列举两种方式：

方式1

若当前时间尚未超过当前副本事件的预期结束时间，则确定当前副本事件尚未结束，若当前时间已经超过当前副本事件的预期结束时间，则确定当前副本事件已经结束。其中，当前副本事件的预期结束时间＝当前副本事件的最新触发时间(指执行到步骤S660时的)+当前副本事件的预期持续时间。

该判断方式和步骤S520中介绍的类似，不再重复阐述。

方式2

若当前副本事件的事件信息中包括结束标记，则可以通过检测结束标记的取值来判断当前副本事件是否已经结束：若结束标记为第三数值，则确定当前副本事件尚未结束，若结束标记为第四数值，则确定当前副本事件已经结束。其中，结束标记在当前副本事件初始化时被设置为第三数值，且在当前副本事件的预期结束时间到来后被设置为第四数值(步骤S530)。

若采用方式2，其实是直接利用了事件结束计时线程中对结束标记的更新结果(步骤S530)，简化了事件触发线程的逻辑。若采用方式1，则此时也可以不设置事件结束计时线程。此外，方式1直接根据当前时间和当前副本事件的预期结束时间进行判断会比较精确，而在方式2中，判断结果正确与否取决于结束标志的值是否正确，若事件结束计时线程在当前副本事件结束时未能及时更新其结束标志(例如，事件结束计时线程的工作频率设置得太低)，则有可能出现当前副本事件已经结束，但其结束标志还未更新为第四数值的情况，这将影响步骤S660中的判断结果。

当然，也不排除方式1和方式2之外的其他判断当前副本事件是否结束的方式。

关于步骤S660引出的两个分支可以这样理解：若当前副本事件尚未结束，则只需更新当前副本事件的某些事件信息(例如，步骤S680中最新触发时间、事件数据)，将当前事件的事件信息融入到当前副本事件的事件信息中去；若当前副本事件已经结束，则除了要更新当前副本事件的某些事件信息，还需将当前副本事件的重复次数累加1，表明经历了一次事件的开始和结束，但需注意，此时并不需要初始化当前副本事件的事件信息，因为当前副本事件并未发送，或者说其事件信息还未通知过服务器，若进行初始化相当于事件信息丢失了。

步骤S670：将当前副本事件的重复次数累加1。

当前副本事件的重复次数表明在当前副本事件被发送以前总共经历了多少次事件的开始和结束，该项事件信息可以出于业务目的设置。

步骤S660、S670都是可选的，例如，若仅在副本事件被发送后才认为其已经结束，期间无论同类型的普通事件的触发时间间隔了多久，都认为副本事件还在持续，则此时判断副本事件是否结束等同于判断副本事件是否已经发送，即可以不执行步骤S660、S670，步骤S640直接与步骤S680衔接。

步骤S680：利用当前事件的触发时间更新当前副本事件的最新触发时间，并利用当前事件的事件数据更新当前副本事件的事件数据。

步骤S680的目的是将当前事件的事件信息融入到当前副本事件的事件信息中去，一方面扩充当前副本事件的事件信息的内容，一方面使得当前副本事件的事件信息总是全部或部分地跟随最新的事件信息，进而使得最新的事件信息不会丢失。

其中，是否要更新当前副本事件的事件数据是可选的，或者因为事件信息中根本未设置该信息项，或者因为某些类型的事件可能没有相应的事件数据。例如，前文提到的移动侦测事件、设备上线事件、设备下线事件可以是不带图片的(图片为事件数据)，而人形事件、区域入侵事件、越界检测事件可以是带图片的。是否要更新当前副本事件的最新触发时间也是可选的，例如，若业务需求中没有对于最新触发时间的需求，则副本事件的事件信息中可以不包含最新触发时间。若当前副本事件的最新触发时间和事件数据都不需要更新(或者根本没有这两项信息)，则步骤S680也可以不执行，或者用于更新当前副本事件中的其他信息。

事件发送线程、事件销毁线程、事件结束计时线程以及事件触发线程可以独立工作，但由于这些线程都会访问存储空间中的副本事件，为避免出现数据不同步的问题，可以限定同一时刻仅有其中一个线程能够访问存储空间中的副本事件，例如，可以通过加锁的方式实现该目的。

可选的，上述四个线程也不全是必须设置的，例如，若事件处理方法不需要发送副本事件，则可以不设置事件发送线程，若事件处理方法不需要销毁副本事件，则可以不设置事件销毁线程。此外，即使要实现上述四个线程的全部功能，也不一定非要将这些功能拆分为四个线程，例如，也可以全部合并到一个线程中，或者合并到两个或三个线程中，总之，其实现方式十分灵活。

图7示出了本申请实施例提供的事件处理装置700可能包含的功能模块。参照图7，事件处理装置700包括：

副本事件获取模块710，用于在所述事件处理设备中的当前事件被触发后，从所述事件处理设备的存储空间中获取与所述当前事件的事件类型对应的当前副本事件；其中，每种类型的事件在所述存储空间中至多保存一个副本事件，该副本事件的事件信息根据该类型事件的事件信息确定；

事件信息更新模块720，用于利用所述当前事件的事件信息更新所述当前副本事件的事件信息。

在事件处理装置700的一种实现方式中，所述副本事件获取模块710从所述事件处理设备的存储空间中获取与所述当前事件的事件类型对应的当前副本事件，包括：根据所述当前事件的事件类型从所述存储空间中查找所述当前副本事件；若查找所述当前副本事件成功，则获得所述当前副本事件；若查找所述当前副本事件失败，则在所述存储空间中创建所述当前副本事件；其中，若查找所述当前副本事件失败，则所述事件信息更新模块720利用所述当前事件的事件信息更新所述当前副本事件的事件信息，包括：利用所述当前事件的事件信息初始化所述当前副本事件的事件信息。

在事件处理装置700的一种实现方式中，所述装置还包括：事件发送模块，用于：根据所述副本事件的事件信息确定所述存储空间中尚未发送的副本事件；其中，所述尚未发送的副本事件是指其对应的事件通知消息尚未被所述事件处理设备成功发送给事件接收设备的副本事件；根据所述尚未发送的副本事件的事件信息生成事件通知消息，并向所述事件接收设备发送所述事件通知消息；其中，成功发送所述事件通知消息表明所述尚未发送的副本事件已经被所述事件处理设备发送。

在事件处理装置700的一种实现方式中，所述副本事件的事件信息包括发送标记，所述事件发送模块根据所述副本事件的事件信息确定所述存储空间中尚未发送的副本事件，包括：将所述存储空间中发送标记为第一数值的副本事件确定为所述尚未发送的副本事件；其中，所述存储空间中发送标记为第二数值的副本事件为已经发送的副本事件，所述存储空间中的副本事件的事件信息初始化时，其中的发送标记被设置为所述第一数值；所述事件发送模块还用于：将新发送的副本事件的发送标记设置为所述第二数值。

在事件处理装置700的一种实现方式中，所述副本事件的事件信息包括结束时间和/或结束标记，所述装置还包括：事件结束处理模块，用于：根据所述副本事件的事件信息确定所述存储空间中已经结束的副本事件；若所述副本事件的事件信息包括结束时间，则设置所述已经结束的副本事件的结束时间；若所述副本事件的事件信息包括结束标记，则将所述已经结束的副本事件的结束标记设置为第四数值；其中，所述存储空间中束标记为第三数值的副本事件为尚未结束的副本事件，所述存储空间中的副本事件的事件信息初始化时，其中的结束标记被设置为所述第三数值。

在事件处理装置700的一种实现方式中，所述副本事件的事件信息包括最新触发时间，所述事件结束处理模块根据所述副本事件的事件信息确定所述存储空间中的已经结束的副本事件，包括：将所述存储空间中预期结束时间已经被当前时间超过的副本事件确定为所述已经结束的副本事件；其中，所述副本事件的预期结束时间为：所述副本事件的最新触发时间加上所述副本事件的预期持续时间；所述事件结束处理模块设置所述已经结束的副本事件的结束时间，包括：将所述已经结束的副本事件的结束时间设置为所述已经结束的副本事件的预期结束时间。

在事件处理装置700的一种实现方式中，所述副本事件的事件信息包括最新触发时间和/或事件数据，所述事件信息更新模块720利用所述当前事件的事件信息更新所述当前副本事件的事件信息，包括：若根据所述当前副本事件的事件信息确定所述前副本事件尚未被发送，则利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据；若根据所述当前副本事件的事件信息确定所述前副本事件已经被发送，则利用所述当前事件的事件信息初始化所述当前副本事件的事件信息；其中，所述已发送副本事件是指其已经被所述事件处理设备发送的副本事件。

在事件处理装置700的一种实现方式中，所述副本事件的事件信息包括发送标记，若所述当前副本事件的发送标记为第一数值，则确定所述当前副本事件尚未被发送，若所述发送标记为第二数值，则确定当前副本事件已经被发送；其中，所述发送标记在所述当前副本事件初始化时被设置为所述第一数值，且在所述当前副本事件被所述事件处理设备发送后被设置为所述第二数值。

在事件处理装置700的一种实现方式中，所述副本事件的事件信息包括重复次数，所述事件信息更新模块720利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据，包括：若根据所述当前副本事件的事件信息确定所述当前副本事件尚未结束，则利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据；若根据所述当前副本事件的事件信息确定所述当前副本事件已经结束，则将所述当前副本事件的重复次数累加1，并利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据；其中，所述重复次数在所述当前副本事件初始化时被设置为1。

在事件处理装置700的一种实现方式中，所述副本事件的事件信息包括结束标记，若所述当前副本事件的结束标记为第三数值，则确定所述当前副本事件尚未结束，若所述结束标记为第四数值，则确定所述当前副本事件已经结束；其中，所述结束标记在所述当前副本事件初始化时被设置为所述第三数值，且在所述当前副本事件的预期结束时间到来后被设置为所述第四数值。

在事件处理装置700的一种实现方式中，所述装置还包括：事件销毁模块，用于：根据所述副本事件的事件信息确定所述存储空间中已经发送的副本事件；其中，所述已经发送的副本事件是指其对应的事件通知消息已经被所述事件处理设备成功发送给事件接收设备的副本事件；销毁所述已经发送的副本事件。

本申请实施例提供的事件处理装置700可用于执行本申请实施例提供的事件处理方法，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考前述任意一个方法实施例中相应内容。

图8示出了本申请实施例提供的事件处理设备800的一种可能的结构。参照图8，事件处理设备800包括：处理器810、存储器820以及通信接口830，这些组件通过通信总线840和/或其他形式的连接机构(未示出)互连并相互通讯。

其中，处理器810包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器810可以是通用处理器，包括中央处理器(CentralProcessing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(Network Processor，简称NP)或者其他常规处理器；还可以是专用处理器，包括图形处理器(Graphics Processing Unit，GPU)、神经网络处理器(Neural-network ProcessingUnit，简称NPU)、数字信号处理器(Digital Signal Processor,简称DSP)、专用集成电路(Application Specific Integrated Circuits，简称ASIC)、现场可编程门阵列(FieldProgrammable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。并且，在处理器810为多个时，其中的一部分可以是通用处理器，另一部分可以是专用处理器。

存储器820包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，电可擦除可编程只读存储器(Electric Erasable Programmable Read-Only Memory，简称EEPROM)等。

处理器810以及其他可能的组件可对存储器820进行访问，读和/或写其中的数据。特别地，在存储器820中可以存储一个或多个计算机程序指令，处理器810可以读取并运行这些计算机程序指令，以实现本申请实施例提供的事件处理方法。

通信接口830包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互，例如，事件处理设备800可以利用通信接口830和事件接收设备进行交互。通信接口830可以包括进行有线和/或无线通信的接口。

可以理解，图8所示的结构仅为示意，事件处理设备800还可以包括比图8中所示更多或者更少的组件，或者具有与图8所示不同的配置。例如，事件处理设备800还可能包括图像采集模块，用于采集图像(含视频)，这里的图像可作为前文提到的事件数据。

图8中所示的各组件可以采用硬件、软件或其组合实现。事件处理设备800可能是实体设备，例如摄像头(比如，图1中的摄像头130)、无人机、无人船、可穿戴设备、手机、PC机、服务器、机器人等，也可能是虚拟设备，例如虚拟机、容器等。并且，事件处理设备800也不限于单台设备，也可以是多台设备的组合或者大量设备构成的集群。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，这些计算机程序指令被处理器读取并运行时，执行本申请实施例提供的事件处理方法。例如，计算机可读存储介质可以实现为图8中事件处理设备800中的存储器820。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序指令，这些计算机程序指令被处理器读取并运行时，执行本申请实施例提供的事件处理方法。

本申请实施例还提供一种事件处理系统，该事件处理系统包括事件接收设备以及至少一台事件处理设备。其中，事件接收设备用于接收并处理事件处理设备根据尚未发送的副本事件的事件信息生成事件通知消息，事件接收设备可以、但不限于采用服务器，事件处理设备则用于执行本申请实施例提供的事件处理方法，事件处理设备可以、但不限于采用图8中的结构。例如，对于图1中的服务器120和摄像头130，若摄像头130能够执行本申请实施例提供的事件处理方法(比如，摄像头130上部署有上述计算机程序产品)，并且服务器120能够接收并处理摄像头130产生的上述事件通知消息，则可以认为服务器120和摄像头130构成了一个上述事件处理系统。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (14)

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

在所述事件处理设备中的当前事件被触发后，从所述事件处理设备的存储空间中获取与所述当前事件的事件类型对应的当前副本事件；其中，每种类型的事件在所述存储空间中至多保存一个副本事件，该副本事件的事件信息根据该类型事件的事件信息确定；

利用所述当前事件的事件信息更新所述当前副本事件的事件信息。

2.根据权利要求1所述的事件处理方法，其特征在于，所述副本事件的事件信息包括以下至少一项：

事件类型、事件数据、最新触发时间、重复次数、开始时间、结束时间、发送标记以及结束标记。

3.根据权利要求1或2所述的事件处理方法，其特征在于，所述从所述事件处理设备的存储空间中获取与所述当前事件的事件类型对应的当前副本事件，包括：

根据所述当前事件的事件类型从所述存储空间中查找所述当前副本事件；

若查找所述当前副本事件成功，则获得所述当前副本事件；

若查找所述当前副本事件失败，则在所述存储空间中创建所述当前副本事件；

其中，若查找所述当前副本事件失败，则所述利用所述当前事件的事件信息更新所述当前副本事件的事件信息，包括：

利用所述当前事件的事件信息初始化所述当前副本事件的事件信息。

4.根据权利要求1-3中任一项所述的事件处理方法，其特征在于，所述方法还包括：

根据所述副本事件的事件信息确定所述存储空间中尚未发送的副本事件；

根据所述尚未发送的副本事件的事件信息生成事件通知消息，并向事件接收设备发送所述事件通知消息；其中，成功发送所述事件通知消息表明所述尚未发送的副本事件已经被所述事件处理设备发送。

5.根据权利要求4所述的事件处理方法，其特征在于，所述副本事件的事件信息包括发送标记，所述根据所述副本事件的事件信息确定所述存储空间中尚未发送的副本事件，包括：

将所述存储空间中发送标记为第一数值的副本事件确定为所述尚未发送的副本事件；其中，所述存储空间中发送标记为第二数值的副本事件为已经发送的副本事件，所述存储空间中的副本事件的事件信息初始化时，其中的发送标记被设置为所述第一数值；

所述方法还包括：

将新发送的副本事件的发送标记设置为所述第二数值。

6.根据权利要求1-5中任一项所述的事件处理方法，其特征在于，所述副本事件的事件信息包括结束时间和/或结束标记，所述方法还包括：

根据所述副本事件的事件信息确定所述存储空间中已经结束的副本事件；

若所述副本事件的事件信息包括结束时间，则设置所述已经结束的副本事件的结束时间；

若所述副本事件的事件信息包括结束标记，则将所述已经结束的副本事件的结束标记设置为第四数值；其中，所述存储空间中束标记为第三数值的副本事件为尚未结束的副本事件，所述存储空间中的副本事件的事件信息初始化时，其中的结束标记被设置为所述第三数值。

7.根据权利要求6所述的事件处理方法，其特征在于，所述副本事件的事件信息包括最新触发时间，所述根据所述副本事件的事件信息确定所述存储空间中的已经结束的副本事件，包括：

将所述存储空间中预期结束时间已经被当前时间超过的副本事件确定为所述已经结束的副本事件；其中，所述副本事件的预期结束时间为：所述副本事件的最新触发时间加上所述副本事件的预期持续时间；

所述设置所述已经结束的副本事件的结束时间，包括：

将所述已经结束的副本事件的结束时间设置为所述已经结束的副本事件的预期结束时间。

8.根据权利要求1-7中任一项所述的事件处理方法，其特征在于，所述副本事件的事件信息包括最新触发时间和/或事件数据，所述利用所述当前事件的事件信息更新所述当前副本事件的事件信息，包括：

若根据所述当前副本事件的事件信息确定所述当前副本事件尚未被发送，则利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据；

若根据所述当前副本事件的事件信息确定所述当前副本事件已经被发送，则利用所述当前事件的事件信息初始化所述当前副本事件的事件信息。

9.根据权利要求8所述的事件处理方法，其特征在于，所述副本事件的事件信息包括重复次数，所述利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据，包括：

若根据所述当前副本事件的事件信息确定所述当前副本事件尚未结束，则利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据；

若根据所述当前副本事件的事件信息确定所述当前副本事件已经结束，则将所述当前副本事件的重复次数累加1，并利用所述当前事件的触发时间更新所述当前副本事件的最新触发时间，和/或，利用所述当前事件的事件数据更新所述当前副本事件的事件数据；其中，所述重复次数在所述当前副本事件初始化时被设置为1。

10.根据权利要求4-5、8-9中任一项所述的事件处理方法，其特征在于，所述方法还包括：

根据所述副本事件的事件信息确定所述存储空间中已经发送的副本事件；

销毁所述已经发送的副本事件。

11.一种计算机程序产品，其特征在于，包括计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行如权利要求1-10中任一项所述的方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行如权利要求1-10中任一项所述的方法。

13.一种事件处理设备，其特征在于，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行权利要求1-10中任一项所述的方法。

14.一种事件处理系统，其特征在于，包括：事件接收设备以及至少一台如权利要求13所述的事件处理设备，所述事件接收设备用于接收并处理所述事件处理设备根据尚未发送的副本事件的事件信息生成事件通知消息。

Images