流量统计方法及装置、分布式流量统计系统

技术领域

本公开实施例涉及流量统计技术领域，特别涉及流量统计方法及装置、分布式流量统计系统、电子设备、计算机可读介质。

背景技术

目前，随着互联网技术的快速发展，开放平台(OpenAPI)作为互联网在线服务的发展基础，已经成为越来越多互联网企业发展服务的必然选择和战略发展方向。

OpenAPI是大平台发展、共享的途径，网站服务商将自己的服务封装成一系列应用程序接口(API)开放出去，供第三方开发者使用，让开发者以较低的成本开发商业应用。开放平台可以向企业、政府等第三方机构开放数据访问接口，以供相关机构进行数据调用、实现第三方业务。

发明内容

本公开实施例提供一种流量统计方法及装置、分布式流量统计系统、电子设备、计算机可读介质。

第一方面，本公开实施例提供一种流量统计方法，包括：

获取当前预设时间段内多个IAM用户的用户请求，多个IAM用户为OpenAPI的接入用户，每个IAM用户对应配置有至少一个基于OpenAPI的应用服务；

在本地内存中创建当前内存并发统计队列，并将当前预设时间段内多个IAM用户的用户请求缓存至对应的当前内存并发统计队列；

将当前内存并发统计队列中的用户请求，按照所属应用服务进行流量统计，以统计出当前预设时间段内每个IAM用户的每个应用服务对应的用户请求量。

在一些实施例中，所述统计出当前预设时间段内每个IAM用户的每个应用服务对应的用户请求量之后，还包括：

将统计好的当前预设时间段内的用户请求缓存至对应的本地数据库。

在一些实施例中，所述将统计好的当前预设时间段内的用户请求缓存至对应的本地数据库，包括：利用实时工作线程，每隔设定时间将统计好的用户请求缓存至所述本地数据库。

在一些实施例中，所述将统计好的当前预设时间段内的用户请求缓存至对应的本地数据库之后，还包括：

当所述本地数据库当前缓存的所有用户请求所占内存大小大于或等于预定大小时，将所述本地数据库中缓存的用户请求异步存储至分布式文件系统。

在一些实施例中，所述统计出当前预设时间段内每个IAM用户的每个应用服务对应的用户请求量之后，还包括：

将统计好的当前预设时间段内的用户请求拷贝至无锁队列；

利用至少一个持久化工作线程，将无锁队列中的用户请求持久化至远端数据库中；

将本地数据库中已成功持久化至所述远端数据库的用户请求进行删除。

在一些实施例中，所述远端数据库为mongodb。

在一些实施例中，所述本地数据库为本地rocksdb。

第二方面，本公开实施例提供一种流量统计装置，包括：

获取模块，用于获取当前预设时间段内多个IAM用户的用户请求，多个IAM用户为OpenAPI的接入用户，每个IAM用户对应配置有至少一个基于OpenAPI的应用服务；

队列创建和缓存模块，用于在本地内存中创建当前内存并发统计队列，并将当前预设时间段内多个IAM用户的用户请求缓存至对应的当前内存并发统计队列；

统计模块，用于将当前内存并发统计队列中的用户请求，按照所属应用服务进行流量统计，以统计出当前预设时间段内每个IAM用户的每个应用服务对应的用户请求量。

在一些实施例中，所述队列创建和缓存模块还用于将统计好的当前预设时间段内的用户请求缓存至对应的本地数据库。

在一些实施例中，所述队列创建和缓存模块具体用于利用实时工作线程，每隔设定时间将统计好的用户请求缓存至所述本地数据库。

在一些实施例中，还包括异步存储模块，用于当所述本地数据库当前缓存的所有用户请求所占内存大小大于或等于预定大小时，将所述本地数据库中缓存的用户请求异步存储至分布式文件系统。

在一些实施例中，还包括拷贝模块、持久化模块和删除模块；

所述拷贝模块用于将统计好的当前预设时间段内的用户请求拷贝至无锁队列；

所述持久化模块用于利用至少一个持久化工作线程，将无锁队列中的用户请求持久化至远端数据库中；

所述删除模块用于将本地数据库中已成功持久化至所述远端数据库的用户请求进行删除。

在一些实施例中，所述远端数据库为mongodb。

在一些实施例中，所述本地数据库为本地rocksdb。

第三方面，本公开实施例提供一种分布式流量统计系统，包括：统计代理层和多个流量统计装置；

其中，所述统计代理层用于从OpenAPI的入口层接收多个IAM用户的用户请求，并将多个IAM用户的用户请求分发给多个流量统计装置；

每个所述流量统计装置用于实现上述权利要求1-8中任一项所述的流量统计方法。

在一些实施例中，所述统计代理层具体用于通过一致性哈希算法，将多个IAM用户的用户请求分发给多个流量统计装置。

第四方面，本公开实施例提供一种电子设备，其包括：

一个或多个处理器；

存储器，其上存储有一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一实施例所述的流量统计方法；

一个或多个I/O接口，连接在所述处理器与存储器之间，配置为实现所述处理器与所述存储器的信息交互。

第五方面，本公开实施例提供一种计算机可读介质，其上存储有计算机程序，其中，所述计算机程序被执行时实现上述任一实施例所述的流量统计方法。

本公开实施例提供的流量统计方法及装置、分布式流量统计系统、电子设备、计算机可读介质，利用本地内存创建高效的内存并发统计队列，从使用维度(所属IAM用户和所属应用服务)和时间维度(预设时间段)实现OpenAPI的流量的统计。相较于传统的使用离线日志的统计方式，本公开实施例所提供的流量统计方法，实时性较高，且统计结果的准确性较好。

附图说明

附图用来提供对本公开实施例的进一步理解，并且构成说明书的一部分，与本公开的实施例一起用于解释本公开，并不构成对本公开的限制。通过参考附图对详细示例实施例进行描述，以上和其他特征和优点对本领域技术人员将变得更加显而易见，在附图中：

图1为本公开实施例一提供的一种流量统计方法的流程图；

图2为本公开实施例一中一种内存并发统计队列的结构示意图；

图3为本公开实施例二提供的一种流量统计方法的流程图；

图4为本公开实施例二中一种本地数据库的结构示意图；

图5为本公开实施例三提供的一种流量统计方法的流程图；

图6为本公开实施例四提供的一种流量统计方法的流程图；

图7为本公开实施例五提供的一种流量统计装置的组成框图；

图8为本公开实施例六提供的一种流量统计装置的组成框图；

图9为本公开实施例七提供的一种流量统计装置的组成框图；

图10为本公开实施例八提供的一种分布式流量统计系统的组成框图；

图11为本公开实施例九提供的一种电子设备的组成框图。

具体实施方式

为使本领域的技术人员更好地理解本公开的技术方案，下面结合附图对本公开提供的流量统计方法及装置、分布式流量统计系统、电子设备、计算机可读介质进行详细描述。

在下文中将参考附图更充分地描述示例实施例，但是所述示例实施例可以以不同形式来体现且不应当被解释为限于本文阐述的实施例。反之，提供这些实施例的目的在于使本公开透彻和完整，并将使本领域技术人员充分理解本公开的范围。

在不冲突的情况下，本公开各实施例及实施例中的各特征可相互组合。

如本文所使用的，术语“和/或”包括一个或多个相关列举条目的任何和所有组合。

本文所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其他特征、整体、步骤、操作、元件、组件和/或其群组。

除非另外限定，否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。

实施例一

图1为本公开实施例一提供的一种流量统计方法的流程图，如图1所示，该方法可以由流量统计装置来执行，该装置可以通过软件和/或硬件的方式实现，该装置可以集成在如服务器等电子设备中。该流量统计方法包括：

步骤11、获取当前预设时间段内多个IAM用户的用户请求。

其中，IAM用户为开放平台(OpenAPI)的接入用户。在本实施例中，开放平台预先为每个接入用户关联一个唯一的身份标识(ID)及对应的账户信息，同时使用身份识别与访问管理系统(Identity and Access Management，简称：IAM)对每个接入用户进行身份验证和授权以使用资源，每个接入用户称为开放平台(OpenAPI)的IAM用户。

在本实施例中，IAM用户即为第三方开发者、第三方机构。每个IAM用户可以在开放平台的控制台上创建一个或多个应用(APP)，每个应用具有唯一的应用标识(Key)，每个应用Key可以具有一个或多个服务权限，以便于IAM用户做权限管理，每个应用Key对应的服务被称为应用服务。例如，一个出行类APP的开发机构在地图开放平台创建一个出行APP，使用应用标识KEY1，该应用下开通了定位服务、地理编码服务、路径规划服务等，通过调用这些服务实现司乘人员位置追踪和司机端导航等功能。因此，在本实施例中，每个IAM用户可以在每个基于开放平台的应用中对应配置有至少一个基于开放平台的应用服务。

当使用者通过IAM用户的应用(APP)访问开放平台，以请求使用该应用相应的基于开放平台的应用服务时，相当于向开放平台发送一条用户请求。

在本实施例中，为了统计开放平台的访问流量，首先，在步骤11中，获取当前预设时间段内多个IAM用户的用户请求。其中，预设时间段可以为秒级的时间段、分级的时间段、小时级的时间段或天级的时间段，例如，预设时间段为1秒(s)。

步骤12、在本地内存中创建当前内存并发统计队列，并将当前预设时间段内多个IAM用户的用户请求缓存至对应的当前内存并发统计队列。

在本实施例中，在步骤12中，在本地内存中创建当前内存并发(concurrent)统计队列，在获取当前预设时间段内多个IAM用户的用户请求后，将当前预设时间段内多个IAM用户的用户请求缓存至当前内存并发统计队列中。

图2为本公开实施例一中一种内存并发统计队列的结构示意图，如图2所示，在一些实施例中，内存并发统计队列包括多个(如16个)桶单元(Bucket_0、Bucket_1、Bucket_2、……、Bucket_16)，即内存并发统计队列采用分桶机制缓存多个IAM用户的用户请求。具体地，可以利用哈希(Hash)算法，将多个IAM用户的用户请求分发至多个桶单元中进行缓存。利用分桶机制进行缓存，能够有效减少锁冲突。

可以理解的是，在每个预设时间段内，每获取预设时间段内的多个IAM用户的用户请求后，均在本地内存创建新的内存并发统计队列作为用于缓存该预设时间段内多个IAM的用户请求的内存并发统计队列。

步骤13、将当前内存并发统计队列中的用户请求，按照所属应用服务进行流量统计，以统计出当前预设时间段内每个IAM用户的每个应用服务对应的用户请求量。

在本实施例中，用户请求中携带有所属IAM用户的身份标识(ID)、所请求使用的应用服务的服务名称(service_name)、以及请求的时间戳(timestamp)。

在步骤13中，将当前内存并发统计队列中的所有用户请求，按照所属IAM用户和所属应用服务进行分类，以统计出当前预设时间段内每个IAM用户的每个应用服务对应的用户请求量。

例如，多个IAM用户包括用户a1、用户a2，用户a1对应的应用服务包括服务service1、服务service2，用户a2对应的应用服务包括服务service1、服务service2。假设在当前预设时间段内，用户a1对应的用户请求有4个，用户a2对应的用户请求有5个。其中，针对用户a1，有2个用户请求所属的应用服务为服务service1，剩余2个用户请求所属的应用服务为服务service2；针对用户a2，有2个用户请求所属的应用服务为服务service1，剩余3个用户请求所属的应用服务为服务service2。则在步骤13中，统计出当前预设时间段内，用户a1的服务service1对应的用户请求量为2，用户a1的服务service2对应的用户请求量为2，用户a2的服务service1对应的用户请求量为2，用户a2的服务service2对应的用户请求量为3。

在本实施例中，预设时间段可以为1秒，则通过上述步骤11至步骤13，可以统计出每个IAM用户的每个应用服务对应的每秒用户请求量(QPS)，进而还可以统计出每个IAM用户的每个应用服务对应的页面浏览量(PV)，其中，页面浏览量等于每秒用户请求量的累加。

本实施例所提供的流量统计方法，获取当前预设时间段内多个IAM用户的用户请求，创建当前内存并发统计队列，并将当前预设时间段内多个IAM用户的用户请求缓存至对应的当前内存并发统计队列，将当前内存并发统计队列中的用户请求，按照所属应用服务进行流量统计，以统计出当前预设时间段内每个IAM用户的每个应用服务对应的用户请求量。本实施例利用本地内存创建高效的内存并发统计队列，从使用维度(所属IAM用户和所属应用服务)和时间维度(预设时间段)实现OpenAPI的流量的统计。相较于传统的使用离线日志的统计方式，本实施例所提供的流量统计方法，实时性较高，且统计结果的准确性较好。

实施例二

图3为本公开实施例二提供的一种流量统计方法的流程图，如图3所示，本公开实施例二所提供的流量统计方法与前述实施例一的流量统计方法的区别在于：步骤13之后还包括步骤14，下面仅针对步骤14进行描述，其他具体描述可参见前述实施例一的流量统计方法的描述，此处不再赘述。

步骤14、将统计好的当前预设时间段内的用户请求缓存至对应的本地数据库。

在步骤14中，在统计出当前预设时间段内每个IAM用户的每个应用服务对应的用户请求量后，将统计好的当前预设时间段内的用户请求写入对应的本地数据库进行缓存。具体地，在步骤14中，通过设定的实时工作线程(realtime-worker)，每隔设定时间将统计好的用户请求缓存至本地数据库，从而实时地将统计好的用户请求缓存至本地数据库。其中，设定时间可以是毫秒(ms)级的时间。

在本实施例中，本地数据库可以采用基于日志结构的合并树(LSM-Tree)的rocksdb，rocksdb是一种基于LSM-Tree的存储引擎，是一个持久型的键值(Key-value)存储系统。

在本实施例中，由于采用了本地内存，一旦机器重启或故障，本地的内存并发统计队列中的数据就面临丢失的风险，导致流量统计不准确，为了解决该问题，采用基于LSM-Tree的rocksdb作为本地数据库，利用其高效的写入性能，将统计好的数据(用户请求)写入rocksdb。

图4为本公开实施例二中一种本地数据库的结构示意图，如图4所示，在本实施例中，本地数据库基于用户(user)维度和应用(app)维度存储统计好的用户请求。其中，本地数据库基于用户维度，按照哈希hash(user_id+service_name)％100的方式切分成多个子库，user表示IAM用户，user_id表示IAM用户的身份标识，service_name表示IAM用户对应的应用服务的服务名称，例如user维度下的slot_0、slot_1代表两个user维度的子库，基于用户维度存储每个IAM用户的每个服务对应的用户请求(realtimeData)，例如某出行APP开发机构使用地理编码服务的用户请求(realtimeData)。

本地数据库基于应用维度，按照哈希hash(user_id+app_id+service_name)％100的方式切分成多个子库，user_id表示IAM用户的身份标识，app_id表示IAM用户创建的应用的应用标识，service_name表示应用服务的服务名称，例如app维度下的slot_0、slot_1代表两个app维度的子库，基于应用维度存储每个IAM用户的每个应用的每个应用服务对应的用户请求(realtimeData)，例如某出行APP开发机构的出行APP对应的路径规划服务的请求量。

此外，本地数据库通过元数据库(MetaData)存储管理本地子库标识数据即总共创建打开了哪些子库，从而可以获取到本地的所有子库标识。通过将本地数据库切分成子库的方式能够有效防止单库数据规模膨胀，在保障整个极高的统计性能的同时保障统计数据的准确性。

实施例三

图5为本公开实施例三提供的一种流量统计方法的流程图，如图5所示，本公开实施例三所提供的流量统计方法与前述实施例二的流量统计方法的区别在于：步骤14之后还包括步骤15和步骤16。下面仅针对步骤15和步骤16进行描述，其他具体描述可参见前述实施例二的流量统计方法的描述，此处不再赘述。

步骤15、判断本地数据库当前缓存的所有用户请求所占内存大小是否小于预定大小，若是，不作进一步处理，否则执行步骤16。

其中，预定大小可以根据实际需要设定，例如，预定大小为2M或15M等。

步骤16、将本地数据库当前缓存的用户请求异步存储至分布式文件系统。

在步骤16中，当本地数据库当前缓存的所有用户请求所占内存大小大于或等于预定大小时，将本地数据库当前缓存的用户请求异步存储至设定的分布式文件系统。从而有效防止单点故障(如本地数据库出现故障)导致数据丢失，进而保障数据的安全性。

实施例四

图6为本公开实施例四提供的一种流量统计方法的流程图，如图6所示，本公开实施例四所提供的流量统计方法与前述实施例二、实施例三的流量统计方法的区别在于：步骤13之后还包括步骤17至步骤19。下面仅针对步骤17至步骤19进行描述，其他具体描述可参见前述实施例二、实施例三的流量统计方法的描述，此处不再赘述。

步骤17、将统计好的当前预设时间段内的用户请求拷贝至无锁队列。

在步骤17中，当统计时间片到达时，将统计好的当前预设时间段内的用户请求拷贝至设定的无锁队列(lock-free queue)。其中，统计时间片可以为预设时间段，即当前预设时间段结束时，将统计好的当前预设时间段内的用户请求拷贝至无锁队列(lock-freequeue)。例如，预设时间段为1秒，则在统计完当前秒的流量后，将当前秒内的用户请求拷贝至无锁队列中。

在一些实施例中，当前内存并发统计队列采用分桶机制缓存当前预设时间段内的用户请求，在步骤17中，可以通过指针传递(switch)的方式，将当前内存并发统计队列中缓存的当前预设时间段内的用户请求拷贝至无锁队列中，无锁队列中存放各个桶单元(bucket)的指针，这样可以提高数据拷贝的效率。

步骤18、利用至少一个持久化工作线程，将无锁队列中的用户请求持久化至远端数据库中。

在本实施例中，定期通过至少一个设定的持久化工作线程(persist-worker)，将无锁队列中的用户请求持久化至远端数据库中。

在一些实施例中，利用至少一个(如3个)持久化工作线程，同时对无锁队列进行扫描，其中，每个持久化工作线程每隔一定时间(如分钟级的时间)对无锁队列中的数据进行扫描，每扫描到一个桶单元的指针，则将该桶单元中的数据弹出(POP)，并持久化至远端数据库中。

在一些实施例中，远端数据库可以采用mongodb，mongodb是一个基于分布式文件存储的数据库。

步骤19、将本地数据库中已成功持久化至远端数据库的用户请求进行删除。

在步骤19中，对于已成功持久化至远端数据库的用户请求，将本地数据库中相应的用户请求进行删除。

在本实施例中，由于本地磁盘和内存空间存储的局限性，因此定期将统计好的用户请求持久化到远端数据库中，同时将已经持久化过的数据从本地数据库中清除，从而可以保障数据存储的扩展性。

实施例五

图7为本公开实施例五提供的一种流量统计装置的组成框图，如图7所示，该流量统计装置用于实现上述的流量统计方法，该流量统计装置包括：获取模块201、队列创建和缓存模块202、统计模块203。

其中，获取模块201用于获取当前预设时间段内多个IAM用户的用户请求，多个IAM用户为OpenAPI的接入用户，每个IAM用户对应配置有至少一个基于OpenAPI的应用服务。

队列创建和缓存模块202用于在本地内存中创建当前内存并发统计队列，并将当前预设时间段内多个IAM用户的用户请求缓存至对应的当前内存并发统计队列。

统计模块203用于将当前内存并发统计队列中的用户请求，按照所属应用服务进行流量统计，以统计出当前预设时间段内每个IAM用户的每个应用服务对应的用户请求量。

在一些实施例中，队列创建和缓存模块202还用于将统计好的当前预设时间段内的用户请求缓存至对应的本地数据库。具体地，队列创建和缓存模块202具体用于利用实时工作线程，每隔设定时间将统计好的用户请求缓存至本地数据库。

实施例六

图8为本公开实施例六提供的一种流量统计装置的组成框图，如图8所示，本公开实施例六提供的流量统计装置与前述实施例五的流量统计装置的区别在于：本公开实施例六所提供的流量统计装置还包括：异步存储模块204，下面仅针对异步存储模块204进行描述，其他相关描述可参见前述实施例五的描述，此处不再赘述。

异步存储模块204用于当本地数据库当前缓存的所有用户请求所占内存大小大于或等于预定大小时，将本地数据库中缓存的用户请求异步存储至分布式文件系统。

实施例七

图9为本公开实施例七提供的一种流量统计装置的组成框图，如图9所示，本公开实施例七提供的流量统计装置与前述实施例六的流量统计装置的区别在于：本公开实施例七所提供的流量统计装置还包括：拷贝模块205、持久化模块206和删除模块207。下面仅针对拷贝模块205、持久化模块206和删除模块207进行描述，其他相关描述可参见前述实施例六的描述，此处不再赘述。

其中，拷贝模块205用于将统计好的当前预设时间段内的用户请求拷贝至无锁队列。

持久化模块206用于利用至少一个持久化工作线程，将无锁队列中的用户请求持久化至远端数据库中。

删除模块207用于将本地数据库中已成功持久化至远端数据库的用户请求进行删除。

在一些实施例中，远端数据库为mongodb。在一些实施例中，本地数据库为本地rocksdb。

此外，本公开实施例所提供的流量统计装置具体用于实现前述流量统计方法，具体相关描述可参见前述流量统计方法的描述，此处不再赘述。

实施例八

图10为本公开实施例八提供的一种分布式流量统计系统的组成框图，如图10所示，该分布式流量统计系统包括：统计代理层301和多个流量统计装置302。

其中，统计代理层301用于从OpenAPI的入口层接收多个IAM用户的用户请求，将多个IAM用户的用户请求分发给多个流量统计装置302。

每个流量统计装置302用于实现上述任一实施例所提供的流量统计方法。

在本实施例中，OpenAPI的入口层每隔预定时间(如10毫秒)将接收到的多个IAM用户的用户请求发送给统计代理层301，统计代理层301再将每隔预定时间(如10毫秒)接收到的多个IAM用户的用户请求分发给多个流量统计装置302。其中，OpenAPI一般具有多个入口层。

在一些实施例中，统计代理层301通过设定的负载均衡器(Load Balancer)，利用一致性哈希(Hash)算法，将每隔预定时间(如10毫秒)接收到的多个IAM用户的用户请求分发给多个流量统计装置302。例如，假设在一预定时间接收到1000个IAM用户的用户请求，且设置有10个流量统计装置302，1000个IAM用户的用户请求会在统计代理层301被一致性哈希到该10个流量统计装置302，每个流量统计装置302可以获取到多个IAM用户的用户请求。

需要说明的是，本实施例中的流量统计装置302，用于实现上述任一实施例的流量统计方法，具体相关描述可参见上述的流量统计方法，此处不再赘述。可以理解的是，前述本地数据库与流量统计装置302一一对应，本地数据库设置于流量统计装置302所在机器。

在本实施例中，分布式流量统计系统还包括前述的远端数据库和前述的分布式文件系统。

在本实施例中，每个流量统计装置302为了充分利用本地内存，采用了高效的内存并发统计队列，利用分桶、无锁等机制来保障整个系统极高的写入性能和计算性能，采用基于LSM-Tree的rocksdb作为本地数据库实时存储OpenAPI的流量数据，从而防止数据丢失和单库数据规模膨胀，在保障整个系统极高的统计性能的同时保障统计数据的准确性；同时，利用分布式文件系统进行异步存储数据，防止单点故障导致数据丢失，从而保障了整个系统的安全性；此外，将流量数据持久化到远端数据库，并将已经持久化过的数据从本地数据库中清除，从而保障了整个系统存储的扩展性。

此外，本实施例所提供的分布式流量统计系统，可以设置在OpenAPI的网关层，能够用于统计整个OpenAPI的所有用户的服务用量。

实施例九

图11为本公开实施例九提供的一种电子设备的组成框图，如图11所示，该电子设备包括：一个或多个处理器501；存储器502，其上存储有一个或多个程序，当一个或多个程序被一个或多个处理器501执行，使得一个或多个处理器501实现上述的流量统计方法；一个或多个I/O接口503，连接在处理器501与存储器502之间，配置为实现处理器501与存储器502的信息交互。

此外，本公开实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，其中，该计算机程序被执行时实现前述的流量统计方法。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其他实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。