CN105243001B

CN105243001B - 业务对象的异常告警方法和装置

Info

Publication number: CN105243001B
Application number: CN201410321380.9A
Authority: CN
Inventors: 张凯隆; 温腾云; 章天锋
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2014-07-07
Filing date: 2014-07-07
Publication date: 2018-05-01
Anticipated expiration: 2034-07-07
Also published as: CN105243001A; HK1217128A1

Abstract

本申请实施例提供了一种业务对象的异常告警方法和装置，包括：在相邻两个基准时间之间的计算周期中，接收中间件发送的业务对象调整事件；所述业务对象调整事件在客户端进行业务对象调整操作时生成；根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量；所述基准存储数值为当前基准时间的业务对象数量，所述累积业务对象调整数量为在所述计算周期中所累积的业务对象调整总数量；当所述基准业务对象数量小于所述累积业务对象调整数量时，判断由所述业务对象调整操作造成异常状态；执行所述异常状态对应的告警操作。本发明实施例实现了在海量数据下异常状态的实时监控，减少了人工处理，降低了人力成本，有效降低了用户损失。

Description

业务对象的异常告警方法和装置

技术领域

本申请涉及监控的技术领域，特别是涉及一种业务对象的异常告警方法和一种业务对象的异常告警装置。

背景技术

随着科技的发展与进步，现代社会已经进入了信息化时代，信息化管理已经广泛普及在各行各业。

事件驱动架构(Event Driven Architecture，EDA)是分布式应用程序的普遍架构形式，分布式应用程序都被设计成为模块化的、封装的、可共享事件服务的组件。

在EDA系统中各组件以异步方式响应事件，在本质上是可以并行的，具有并发执行、事件触发/数据触发/时间规则触发、实时/增量响应、分布式事件系统处理等特点，因而在应用中具有极大的优势。

由于EDA系统的上述特点，因此，在金融贸易、能源贸易、电信以及欺诈检测等行业中，普遍采用事件驱动架构技术。例如，利用EDA系统的分布式处理架构的优势构建共享交换平台，实现跨部门、跨平台、跨应用系统的信息资源的共享与交换，并对不同部门之间的业务协同工作提供支撑和保障。

但正是由于EDA系统以异步方式响应事件，容易出现异常状态。而在出现异常状态时，通常有两种方法进行处理。

一种方法是通过线下用户反馈异常状态，由技术人员协助确认。但是，这种方法反馈并由技术人员介入排查的方案完全基于人工处理，效率非常低下且结果并不精准，容易出错。

另一种方法通过诸如分布式系统基础架构Hadoop等技术手段，采取事后离线计算的方式计算。虽然离线计算的方式一定程度上减少了人为分析的介入，但是有个较大的缺点，当计算海量数据时，需要延后较长时间(一般为一个自然日)才能获得分析结果。

上述两种方法都是基于被动发现并反馈的机制，对异常状态只是在异常状态发生了，事后人为反馈或者统计异常状态数据，用户损失十分之大。因此，目前需要本领域技术人员迫切解决的一个技术问题就是：如何提出一种业务对象的异常告警机制，在海量数据下实现实时处理，以减少用户损失。

发明内容

本申请实施例所要解决的技术问题是提供一种业务对象的异常告警方法，在海量数据下实现实时处理，以减少用户损失。

相应的，本申请实施例还提供了一种业务对象的异常告警装置，用以保证上述方法的实现及应用。

为了解决上述问题，本申请实施例公开了一种业务对象的异常告警方法，包括：

在相邻两个基准时间之间的计算周期中，接收中间件发送的业务对象调整事件；所述业务对象调整事件在客户端进行业务对象调整操作时生成；

根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量；所述基准存储数值为当前基准时间的业务对象数量，所述累积业务对象调整数量为在所述计算周期中所累积的业务对象调整总数量；

当所述基准业务对象数量小于所述累积业务对象调整数量时，判断由所述业务对象调整操作造成异常状态；

执行所述异常状态对应的告警操作。

优选地，所述业务对象调整事件包括调整前的业务对象数量、调整时间、调整操作版本号、业务对象标识、第一用户调整数量和第二用户调整数量中的至少一个。

优选地，所述调整时间在当前计算周期中。

优选地，所述根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量的步骤包括：

判断是否存在所述业务对象标识对应的基准业务对象数据；所述基准业务对象数据包括基准业务对象数量、基准调整时间、基准调整操作版本号、业务对象标识、第一用户累积调整数量和第二用户累积调整数量中的至少一个；

若否，则将所述调整前的业务对象数量设置为基准业务对象数量，将所述调整时间设置为基准调整时间，将所述调整操作版本号设置为基准调整操作版本号，写入所述业务对象标识，将所述第一用户调整数量设置为第一用户累积调整数量，将所述第二用户调整数量设置为第二用户累积调整数量；

计算所述第一用户累积调整数量和所述第二用户累积调整数量之和，获得累积业务对象调整数量。

子步骤S21，判断是否存在所述业务对象标识对应的基准业务对象数据；若是，则执行子步骤S22；

所述基准业务对象数据包括基准业务对象数量、基准调整时间、基准调整操作版本号、业务对象标识、第一用户累积调整数量和第二用户累积调整数量中的至少一个；

子步骤S22，判断所述业务对象调整事件是否存在去重记录；若否，则执行子步骤S23；

子步骤S23，判断是否满足第一条件或者第二条件；若是，则执行子步骤S24；若否，则执行子步骤S25；

所述第一条件包括所述基准调整时间为空，或者，所述基准调整操作版本号为空；

所述第二条件包括所述调整时间小于基准调整时间，且，所述调整操作版本号小于或等于所述基准调整操作版本号；

子步骤S24，将所述调整前的业务对象数量设置为基准业务对象数量，将所述调整时间设置为基准调整时间，将所述调整操作版本号设置为基准调整操作版本号；

子步骤S25，将所述第一用户调整数量累积到第一用户累积调整数量中，或者，将所述第二用户调整数量累积到第二用户累积调整数量中；

子步骤S26，计算所述第一用户累积调整数量和所述第二用户累积调整数量之和，获得累积业务对象调整数量。

优选地，所述根据所述库业务对象调整事件计算基准业务对象数量和累积业务对象调整数量的步骤还包括：

增加所述业务对象调整事件对应的去重记录。

优选地，还包括：

当基于新的业务对象调整事件计算出新的基准业务对象数量，且新的基准业务对象数量大于或等于所述累积业务对象调整数量时，判断由所述业务对象操作造成异常状态属于错误判断。

优选地，包括：

执行所述错误判断对应的误报操作。

优选地，还包括：

当所述基准业务对象数量大于或等于所述累积业务对象调整数量时，判断由所述业务对象调整操作未造成异常状态。

优选地，还包括：

当基于新的业务对象调整事件计算出新的基准业务对象数量，且新的基准业务对象数量小于所述累积业务对象调整数量时，判断由所述业务对象调整操作造成异常状态。

本申请实施例还公开了一种业务对象的异常告警装置，包括：

业务对象调整事件接收模块，用于在相邻两个基准时间之间的计算周期中，接收中间件发送的业务对象调整事件；所述业务对象调整事件在客户端进行业务对象调整操作时生成；

基准计算模块，用于根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量；所述基准存储数值为当前基准时间的业务对象数量，所述累积业务对象调整数量为在所述计算周期中所累积的业务对象调整总数量；

第一异常状态判断模块，用于在所述基准业务对象数量小于所述累积业务对象调整数量时，判断由所述业务对象调整操作造成异常状态；

告警模块，用于执行所述异常状态对应的告警操作。

优选地，所述调整时间在当前计算周期中。

优选地，所述基准计算模块包括：

基准判断子模块，用于判断是否存在所述业务对象标识对应的基准业务对象数据；所述基准业务对象数据包括基准业务对象数量、基准调整时间、基准调整操作版本号、业务对象标识、第一用户累积调整数量和第二用户累积调整数量中的至少一个；若否，则调用初始化子模块；

初始化子模块，用于将所述调整前的业务对象数量设置为基准业务对象数量，将所述调整时间设置为基准调整时间，将所述调整操作版本号设置为基准调整操作版本号，写入所述业务对象标识，将所述第一用户调整数量设置为第一用户累积调整数量，将所述第二用户调整数量设置为第二用户累积调整数量；

和计算子模块，用于计算所述第一用户累积调整数量和所述第二用户累积调整数量之和，获得累积业务对象调整数量。

优选地，所述基准计算模块包括：

基准判断子模块，用于判断是否存在所述业务对象标识对应的基准业务对象数据；所述基准业务对象数据包括基准业务对象数量、基准调整时间、基准调整操作版本号、业务对象标识、第一用户累积调整数量和第二用户累积调整数量中的至少一个；若是，则调用去重判断子模块；

去重判断子模块，用于判断所述业务对象调整事件是否存在去重记录；若否，则调用条件判断子模块；

条件判断子模块，用于判断是否满足第一条件或者第二条件；若是，则调用基准调整子模块；若否，则调用数量累积子模块；

基准调整子模块，用于将所述调整前的业务对象数量设置为基准业务对象数量，将所述调整时间设置为基准调整时间，将所述调整操作版本号设置为基准调整操作版本号；

数量累积子模块，用于将所述第一用户调整数量累积到第一用户累积调整数量中，或者，将所述第二用户调整数量累积到第二用户累积调整数量中；

优选地，所述基准计算模块还包括：

去重记录子模块，用于增加所述业务对象调整事件对应的去重记录。

优选地，还包括：

误判判断模块，用于在基于新的业务对象调整事件计算出新的基准业务对象数量，且新的基准业务对象数量大于或等于所述累积业务对象调整数量时，判断由所述业务对象操作造成异常状态属于错误判断。

优选地，还包括：

误报操作执行模块，用于执行所述错误判断对应的误报操作。

优选地，还包括：

非异常状态判断模块，用于在所述基准业务对象数量大于或等于所述累积业务对象调整数量时，判断由所述业务对象调整操作未造成异常状态。

优选地，还包括：

第二异常状态判断模块，用于在基于新的业务对象调整事件计算出新的基准业务对象数量，且新的基准业务对象数量小于所述累积业务对象调整数量时，判断由所述业务对象调整操作造成异常状态。

与背景技术相比，本申请实施例包括以下优点：

在本申请实施例在计算周期中接收中间件发送的业务对象调整事件，基于该业务对象调整事件计算出基准业务对象数量和累积业务对象调整数量，并由此判断是否出现异常状态，实现了在海量数据下异常状态的实时监控，减少了人工处理，降低了人力成本，提高了异常状态的计算效率，同时避免了离线计算，在发现异常状态时可以及时执行告警操作，有效降低了用户损失。

本申请实施例以调整时间作为在哪个计算周期的依据，规范了业务对象调整事件在计算周期临界点应遵循的计算规则，提高了异常状态计算的精确度。

本申请实施例在新的基准业务对象数量大于或等于累积业务对象调整数量时，识别出异常状态的误判，进一步提高了异常状态计算的精确度，减少了误操作的影响。

本申请实施例在新的基准业务对象数量小于累积业务对象调整数量时，识别出在先未计算出的异常状态，进一步提高了异常状态计算的精确度，减少了误操作的影响。

附图说明

图1是本申请的一种业务对象的异常告警方法实施例的步骤流程图；

图2是本申请的一种计算周期的示例图；

图3是本申请的一种溯源计算的示例图；

图4是本申请的一种溯源计算的示例图；

图5A至图5D是本申请的一种业务对象调整事件计算规则的示例图；

图6是本申请的一种业务对象的异常告警装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

在一个有海量数据的网站中，例如，电子商务(Electronic Commerce，EC)网站需要处理海量的商品买卖数据，进行后台系统架构设计时，考虑到扩展性、高并发等原因，一般会选取基于事件驱动架构的设计思路。

事件驱动架构有一个特点：事件投递及处理的异步性。

一个典型的事件驱动系统由事件消费者和事件产生者组成。事件消费者(例如，服务器)向事件管理器(即中间件)订阅事件，事件产生者(例如，客户端)向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。这种事件传送方法在基于事件的系统里就是：储存(store)和转送(forward)。

其中，中间件可以是指利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。中间件可以通过提供消息传递和消息排队模型，在分布式环境下扩展进程间的通信。

中间件实现了应用程序之间的协同，其优点在于，能够在客户和服务器之间提供同步和异步的连接，并且在任何时刻都可以将事件进行传送或者存储转发。

中间件在保证即事件投递及处理顺序方面，有不同的解决方案。一些中间件(例如，metaQ)能够保证事件投递与处理的顺序性，但从性能及存储成本等多方面与不保证事件顺序性的中间件(例如，Notify)有较大的差距。

由于EDA系统以异步方式响应事件，事件投递及处理并不能完全同步，因此，在不同业务领域中的EDA系统中不可避免会出现异常状态。

对于不同业务领域而言，可以具有不同的业务对象，即具有业务领域特征的对象。例如，对于半导体领域而言，业务对象可以包括物料(如硅片)；对于新闻媒体领域而言，业务对象可以包括新闻数据；对于移动通讯领域而言，业务对象可以包括移动通讯数据；对于电子商务领域而言，业务对象可以包括商品。

为使本领域技术人员更好地理解本申请实施例，在本说明书中，将电子商务领域的商品作为业务对象的一种示例进行说明。在此示例中，异常状态可以为超卖，即商品售出量大于商品库存。

库存，可以指仓库中实际储存的商品数量。通常库存可以以最小库存单位SKU进行计算。例如对于某款手机，商品管理中可以将黑色手机和白色手机单独进行管理。

一个商品在其生命周期(即从商品的创建至该商品的删除的时间范围)内，库存将不断发生变化，进行的商品入库或出库意味着该商品库存的增加或减少，反映到电子商务网站上的商品，意味着商品库存数值的增加或减少。

如下介绍超卖发生的典型场景。

超卖一般涉及的主体有三个：买家、卖家、用于交易的平台系统。

买家在电子商务网站进行商品交易时，大致需要经历浏览商品详情页，下单及付款等几个步骤。当买家进行浏览、下单及付款时，平台系统将进行复杂的逻辑计算。对于商品库存来说，“浏览”会进行商品库存数的查询，“下单”及“付款”操作会根据不同的库存扣减方式采取不同的库存计算逻辑。

平台系统采取的库存扣减方式一般有三种：1)、拍下减库存；2)、纯付款减库存；3)、预扣付款减库存。

1)、拍下减库存

在此种库存扣减方式下，买家下单时(即使未付款)，即进行库存扣减。

在一般情况下，拍下减库存方式不会出现库存超卖情况。但是，在系统出现问题时，也是有可能出现商品超卖的。譬如，在某次促销活动时，由于访问流量过大，导致平台系统的网卡出现问题，触发平台系统中的tair缓存系统进行减库存容灾，其中，容灾的目的是在系统出现突发问题时，采取与当前主流程逻辑不同的执行逻辑，以减少突发问题对系统及业务所造成的影响，是保证系统高可用性的一种技术。例如，在数据库db出现严重问题时，譬如宕机，若没有容灾方案，那么扣减库存这一业务逻辑操作在宕机时间段内会操作失败且不可用。

“减库存容灾”指的是，本来扣减库存是直接在数据库db层面进行操作(写或者更新库存数值)的，但是，在数据库db不可用(例如宕机)时，导致扣减库存的操作暂时不可用。于是系统自动进行容灾，容灾后扣减库存操作不是在数据库db上进行，而是基于tair缓存进行库存扣减，便于保证平台系统扣减库存功能的完整性和可用性，这就是“减库存容灾”。

若平台系统采用双机房双数据设计(即在两个不同的机房分别有一份独立的库存数据，例如，10个实际库存在双机房下就有20个库存)，则可能在两个机房同时扣减一份库存时，在tair缓存中会扣减两份库存，导致扣减的库存超过实际库存数量的一倍，可能出现严重的超卖。

并且，此种库存扣减方式容易被买家恶意利用，导致出现“恶拍”现象，即买家大量拍下商品，但不进行付款，导致商品库存一直被扣减至零后，商品做下架处理。这种“恶拍”现象容易被竞争对手(卖家)利用并让卖家承受较大的经济损失。

2)、纯付款减库存

在此种库存扣减方式下，买家下单时可以不进行库存扣减操作，而是在付款后才进行库存扣减。

此种库存扣减方式出现超卖的概率很大，尤其是对于热门商品。

当大量买家下单热门商品，并在相当接近的时间内付款，付款事件由中间件发送给服务器，因此，平台系统并未立即处理付款事件，即扣减库存，因此大量的买家可以付款成功。而在平台系统中进行库存扣减操作时，会有一部分扣减失败，由于付款的商品数已经超过商品库存，因此商品库存已经不够进行扣减。这部分出现“付款成功但无货(库存扣减失败)”商品的情况，即为超卖。

例如，在纯付款减库存方式中，商品库存有5件，买家A下单5件，买家B、C和D各下单2件，买家A、B、C和D按顺序在相当接近的时间内付款，由于服务器并未立即扣减库存，在库存扣减完5个之前，实际可能已被买家A、B、C和D付款10个，那么就出现买家A、B、C和D中某人付款成功，但无库存的情况，即超卖了5件商品。

3)、预扣付款减库存

为了解决“拍下减库存”引起的“恶拍”以及“纯付款减库存”引起的超卖，引入了“预扣付款减库存”的库存扣减方式。

所谓“预扣付款减库存”模式，即买家在下单时，平台系统可以预先对商品库存进行预扣操作，待买家付款后，再将预扣库存转换为实际库存扣减。

而如果买家在下单后30分钟(预扣库存释放超时时间)未进行付款操作，那么下单后进行的预扣库存将会被释放，供其他买家下单。

“预扣付款减库存”的大量应用，使得商品超卖现象得到极大的减少，然而在特殊情况下还是不能避免。

例如，商品库存为100件，共有100个买家下单，每个买家各下单一件，根据“预扣付款减库存”方式，平台系统会先预扣100个库存，假设此时卖家在后台将商品库存调整为90件，那么前90位买家仍可进行正常付款，但当第91个买家进行付款时，由于卖家调整因为实际库存数已编辑为90件，此时预扣库存数无法转换为实际库存数的扣减(否则库存数将小于0)。但是，平台系统中并未处理付款事件，即扣减库存，即剩下的10个买家依然可以成功付款，结果是将有10个买家出现“已付款，但无货”的情况，也即出现了10个库存的超卖。

正如上述所讨论的，该三种库存扣减方式都有可能出现超卖。

因此，提出了本申请实施例的核心构思之一，基于连续较小时间周期内迭代计算业务对象的调整数量，判定是否出现异常状态。

在电子商务领域中，可以确定商品在其生命周期内哪个时间周期内商品库存变化是正常的，哪个时间周期内商品库存变化出现超卖，是一种分而治之的解决思路。

参照图1，其示出了本申请的一种业务对象的异常告警方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，在相邻两个基准时间之间的计算周期中，接收中间件发送的业务对象调整事件；

需要说明的是，本申请实施例可以应用于基于事件驱动架构的系统中，业务对象的操作可以以事件的形式进行通知。

基于分而治之的解决思路，本申请实施例中，可以设置多个基准时间，划分出一个或多个连续的计算周期。

该基准时间可以是一个逻辑时间概念，可以由本领域技术人员根据实际情况进行设定，可以为任意时间，例如，每天0时，本申请实施例对此不加以限制。

例如，如图2所示，T₀、T₁、T₂和T₃为基准时间，在T₀和T₁之间的ΔT₀和在T₁和T₂之间的ΔT₁为计算周期。其中，计算周期ΔT_i可以为[T_i，T_i+1)，i为自然数，即ΔT₀可以为[T₀，T₁)，ΔT₁可以为[T₁，T₂)。

在具体实现中，所述业务对象调整事件可以在客户端进行业务对象调整操作时生成，即在客户端进行业务对象调整操作时，会记录一条对应的业务对象调整事件，该业务对象调整事件可以发送至中间件，中间件再发送给服务器。

在电子商务领域中，业务对象调整事件可以为由库存变更操作行为生成的库存变更事件。

商品库存在任一计算周期内，随着不同的库存操作行为而变化。

库存变更操作行为可以归为两类，一类是卖家(即第一用户)在客户端编辑商品(例如，后台增加、减少商品库存)引起的库存变更(β)；另一类是买家(即第二用户)在客户端编辑商品(例如下单、付款等操作减少商品库存)引起的库存变更(γ)。

在具体实现中，所述业务对象调整事件可以包括调整前的业务对象数量、调整时间、调整操作版本号、业务对象标识、第一用户调整数量和第二用户调整数量中的至少一个。

该业务对象调整事件的数据格式可以如下表所示：

N_msg

change_qty

change_time

change_ver

item_id

Δβ

Δγ

…

其中，N_msg可以表示业务对象调整事件，change_qty可以表示调整前的业务对象数量，change_time可以表示调整时间，change_ver可以表示调整操作版本号，item_id为业务对象标识，Δβ可以表示第一用户调整数量，Δγ可以表示第二用户调整数量。

在实际应用中，对于每一次业务对象的调整操作，可以配置一个唯一的调整操作版本号以标识调整操作，而且，该调整操作版本号可以按顺序递增。例如，上一调整操作版本号为0001，则下一调整操作版本号可以为0002。

第一用户调整数量Δβ可以为第一用户的调整的业务对象的数量，可以是增加，也可以是减少，即可以为正也可以为负；第二用户调整数量Δγ可以为第二用户的调整的业务对象的数量，可以是增加，也可以是减少，即可以为正也可以为负。

在电子商务领域中，业务对象调整事件N_msg可以为库存变更事件，调整前的业务对象数量change_qty可以为变更前的库存数，调整时间change_time可以为变更时间，调整操作版本号change_ver可以为变更操作版本号，业务对象标识item_id可以为商品标识，第一用户调整数量Δβ可以为卖家引起的库存变更数量，第二用户调整数量Δγ可以为买家引起的库存变更数量。

商品库存变更事件可以如下表所示：

N_msg

change_qty

change_time

change_ver

item_id

Δβ

Δγ

…

N_msg1

10

10:00:00

0001

123456

5

…

N_msg2

5

11:00:00

0002

123456

-10

…

其中，商品库存变更事件N_msg1可以表示买家在10:00:00由于下单或者付款而引起ID为123456的商品的库存减少5件，而库存在减少前的数量为10件；商品库存变更事件N_msg2可以表示卖家在11:00:00由于补货等操作而引起ID为123456的商品的库存增加10件，而库存在增加前的数量为5件。

步骤102，根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量；

其中，所述基准业务对象数量可以为当前基准时间的业务对象数量，所述累积业务对象调整数量可以为在所述计算周期中所累积的业务对象调整总数量；

在电子商务领域中，基准业务对象数量可以为基准库存，即当前基准时间的商品库存；累积业务对象调整数量可以为卖家累计变更数β和买家累计变更数γ，即由卖家和买家的变更操作所累计的商品变更数量。

如图2所示，假设在基准时间T₀中，商品A的库存为α，则α可以为计算周期ΔT₀的基准库存(即基准业务对象数量)。

在计算周期ΔT₀内，若商品A的库存变化满足如下公式：

α-(β+γ)<0

即基准库存小于由买家和卖家的库存变更操作行为而减少的库存，则可以认为该商品A在库存计算周期ΔT₀内发生超卖。

在此示例中，β和γ可以以业务对象数量减少时为正，以业务对象数量增加时为负。但是，在其他示例中，β和γ可以以业务对象数量减少时为负，以业务对象增加数量时为正，上述公式做相应的调整即可，本申请实施例对此不加以限制。

本申请实施例中，可以以α-(β+γ)<0作为计算业务对象(例如商品)是否出现异常状态(例如超卖)的判断公式，此公式有几个变量，基准业务对象数量α、累积业务对象调整数量(β+γ)。

因此，需要计算业务对象是否出现异常状态，则需要确定这几个变量。

在电子商务领域中，α可以为商品在计算周期[T_i，T_i+1)内的基准库存，在计算周期[T_i，T_i+1)确定的情况下，α值事实上也是确定的。

然而在基于事件驱动架构的系统中，α值的确定却是一个较大的难点。

因为在事件驱动架构下，事件投递及处理存在异步性，即事件消费者(例如电子商务领域中的平台系统)接收到的事件顺序并不能与事件产生者(例如电子商务领域中的买家和卖家)发送顺序保持一致。

由于事件接收无序，因此每个接收到的业务对象调整事件，都可能是在最接近基准时间发生的事件。

在事件接收无序情况下，为保证计算出计算周期中的首个事件，本申请实施例提出了“溯源计算”的概念，并利用这一概念计算基准业务对象数量α。

假设对于业务对象A，有两个业务对象调整操作引起了数量调整，即C₀:(t₀,q₀,v₀,Δβ₀,Δγ₀)及C₁:(t₁,q₁,v₁,Δβ₁,Δγ₁)。

其中，t_i(i∈[0,1,2,…])为调整时间，q_i(i∈[0,1,2,…])为调整前的业务对象数量，v_i(i∈[0,1,2,…])为调整操作版本号，Δβ_i(i∈[0,1,2,…])为第一用户调整数量；Δγ_i(i∈[0,1,2,…])为第二用户调整数量。

上述两个业务对象调整操作满足如下条件：

t₀≤t₁且v₀<v₁

根据上述条件，在时序上C₀早于C₁发生。按理说，C₀也应该早于C₁进行处理，但在基于事件驱动架构的系统中，由于中间件发送基于该业务对象调整操作生成的业务对象调整事件是无序的，上述论述不一定成立。

在一种场景中：C₀早于C₁处理。

如图3所示，服务器在t₂时刻接收到中间件发送的C₀的业务对象调整事件并处理，在t₃时刻接收到中间件发送的C₁的业务对象调整事件并处理。

因为t₀≤t₁，t₂≤t₃，也即业务对象调整事件发生的顺序与业务对象调整事件处理顺序是一致的。

在先接收的业务对象调整事件(即C₀的业务对象调整事件)更接近基准时间(即图3所示的基准点)，因此可以采用先接收的业务对象调整事件(即C₀的业务对象调整事件)来计算基准业务对象数量，即基于C₀生成的业务对象调整事件所计算出的q₀可以作为基准业务对象数量α。

在另一种场景中：C₁早于C₀处理。

在此场景中，业务对象调整事件发生的顺序与业务对象调整事件的处理顺序是不一致的。

如图4所示，服务器在t₂时刻接收到中间件发送的C₁的业务对象调整事件并处理，在t₃时刻接收到中间件发送的C₂的业务对象调整事件并处理。

当服务器在t₂时刻处理C₁的业务对象调整事件后，可以设定C₁为基准时间的业务对象数据。在t₃时刻处理C₀的业务对象调整事件时，将C₀:(t₀,q₀,v₀,Δβ₀,Δγ₀)与C₁:(t₁,q₁,v₁,Δβ₁,Δγ₁)进行比较，比较发现C₀:(t₀,q₀,v₀,Δβ₀,Δγ₀)更靠近基准时间(即图4所示的基准点)，也即C₀:(t₀,q₀,v₀,Δβ₀,Δγ₀)所对应的业务对象调整事件是早于C₁:(t₁,q₁,v₁,Δβ₁,Δγ₁)所对应的业务对象调整事件发生。在后接收的的业务对象调整事件(即C₀的业务对象调整事件)更接近基准时间(即图4所示的基准点)，可以采用后接收的业务对象调整事件(即C₀的业务对象调整事件)来计算基准业务对象数量，基于C₀所计算出的q₀可以作为基准业务对象数量α。

以上计算模式，可以称之为“溯源计算”，即在有限步骤内确定最接近基准时间的业务对象调整事件，服务器可以根据该业务对象调整事件计算并确定出基准业务对象数量α。

在本申请的一种优选实施例中，步骤102可以包括如下子步骤：

子步骤S11，判断是否存在所述业务对象标识对应的基准业务对象数据；若否，则执行子步骤S12；

子步骤S12，将所述调整前的业务对象数量设置为基准业务对象数量，将所述调整时间设置为基准调整时间，将所述调整操作版本号设置为基准调整操作版本号，写入所述业务对象标识，将所述第一用户调整数量设置为第一用户累积调整数量，将所述第二用户调整数量设置为第二用户累积调整数量；

子步骤S13，计算所述第一用户累积调整数量和所述第二用户累积调整数量之和，获得累积业务对象调整数量。

在具体实现中，基准业务对象数据的数据格式可以如下表所示：

N_msg

change_qty

change_time

change_ver

item_id

Δβ

Δγ

…

R

datum_qty/α

datum_time

datum_ver

item_id

β

γ

…

其中，R可以表示基准业务对象数据，datum_qty可以表示基准业务对象数量α，datum_time可以表示基准调整时间，datum_ver可以表示基准调整操作版本号，item_id可以表示业务对象标识，β可以表示第一用户累积调整数量，γ可以表示第二用户累积调整数量。

第一用户累积调整数量β可以为在当前计算周期中，第一用户的调整所累积的业务对象的数量；第二用户累积调整数量γ可以为在当前计算周期中，第二用户的调整所累积的业务对象的数量。

本申请实施例中，在判断不存在业务对象标识对应的基准业务对象数据时，可以认为当前接收的业务对象调整事件为计算周期中的首个事件，需要对基准业务对象数量、基准调整时间和基准调整操作版本号进行初始化：

R.datum_qty＝N_msg.change_qty

R.datum_time＝N_msg.change_time

R.datum_ver＝N_msg.change_ver

每一个计算周期中都可以有唯一确定的基准时间，也就是说，每一个计算周期中，其基准业务对象数量可以是一个常量。

由异常状态的判断公式α-(β+γ)<0可知，β及γ可以是引起业务对象是否出现异常状态的变量。

假设Δβ是由第一用户(例如卖家)调整业务对象引起的一次业务对象调整数量，β’为调整前的累积的业务对象数量，那么业务对象调整后累积的业务对象数量R.β＝R.β’+N_msg.Δβ。而在本申请实施例中，由于基数业务对象数据不存在，因此β’＝0，即R.β＝N_msg.Δβ。

假设Δγ是由第二用户(例如买家)调整业务对象引起的一次业务对象调整数量，γ’为调整前的累积的业务对象数量，那么业务对象调整后累积的业务对象数量R.γ＝R.γ’+N_msg.Δγ。而在本申请实施例中，由于基数业务对象数据不存在，因此γ’＝0，即R.γ＝N_msg.Δγ。

在本申请实施例中，步骤102还可以包括如下子步骤：

子步骤S14，增加所述业务对象调整事件对应的去重记录。

在根据该业务对象调整事件创建属于当前计算周期内的新的业务对象基准数据R时，可以新增该业务对象调整事件对应的去重记录，可以记录在去重记录表格中，表示服务器已经处理过该业务对象调整事件。

在本申请的另一种优选实施例中，步骤102可以包括如下子步骤：

其中，所述基准业务对象数据可以包括基准业务对象数量、基准调整时间、基准调整操作版本号、业务对象标识、第一用户累积调整数量和第二用户累积调整数量中的至少一个；

在具体实现中，可以在去重表格中业务中查找该业务对象调整事件，若未查找到，则可以表示该业务对象调整事件不存在去重记录，可以认为该业务对象调整事件未被处理。

其中，所述第一条件可以包括所述基准调整时间为空，或者，所述基准调整操作版本号为空；

所述第二条件可以包括所述调整时间小于基准调整时间，且，所述调整操作版本号小于或等于所述基准调整操作版本号；

在第一条件中，基准业务对象数据存在，但尚未确定基准业务对象数量、基准调整时间及基准调整操作版本号：

R.datum_ver＝＝0&&R.datum_time＝＝null

在第二条件中，基准业务对象数据存在，且调整时间小于基准调整时间，且，调整操作版本号小于或等于基准调整操作版本号：

N_msg.change_time.before(R.datum_time)且N_msg.change_ver<＝R.datum_ver

符合第一条件或第二条件的业务对象调整事件更接近基准时间，可以用于计算基准业务对象数量α。

对于不符合第一条件或第二条件的业务对象调整事件，即调整时间大于基准调整时间，且，调整操作版本号大于基准调整操作版本号：

N_msg.change_time.after(R.datum_time)且N_msg.change_ver>R.datum_ver

此种情况下，基准业务对象数据更加接近基准时间。

在符合第一条件或第二条件时，可以更新基准业务对象数据R，记录更接近基准时间的业务对象调整事件，即初始化基准业务对象数量、基准调整时间及基准调整操作版本号：

R.α＝N_msg.change_qty

R.datum_time＝N_msg.change_time

R.datum_ver＝N_msg.change_ver

再进行第一用户调整数量或者第二用户调整数量的累积。

而未符合第一条件或第二条件时，无需更新基准业务对象数据R，直接进行第一用户调整数量或者第二用户调整数量的累积。

假设Δβ是由第一用户(例如卖家)调整业务对象引起的一次业务对象调整数量，β’为调整前的累积的业务对象数量，那么业务对象调整后累积的业务对象数量R.β＝R.β’+N_msg.Δβ。

假设Δγ是由第二用户(例如买家)调整业务对象引起的一次业务对象调整数量，γ’为调整前的累积的业务对象数量，那么业务对象调整后累积的业务对象数量R.γ＝R.γ’+N_msg.Δγ。

对第一用户累积调整数量和第二用户累积调整数量求和，可以计算出累积业务对象调整数量(β+γ)。

在本申请实施例中，步骤102还可以包括如下子步骤：

子步骤S27，增加所述业务对象调整事件对应的去重记录。

同样，可以在去重表格中业务中查找该业务对象调整事件，若未查找到，则可以表示该业务对象调整事件不存在去重记录，可以认为该业务对象调整事件未被处理。

步骤103，当所述基准业务对象数量小于所述累积业务对象调整数量时，判断由所述业务对象调整操作造成异常状态；

当业务对象满足α-(β+γ)<0，即α<(β+γ)时，可以判断由所述业务对象调整操作造成异常状态。

根据异常状态判断公式α-(β+γ)<0，α和(β+γ)这几个变量的变化都存在满足此公式的场景中。

α值的变化可以体现在“溯源计算”确定基准业务对象数量的过程中，β的变化可以体现在第一用户(例如买家)的调整操作(例如后台减少商品库存)之中，而γ的变化可以体现在第二用户(例如买家)的调整操作(例如付款减少商品库存)之中。

具体而言，对于β变化，假设Δβ是由第一用户(例如卖家)调整业务对象(例如后台减少商品库存)引起的一次业务对象(例如商品)的调整数量。如果调整前业务对象满足α-(β’+γ)≥0，也即非异常状态(例如超卖)，当调整后，β＝β’+Δβ，若发现α-(β+γ)<0，则可以认为Δβ造成了异常状态(例如超卖)，即第一用户的调整操作造成了异常状态(例如超卖)。

对于γ变化，假设Δγ是由第二用户(例如买家)调整业务对象(例如付款减少商品库存)引起的一次业务对象(例如商品)的调整数量。如果调整前业务对象满足α-(β+γ’)≥0，也即非异常状态(例如超卖)，当调整后，γ＝γ’+Δγ，若发现α-(β+γ)<0，则可以认为Δγ造成了异常状态(例如超卖)，即第二用户的调整操作造成了异常状态(例如超卖)。

需要说明的是，计算周期需要切分为较小的周期并进行业务对象迭代调整数量，计算异常状态，主要从两个方面考虑。

一方面，如果计算周期不进行切分，也即业务对象的整个生命周期作为计算周期的话，由于无法确定业务对象的生命周期有多长，因此无法实施。

另一方面，服务器难以避免在长时间里不出现任何问题，通过计算周期的切分，在新的计算周期内，基准业务对象数量可以重新计算，这能及时纠正上一计算周期出现的计算偏差，而不会随着时间的推延，数据计算偏差问题越来越大。

采取了计算周期切分策略，为了保证在业务对象调整事件横跨相邻库存计算周期之间临界点所带来的计算精确性，本申请实施例提出了四种计算规则。

规则一：

如图5A所示，如果业务对象的调整开始时间(例如商品的下单时间)，此时并未执行调整操作(例如商品的付款操作)，t₁，业务对象调整事件中的调整时间t₂及服务器处理业务对象调整事件的事件处理时间t₃都在同一计算周期ΔT₁内，也即t₁∈ΔT₁且t₂∈ΔT₁且t₃∈ΔT₁，则异常状态的计算可以在ΔT₁中进行，即ΔT₁为当前计算周期。

规则二：

如图5B所示，如果业务对象的调整开始时间t₁及调整时间t₂在上一计算周期ΔT₀内，事件处理时间t₃在当前计算周期ΔT₁内，也即t₁∈ΔT₀且t₂∈ΔT₀且t₃∈ΔT₁，则异常状态的计算可以在ΔT₀中进行，即ΔT₀为当前计算周期。

规则三：

如图5C所示，如果业务对象的调整开始时间t₁在上一计算周期ΔT₀内，调整时间t₂及事件处理时间t₃在当前计算周期ΔT₁内，也即t₁∈ΔT₀且t₂∈ΔT₁且t₃∈ΔT₁，则异常状态的计算可以在ΔT₁中进行，即ΔT₁为当前计算周期。

规则四：

如图5D所示，如果业务对象的调整开始时间t₁在计算周期ΔT₀内，调整时间t₂在计算周期ΔT₁内，事件处理时间t₃在当前计算周期ΔT₂内，也即t₁∈ΔT₀且t₂∈ΔT₁且t₃∈ΔT₂，则异常状态的计算可以在ΔT₁中进行，即ΔT₁为当前计算周期。

其中，规则四可以推广到横跨多个计算周期的场景。

如上四个规则所述，所述调整时间可以在当前计算周期中。也即异常状态的计算按照调整时间来确定该业务对象调整事件应该归属到哪个计算周期内进行异常状态的计算。

假如不统一按照调整时间确定该业务对象调整事件在相应的计算周期内参与异常状态的计算，那么异常状态的计算结果的正确性就无法保证。也即，通过规范临界点前后应遵循的异常状态的计算规则，为异常状态的计算的精确性提供了保障。

步骤104，执行所述异常状态对应的告警操作。

在具体实现中，当业务对象的异常状态被识别后，可以通过事件驱动架构的将异常状态事件投递，以进行告警操作。

告警操作可以包括生成告警提示，发送告警通知，进行紧急处理等等，可以控制业务对象的调整的继续执行。

在电子商务领域中，告警提示可以包括在卖家所在的客户端或者平台系统的监控中心进行提示，告警通知可以包括发送短信、电子邮件给卖家或者平台系统的技术人员，紧急处理可以包括对商品进行下架处理(即停止销售)等等。

例如，在纯付款减库存方式中，商品库存有5件，买家A下单5件，买家B、C和D各下单1件，买家A、B、C和D按顺序在相当接近的时间内付款，服务器先接收到买家A的付款事件后，可以设置基准库存为α＝5，由买家变更库存累积的库存数γ＝5，α-(β+γ)＝0，未出现超卖，在接收到买家B的付款事件后，由买家变更库存累积的库存数γ＝6，α-(β+γ)＝-1＜0，判断出现超卖，可以立即做商品下架处理，用户C和D付款将会失败，控制了超卖。

在本申请的一种优选实施中，所述方法还可以包括如下步骤：

步骤105，当基于新的业务对象调整事件计算出新的基准业务对象数量，且新的基准业务对象数量大于或等于所述累积业务对象调整数量时，判断由所述业务对象操作造成异常状态属于错误判断；

步骤106，执行所述错误判断对应的误报操作；

对于α变化，可以存在两种情形，而对于α变化的两种情况的存在，可以是因为在基于事件驱动架构下，事件产生投递的顺序与事件处理的顺序不一致所导致的。

在α变化的一种情形中，参考图4，在t₂时间点，服务器处理的是C₁，若满足α(＝q₁)-(β+γ)<0，根据异常状态的判断公式可以判断出现异常状态。

在t₃(t₂<t₃)时间点，服务器处理的是C₀。按要求C₀应早于C₁进行处理，但由于异步事件处理顺序不保证，出现C₁早于C₀进行处理，导致α值计算结果需要纠正，故需要进行“溯源计算”来重新计算α值。

假设q₀>α(＝q₁)，那么进行“溯源计算”后，α＝q₀，若q₁＜q₀，则可能出现α(＝q₀)-(β+γ)>0的情况。也即，因为α值变大，导致该出现异常状态的误判。

例如，假设在C₁中q₁＝5，β＝0，γ＝6，即业务对象调整前的数量为5，第二用户的调整使得业务对象数量减少了6，在C₀中q₀＝10，即业务对象调整前的数量为10。在t₂时间点服务器处理C₁时，判断C₁更接近基准时间点，则可以设置基准业务对象数量α＝q₁＝5，即α-(β+γ)＝5-(0+6)＝-1＜0，判断出现异常状态，而在t₃时间点服务器处理C₀时，判断C₀比C₁更接近基准时间，则可以设置基准业务对象数量α＝q₀＝10，即α值增加了，对于C₁的异常状态判断变为α-(β+γ)＝10-(0+6)＝4＞0，判断未出现异常状态，即上异常状态属于误判。

在较早事件处理时间t₂判定出现异常状态，但在较晚事件处理时间t₃判定未出现异常状态，则服务器可以以较晚事件处理时间t₃的计算结果作为判定异常状态出现与否的依据。

即若在接收通过异步方式发送的一条业务对象调整事件N_msg后，对基准业务对象数据进行了调整，即从旧的基准业务对象数据R_old调整到新的基准业务对象数据R_new；

若满足：

R_old.α–(R_old.β+R_old.γ)<0&&R_new.α–(R_new.β+R_new.γ)≥0

那么业务对象的异常状态被识别为误判，服务器可以发出异常状态矫正事件，对误判进行矫正。

例如，可以发出消息通知事件以通知相关人员处理异常状态的误判。

步骤107，当所述基准业务对象数量大于或等于所述累积业务对象调整数量时，判断由所述业务对象调整操作未造成异常状态；

步骤108，当基于新的业务对象调整事件计算出新的基准业务对象数量，且新的基准业务对象数量小于所述累积业务对象调整数量时，判断由所述业务对象调整操作造成异常状态。

在α变化的另一种情形中，参考图4，在t₂时间点，服务器处理的是C₁，若满足α(＝q₁)-(β+γ)≥0，根据异常状态的判断公式可以判断未出现异常状态。

在t₃(t₂<t₃)时间点，服务器处理的是C₀。而按要求C₀应早于C₁进行处理，但由于异步事件处理顺序不保证，出现C₁早于C₀进行处理，导致α值计算结果需要纠正，故需进行“溯源计算”来重新计算α值。

假设q₀<α(＝q₁)，那么进行“溯源计算”后，α＝q₀，若q₁＞q₀，则可能出现α(＝q₀)-(β+γ)<0的情况。也即，因为α值变小，导致出现异常状态。

例如，假设在C₁中q₁＝10，β＝0，γ＝6，即业务对象调整前的数量为10，第二用户的调整使得业务对象数量减少了6，在C₀中q₀＝5，即业务对象调整前的数量为5。在t₂时间点服务器处理C₁时，判断C₁更接近基准时间点，则可以设置基准业务对象数量α＝q₁＝10，即α-(β+γ)＝10-(0+6)＝4＞0，判断未出现异常状态。而在t₃时间点服务器处理C₀时，判断C₀比C₁更接近基准时间，则可以设置基准业务对象数量α＝q₀＝5，即α值减少了，对于C₁的异常状态判断变为α-(β+γ)＝5-(0+6)＝-1＜0，判断出现异常状态。

在较早事件处理时间t₂判定为未出现异常状态，在较晚事件处理时间t₃却判定为出现异常状态，则服务器可以以较晚事件处理时间t₃的计算结果作为判定异常状态出现与否的依据。

即若在接收到通过异步方式发送的一条业务对象调整事件N_msg后，对基准业务对象数据进行了调整，即从旧的基准业务对象数据R_old调整到新的基准业务对象数据R_new；

若满足：

R_old.α–(R_old.β+R_old.γ)≥0&&R_new.α–(R_new.β+R_new.γ)<0

那么业务对象的异常状态被识别出，可以发出异常状态事件。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图6，其示出了本申请一种业务对象的异常告警装置实施例的结构框图，具体可以包括如下模块：

业务对象调整事件接收模块601，用于在相邻两个基准时间之间的计算周期中，接收中间件发送的业务对象调整事件；所述业务对象调整事件可以在客户端进行业务对象调整操作时生成；

基准计算模块602，用于根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量；

所述基准存储数值可以为当前基准时间的业务对象数量，所述累积业务对象调整数量可以为在所述计算周期中所累积的业务对象调整总数量；

异常判断模块603，用于在所述基准业务对象数量小于所述累积业务对象调整数量时，判断由所述业务对象调整操作造成异常状态；

告警模块604，用于执行所述异常状态对应的告警操作。

在本申请实施例的一种优选示例中，所述业务对象调整事件可以包括调整前的业务对象数量、调整时间、调整操作版本号、业务对象标识、第一用户调整数量和第二用户调整数量中的至少一个。

在本申请的一种优选实施例中，所述调整时间在当前计算周期中。

在本申请的一种优选实施例中，所述基准计算模块602可以包括如下子模块：

在本申请的一种优选实施例中，所述基准计算模块602还可以包括如下子模块：

在本申请的一种优选实施例中，还可以包括如下模块：

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种业务对象的异常告警方法和一种业务对象的异常告警装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种业务对象的异常告警方法，其特征在于，包括：

在相邻两个基准时间之间的计算周期中，接收中间件发送的业务对象调整事件；所述业务对象调整事件在客户端进行业务对象调整操作时生成；所述业务对象为具有业务领域特征的对象，所述中间件为利用消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成；

根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量；所述基准业务对象数量为当前基准时间的业务对象数量，所述累积业务对象调整数量为在所述计算周期中所累积的业务对象调整总数量；

执行所述异常状态对应的告警操作。

2.根据权利要求1所述的方法，其特征在于，所述业务对象调整事件包括调整前的业务对象数量、调整时间、调整操作版本号、业务对象标识、第一用户调整数量和第二用户调整数量中的至少一个。

3.根据权利要求2所述的方法，其特征在于，所述调整时间在当前计算周期中。

4.根据权利要求2所述的方法，其特征在于，所述根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量的步骤包括：

5.根据权利要求2所述的方法，其特征在于，所述根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量的步骤包括：

子步骤S22，判断所述业务对象调整事件是否存在去重记录；若否，则执行子步骤S23；所述去重记录为根据业务对象调整事件，创建当前计算周期内的新的业务对象基准数据时新增的记录；

6.根据权利要求4或5所述的方法，其特征在于，所述根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量的步骤还包括：

增加所述业务对象调整事件对应的去重记录。

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

当基于新的业务对象调整事件计算出新的基准业务对象数量，且新的基准业务对象数量大于或等于所述累积业务对象调整数量时，判断由所述业务对象调整操作造成异常状态属于错误判断。

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

执行所述错误判断对应的误报操作。

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

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

11.一种业务对象的异常告警装置，其特征在于，包括：

业务对象调整事件接收模块，用于在相邻两个基准时间之间的计算周期中，接收中间件发送的业务对象调整事件；所述业务对象调整事件在客户端进行业务对象调整操作时生成；所述业务对象为具有业务领域特征的对象，所述中间件为利用消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成；

基准计算模块，用于根据所述业务对象调整事件计算基准业务对象数量和累积业务对象调整数量；所述基准业务对象数量为当前基准时间的业务对象数量，所述累积业务对象调整数量为在所述计算周期中所累积的业务对象调整总数量；

告警模块，用于执行所述异常状态对应的告警操作。

12.根据权利要求11所述的装置，其特征在于，所述业务对象调整事件包括调整前的业务对象数量、调整时间、调整操作版本号、业务对象标识、第一用户调整数量和第二用户调整数量中的至少一个。

13.根据权利要求12所述的装置，其特征在于，所述调整时间在当前计算周期中。

14.根据权利要求12所述的装置，其特征在于，所述基准计算模块包括：

15.根据权利要求12所述的装置，其特征在于，所述基准计算模块包括：

去重判断子模块，用于判断所述业务对象调整事件是否存在去重记录；若否，则调用条件判断子模块；所述去重记录为根据业务对象调整事件，创建当前计算周期内的新的业务对象基准数据时新增的记录；

16.根据权利要求14或15所述的装置，其特征在于，所述基准计算模块还包括：

17.根据权利要求11或12或13或14或15所述的装置，其特征在于，还包括：

误判判断模块，用于在基于新的业务对象调整事件计算出新的基准业务对象数量，且新的基准业务对象数量大于或等于所述累积业务对象调整数量时，判断由所述业务对象调整操作造成异常状态属于错误判断。

18.根据权利要求17所述的装置，其特征在于，还包括：

19.根据权利要求11或12或13或14或15所述的装置，其特征在于，还包括：

20.根据权利要求19所述的装置，其特征在于，还包括：