CN110928872A - 处理系统和方法 - Google Patents

Abstract

本发明涉及一种处理系统和方法。如果响应于流事件的第一事件的处理由于例外或超时的发生而未正常结束，则在从第一事件的发生起的预定时间段期间重复地执行该处理。然后，在经过了该预定时间段之后，发出错误通知，同时仅执行一次在该预定时间段期间发生的第二事件的处理。

Description

处理系统和方法

技术领域

本发明涉及用于在使用云服务的事件驱动型服务中进行事件处理的技术。

背景技术

近年来，已经可用各种云计算服务。其示例包括Amazon Web服务(以下称为“AWS”)、Google云平台和Microsoft Azure。这些服务通过提供诸如虚拟机和存储装置等的计算资源、并基于所使用的性能和容量以时间为单位对所提供的计算资源进行收费而变得普及。通过使用这些服务，服务用户可以在无需在用户侧准备物理设施的情况下以低成本灵活地构建诸如web系统等的信息处理系统。

作为云计算服务的使用示例，存在从连接至网络的各种装置、计算机终端和移动终端收集装置和应用的设置值、将所收集到的设置值存储在存储装置中、并在数据库中管理这些值的服务。在这样的服务中，每当上传诸如文件等的所收集到的信息时，生成记录，并且管理文件名及其在存储装置中的存储位置。

例如，日本特开2004-38759论述了事件驱动型脚本技术。在该技术中，在更新特定信息的情况下，响应于更新事件而激活预先登记的脚本。

云计算服务还提供响应于发生的事件而对特定计算资源执行轻量级处理的服务(以下称为“事件驱动型计算服务”)。其示例包括AWS Lambda、Google云功能和MicrosoftAzure功能。

在这样的服务中，将用于实现期望处理的程序代码连同被配置为执行该程序代码的虚拟机的中央处理单元(CPU)和存储器的指定规范一起预先登记在云计算服务中。然后，将所登记的程序代码与计算资源和对计算资源发生的特定事件相关联。

为了实现与事件驱动型计算服务所实现的处理等同的处理，传统的云计算服务的用户需要进行实现该处理所需的开发和管理。例如，用户需要开发用于检测对计算资源发生的事件和用于执行期望处理的应用，并且构建和管理将运行应用的基础架构。

然而，上述的事件驱动型计算服务允许云计算服务的用户仅关注于期望处理的开发。由于事件驱动型计算服务采用基于执行所登记的程序代码的时间长度以时间为单位对所提供的服务进行收费的形式来提供服务，因此从基础架构成本方面也促进了应用开发。

另一方面，以AWS Lambda为例的当前可用的事件驱动型计算服务在响应于事件的发生而执行的程序代码的执行时存在限制事项。更具体地，如果程序代码的处理未在由事件驱动型计算服务指定的时间长度内完成，则发生超时，并且该处理作为错误而结束。

因而，除了由于程序代码或事件中的缺陷而导致发生例外的情况之外，开发者还需要为在与这样的限制事项冲突的情况下发生的错误作准备，以例如通过检测错误的发生或接收到通知来迅速地从错误恢复。

触发上述的事件驱动型计算服务的更新事件(以下称为“流事件”)在发生之后可被保持为流。流事件的示例是数据库表更新事件。

在这样的基于流的事件的情况下，事件驱动型计算服务周期性地轮询流，并且如果存在更新后的记录，则事件驱动型计算服务执行与该记录相关联地登记的程序代码。例如，在数据库表在短时间内连续改变的情况下，发生多个流事件。事件驱动型计算服务执行程序代码以按时间顺序处理这些流事件。

在由流事件触发的通过执行程序代码所进行的处理失败了多次的情况下，事件驱动型计算服务重试对象事件的处理，直到从流中删除失败的事件为止。在响应于数据库表更新而发生的流事件的情况下，例如在24小时内从流中删除该流事件。因而，在按时间顺序对流事件执行特殊处理的情况下，如果在一个事件的处理中发生错误，则在长时间段期间不执行下一流事件的处理，直到从流中删除对象事件为止。在这种情况下，事件驱动型计算服务的整个处理变得停滞。

在从流中删除事件时，事件驱动型计算服务不再执行对象事件的处理。然而，在这种情况下，由于不是因为通过执行程序代码所进行的处理不成功，因此不发出与对象事件有关的错误通知。

用于防止由流事件触发的通过事件驱动型计算服务所进行的处理中的停滞的可能方法是仅在预定时间长度(例如，10分钟)期间重试的机制。更具体地，在开始事件驱动型计算服务中的处理时，将当前时间点与数据库表所管理的事件发生时间点进行比较。进行控制，使得：如果当前时间点和事件发生时间点之间的差不大于预定时间长度，则正常地进行处理，而如果该差大于预定时间长度，则发出错误通知，并且不进行处理且处理结束。因此，可以防止事件驱动型计算服务连续重试直到从流中删除对象事件为止。

然而，在该机制中，如果在流上连续并且基本上同时发生多个事件、并且如果反复重试先前事件而超过预定时间长度，则出现问题。更具体地，在事件驱动型计算服务获取到后续事件时，将当前时间点与数据库表所管理的事件发生时间点进行比较，并且可以判断为当前时间点和事件发生时间点之间的差已超过预定时间长度。换句话说，后续事件可能被作为错误进行处理，而事件驱动型计算服务一次也不尝试通过对后续事件执行程序代码所要进行的处理。

发明内容

根据本发明的实施例，一种处理系统，其被配置为在第一时间长度期间管理响应于对数据库进行的多个改变而发出的多个事件，并且响应于所述多个事件而执行与所述多个改变中的各个改变相对应的代码，以按时间顺序处理所述多个事件，所述处理系统包括：重试部件，其被配置为如果在当前时间点和发生处理对象事件的时间点之间的差不大于第二时间长度的情况下作为对所述处理对象事件的事件处理而开始的第一事件处理没有正常结束，则进行控制以重试该事件处理，所述第二时间长度短于所述第一时间长度；以及第一通知部件，其被配置为如果在当前时间点和发生所述处理对象事件的时间点之间的差大于所述第二时间长度的情况下作为对所述处理对象事件的事件处理而开始的第二事件处理没有正常结束，则执行用于该事件处理的失败通知的处理。

根据本发明的实施例，一种处理系统，其被配置为在第一时间长度期间管理响应于对数据库进行的多个改变而发出的多个事件，并且响应于所述多个事件而执行与所述多个改变中的各个改变相对应的代码，以处理所述多个事件，所述处理系统包括：通知部件，其被配置为响应于所发出的事件，向第一消息传递服务通知所发出的事件；以及处理部件，其被配置为响应于来自第一消息传递服务的事件通知，控制对所发出的事件的事件处理，其中，在所述事件处理由于发生例外或超时而结束的情况下，执行所述事件处理的重试，以及其中，在所述事件处理由于发生例外或超时而结束、并且重试次数大于预定次数的情况下，执行用于所发出的事件的事件处理的失败通知的处理。

根据本发明的实施例，一种处理系统中的方法，所述处理系统被配置为在第一时间长度期间管理响应于对数据库进行的多个改变而发出的多个事件，并且响应于所述多个事件而执行与所述多个改变中的各个改变相对应的代码，以按时间顺序处理所述多个事件，所述方法包括：如果在当前时间点和发生处理对象事件的时间点之间的差不大于第二时间长度的情况下作为对所述处理对象事件的事件处理而开始的第一事件处理没有正常结束，则进行控制以重试该事件处理，所述第二时间长度短于所述第一时间长度；以及如果在当前时间点和发生所述处理对象事件的时间点之间的差大于所述第二时间长度的情况下作为对所述处理对象事件的事件处理而开始的第二事件处理没有正常结束，则执行用于该事件处理的失败通知的处理。

根据本发明的实施例，一种处理系统中的方法，所述处理系统被配置为在第一时间长度期间管理响应于对数据库进行的多个改变而发出的多个事件，并且响应于所述多个事件而执行与所述多个改变中的各个改变相对应的代码，以处理所述多个事件，所述方法包括：响应于所发出的事件，向第一消息传递服务通知所发出的事件；以及响应于来自第一消息传递服务的事件通知，控制对所发出的事件的事件处理，其中，在所述事件处理由于发生例外或超时而结束的情况下，执行所述事件处理的重试，以及其中，在所述事件处理由于发生例外或超时而结束、并且重试次数大于预定次数的情况下，执行用于所发出的事件的事件处理的失败通知的处理。

通过以下参考附图对典型实施例的说明，本发明的更多特征将变得明显。

附图说明

图1是示出事件驱动型计算服务的系统结构的框图。

图2A是示出客户端设备的硬件结构的框图，并且图2B是示出事件驱动处理系统的硬件结构的框图。

图3是示出根据第一典型实施例的事件驱动处理系统的软件结构的框图。

图4是示出发出更新事件的序列的序列图。

图5是示出根据第一典型实施例的事件驱动处理系统所进行的事件处理的示例的序列图。

图6A是示出根据第一典型实施例的处理的流程的流程图。

图6B1和6B2是示出根据第一典型实施例的处理的流程的流程图。

图7是示出根据第二典型实施例的事件驱动处理系统的软件结构的框图。

图8是示出根据第二典型实施例的事件驱动处理系统所进行的事件处理的示例的序列图。

图9是示出根据第二典型实施例的处理的流程的流程图。

图10是示出根据第三典型实施例的事件驱动处理系统的软件结构的框图。

图11是示出根据第三典型实施例的事件驱动处理系统所进行的事件处理的示例的序列图。

具体实施方式

以下将参考附图来说明本发明的各种典型实施例。

图1示出根据典型实施例的事件驱动型计算服务的系统结构(网络结构)。

客户端设备100经由网络101与事件驱动处理系统102进行通信。客户端设备100的示例包括诸如个人计算机、膝上型计算机、平板计算机和智能电话等的计算机。其它示例包括诸如办公多功能外设和打印机等的图像处理设备。

网络101是诸如因特网等的网络。

事件驱动处理系统102是包括诸如服务器等的信息处理设备的信息处理系统，并且提供事件驱动型计算服务。后面将说明事件驱动处理系统102的详情。

图2A示出客户端设备100的硬件结构。

中央处理单元(CPU)200执行从随机存取存储器(RAM)201、只读存储器(ROM)202或二级存储设备206读取的程序。

RAM 201是存临时储区域。ROM 202记录内置的程序和数据。

网络接口(I/F)203是用于连接至诸如局域网(LAN)等的网络以与其它计算机或网络装置进行通信的网络接口。通信可以是有线或无线通信。

输入/输出I/F 205是用于经由显示器、键盘、鼠标、触摸面板和按钮来输入和输出信息和信号的输入/输出接口。在不包括这些硬件组件的计算机的情况下，可以使用远程桌面或远程外壳从其它计算机连接和操作该计算机。

二级存储设备206是以硬盘驱动器(HDD)和闪速存储器为例的存储设备。

上述的硬件组件经由系统总线204连接。在本典型实施例中，除非另外指定，否则系统总线204将来自CPU 200的控制指示发送到连接至系统总线204的硬件组件。

图2B示出事件驱动处理系统102中所包括的服务器的硬件结构。

CPU 207执行从RAM 208、ROM 209或二级存储设备212读取的程序。

RAM 208是临时存储区域。ROM 209记录内置的程序和数据。

网络I/F 210是用于连接至诸如LAN等的网络以与其它计算机或网络装置进行通信的网络接口。通信可以是有线或无线通信。

二级存储设备212是以HDD和闪速存储器为例的存储设备。

上述的硬件组件经由系统总线211连接。在本典型实施例中，除非另外指定，否则系统总线211将来自CPU 207的控制指示发送到连接至系统总线211的硬件组件。

事件驱动处理系统102中所包括的服务器被提供为云计算服务。图2B所示的各个硬件组件的功能由虚拟机软件实现为应用软件，并且与物理硬件元件同样地表现。

图3是示出根据第一典型实施例的事件驱动处理系统102的软件结构(功能结构)的框图。

在事件驱动处理系统102中，基于来自客户端设备100的请求，数据库表300响应于对在数据库表300中管理的项进行的改变(例如，创建、更新、删除)而发出流事件。更新事件存储单元301存储数据库表300所发出的流事件。在第一典型实施例中，术语“流事件”是指表示数据库表300的更新的事件。

如后面所述，错误消息传递服务302在用于执行程序代码的处理由于诸如例外或超时等的异常而异常结束的情况下，从事件处理服务303的事件发送单元307接收到流事件。然后，错误消息传递服务302将错误消息发送至预先登记的目的地。

事件处理服务303对更新事件存储单元301进行轮询，并且如果存在未处理的流事件，则事件处理服务303处理该未处理的流事件。

事件处理服务303无需服务器规定或管理，并且通过被配置为使用由系统为预定事件分配的资源而执行程序代码的机制来实现。

在事件处理开始时，事件处理服务303的经过时间判断单元304首先确定执行状态。这里的执行状态包括正常执行状态和准备终止执行状态这两个类型。

在正常执行状态下，如果发生流事件，则事件处理服务303的处理执行单元305执行所登记的程序代码。在执行程序代码时发生例外的情况下，或者在经过时间超过容许范围(预定时间长度)、即发生超时的情况下，如果程序代码在执行中，则事件处理服务303取消程序代码的执行。然后，在经过时间判断单元304判断为经过了预定时间长度之后，事件处理服务303重试执行程序代码，直到经过了预先定义的预定时间段为止。

在准备终止执行状态下，事件处理服务303的处理执行单元305执行程序代码，同时事件处理服务303的时间管理单元306对经过时间进行计数。在执行程序代码时发生例外或超时的情况下，如果程序代码在执行中，则事件处理服务303结束用于执行程序代码的处理。然后，事件处理服务303将流事件从事件发送单元307发送至错误消息传递服务302。

图4是示出用于发出关于数据库表300的更新事件的处理的序列图。

首先，在步骤S400中，客户端设备100指示事件驱动处理系统102的数据库表300更新数据库表300。数据库表300的示例包括保持与作为客户端设备100的计算机的状况有关的信息和与作为客户端设备100的图像处理设备的消耗品有关的信息的数据库。另外，表更新的示例包括新记录的登记和现有记录的更新或删除。

然后，在步骤S401中，数据库表300将表更新的内容作为流事件在更新事件存储单元301上发出。这里，表的更新事件是以诸如JavaScript对象表示法(JSON)等的数据描述语言编写的。

在该序列中客户端设备100所执行的程序是从RAM 201、ROM 202或二级存储设备206读取并由CPU 200执行的。此外，与数据库表300有关的程序是从RAM 208、ROM 209或二级存储设备212读取并由CPU 207执行的。

以下将以JSON格式描述数据库表更新事件的示例。该示例描述将具有主键“101”的记录的“status(状况)”值从“STARTED(开始)”更新为“SUCCEEDED(成功)”的事件。

图5是示出包括事件驱动处理系统102所进行的事件处理的整个处理的示例的序列图。

首先，在步骤S500中，事件处理服务303对更新事件存储单元301进行轮询以获取流事件。这里的流事件是用于更新数据库表的事件。更新事件存储单元301可以管理多个流事件，并且在该示例中，将这多个流事件按时间顺序发送至事件处理服务303。更新事件存储单元301仅在预定时间段期间管理各个流事件。超过该时间段的流事件由更新事件存储单元301删除。所删除的流事件未被发送至事件处理服务303。

另一方面，事件处理服务303的经过时间判断单元304使用当前时间点来计算从流事件的发生起的经过时间，并且基于该经过时间是否短于预先定义的预定时间长度来确定执行状态。

如上所述，执行状态具有两个类型，并且第一执行状态是正常执行状态。

在正常执行状态的情况下，首先，在步骤S501中，事件处理服务303的处理执行单元305执行与所获取到的流事件相关联地预先登记的程序代码。因此，执行事件处理。

如果程序代码的执行正常结束，则事件处理服务303的处理结束。另一方面，如果程序代码的执行由于例外或超时的发生而结束，则在步骤S502中，对相同的流事件再次执行程序代码，直到经过了预先定义的预定时间段为止。

在再次执行程序代码的情况下，如果从流事件的发生起的经过时间超过预定时间长度，则事件处理服务303在作为第二执行状态的准备终止执行状态下进行处理。

在准备终止执行状态的情况下，在步骤S503中，事件处理服务303建立第二线程(多线程处理)。在第一线程中，处理执行单元305执行与步骤S500中所获取到的流事件相关联地预先登记的上述程序代码。在第二线程中，时间管理单元306对从在第一线程中执行的程序代码的执行开始起的经过时间进行计数。

此时，预先定义直到在程序代码的执行期间发生超时为止的时间长度和足够长到输出错误的时间长度之间的差的时间长度(以下称为“超时估计时间”)。例如，在直到发生超时为止的时间长度是5分钟并且1分钟足够长到输出错误的情况下，超时估计时间是4分钟。

如果第一线程中的对象流事件的事件处理正常结束，则事件处理服务303的处理结束。

另一方面，如果第一线程中的事件处理不是正常结束、而是由于例外的发生而结束，则在步骤S504中，事件发送单元307将流事件发送至错误消息传递服务302。然后，事件处理服务303的处理结束。

如果在第一线程中的程序代码的执行正常结束或者由于例外的发生而结束之前、在第二线程中经过了超时估计时间，则事件处理服务303在该时间点取消第一线程中的程序代码的执行。然后，在步骤S504中，事件发送单元307将流事件发送至错误消息传递服务302。然后，事件处理服务303的处理结束。

将错误通知目的地作为目的地预先登记在错误消息传递服务302中。错误通知目的地例如是开发人员的电子邮件地址、聊天服务或项目管理工具。

在连续发生流事件的情况下，如果执行状态是正常执行状态，则在步骤S501中处理先前流事件，并且在先前流事件正常结束之后，再次执行步骤S500以处理后续流事件。

存在如下的情况：在步骤S504中先前流事件的处理结束、之后在步骤S500中获取到后续流事件时，从该事件的发生起的经过时间已超过预定时间长度。在这种情况下，跳过步骤S501和S502的正常处理，并且从一开始在准备终止执行状态下处理后续流事件。

该序列中的事件处理服务303的处理执行单元305无需服务器规定或管理，并且通过被配置为使用由系统为预定事件分配的资源而执行程序代码的机制来实现。

图6A、6B1和6B2是示出在图5所示的序列中事件处理服务303所进行的处理的详情的流程图。这些流程图所示的处理的开始由流事件的发生触发。

在图6A的流程图的步骤S600中，在执行程序代码时，事件处理服务303的经过时间判断单元304首先确认当前时间点和事件发生时间点之间的差。

在步骤S600中，如果当前时间点与发生处理对象事件的时间点之间的差小于预先定义的预定时间长度(步骤S600中为“否”)，则在步骤S601中，处理执行单元305执行与该对象事件相对应的程序代码，以处理该对象事件。步骤S600的判断中所使用的“预定时间长度”短于更新事件存储单元301管理各个流事件、直到该流事件被删除为止的预定时间段。

然后，在步骤S602中，处理执行单元305确认处理是否完成。

如果处理未完成(步骤S602中为“否”)，则在步骤S603中，经过时间判断单元304判断在处理完成之前是否发生超时(例如，五分钟)。

如果发生了超时(步骤S603中为“是”)，则经过时间判断单元304从步骤S600的条件判断起重试处理。

另一方面，如果在发生超时之前处理结束(步骤S602中为“是”)，则在步骤S604中，处理执行单元305判断处理是否成功。

如果处理成功(步骤S604中为“是”)，则事件处理服务303所进行的处理结束。另一方面，如果处理不成功(例如，由于例外而结束)(步骤S604中为“否”)，则经过时间判断单元304从步骤S600的条件判断起重试处理。

如果经过时间判断单元304所确认的当前时间点和事件发生时间点之间的差大于或等于预定时间长度(例如，1小时或更长)(步骤S600中为“是”)，则在步骤S605中，处理执行单元305生成新的线程(第二线程)。在步骤S600中经过时间判断单元304判断为差大于或等于预定时间长度(步骤S600中为“是”)的情况其中之一是如下的情况：根据步骤S603或步骤S604的判断结果来针对一个流事件多次重试处理。在步骤S600中经过时间判断单元304判断为差大于或等于预定时间长度(步骤S600中为“是”)的其它情况是如下的情况：连续且基本上同时发生多个流事件，并且在获取到后续事件时已重试了多次先前事件的处理。在后者情况下，处理有时在不执行步骤S601的情况下进入步骤S605。然后，在步骤S612中，开始图6B1和6B2所示的多线程处理。

图6B1是示出在第一线程中执行的处理的流程图。在步骤S606中，与步骤S601一样，处理执行单元305执行与流事件相对应的程序代码并且执行事件处理。

图6B2是示出与在第一线程中执行的处理同时执行的并且在步骤S605中生成的第二线程中执行的处理的流程图。在步骤S610中，时间管理单元306对从线程的生成起的经过时间进行计数。

首先，以下将说明图6B2所示的第二线程中的处理。

如果在步骤S610中开始计数的从线程的生成起的经过时间达到超时估计时间(例如，四分钟)，则在该时间点，在步骤S611中，处理执行单元305取消在步骤S606中开始的程序代码的执行。由于超时估计时间是与一个事件处理相对应的时间长度，因此超时估计时间通常被定义为比步骤S600中的预定时间长度短的时间。

然后，在步骤S612中，事件发送单元307将流事件发送至错误消息传递服务302。

因而，事件处理服务303的处理结束。

接着，以下将说明图6B1所示的第一线程中的处理。

如果在图6B2中的从线程的生成起的经过时间达到超时估计时间之前、步骤S606中的通过执行程序代码所开始的事件处理完成，则在步骤S607中，时间管理单元306取消经过时间的计数。

然后，在步骤S608中，处理执行单元305判断通过执行程序代码所进行的事件处理是否成功。如果处理成功(步骤S608中为“是”)，则事件处理服务303所进行的处理结束。

另一方面，如果事件处理不成功(步骤S608中为“否”)，则在步骤S609中，事件发送单元307在该时间点将流事件发送至错误消息传递服务302。在这种情况下，与图6A所示的处理不一样，不重试事件处理。随后，事件处理服务303所进行的处理结束。

如上所述，根据第一典型实施例，在发生流事件之后经过了预先定义的预定时间长度的情况下，执行状态改变为准备终止执行状态，使得限制事件处理的重试。这防止了由于更新事件存储单元301反复重试流事件直到该流事件被自动删除为止而导致处理长时间停滞。

根据第一典型实施例，即使在连续发生流事件并且多次重试先前流事件的情况下，也确保了对后续流事件进行至少一次处理。

根据第一典型实施例，由于更新事件存储单元301自动删除流事件，因此没有发生流事件的重试的取消，由此经由错误消息传递服务302可靠地发出事件处理的失败通知。

接着，以下将主要关于与第一典型实施例的不同之处来说明第二典型实施例。

图7是示出根据第二典型实施例的事件驱动处理系统102的软件结构(功能结构)的框图。

根据第一典型实施例，事件处理服务303在事件驱动处理系统102中执行处理。另一方面，根据第二典型实施例，包括事件转换单元701的事件传送服务700、包括处理执行单元706的事件处理服务705、事件消息传递服务703和错误通知队列704执行处理。

事件传送服务700和事件处理服务705无需服务器规定或管理，并且通过被配置为使用由系统为预定事件分配的资源而执行程序代码的机制来实现。

图8是示出根据第二典型实施例的事件驱动处理系统102所进行的事件处理的示例的序列图。

根据第二典型实施例，在步骤S800中，事件传送服务700进行轮询以获取流事件。与第一典型实施例相同，这里的流事件是指数据库表更新事件。

然后，如果流事件是批处理事件，则事件传送服务700将流事件分割成个体事件。此时，在步骤S801中，事件转换单元701对事件的格式进行转换以用于后续处理。也可以跳过事件转换处理。

然后，在步骤S802中，事件传送服务700的事件发送单元702将处理后的事件传送至事件消息传递服务703。

在步骤S803中，为了进行事件通知，事件消息传递服务703向事件处理服务705通知从事件传送服务700传送来的事件。将事件处理服务705作为目的地预先登记在事件消息传递服务703中。如果从事件传送服务700传送了多个事件，则事件消息传递服务703将这多个事件按传送这多个事件的顺序通知到事件处理服务705。

在步骤S804中，事件处理服务705响应于来自事件消息传递服务703的通知而执行与流事件相关联地预先登记的程序代码。

如果在发生超时之前处理正常结束，则事件处理服务705的处理结束。

从事件消息传递服务703向事件处理服务705的通知是按传送事件的顺序进行的。然而，在步骤S804的处理中，在顺次执行连续通知的事件的程序代码并且同时执行事件处理时，后续事件的事件处理完成的定时可以在先前事件的事件处理完成的定时之前。

另一方面，如果基于程序代码的执行的事件处理由于例外或超时的发生而结束，则在步骤S805中，事件处理服务705重试事件处理，直到重试次数达到预先定义的预定次数为止。

如果不成功重试的次数已超过预定次数，则在该时间点，在步骤S806中，事件处理服务705将流事件发送至错误通知队列704。然后，事件处理服务705的处理结束。

然后，在步骤S807中，队列704将流事件发送至被登记为目的地的错误消息传递服务302。

图9是示出在图8所示的序列中事件处理服务705所进行的处理的详情的流程图。

首先，在步骤S900中，事件处理服务705中的处理执行单元706从事件消息传递服务703接收与流事件有关的通知。

然后，在步骤S901中，响应于来自事件消息传递服务703的通知，处理执行单元706通过执行与流事件相关联地预先登记的程序代码来控制事件处理的执行。

然后，在步骤S902中，处理执行单元706确认事件处理是否完成。

如果事件处理完成(步骤S902中为“是”)，则在步骤S904中，处理执行单元706确认处理是否成功。如果处理成功(步骤S904中为“是”)，则事件处理服务705的处理结束。

另一方面，如果事件处理未完成(步骤S902中为“否”)，则在步骤S903中，处理执行单元706确认是否发生超时。如果没有发生超时(步骤S903中为“否”)，则处理返回到步骤S902。

如果事件处理由于例外的发生而结束(步骤S904中为“否”)、或者如果发生了超时(步骤S903中为“是”)，则在步骤S905中，处理执行单元706判断在由于例外或超时而导致的结束的情况下执行的重试次数是否超过预先定义的预定次数。

如果重试次数未超过预定次数(步骤S905中为“否”)，则在步骤S901中，处理执行单元706再次执行程序代码以重试事件处理。

另一方面，如果重试次数超过预定次数(步骤S905中为“是”)，则在步骤S906中，事件发送单元707向错误通知队列704通知流事件。

因而，事件处理服务705的处理结束。

如上所述，根据第二典型实施例，经由事件消息传递服务703基于消息来激活事件驱动型计算服务。如果在不成功事件处理的情况下执行的重试次数超过所定义的预定次数，则将流事件作为错误消息发送至队列704。

因此，在事件驱动型计算服务处理来自数据库的流事件的情况下，无需在开发者侧管理重试次数，如果失败次数达到预定次数则提供错误通知，而同时防止了处理停滞。

接着，以下将主要关于与第一典型实施例和第二典型实施例的不同之处来说明第三典型实施例。

图10是示出根据第三典型实施例的事件驱动处理系统102的软件结构(功能结构)的框图。

根据第三典型实施例的事件驱动处理系统102组合地包括图3所示的根据第一典型实施例的处理系统(“第一系统1004”)的功能结构和图7所示的根据第二典型实施例的处理系统(“第二系统1005”)的功能结构。

与根据第一典型实施例的事件处理服务303相对应的事件处理服务1000还包括处理执行判断单元1001，该处理执行判断单元1001被配置为判断是否要执行所轮询的流事件。此外，与根据第二典型实施例的事件传送服务700相对应的事件传送服务1002还包括处理执行判断单元1003。

事件处理服务1000和事件传送服务1002无需服务器规定或管理，并且通过被配置为使用由系统为预定事件分配的资源而执行程序代码的机制来实现。

由于根据第三典型实施例的事件驱动处理系统102是根据第一典型实施例的第一系统1004和根据第二典型实施例的第二系统1005的组合，因此事件驱动处理系统102也可被称为“混合处理系统”。

在第三典型实施例中，组合使用根据第一典型实施例和第二典型实施例的系统1004和1005，使得可以享受这两个系统的优点。

在第三典型实施例中，各流事件类型与这些处理系统其中之一(即，第一系统1004或第二系统1005)相关联，并且被登记在事件识别映射中。然后，根据流事件类型来选择第一系统1004或第二系统1005。

更具体地，针对需要特别是基于在基本上实时地管理事件的情况下登记事件的顺序来严格维持事件的顺序的流事件类型，选择第一系统1004。在第二系统1005中，在一定程度上维持处理顺序，并且在频繁地发生许多事件的情况下，对所有事件执行事件处理所需的时间与第一系统1004中的该时间相比相对较短。管理员可以选择这些处理系统中的适合于事件类型的任一处理系统。

图11是示出根据第三典型实施例的事件驱动处理系统102所进行的事件处理的示例的序列图。

首先，在步骤S1100中，第一系统1004的事件处理服务1000对更新事件存储单元301进行轮询以获取流事件。然后，在步骤S1101中，第二系统1005的事件传送服务1002对更新事件存储单元301进行轮询以获取流事件。与第一典型实施例和第二典型实施例一样，这里的流事件是指数据库表更新事件。

接着，在步骤S1102中，事件处理服务1000参考事件识别映射并判断是否执行程序代码。此外，在步骤S1103中，事件传送服务1002也参考事件识别映射并判断是否执行程序代码。

这里的事件识别映射是指将各流事件类型预先与要执行的第一系统1004或第二系统1005相关联地记录的映射。事件识别映射可在外部被保持为采用JSON格式的文件，或者可被直接写入程序。

如果所接收到的流事件的类型与第一系统1004相关联，则第一系统1004的事件处理服务1000进行图5的序列所示的步骤S501和后续步骤。第二系统1005的事件传送服务1002不进行处理，并且处理结束。

另一方面，如果所接收到的流事件的类型与第二系统1005相关联，则第一系统1004的事件处理服务1000不进行处理，并且处理结束。第二系统1005的事件传送服务1002进行图8的序列图所示的步骤S801和后续步骤。

该序列中的事件处理服务1000和事件传送服务1002无需服务器规定或管理。事件处理服务1000和事件传送服务1002通过被配置为使用由系统为预定事件分配的资源而执行程序代码的机制来实现。

由于与流事件相对应的程序代码的执行不具有幂等性，因而与第一系统1004相关联的流事件的示例是图像形成设备中的纸张的计数器值相加事件。在这种情况下，如果程序代码的执行多于一次，则在要相加的计数值中发生错误。

以下将采用JSON格式描述计数器值相加事件的示例。这是在使用具有租户ID“1000BA”和装置ID“200-aaa”的装置在再生纸上进行单色打印的情况下的计数器值相加事件的示例。

此外，不必维持顺序的具有幂等性的程序代码的执行的示例是如下的处理：响应于装置的备份成功事件，删除数据库表中所登记的除预定数量的最近备份记录以外的备份记录。在这种情况下，即使顺序改变或者程序代码的执行多于一次，最终剩余的备份记录的数量也相同，使得不太可能发生缺陷。

以下将采用JSON格式描述备份成功事件的示例。这是将具有与租户ID“1000BA”相关联的备份ID“1111-2345”的备份的状况从“STARTED”更新为“SUCCEEDED”的事件的示例。

其它实施例

本发明的实施例还可以通过如下的方法来实现，即，通过网络或者各种存储介质将执行上述实施例的功能的软件(程序)提供给系统或装置，该系统或装置的计算机或是中央处理单元(CPU)、微处理单元(MPU)读出并执行程序的方法。

尽管本发明包括典型实施例，但是应该理解，本发明不限于所公开的典型实施例。所附权利要求书的范围符合最宽的解释，以包含所有这类修改、等同结构和功能。

Claims (7)

1.一种处理系统，其被配置为在第一时间长度期间管理响应于对数据库进行的多个改变而发出的多个事件，并且响应于所述多个事件而执行与所述多个改变中的各个改变相对应的代码，以按时间顺序处理所述多个事件，所述处理系统包括：

重试部件，其被配置为如果在当前时间点和发生处理对象事件的时间点之间的差不大于第二时间长度的情况下作为对所述处理对象事件的事件处理而开始的第一事件处理没有正常结束，则进行控制以重试该事件处理，所述第二时间长度短于所述第一时间长度；以及

第一通知部件，其被配置为如果在当前时间点和发生所述处理对象事件的时间点之间的差大于所述第二时间长度的情况下作为对所述处理对象事件的事件处理而开始的第二事件处理没有正常结束，则执行用于该事件处理的失败通知的处理。

2.根据权利要求1所述的处理系统，还包括：

生成部件，其被配置为在当前时间点和发生所述处理对象事件的时间点之间的差大于所述第二时间长度的情况下，生成与用于执行所述第二事件处理的第一线程不同的第二线程；

取消部件，其被配置为在所生成的第二线程中进行控制，以在判断为仅经过了第三时间长度的情况下取消所述第二事件处理；以及

第二通知部件，其被配置为在所生成的第二线程中，在所述第二事件处理被取消的情况下，执行用于失败通知的处理，

其中，所述第一通知部件被配置为在所述第一线程中执行用于失败通知的处理。

3.根据权利要求2所述的处理系统，其中，所述第三时间长度短于所述第二时间长度。

4.一种处理系统，其被配置为在第一时间长度期间管理响应于对数据库进行的多个改变而发出的多个事件，并且响应于所述多个事件而执行与所述多个改变中的各个改变相对应的代码，以处理所述多个事件，所述处理系统包括：

通知部件，其被配置为响应于所发出的事件，向第一消息传递服务通知所发出的事件；以及

处理部件，其被配置为响应于来自第一消息传递服务的事件通知，控制对所发出的事件的事件处理，

其中，在所述事件处理由于发生例外或超时而结束的情况下，执行所述事件处理的重试，以及

其中，在所述事件处理由于发生例外或超时而结束、并且重试次数大于预定次数的情况下，执行用于所发出的事件的事件处理的失败通知的处理。

5.根据权利要求4所述的处理系统，其中，在用于所述事件处理的失败通知的处理中，经由队列向第二消息传递服务通知处理失败的事件。

6.一种处理系统中的方法，所述处理系统被配置为在第一时间长度期间管理响应于对数据库进行的多个改变而发出的多个事件，并且响应于所述多个事件而执行与所述多个改变中的各个改变相对应的代码，以按时间顺序处理所述多个事件，所述方法包括：

如果在当前时间点和发生处理对象事件的时间点之间的差不大于第二时间长度的情况下作为对所述处理对象事件的事件处理而开始的第一事件处理没有正常结束，则进行控制以重试该事件处理，所述第二时间长度短于所述第一时间长度；以及

如果在当前时间点和发生所述处理对象事件的时间点之间的差大于所述第二时间长度的情况下作为对所述处理对象事件的事件处理而开始的第二事件处理没有正常结束，则执行用于该事件处理的失败通知的处理。

7.一种处理系统中的方法，所述处理系统被配置为在第一时间长度期间管理响应于对数据库进行的多个改变而发出的多个事件，并且响应于所述多个事件而执行与所述多个改变中的各个改变相对应的代码，以处理所述多个事件，所述方法包括：

响应于所发出的事件，向第一消息传递服务通知所发出的事件；以及

响应于来自第一消息传递服务的事件通知，控制对所发出的事件的事件处理，

其中，在所述事件处理由于发生例外或超时而结束的情况下，执行所述事件处理的重试，以及

其中，在所述事件处理由于发生例外或超时而结束、并且重试次数大于预定次数的情况下，执行用于所发出的事件的事件处理的失败通知的处理。

Images