CN105138691B

CN105138691B - 分析用户业务量的方法和系统

Info

Publication number: CN105138691B
Application number: CN201510600731.4A
Authority: CN
Inventors: 张帅; 付强
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2015-09-18
Filing date: 2015-09-18
Publication date: 2018-10-02
Anticipated expiration: 2035-09-18
Also published as: CN105138691A

Abstract

本申请公开了分析用户业务量的方法和系统。所述方法的一具体实施方式包括：单机节点以分钟为间隔执行以下第一操作流程：获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，发送第一业务量数据至数据处理节点；数据处理节点以分钟为间隔执行以下第二操作流程：根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据，发送第二业务量数据至业务节点；业务节点根据接收的第二业务量数据，分析用户业务量。该实施方式减少了不必要的重复数据的传输，且计算延迟较低。

Description

分析用户业务量的方法和系统

技术领域

本申请涉及计算机通信技术领域，具体涉及互联网通信数据传输技术领域，尤其涉及分析用户业务量的方法和系统。

背景技术

为了满足用户对业务量的分析结果(例如根据业务量得到的计费结果)的需求，对象存储系统需要根据用户的业务量数据(流量数据、容量数据和应用程序编程接口API的调用数据等)进行实时业务结算，具有数据量大、实时性要求高的特点。一方面，对象存储系统的海量用户导致了需要分析的数据量巨大，会对数据传输和后端的分析服务造成较大的压力。另一方面，对象存储系统要求对每个用户的业务量数据间隔一分钟记录一次，用户的操作要在几分钟之内展现在图表当中以供查看，对实时性提出了很高的要求。

目前，分析这种密集更新的业务量数据的方法主要有两种：一种是将用户请求日志传输到分布式系统基础架构Hadoop之类的大规模数据批处理平台上，统一进行分析；另一种方法是使用内存数据库对数据的更新进行缓存，然后再将数据推送给后端完成业务量数据分析的业务节点。

然而，如果使用Hadoop之类的大规模数据批处理平台，首先，数据需要凑齐一个批次才能够进行分析，计算延迟比较高；其次，由于Hadoop本身就是针对大吞吐量而非低延迟进行设计和优化的，每个作业任务之间还需要进行同步和调度，数据在不同节点之间传输，都会引入新的延迟。如果考虑到实时性，以分钟为间隔对数据进行批处理，则会在分布式文件系统HDFS中产生大量的小文件，从而给元数据服务器MetaServer造成很大压力。如果以小时为间隔对数据进行批处理，则用户需要等待一段时间才能查询到上一小时的数据。如果使用内存数据库，由于大部分内存数据库都不提供完整的持久化支持。因此只能间隔一段时间产生一份内存数据快照，如果在间隔的这段时间内系统宕机，则会丢失一部分修改。需要注意的是，如果在将数据发送给后端的业务节点后出现系统宕机的情况，而将内存中的数据删除这一改动还没有来得及同步到硬盘中，将会提供给用户额外的、不公平的业务结算结果。

发明内容

本申请的目的在于提出一种改进的分析用户业务量的方法和系统，来解决以上背景技术部分提到的技术问题。

第一方面，本申请提供了一种分析用户业务量的方法，所述方法包括：单机节点以分钟为间隔执行以下第一操作流程：获取具有同一时间戳的请求日志，从所述请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，发送所述第一业务量数据至数据处理节点，其中，所述请求日志用于记录用户的业务量请求，所述时间戳的格式为年月日时分；所述数据处理节点以分钟为间隔执行以下第二操作流程：根据用户信息，合并来自于不同单机节点且具有所述同一时间戳的所述第一业务量数据，得到第二业务量数据，发送所述第二业务量数据至业务节点；所述业务节点根据接收的所述第二业务量数据，分析用户业务量。

第二方面，本申请提供了一种分析用户业务量的系统，所述系统包括：单机节点，用于以分钟为间隔进行以下操作：获取具有同一时间戳的请求日志，从所述请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，发送所述第一业务量数据至数据处理节点,其中，所述请求日志用于记录用户的业务量请求，所述时间戳的格式为年月日时分；所述数据处理节点，用于以分钟为间隔进行以下操作：根据用户信息，合并来自于不同单机节点且具有所述同一时间戳的所述第一业务量数据，得到第二业务量数据，发送所述第二业务量数据至业务节点；所述业务节点，根据接收的所述第二业务量数据，分析用户业务量。

本申请提供的分析用户业务量的方法和系统，首先通过单机节点以分钟为间隔执行以下第一操作流程：获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，发送第一业务量数据至数据处理节点；之后通过数据处理节点以分钟为间隔执行以下第二操作流程：根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据，发送第二业务量数据至业务节点；最后通过业务节点根据接收的第二业务量数据，分析用户业务量。由于在业务量数据传输的过程中进行了两次数据合并，减少了不必要的重复数据的传输，并实现了按分钟处理业务量数据，计算延迟较低。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是本申请可以应用于其中的示例性系统架构图；

图2是根据本申请实施例的分析用户业务量的方法的一个示意性流程图；

图3是根据本申请实施例的图2的分析用户业务量的方法的一个应用场景所应用的框架示意图；

图4是根据本申请实施例的基于图2的分析用户业务量的方法的一个示意性流程图；

图5是根据本申请实施例的基于图4的分析用户业务量的方法的一个示意性流程图；

图6是根据本申请实施例的基于图5的分析用户业务量的方法的一个示意性流程图；

图7是根据本申请实施例的基于图6的分析用户业务量的方法的一个示意性流程图；

图8是根据本申请实施例的基于图2至图7中任意一方法的分析用户业务量的方法的一个示意性流程图。

图9是根据本申请实施例的基于图8的分析用户业务量的方法的一个示意性流程图；

图10是根据本申请实施例的基于图9的分析用户业务量的方法的一个示意性流程图；

图11是根据本申请实施例的基于图10的分析用户业务量的方法的一个示意性流程图；

图12是根据本申请实施例的分析用户业务量的系统的一个示例性结构图；

图13是适于用来实现本申请实施例的服务器的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1示出了可以应用本申请的分析用户业务量的方法或分析用户业务量的系统的实施例的示例性系统架构100。

如图1所示，系统架构100可以包括终端设备101、102和多个服务器104。网络103用以在终端设备101、102和服务器104之间提供通信链路的介质。网络103可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户110可以使用终端设备101、102通过网络103与服务器104交互，以上传或下载数据等。终端设备101、102上可以安装有各种客户端应用，例如网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件、云平台应用等。

终端设备101、102可以是具有显示屏并且支持数据上传下载的各种电子设备，包括但不限于移动智能终端、平板电脑、膝上型便携计算机、台式计算机、多媒体播放器和电子阅读器等等。

服务器104可以是提供对象存储或数据处理的服务器，数量可以为多个，并且多个服务器104可以形成服务器集群。例如对终端设备101、102上网页显示的文件提供对象存储的服务器或对存储的业务量数据进行分析处理的服务器。提供对象存储的服务器可以对接收到的上传请求或下载请求等数据进行分析处理，并将处理结果(例如上传或下载的文件数据)反馈给终端设备。

需要说明的是，本申请实施例所提供的分析用户业务量的方法中的操作步骤一般由服务器104形成的服务器集群执行，相应地，分析用户业务量的系统中的节点一般设置于各服务器104中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

继续参考图2，其示出了根据本申请实施例的分析用户业务量的方法的一个示意性流程图200。该分析用户业务量的方法200，包括以下步骤：

步骤201，单机节点以分钟为间隔执行以下第一操作流程：获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，发送第一业务量数据至数据处理节点。

在本实施例中，第一操作流程可以同时运行于服务器集群中的多个服务器上，而服务器集群是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。服务器集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个服务器坏了整个服务器集群还是能正常运行。

在上述的多个服务器中，每一个服务器可以作为一个单机节点，获取本地具有同一时间戳Ti的请求日志。通常，获取的请求日志记录了用户的业务量请求，例如记录用户的流量、容量和API调用等业务量请求，该请求日志的时间戳的格式可以为年月日时分。

之后，各单机节点从各自获取的请求日志中解析出分析业务量所需要的初始业务量数据，并将属于同一用户的初始业务量数据进行合并，得到第一业务量数据。

单机节点在进行初始业务量数据的合并时，可以仅根据属于同一用户这一特征合并初始业务量数据，例如将解析出的初始业务量数据分别合并至张某、王某及其他用户名下；也可以根据属于同一用户之下的同一业务量种类，分别合并初始业务量数据，例如将解析出的属于张某的初始业务量数据分别合并至张某的流量、容量和API调用这三种业务量种类下。

单机节点在进行上述合并步骤之后，将合并得到的第一业务量数据发送给数据处理节点，以便进行下一步处理。

在本实施例的一些可选实现方式中，在发送第一业务量数据至数据处理节点时，可以记录第一发送事务的处理标记至预设的第一重做日志。

需要说明的是，上述的第一发送事务为发送第一业务量数据至数据处理节点的事务；第一发送事务的处理标记至少包括第一发送事务的开始标记和结束标记。

在本实施例的一些可选实现方式中，上述的单机节点发送第一业务量数据至数据处理节点还可以包括但不限于：响应于发送第一业务量数据成功，间隔第一预定时间删除内存中发送成功的第一业务量数据；响应于将发送失败的第一业务量数据合并回内存的次数超过第一预置次数或持续发送失败的时间超过第一预置时间，触发报警提醒。

需要说明的是，上述的第一预定时间，是指预先设定的用于删除内存中发送成功的第一业务量数据的间隔时间，当发送第一业务量数据成功第一预定时间后，删除发送成功的第一业务量数据；上述的第一预置次数，是指预先设置的允许将发送失败的第一业务量数据合并回内存的次数，当将发送失败的第一业务量数据合并回内存的次数超过第一预置次数时，触发报警提醒；上述的第一预置时间，是指预先设置的允许持续发送失败的时间，当持续发送失败的时间超过第一预置时间时，触发报警提醒。

在本实施例的一些可选实现方式中，在获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据时，可以记录第一获取事务的处理标记至第一重做日志。

需要说明的是，上述的第一获取事务为获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据的事务；第一获取事务的处理标记至少包括第一获取事务的开始标记和结束标记。

步骤202，数据处理节点以分钟为间隔执行以下第二操作流程：根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据，发送第二业务量数据至业务节点。

在本实施例中，第二操作流程可以运行于数据处理节点上。该数据处理节点，可以根据接收的第一业务量数据以及服务器的硬件配置来确定：当接收的第一业务量数据较少能够和处理初始业务量数据的单机节点合并时，数据处理节点可以是上述的单机节点中的一个；当接收的第一业务量数据需要使用单独的服务器进行处理时，数据处理节点也可以是独立于上述的单机节点的专用服务器，该专用服务器可以位于上述的包括单机节点的服务器集群中，也可以独立于上述的包括单机节点的服务器集群存在；当接收的第一业务量数据特别多需要使用多台服务器组成专用服务器集群进行处理时，数据处理节点还可以是专用的服务器集群。

数据处理节点在接收到上述的多个单机节点在步骤201中发送的第一业务量数据之后，可以按照用户信息，合并来自于不同单机节点且具有统一时间戳的第一业务量数据。

数据处理节点在合并第一业务量数据时，可以按照单机节点合并初始业务量的格式进行第一业务量数据的合并：当单机节点仅按照属于同一用户这一特征合并第一业务量数据时，数据处理节点也仅按照属于同一用户这一特征合并第一业务量数据，例如将从不同单机节点接收的属于同一用户的第一业务量数据分别合并至张某、王某及其他用户名下；当单机节点按照属于同一用户的同一业务量种类分别合并初始业务量数据时，数据处理节点也可以按照属于同一用户之下的同一业务量种类，分别合并第一业务量数据，例如将来自于不同单机节点的属于张某的第一业务量数据分别合并至张某的流量、容量和API调用这三种业务量种类下。

数据处理节点在进行上述合并步骤之后，将合并得到的第二业务量数据发送给业务节点，以便进行下一步处理。

在本实施例的一些可选实现方式中，在发送第二业务量数据至业务节点时，并记录第二发送事务的处理标记至预设的第二重做日志。

需要说明的是，上述的第二发送事务为发送第二业务量数据至业务节点的事务；第二发送事务的处理标记至少包括第二发送事务的开始标记和结束标记。

在本实施例的一些可选实现方式中，上述的发送第二业务量数据至业务节点还可以包括但不限于：响应于第二业务量数据发送成功，间隔第二预定时间删除内存中发送成功的第二业务量数据；响应于将发送失败的第二业务量数据合并回内存的次数超过第二预置次数或持续发送失败的时间超过第二预置时间，触发报警提醒。

需要说明的是，上述的第二预定时间，是指预先设定的用于删除内存中发送成功的第二业务量数据的间隔时间，当发送第二业务量数据成功第二预定时间后，删除发送成功的第二业务量数据；上述的第二预置次数，是指预先设置的允许将发送失败的第二业务量数据合并回内存的次数，当将发送失败的第二业务量数据合并回内存的次数超过第二预置次数时，触发报警提醒；上述的第二预置时间，是指预先设置的允许持续发送失败的时间，当持续发送失败的时间超过第二预置时间时，触发报警提醒。

在本实施例的一些可选实现方式中，在根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据时，可以记录第二获取事务的处理标记至第二重做日志。

需要说明的是，第二获取事务为根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据的事务；第二获取事务的处理标记至少包括第二获取事务的开始标记和结束标记。

步骤203，业务节点根据接收的第二业务量数据，分析用户业务量。

在本实施例中，分析用户业务量这一操作步骤运行于业务节点上。该业务节点，与数据处理节点类似，可以根据接收的第二业务量数据和服务器的硬件配置来确定：当接收的第二业务量数据能够和初始业务量数据和/或第一业务量数据位于同一单机节点处理时，业务节点可以是上述的单机节点或数据处理节点中的一个；当接收的第二业务量数据需要使用单独的服务器进行处理时，业务节点也可以是独立于上述的单机节点或数据处理节点的专用服务器，该专用服务器可以位于上述的包括单机节点或数据处理节点的服务器集群之一中，也可以独立于上述的服务器集群存在；当接收的第二业务量数据特别多，需要使用多台服务器组成专用服务器集群进行处理时，业务节点还可以是专用的服务器集群。

在本实施例的一个具体的应用场景中，用户的业务量请求会被负载均衡至多个单机节点上并记录到各个单机节点本地的请求日志中，计费粒度为分钟。分析用户业务量的方法可以包括以下四个主要步骤：

1.单机节点从本地的请求日志中提取初始业务量数据，并合并初始业务量数据至第一业务量数据；

2.单机节点将合并的第一业务量数据发送至数据处理节点；

3.数据处理节点合并来自于多个单机节点的第一业务量数据，得到第二业务量数据；

4.数据处理节点发送第二业务量数据至业务节点。

在这里，从单机节点的请求日志中提取初始业务量数据，也即将用户的请求日志转化为分析用户业务量(例如计费业务量)所需要的初始业务量数据(例如流量数据、容量数据和API调用数据等)。

在上述的单机节点中合并初始业务量数据至第一业务量数据，也即将初始业务量数据按照用户业务量(例如计费业务量)的时间粒度，用户和其他业务量维度(例如流量维度、容量维度和API调用维度等)进行合并，从而大大减少数据量。

由于负载均衡，一个用户的业务量请求可能会由不同的单机节点进行处理，因此可以将多个单机节点产生的第一业务量数据汇总到一起再次进行合并，得到第二业务量数据，进一步减少数据量。

最终，再将合并后的第二业务量数据发送给业务节点，既可以减少传输量，又可以减轻业务节点的计算负担，提高业务节点的计算效率。

如图3所示，上述的四个主要步骤，前两个步骤合并为一个模块，称为收集模块Collector；后两个步骤合并为一个模块，称为发送模块Sender。Collector和Sender都使用事务、重做日志Redo-Log和快照的方法来解决数据一致性和持久化的问题。

以下描述由位于单机节点中的Collector处理的第一操作流程：

Collector首先记录一条<BEGIN TRANSACTION Ti,READ>(开始读取时间戳Ti的日志，因为系统每一分钟向消息队列发送一次数据，所以Ti的格式为“年月日时分”；因为Ti的粒度为分，所以会从日志中读取多条相同时间戳的日志上来)，然后开始逐条解析本机上的用户请求日志，每解析成功一条就向本地的Redo-Log中追加记录<Ti,Vorig,Vdest>(记录数据修改，其中Vorig指的是依据此日志内容被修改的内存中的用户数据的原始值，Vdest指的是该用户数据修改后的值，整体的格式是“年月日时分用户身份id统计项名称原始值修改后值”)，并将解析得到的用户数据(也即第一业务量数据)合并进内存中维护的数据集中。成功解析若干条后，或者没有更多用户请求日志时，向本地Redo-Log中追加记录当前读取的位置信息并结束当前的事务<FINISH TRANSACTION Ti,Offset>(结束读取事务，其中Offset指的是日志文件中的偏移量)。

Collector每隔一分钟发送一批数据。首先记录一条事务开始标记<BEGINTRANSACTION Ti,SEND>(开始发送事务，此Ti格式同上面的Ti，系统以时间戳标识一批数据，一批数据会在重做日志中出现两次，一次是上一段中从日志收集它时，另外一次就是这里说明的发送它给消息队列时)，然后将所有数据从内存数据集中取下，进行编号后发送。发送如果失败，则按照一定规则进行重试，例如若重试发送的次数未达到预设的重试次数或重试发送的时间未达到预设的重试时间，则可以进行重试。如果重试最终仍然失败，将取下的数据合并回内存数据集并在本地Redo-Log中记录<ABORT TRANSACTION Ti>(取消发送事务，此Ti含义同前)。发送成功则更新发送编号并结束当前事务<FINISH TRANSACTIONTi,Sequence Number>(结束发送事务，此Ti含义同前，Sequence Number一个递增的值，标记数据发送的顺序，由消息队列产生，在推送成功的返回值中)。为防止Collector占用内存过多，每隔一段时间，Collector会对已经发送成功的数据进行删除；如果因为发送失败而导致记录在内存中的数据过多，则会触发报警。

以下描述由位于数据处理节点中的Sender处理的第二操作流程：

Sender首先在本地的重做日志Redo-Log中记录一条<BEGIN TRANSACTION Ti,READ>(开始从消息队列读取时间戳Ti的单机数据，格式同前)，然后开始逐条从消息队列中解析来自于单机节点的第一业务量数据，每解析成功一条先根据单机节点的ip地址加上时间戳Ti去重，发现重复的数据就丢弃并向本地的Redo-Log中追加记录<Ti,SequenceNumber,DISCARD>(丢弃重复数据，Sequence Number含义同上,这里之所以不记录数据的变化是因为消息队列本身就能暂存数据的作用)；如果第一业务量数据没有重复则向Redo-Log中追加记录<Ti,Sequence Number,ACCUMULATED>(处理此条单机数据，SequenceNumber含义同上)，并将数据合并进内存中维护的数据集中。收集齐全部单机的同一时间戳的数据后，或者没收集齐但是超时了，向Redo-Log中追加记录当前读取的消息队列中的位置信息并结束当前的事务<FINISH TRANSACTION Ti,Last Sequence Number>(LastSequence Number是处理了的最后一条单机数据在消息队列中的Sequence Number)。

Sender每隔一分钟通过消息队列发送一批数据给后面的计费系统。首先记录一条事务开始标记<BEGIN TRANSACTION Ti,SEND>(开始发送事务，此Ti格式同上面的Ti)，然后将所有数据从内存数据集中取下，编号后进行发送。发送如果失败，则依据一定策略进行重试，例如重试发送的次数未达到预设的重试次数或重试发送的时间未达到预设的重试时间，则可以进行重试。如果最终发送仍然失败，将取下的数据合并回内存数据集并在Redo-Log中记录<ABORT TRANSACTION Ti>(取消发送事务，此Ti含义同前)。成功则更新发送编号并结束当前事务<FINISH TRANSACTION Ti,Sequence Number>(结束发送事务，此Ti含义同前，Sequence Number来源同前)。为防止Sender占用内存过多，每隔一段时间，Sender会对已经发送成功的数据进行删除；如果因为发送失败而导致记录在内存中的数据过多，则会触发报警。

本申请的上述实施例提供的方法在业务量数据传输的过程中进行了两次数据合并，减少了不必要的重复数据的传输，并实现了按分钟处理业务量数据，计算延迟较低。

进一步参考图4，其示出了根据本申请实施例的基于图2的分析用户业务量的方法的一个示意性流程图400。该分析用户业务量的方法400，在图2的分析用户业务量的基础上，上述的发送第一业务量数据至数据处理节点，并记录第一发送事务的处理标记至预设的第一重做日志，可以包括以下步骤：

步骤401，记录第一发送事务的开始标记至预设的第一重做日志。

在本实施例中，记录第一发送事务的开始标记至预设的第一重做日志这一操作步骤可以运行于单机节点中。其中，第一发送事务为发送第一业务量数据至数据处理节点的事务。第一发送事务的开始标记包括发送的第一业务量数据的时间戳。

步骤402，根据发送的第一业务量数据的时间戳，获取第一业务量数据。

在本实施例中，在步骤401记录第一发送事务的开始标记至预设的第一重做日志之后，可以根据第一发送事务的开始标记中精确到分钟的时间戳，获取具有同一时间戳Ti的第一业务量数据。

步骤403，将获取的第一业务量数据编号，形成第一消息队列。

在本实施例中，在获取具有同一时间戳Ti的第一业务量数据之后，可以对具有同一时间戳Ti的第一业务量数据进行编号，例如按照通用唯一识别码UUID对具有同一时间戳Ti的第一业务量数据进行编号，从而形成第一消息队列，其中UUID可以包括生成第一业务量数据的日期和时间、时钟序列和全局唯一的IEEE机器识别码等。

步骤404，发送第一消息队列至数据处理节点。

在本实施例中，在将获取的第一业务量数据编号，形成第一消息队列之后，可以将形成的第一消息队列发送至数据处理节点。

步骤405，响应于发送第一消息队列失败，重试发送第一消息队列。

在本实施例中，在发送第一消息队列失败之后，可以重试发送第一消息队列，以提高发送第一消息队列的成功率。

步骤406，若第一消息队列重试发送的次数达到第一预设重试次数或重试发送的时间达到第一预设重试时间，将从内存中获取的第一业务量数据合并回内存，并记录第一发送事务的异常终止标记至第一重做日志。

在本实施例中，记录了第一发送事务的异常终止标记，该第一发送事务的异常终止标记中包括了发送失败的第一业务量数据的时间戳，以便之后可以根据该时间戳，确定发送失败的第一业务量数据的批次，从而重新发送该批次的第一业务量数据。

步骤407，响应于发送第一消息队列成功，更新发送第一消息队列的编号，并记录第一发送事务的结束标记至第一重做日志。

在本实施例中，第一发送事务的结束标记包括发送成功的第一业务量数据的时间戳和发送成功的第一业务量数据的接续编号，也即当发送第一消息队列成功时，记录了发送成功的第一业务量数据的批次，并将下一批次需要发送的第一业务量数据的编号更新至接续编号。

从图4中可以看出，与图2对应的实施例相比，本实施例中的分析用户业务量的方法的流程400，突出了记录第一发送事务的处理标记至预设的第一重做日志的步骤。由此，本实施例描述的方案可以引入第一重做日志，当发送第一业务量数据至数据处理节点的事务失败或单机节点崩溃时，可以对发送第一业务量数据的事务进行恢复。

应当说明的是，在上述的服务器集群环境中，当实例或介质失败时，其他仍然完好的节点数据库实例就可以联机失败的实例或介质，对其中的重做日志文件进行访问，执行实例恢复，进行已提交事务的前滚和未提交事务的回滚，从而实现失败事务的恢复或集群角度的崩溃恢复。

进一步参考图5，其示出了根据本申请实施例的基于图4的分析用户业务量的方法的一个示意性流程图500。该分析用户业务量的方法500，在图4的分析用户业务量的方法的基础上，还包括以下步骤：

步骤501，单机节点间隔第一预设时间或响应于发送成功第一预设数量的第一业务量数据至数据处理节点，新建第一重做日志。

在本实施例中，单机节点可以间隔第一预设时间新建第一重做日志，也可以响应于发送成功第一预设数量的第一业务量数据至数据处理节点，新建第一重做日志。其中，第一预设时间可以为预先设置的生成第一快照的间隔时间；第一预设次数可以为预先设置的生成第一快照之间间隔的成功发送第一业务量数据至数据处理节点的次数。

步骤502，响应于新建第一重做日志完成，同时在原第一重做日志和新建第一重做日志中记录第一获取事务的处理标记和第一发送事务的处理标记。

在本实施例中，当步骤501中新建第一重做日志完成时，可以同时在原第一重做日志和新建第一重做日志中记录第一获取事务的处理标记和第一发送事务的处理标记，以便在生成第一快照失败时，进行已提交事务和未提交事务的回滚，重新生成第一快照。

步骤503，查询当前正在进行的事务的时间戳。

在本实施例中，可以查询当前正在进行的事务的时间戳，以便根据查询到的时间戳，确定具有该时间戳的数据批次。

步骤504，生成内存中数据集的第一快照，并同时在原第一重做日志和新建第一重做日志中记录第一快照事务的开始标记。

在本实施例中，在查询到当前正在进行的事务的时间戳之后，可以生成内存中数据集的第一快照，并可以同时在原第一重做日志和新建第一重做日志中记录第一快照事务的开始标记，以便在第一快照事务失败时，可以对第一快照事务进行恢复。其中，第一快照事务的开始标记包括第一快照的检查点所存入的文件名称和正在进行的事务的时间戳。

步骤505，将生成的第一快照存入磁盘，并同时在原第一重做日志和新建第一重做日志中记录第一快照事务的结束标记。

在本实施例中，当第一快照事务完成时，可以将生成的第一快照存入磁盘，并同时在原第一重做日志和新建的第一重做日志中记录第一快照事务的结束标记。其中，第一快照事务的结束标记包括第一快照的检查点所存入的文件名称。

之后，当单机节点崩溃或发送第一业务量数据至数据处理节点失败时，可以查询新建的第一重做日志中是否包括第一快照事务的结束标记，若包括，则可以根据第一快照事务的结束标记中包括的第一快照的检查点所存入的文件名称，得到第一快照，继而根据第一快照，恢复生成第一快照时内存中的数据集。

步骤506，响应于同时在原第一重做日志和新建第一重做日志中记录第一快照事务的结束标记完成，删除原第一重做日志。

在本实施例中，在同时在原第一重做日志和新建第一重做日志中记录第一快照事务的结束标记完成之后，可以删除原第一重做日志以节省单机节点的磁盘空间。

在本实施例的一个具体应用场景中，上述的位于单机节点中的Collector每隔一段时间，或者是完成了一定数量的事务后，将生成快照并清理本地Redo-Log，以免本地Redo-Log过大。生成快照时，首先产生新的本地Redo-Log，从此刻起，所有的记录都要同时向新旧两个本地Redo-Log中进行追加操作。然后查询当前正在进行中的事务，生成一份内存中当前数据集的快照，并在Redo-Log中记录<BEGIN CHECKPOINT filename,T1,T2,…>(filename指的是检查点所存入的文件名称)，其中<T1,T2,…>是当前正在进行中的事务编号(同时也是时间戳，指示一批数据的编号)。将修改后的快照存入磁盘后，记录<FINISHCHECKPOINT filename>(filename指的是检查点所存入的文件名称)。从此刻起，可以抛弃旧的本地Redo-Log，而使用新的本地Redo-Log。

在发生系统故障时，Collector可以直接加载最新的快照，并且重放此次快照之后所有成功事务造成的数据更改。对于从单机节点的请求日志中提取初始业务量数据的事务，可以安全的抛弃掉未完成的事务，从最后一次成功的从单机节点的请求日志中提取初始业务量数据的事务处继续执行。对于单机节点将合并的第一业务量数据发送至数据处理节点的事务，因为不知道系统结束时数据是否已经发送成功，所以必须进行重试直到事务成功。Sender会根据信息编号对数据进行去重。

从图5中可以看出，与图4对应的实施例相比，本实施例中的分析用户业务量的方法的流程500突出了生成第一快照的步骤。由此，本实施例描述的方案可以引入第一快照，从而实现在生成第一快照失败时对已提交事务的前滚和未提交事务的回滚，完成数据恢复。

进一步参考图6，其示出了根据本申请实施例的基于图5的分析用户业务量的方法的一个示意性流程图600。该分析用户业务量的方法600，在图5的分析用户业务量的方法的基础上，上述的获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，并记录第一获取事务的处理标记至第一重做日志，可以包括以下步骤：

步骤601，记录第一获取事务的开始标记至第一重做日志。

在本实施例中，单机节点可以记录第一获取事务的开始标记至第一重做日志。其中，第一获取事务为获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据的事务；第一获取事务的开始标记包括获取的请求日志的时间戳。

步骤602，根据获取的请求日志的时间戳，获取请求日志。

在本实施例中，在步骤601记录第一获取事务的开始标记至第一重做日志之后，可以根据获取的请求日志精确到分钟的时间戳，获取具有同一时间戳Ti的请求日志。

步骤603，从请求日志中逐条解析初始业务量数据，将解析的初始业务量数据合并至内存中属于同一用户的数据集中以累积第一业务量数据，并记录第一获取事务的单条解析成功标记至第一重做日志。

在本实施例中，在步骤602获取具有同一时间戳Ti的请求日志之后，可以将解析获取的请求日志得到的初始业务量数据合并至内存中属于同一用户的数据集中，以累积第一业务量数据，并记录第一获取事务的单条解析成功标记至第一重做日志。其中，第一获取事务的单条解析成功标记可以包括解析成功的单条请求日志的时间戳、内存中数据集的原始值和修改后值。

步骤604，响应于解析单条请求日志成功的次数符合预设的解析次数或完成单机节点中所有请求日志的解析，记录第一获取事务的结束标记至第一重做日志。

在本实施例中，单机节点可以响应于解析单条请求日志成功的次数符合预设的解析次数，记录第一获取事务的结束标记至第一重做日志，也可以响应于完成单机节点中所有请求日志的解析，记录第一获取事务的结束标记至第一重做日志。其中，第一获取事务的结束标记可以包括获取的请求日志的时间戳和请求日志文件中的偏移量；请求日志文件中的偏移量记录当前读取的请求日志的位置信息。

从图6中可以看出，与图5对应的实施例相比，本实施例中的分析用户业务量的方法的流程600突出了记录第一获取事务的处理标记至第一重做日志的步骤。由此，本实施例描述的方案可以引入第一重做日志，从而在得到第一业务量数据的事务失败时，可以对得到第一业务量数据的事务进行恢复。

进一步参考图7，其示出了根据本申请实施例的基于图6的分析用户业务量的方法的一个示意性流程图700。该分析用户业务量的方法700，在图6的分析用户业务量的方法的基础上，还包括以下步骤：

步骤701，响应于执行第一操作流程失败，加载最后一次的第一快照以及最后一次的第一快照之后由成功事务造成的数据更改。

在本实施例中，当执行第一操作流程失败时，可以根据新建第一重做日志，得到最后一次的第一快照之后由成功事务造成的数据更改，之后加载最后一次的第一快照以及得到的数据更改，以便将内存中的数据集以及正在执行的事务恢复至执行失败之前的状态。

在本实施例的一些可选方式中，响应于执行第一操作流程失败，加载最后一次的第一快照以及最后一次的第一快照之后由成功事务造成的数据更改可以包括：响应于获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据失败，加载最后一次的第一快照和新建第一重做日志中最后一次记录的第一获取事务的结束标记。

在本实现方式中，响应于将请求日志中解析的初始业务量数据合并为第一业务量数据失败，可以加载最后一次的第一快照和新建第一重做日志中最后一次记录的第一获取事务的结束标记，以便根据该第一快照恢复内存中的数据集，根据该结束标记中包括的获取的请求日志的时间戳和请求日志文件中的偏移量，确定需要解析的下一条请求日志。

在本实施例的一些可选方式中，响应于执行第一操作流程失败，加载最后一次的第一快照以及最后一次的第一快照之后由成功事务造成的数据更改可以包括：响应于以分钟为间隔发送第一业务量数据至数据处理节点失败，加载最后一次的第一快照和新建第一重做日志中未记录第一发送事务的结束标记的第一发送事务的开始标记。

在本实现方式中，响应于以分钟为间隔发送第一业务量数据至数据处理节点失败，可以加载最后一次的第一快照和新建第一重做日志中未记录第一发送事务的结束标记的第一发送事务的开始标记，以便根据该第一快照恢复内存中的数据集，根据未记录第一发送事务的结束标记的第一发送事务的开始标记中包括的发送的第一业务量数据的时间戳，确定需要发送的第一业务量数据，之后发送确定的该第一业务量数据。

步骤702，根据最后一次的第一快照以及数据更改，执行第一操作流程。

在本实施例中，可以根据加载的最后一次的第一快照以及最后一次的第一快照之后由成功事务造成的数据更改，重新执行之前失败的第一操作流程。

在本实施例的一些可选实现方式中，与上述的响应于获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据失败，加载最后一次的第一快照和新建第一重做日志中最后一次记录的第一获取事务的结束标记相对应，根据最后一次的第一快照以及数据更改，执行第一操作流程可以包括：根据最后一次的第一快照和新建第一重做日志中最后一次记录的第一获取事务的结束标记，继续获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，之后执行发送第一业务量数据至数据处理节点。

在本实施例的一些可选实现方式中，与上述的响应于以分钟为间隔发送第一业务量数据至数据处理节点失败，加载最后一次的第一快照和新建第一重做日志中未记录第一发送事务的结束标记的第一发送事务的开始标记相对应，根据最后一次的第一快照以及数据更改，执行第一操作流程可以包括：根据最后一次的第一快照和新建第一重做日志中未记录第一发送事务的结束标记的第一发送事务的开始标记，重新发送第一业务量数据至数据处理节点。

从图7中可以看出，与图6对应的实施例相比，本实施例中的分析用户业务量的方法的流程700突出了恢复失败的第一操作流程的步骤。由此，本实施例描述的方案可以防止单机节点在执行第一操作流程时因宕机而造成数据丢失。

进一步参考图8，其示出了基于图2至图7的任意一方法的分析用户业务量的方法的一个示意性流程图800。该分析用户业务量的方法800，在图2至图7的任意一方法的基础上，上述的发送第二业务量数据至业务节点，并记录第二发送事务的处理标记至预设的第二重做日志，可以包括以下步骤：

步骤801，记录第二发送事务的开始标记至预设的第二重做日志。

在本实施例中，记录第二发送事务的开始标记至预设的第二重做日志这一操作步骤可以运行于数据处理节点中。其中，第二发送事务为发送第二业务量数据至业务节点的事务。第二发送事务的开始标记包括发送的第二业务量数据的时间戳。

步骤802，根据发送的第二业务量数据的时间戳，获取第二业务量数据。

在本实施例中，在步骤801记录第二发送事务的开始标记至预设的第二重做日志之后，可以根据第二发送事务的开始标记中精确到分钟的时间戳，获取具有同一时间戳Ti的第二业务量数据。

步骤803，将获取的第二业务量数据编号，形成第二消息队列。

在本实施例中，在获取具有同一时间戳Ti的第二业务量数据之后，可以对具有同一时间戳Ti的第二业务量数据进行编号，例如按照通用唯一识别码UUID对具有同一时间戳Ti的第二业务量数据进行编号，从而形成第二消息队列，其中UUID可以包括生成第二业务量数据的日期和时间、时钟序列和全局唯一的IEEE机器识别码等。

步骤804，发送第二消息队列至业务节点。

在本实施例中，在将获取的第二业务量数据编号，形成第二消息队列之后，可以将形成的第二消息队列发送至数据处理节点。

步骤805，响应于发送第二消息队列失败，重试发送第二消息队列。

在本实施例中，在发送第二消息队列失败之后，可以重试发送第二消息队列，以提高发送第二消息队列的成功率。

步骤806，若第二消息队列重试发送的次数达到第二预设重试次数或重试发送的时间达到第二预设重试时间，将从内存中获取的第二业务量数据合并回内存，并记录第二发送事务的异常终止标记至第二重做日志。

在本实施例中，记录了第二发送事务的异常终止标记，该第二发送事务的异常终止标记中包括了发送失败的第二业务量数据的时间戳，以便之后可以根据该时间戳，确定发送失败的第二业务量数据的批次，从而重新发送该批次的第一业务量数据。

步骤807，响应于发送第二消息队列成功，更新发送第二消息队列的编号，并记录第二发送事务的结束标记至第二重做日志.

在本实施例中，第二发送事务的结束标记包括发送成功的第二业务量数据的时间戳和发送成功的第二业务量数据的接续编号，也即当发送第二消息队列成功时，记录了发送成功的第二业务量数据的批次，并将下一批次需要发送的第二业务量数据的编号更新至接续编号。

从图8中可以看出，与图2至图7对应的实施例相比，本实施例中的分析用户业务量的方法的流程800突出了记录第二发送事务的处理标记至预设的第二重做日志的步骤。由此，本实施例描述的方案可以引入第二重做日志，当发送第二业务量数据至业务节点的事务失败或数据处理节点崩溃时，可以对发送第二业务量数据的事务进行恢复。

进一步参考图9，其示出了根据本申请实施例的基于图8的分析用户业务量的方法的一个示意性流程图900。该分析用户业务量的方法900，在图8中分析用户业务量的方法的基础上，还包括以下步骤：

步骤901，数据处理节点间隔第二预设时间或响应于发送成功第二预设数量的第二业务量数据至业务节点，新建第二重做日志。

在本实施例中，数据处理节点可以间隔第二预设时间新建第二重做日志，也可以响应于发送成功第二预设数量的第二业务量数据至业务节点，新建第二重做日志。其中，第二预设时间可以为预先设置的生成第二快照的间隔时间；第二预设次数可以为预先设置的生成第二快照之间间隔的成功发送第二业务量数据至业务节点的次数。

步骤902，响应于新建第二重做日志完成，同时在原第二重做日志和新建第二重做日志中记录第二获取事务的处理标记和第二发送事务的处理标记。

在本实施例中，当步骤901中新建第二重做日志完成时，可以同时在原第二重做日志和新建第二重做日志中记录第二获取事务的处理标记和第二发送事务的处理标记，以便在生成第二快照失败时，进行已提交事务和未提交事务的回滚，重新生成第二快照。

步骤903，查询当前正在进行的事务的时间戳。

步骤904，生成内存中数据集的第二快照，并同时在原第二重做日志和新建第二重做日志中记录第二快照事务的开始标记。

在本实施例中，在查询到当前正在进行的事务的时间戳之后，可以生成内存中数据集的第二快照，并可以同时在原第二重做日志和新建第二重做日志中记录第二快照事务的开始标记，以便在第二快照事务失败时，可以对第二快照事务进行恢复。其中，第二快照事务的开始标记包括第二快照的检查点所存入的文件名称和正在进行的事务的时间戳。

步骤905，将生成的第二快照存入磁盘，并同时在原第二重做日志和新建第二重做日志中记录第二快照事务的结束标记，第二快照事务的结束标记包括第二快照的检查点所存入的文件名称。

在本实施例中，当第二快照事务完成时，可以将生成的第二快照存入磁盘，并同时在原第二重做日志和新建的第二重做日志中记录第二快照事务的结束标记。其中，第二快照事务的结束标记包括第二快照的检查点所存入的文件名称。

之后，当数据处理节点崩溃或发送第二业务量数据至业务节点失败时，可以查询新建的第二重做日志中是否包括第二快照事务的结束标记，若包括，则可以根据第二快照事务的结束标记中包括的第二快照的检查点所存入的文件名称，得到第二快照，继而根据第二快照，恢复生成第二快照时内存中的数据集。

步骤906，响应于同时在原第二重做日志和新建第二重做日志中记录第二快照事务的结束标记完成，删除原第二重做日志。

在本实施例中，在同时在原第二重做日志和新建第二重做日志中记录第二快照事务的结束标记完成之后，可以删除原第二重做日志以节省单机节点的磁盘空间。

在本实施例的一个具体使用场景中，上述的位于数据处理节点中的Sender每隔一段时间，或者是完成了一定数量的事务后，将生成快照并清理本地Redo-Log，以免本地Redo-Log过大。生成快照时，首先产生新的本地Redo-Log，从此刻起，所有的记录都要同时向新旧两个本地Redo-Log中进行追加操作。然后查询当前正在进行中的事务，生成一份当前数据集的快照，并在Redo-Log中记录<BEGIN CHECKPOINT filename,T1,T2,…>(filename指的是检查点所存入的文件名称)，其中<T1,T2,…>是当前正在进行中的事务编号(同时也是时间戳，指示一批数据的编号)。将修改后的快照存入磁盘后，记录<FINISHCHECKPOINT filename>(filename指的是检查点所存入的文件名称)。从此刻起，可以抛弃旧的本地Redo-Log，而使用新的本地Redo-Log。

在发生系统故障时，Sender可以直接加载最新的快照，并且重放此次快照之后所有成功事务造成的数据更改。对于合并来自于多个单机节点的第一业务量数据，得到第二业务量数据的事务，可以安全的抛弃掉未完成的事务，从最后一次成功的合并来自于多个单机节点的第一业务量数据，得到第二业务量数据事务处继续执行。对于数据发送类事务，因为不知道系统结束时数据是否已经发送成功，所以必须进行重试直到事务成功。

从图9中可以看出，与图8对应的实施例相比，本实施例中的分析用户业务量的方法的流程900突出了生成第二快照的步骤。由此，本实施例描述的方案可以引入第二快照，从而实现在生成第二快照失败时对已提交事务的前滚和未提交事务的回滚，完成数据恢复。

进一步参考图10，其示出了根据本申请实施例的基于图9的分析用户业务量的方法的一个示意性流程图1000。该分析用户业务量的方法的流程1000，在图9的分析用户业务量的方法的基础上，上述的根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据，可以包括以下步骤：

步骤1001，记录第二获取事务的开始标记至第二重做日志。

在本实施例中，数据处理节点可以记录第二获取事务的开始标记至第二重做日志。其中，第二获取事务为根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据的事务；第二获取事务的开始标记包括获取的第一业务量数据的时间戳，也即读取的第一消息队列的时间戳。

步骤1002，根据获取的第一业务量数据的时间戳，获取第一业务量数据。

在本实施例中，在步骤1001记录第二获取事务的开始标记至第二重做日志之后，可以从接收的第一消息队列中获取第一业务量数据。

步骤1003，逐条解析第一业务量数据，根据第一业务量数据的IP地址和时间戳，判断当前解析的第一业务量数据与之前解析的第一业务量数据是否为重复数据。

在本实施例中，对于从接收的第一消息队列中获取的第一业务量数据，可以逐条进行解析，以便判断当前解析的第一业务量数据与之前解析的第一业务量数据是否为重复数据。在进行上述判断时，可以将当前解析的第一业务量数据的IP地址和时间戳的与之前解析的第一业务量数据的IP地址和时间戳分别进行比对，若比对结果相同，则判断结果为当前解析的第一业务量数据与之前解析的第一业务量数据为重复数据。

步骤1004，若重复，抛弃当前解析的第一业务量数据，并记录抛弃标记至第二重做日志。

在本实施例中，若步骤1003中的判断结果表明当前解析的第一业务量数据与之前解析的第一业务量数据为重复数据，则抛弃当前解析的第一业务量数据，可以记录抛弃标记至第二重做日志，以便在第二获取事务失败或数据处理节点发生崩溃时，根据第二重做日志中的抛弃标记确定需要进行去重处理的下一条的第一业务量数据的编号，也即确定抛弃的第一业务量数据的接续编号。其中，抛弃标记包括抛弃的第一业务量数据的时间戳和抛弃的第一业务量数据的接续编号。

步骤1005，若不重复，将当前解析的第一业务量数据合并至内存中属于同一用户的数据集中以累积第二业务量数据，并记录第二获取事务的单条合并成功标记至第二重做日志。

在本实施例中，在对获取的具有同一时间戳Ti的第一业务量数据进行逐条解析及去重处理之时，可以将不重复的第一业务量数据合并至内存中属于同一用户的数据集中以累积第二业务量数据，并记录第二获取事务的单条合并成功标记至第二重做日志。其中，第二获取事务的单条合并成功标记包括合并成功的单条第一业务量数据的时间戳和合并成功的单条第一业务量数据的接续编号。

步骤1006，响应于不同单机节点中具有同一时间戳的第一业务量数据全部合并完成或合并第一业务量数据的时间达到预置的合并时间，记录第二获取事务的结束标记至第二重做日志。

在本实施例中，数据处理节点可以响应于不同单机节点中具有同一时间戳的第一业务量数据全部合并完成，记录第二获取事务的结束标记至第二重做日志，也可以响应于合并第一业务量数据的时间达到预置的合并时间，记录第一获取事务的结束标记至第一重做日志。其中，第二获取事务的结束标记包括获取的第一业务量数据的时间戳和获取的最后一条第一业务量数据的接续编号；获取的最后一条第一业务量数据的接续编号指示当前读取的第一消息队列中的位置信息。

从图10中可以看出，与图9对应的实施例相比，本实施例中的分析用户业务量的方法的流程1000突出了记录第二获取事务的处理标记至第二重做日志的步骤。由此，本实施例描述的方案可以引入第二重做日志，从而在得到第二业务量数据失败时，可以对得到第二业务量数据的事务进行恢复。

进一步参考图11，其示出了根据本申请实施例的基于图10的分析用户业务量的方法的一个示意性流程图1100。该分析用户业务量的方法1100，在图10的分析用户业务量的方法的基础上，还包括以下步骤：

步骤1101，响应于执行第二操作流程失败，加载最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改。

在本实施例中，当执行第二操作流程失败时，可以根据新建第二重做日志，得到最后一次的第二快照之后由成功事务造成的数据更改，之后加载最后一次的第二快照以及得到的数据更改，以便将内存中的数据集以及正在执行的事务恢复至执行失败之前的状态。

在本实施例的一些可选方式中，响应于执行第二操作流程失败，加载最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改可以包括：响应于根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据失败，加载最后一次的第二快照和新建第二重做日志中最后一次记录的第二获取事务的结束标记。

在本实现方式中，响应于将解析的第一业务量数据合并为第二业务量数据失败，可以加载最后一次的第二快照和新建第二重做日志中最后一次记录的第二获取事务的结束标记，以便根据该第二快照恢复内存中的数据集，根据该结束标记中包括的获取的第一业务量数据的时间戳和获取的最后一条第一业务量数据的接续编号，确定需要解析的下一条第一业务量数据。

在本实施例的一些可选方式中，响应于执行第二操作流程失败，加载最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改可以包括：响应于发送第二业务量数据至业务节点失败，加载最后一次的第二快照和新建第二重做日志中未记录第二发送事务的结束标记的第二发送事务的开始标记。

在本实现方式中，响应于发送第二业务量数据至业务节点失败，可以加载最后一次的第二快照和新建第二重做日志中未记录第二发送事务的结束标记的第二发送事务的开始标记，以便根据该第二快照恢复内存中的数据集，根据未记录第二发送事务的结束标记的第二发送事务的开始标记中包括的发送的第二业务量数据的时间戳，确定需要发送的第二业务量数据，之后发送确定的该第二业务量数据。

步骤1102，根据最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改，执行第二操作流程。

在本实施例中，可以根据加载的最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改，重新执行之前失败的第二操作流程。

在本实施例的一些可选实现方式中，与上述的响应于根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据失败，加载最后一次的第二快照和新建第二重做日志中最后一次记录的第二获取事务的结束标记相对应，根据最后一次的第二快照以及数据更改，执行第二操作流程可以包括：根据最后一次的第二快照和新建第二重做日志中最后一次记录的第二获取事务的结束标记，继续执行根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据，之后执行发送第二业务量数据至业务节点。

在本实施例的一些可选实现方式中，与上述的响应于发送第二业务量数据至业务节点失败，加载最后一次的第二快照和新建第二重做日志中未记录第二发送事务的结束标记的第二发送事务的开始标记相对应，根据最后一次的第二快照以及数据更改，执行第二操作流程可以包括：根据最后一次的第二快照和新建第二重做日志中未记录第二发送事务的结束标记的第二发送事务的开始标记，重试发送第二业务量数据至业务节点。

从图11中可以看出，与图10对应的实施例相比，本实施例中的分析用户业务量的流程1100突出了恢复失败的第二操作流程的步骤。由此，本实施例描述的方案可以防止数据处理节点在执行第二操作流程时因宕机而造成数据丢失。

作为对上述各图所示方法的实现，本申请提供了一种分析用户业务量的系统的一个实施例，该系统实施例与图2所示的方法实施例相对应，该系统中的各个节点可以应用于各服务器中。

如图12所示，本实施例的分析用户业务量的系统1200包括：单机节点1201，数据处理节点1202和业务节点1203。

单机节点1201，用于以分钟为间隔进行以下操作：获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，发送第一业务量数据至数据处理节点。

在本实施例中，单机节点可以为服务器集群中的服务器，通过服务器集群将很多服务器集中起来一起进行同一种服务，在客户端看来服务器集群就像是只有一个服务器。服务器集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个服务器坏了整个服务器集群还是能正常运行。

在上述的多个服务器中，每一个服务器可以作为单机节点，获取本地具有同一时间戳Ti的请求日志，该请求日志用于记录用户的业务量请求，例如记录用户的流量、容量和API调用等业务量请求，该请求日志的时间戳的格式为年月日时分。

每一个单机节点在获取本地具有同一时间戳Ti的请求日志之后，从请求日志中解析出分析业务量所需要的初始业务量数据，并将属于同一用户的初始业务量数据进行合并，得到第一业务量数据。

数据处理节点1202，用于以分钟为间隔进行以下操作：根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据，发送第二业务量数据至业务节点。

在本实施例中，第二操作流程可以运行于数据处理节点上。该数据处理节点，可以根据接收的第一业务量数据以及服务器的硬件配置来确定：当接收的第一业务量数据较少能够和处理初始业务量数据的单机节点合并时，数据处理节点可以是上述的单机节点中的一个；当接收的第一业务量数据需要使用单独的服务器进行处理时，数据处理节点也可以是独立于上述的单机节点的进行数据处理的专用服务器，该专用服务器可以位于上述的包括单机节点的服务器集群中，也可以独立于上述的包括单机节点的服务器集群存在；当接收的第一业务量数据特别多需要使用多台服务器组成专用服务器集群进行处理时，数据处理节点还可以是专用的服务器集群。

数据处理节点在接收到上述的多个单机节点发送的第一业务量数据之后，可以按照用户信息，合并来自于不同单机节点且具有统一时间戳的第一业务量数据。

业务节点1203，根据接收的第二业务量数据，分析用户业务量。

在本实施例中，该业务节点，与数据处理节点类似，可以根据接收的第二业务量数据以及服务器的硬件配置来确定：当接收的第二业务量数据能够和初始业务量数据和/或第一业务量数据位于同一单机节点处理时，业务节点可以是上述的单机节点或数据处理节点中的一个；当接收的第二业务量数据需要使用单独的服务器进行处理时，业务节点也可以是独立于上述的单机节点或数据处理节点的进行用户业务量分析的专用服务器，该专用服务器可以位于上述的包括单机节点的服务器集群中，也可以独立于上述的包括单机节点的服务器集群存在；当接收的第二业务量数据特别多，需要使用多台服务器组成专用服务器集群进行处理时，业务节点还可以是专用的服务器集群。

本申请的上述实施例提供的系统在业务量数据传输的过程中进行了两次数据合并，减少了不必要的重复数据的传输，并实现了按分钟处理业务量数据，计算延迟较低。

本领域技术人员可以理解，上述各节点中还包括一些其他公知结构，例如处理器、存储器等，为了不必要地模糊本公开的实施例，这些公知的结构在图12中未示出。

下面参考图13，其示出了适于用来实现本申请实施例的服务器的计算机系统1300的结构示意图。

如图13所示，计算机系统1300包括中央处理单元(CPU)1301，其可以根据存储在只读存储器(ROM)1302中的程序或者从存储部分1308加载到随机访问存储器(RAM)1303中的程序而执行各种适当的动作和处理。在RAM 1303中，还存储有系统1300操作所需的各种程序和数据。CPU 1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(I/O)接口1305也连接至总线1304。

以下部件连接至I/O接口1305：包括键盘、鼠标等的输入部分1306；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1307；包括硬盘等的存储部分1308；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1309。通信部分1309经由诸如因特网的网络执行通信处理。驱动器1310也根据需要连接至I/O接口1305。可拆卸介质1311，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1310上，以便于从其上读出的计算机程序根据需要被安装入存储部分1308。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，所述计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1309从网络上被下载和安装，和/或从可拆卸介质1311被安装。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本申请还提供了一种非易失性计算机存储介质，该非易失性计算机存储介质可以是上述实施例中所述系统中所包含的非易失性计算机存储介质；也可以是单独存在，未装配入终端中的非易失性计算机存储介质。上述非易失性计算机存储介质存储有一个或者多个程序，当所述一个或者多个程序被一个设备执行时，使得所述系统：单机节点以分钟为间隔执行以下第一操作流程：获取具有同一时间戳的请求日志，从请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，发送第一业务量数据至数据处理节点，其中，所述请求日志用于记录用户的业务量请求，所述时间戳的格式为年月日时分；数据处理节点以分钟为间隔执行以下第二操作流程：根据用户信息，合并来自于不同单机节点且具有同一时间戳的第一业务量数据，得到第二业务量数据，发送第二业务量数据至业务节点；业务节点根据接收的第二业务量数据，分析用户业务量。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims

1.一种分析用户业务量的方法，其特征在于，所述方法包括：

单机节点以分钟为间隔执行以下第一操作流程：获取具有同一时间戳的请求日志，从所述请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，发送所述第一业务量数据至数据处理节点，其中，所述请求日志用于记录用户的业务量请求，所述时间戳的格式为年月日时分；

所述数据处理节点以分钟为间隔执行以下第二操作流程：根据用户信息，合并来自于不同单机节点且具有所述同一时间戳的所述第一业务量数据，得到第二业务量数据，发送所述第二业务量数据至业务节点；

所述业务节点根据接收的所述第二业务量数据，分析用户业务量。

2.根据权利要求1所述的方法，其特征在于，所述发送所述第一业务量数据至数据处理节点包括：

发送所述第一业务量数据至数据处理节点，并记录第一发送事务的处理标记至预设的第一重做日志；

其中，所述第一发送事务为发送所述第一业务量数据至数据处理节点的事务；所述第一发送事务的处理标记至少包括所述第一发送事务的开始标记和结束标记。

3.根据权利要求2所述的方法，其特征在于，所述发送所述第一业务量数据至数据处理节点，并记录第一发送事务的处理标记至预设的第一重做日志包括：

记录第一发送事务的开始标记至预设的第一重做日志，其中，所述第一发送事务的开始标记包括发送的第一业务量数据的时间戳；

根据所述发送的第一业务量数据的时间戳，获取第一业务量数据；

将获取的所述第一业务量数据编号，形成第一消息队列；

发送所述第一消息队列至所述数据处理节点；

响应于发送所述第一消息队列失败，重试发送所述第一消息队列；

若所述第一消息队列重试发送的次数达到第一预设重试次数或重试发送的时间达到第一预设重试时间，将从内存中获取的所述第一业务量数据合并回内存，并记录第一发送事务的异常终止标记至所述第一重做日志，其中，所述第一发送事务的异常终止标记包括发送失败的第一业务量数据的时间戳；

响应于发送所述第一消息队列成功，更新发送所述第一消息队列的编号，并记录第一发送事务的结束标记至所述第一重做日志，其中，所述第一发送事务的结束标记包括发送成功的第一业务量数据的时间戳和发送成功的第一业务量数据的接续编号。

4.根据权利要求3所述的方法，其特征在于，所述发送所述第一业务量数据至数据处理节点还包括：

响应于发送所述第一业务量数据成功，间隔第一预定时间删除内存中发送成功的所述第一业务量数据；

响应于将发送失败的第一业务量数据合并回内存的次数超过第一预置次数或持续发送失败的时间超过第一预置时间，触发报警提醒。

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

单机节点间隔第一预设时间或响应于发送成功第一预设数量的所述第一业务量数据至数据处理节点，新建第一重做日志；

响应于新建第一重做日志完成，同时在原第一重做日志和所述新建第一重做日志中记录第一获取事务的处理标记和第一发送事务的处理标记；

查询当前正在进行的事务的时间戳；

生成内存中数据集的第一快照，并同时在所述原第一重做日志和所述新建第一重做日志中记录第一快照事务的开始标记，其中，所述第一快照事务的开始标记包括第一快照的检查点所存入的文件名称和正在进行的事务的时间戳；

将生成的第一快照存入磁盘，并同时在所述原第一重做日志和所述新建第一重做日志中记录第一快照事务的结束标记，其中，所述第一快照事务的结束标记包括第一快照的检查点所存入的文件名称；

响应于同时在所述原第一重做日志和所述新建第一重做日志中记录第一快照事务的结束标记完成，删除所述原第一重做日志。

6.根据权利要求5所述的方法，其特征在于，所述获取具有同一时间戳的请求日志，从所述请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据包括：

获取具有同一时间戳的请求日志，从所述请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，并记录第一获取事务的处理标记至所述第一重做日志；

其中，所述第一获取事务为获取具有同一时间戳的请求日志，从所述请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据的事务；所述第一获取事务的处理标记至少包括所述第一获取事务的开始标记和结束标记。

7.根据权利要求6所述的方法，其特征在于，所述获取具有同一时间戳的请求日志，从所述请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，并记录第一获取事务的处理标记至所述第一重做日志包括：

记录第一获取事务的开始标记至所述第一重做日志，其中，所述第一获取事务的开始标记包括获取的请求日志的时间戳；

根据所述获取的请求日志的时间戳，获取请求日志；

从所述请求日志中逐条解析初始业务量数据，将解析的初始业务量数据合并至内存中属于同一用户的数据集中以累积第一业务量数据，并记录第一获取事务的单条解析成功标记至所述第一重做日志，其中，所述第一获取事务的单条解析成功标记包括解析成功的单条请求日志的时间戳、所述数据集的原始值和修改后值；以及

响应于解析单条请求日志成功的次数符合预设的解析次数或完成单机节点中所有请求日志的解析，记录第一获取事务的结束标记至所述第一重做日志，其中，所述第一获取事务的结束标记包括获取的请求日志的时间戳和请求日志文件中的偏移量。

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

响应于执行所述第一操作流程失败，加载最后一次的第一快照以及最后一次的第一快照之后由成功事务造成的数据更改，其中，所述数据更改根据所述新建第一重做日志得到；

根据所述最后一次的第一快照以及所述数据更改，执行所述第一操作流程。

9.根据权利要求8所述的方法，其特征在于，所述响应于执行所述第一操作流程失败，加载最后一次的第一快照以及最后一次的第一快照之后由成功事务造成的数据更改包括：响应于获取具有同一时间戳的请求日志，从所述请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据失败，加载最后一次的第一快照和所述新建第一重做日志中最后一次记录的第一获取事务的结束标记；以及

所述根据所述最后一次的第一快照以及所述数据更改，重新执行所述第一操作流程包括：根据所述最后一次的第一快照和所述新建第一重做日志中最后一次记录的第一获取事务的结束标记，继续获取具有同一时间戳的请求日志，从所述请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，发送所述第一业务量数据至数据处理节点。

10.根据权利要求8所述的方法，其特征在于，所述响应于执行所述第一操作流程失败，加载最后一次的第一快照以及最后一次的第一快照之后由成功事务造成的数据更改包括：响应于所述以分钟为间隔发送所述第一业务量数据至数据处理节点失败，加载最后一次的第一快照和所述新建第一重做日志中未记录第一发送事务的结束标记的第一发送事务的开始标记；以及

所述根据所述最后一次的第一快照以及所述数据更改，重新执行所述第一操作流程包括：根据所述最后一次的第一快照和所述新建第一重做日志中未记录第一发送事务的结束标记的第一发送事务的开始标记，重新发送所述第一业务量数据至数据处理节点。

11.根据权利要求1-10之一所述的方法，其特征在于，所述发送所述第二业务量数据至所述业务节点包括：

发送所述第二业务量数据至所述业务节点，并记录第二发送事务的处理标记至预设的第二重做日志；

其中，所述第二发送事务为发送所述第二业务量数据至数据处理节点的事务；所述第二发送事务的处理标记至少包括所述第二发送事务的开始标记和结束标记。

12.根据权利要求11所述的方法，所述发送所述第二业务量数据至所述业务节点，并记录第二发送事务的处理标记至预设的第二重做日志包括：

记录第二发送事务的开始标记至预设的第二重做日志，其中，所述第二发送事务的开始标记包括发送的第二业务量数据的时间戳；

根据所述发送的第二业务量数据的时间戳，获取第二业务量数据；

将获取的第二业务量数据编号，形成第二消息队列；

发送所述第二消息队列至所述业务节点；

响应于发送所述第二消息队列失败，重试发送所述第二消息队列；

若所述第二消息队列重试发送的次数达到第二预设重试次数或重试发送的时间达到第二预设重试时间，将从内存中获取的所述第二业务量数据合并回内存，并记录第二发送事务的异常终止标记至所述第二重做日志，其中，所述第二发送事务的异常终止标记包括发送失败的第二业务量数据的时间戳；

响应于发送所述第二消息队列成功，更新发送所述第二消息队列的编号，并记录第二发送事务的结束标记至所述第二重做日志，其中，所述第二发送事务的结束标记包括发送成功的第二业务量数据的时间戳和发送成功的第二业务量数据的接续编号。

13.根据权利要求12所述的方法，其特征在于，所述发送所述第二业务量数据至所述业务节点还包括：

响应于所述第二业务量数据发送成功，间隔第二预定时间删除内存中发送成功的所述第二业务量数据；

响应于将发送失败的第二业务量数据合并回内存的次数超过第二预置次数或持续发送失败的时间超过第二预置时间，触发报警提醒。

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

数据处理节点间隔第二预设时间或响应于发送成功第二预设数量的所述第二业务量数据至业务节点，新建第二重做日志；

响应于新建第二重做日志完成，同时在原第二重做日志和所述新建第二重做日志中记录第二获取事务的处理标记和第二发送事务的处理标记；

查询当前正在进行的事务的时间戳；

生成内存中数据集的第二快照，并同时在所述原第二重做日志和所述新建第二重做日志中记录第二快照事务的开始标记，其中，所述第二快照事务的开始标记包括第二快照的检查点所存入的文件名称和正在进行中的事务的时间戳；

将生成的第二快照存入磁盘，并同时在所述原第二重做日志和所述新建第二重做日志中记录第二快照事务的结束标记，其中，所述第二快照事务的结束标记包括第二快照的检查点所存入的文件名称；

响应于同时在所述原第二重做日志和所述新建第二重做日志中记录第二快照事务的结束标记完成，删除所述原第二重做日志。

15.根据权利要求14所述的方法，其特征在于，所述根据用户信息，合并来自于不同单机节点且具有所述同一时间戳的所述第一业务量数据，得到第二业务量数据包括：

根据用户信息，合并来自于不同单机节点且具有所述同一时间戳的所述第一业务量数据，得到第二业务量数据，并记录第二获取事务的处理标记至所述第二重做日志；

其中，所述第二获取事务为根据用户信息，合并来自于不同单机节点且具有所述同一时间戳的所述第一业务量数据，得到第二业务量数据的事务；所述第二获取事务的处理标记至少包括所述第二获取事务的开始标记和结束标记。

16.根据权利要求15所述的方法，其特征在于，所述根据用户信息，合并来自于不同单机节点且具有所述同一时间戳的所述第一业务量数据，得到第二业务量数据，并记录第二获取事务的处理标记至所述第二重做日志包括：

记录第二获取事务的开始标记至所述第二重做日志，其中，所述第二获取事务的开始标记包括获取的第一业务量数据的时间戳；

根据所述获取的第一业务量数据的时间戳，获取第一业务量数据；

逐条解析所述第一业务量数据，根据所述第一业务量数据的IP地址和时间戳，判断当前解析的第一业务量数据与之前解析的第一业务量数据是否为重复数据；

若重复，抛弃当前解析的第一业务量数据，并记录抛弃标记至所述第二重做日志，其中，所述抛弃标记包括抛弃的第一业务量数据的时间戳和抛弃的第一业务量数据的接续编号；

若不重复，将当前解析的所述第一业务量数据合并至内存中属于同一用户的数据集中以累积第二业务量数据，并记录第二获取事务的单条合并成功标记至所述第二重做日志，其中，所述第二获取事务的单条合并成功标记包括合并成功的单条第一业务量数据的时间戳和合并成功的单条第一业务量数据的接续编号；以及

响应于不同单机节点中具有所述同一时间戳的所述第一业务量数据全部合并完成或合并第一业务量数据的时间达到预置的合并时间，记录第二获取事务的结束标记至所述第二重做日志，所述第二获取事务的结束标记包括获取的第一业务量数据的时间戳和获取的最后一条第一业务量数据的接续编号。

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

响应于执行第二操作流程失败，加载最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改；

根据所述最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改，重新执行所述第二操作流程。

18.根据权利要求17所述的方法，其特征在于，所述响应于执行第二操作流程失败，加载最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改包括：响应于根据用户信息，合并来自于不同单机节点且具有所述同一时间戳的所述第一业务量数据，得到第二业务量数据失败，加载最后一次的第二快照和所述新建第二重做日志中最后一次记录的第二获取事务的结束标记；以及

所述根据所述最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改，重新执行所述第二操作流程包括：根据所述最后一次的第二快照和所述新建第二重做日志中最后一次记录的第二获取事务的结束标记，重新执行所述根据用户信息，合并来自于不同单机节点且具有所述同一时间戳的所述第一业务量数据，得到第二业务量数据，发送所述第二业务量数据至业务节点。

19.根据权利要求17所述的方法，其特征在于，所述响应于执行第二操作流程失败，加载最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改包括：响应于发送所述第二业务量数据至业务节点失败，加载最后一次的第二快照和所述新建第二重做日志中未记录第二发送事务的结束标记的第二发送事务的开始标记；以及

所述根据所述最后一次的第二快照以及最后一次的第二快照之后由成功事务造成的数据更改，重新执行所述第二操作流程包括：根据所述最后一次的第二快照和所述新建第二重做日志中未记录第二发送事务的结束标记的第二发送事务的开始标记，重试发送所述第二业务量数据至业务节点。

20.一种分析用户业务量的系统，其特征在于，所述系统包括：

单机节点，用于以分钟为间隔进行以下操作：获取具有同一时间戳的请求日志，从所述请求日志中解析初始业务量数据，合并属于同一用户的初始业务量数据，得到第一业务量数据，发送所述第一业务量数据至数据处理节点,其中，所述请求日志用于记录用户的业务量请求，所述时间戳的格式为年月日时分；

所述数据处理节点，用于以分钟为间隔进行以下操作：根据用户信息，合并来自于不同单机节点且具有所述同一时间戳的所述第一业务量数据，得到第二业务量数据，发送所述第二业务量数据至业务节点；

所述业务节点，根据接收的所述第二业务量数据，分析用户业务量。