CN105407013A - 用户在线状态统计系统及方法 - Google Patents

Abstract

本发明公开了一种在线状态统计系统及方法，至少能够解决传统的单机统计方式因受限于单台服务器的处理速度以及内存容量而无法满足互联网用户大规模增长需求的技术问题。该用户在线状态统计系统包括：多台前端打点服务器，以及供多台前端打点服务器共享的后端存储数据库，其中，每台前端打点服务器适于接收来自在线用户终端的打点请求，并将根据打点请求中包含的打点数据获得的用户在线状态信息发送给后端存储数据库；后端存储数据库适于对各台前端打点服务器发来的用户在线状态信息进行统计及存储，其中，后端存储数据库通过一台或多台SSDB服务器实现。

Description

用户在线状态统计系统及方法

技术领域

本发明涉及网络通信技术领域，具体涉及一种用户在线状态统计系统及方法。

背景技术

随着互联网技术的日趋成熟，网络应用的种类和数量也越来越多，出现了多种多样的网络应用，例如网络游戏、网络直播等。为了更好地为用户提供服务，这些网络应用的提供商往往需要对用户的在线状态进行统计。

目前，在统计用户在线状态时，是由一台单独的打点服务器接收来自在线用户终端的打点请求，获取其中包含的打点数据，并将根据打点数据得到的用户在线状态信息保存到内存中。当需要查询某用户的在线状态时，由该打点服务器从内存中读取用户在线状态信息并反馈查询结果。

由于目前的用户在线状态信息采用内存存储方式，因此，只能通过单机实现用户在线状态的统计。然而，单机统计的方式仅适用于用户量级较小的应用场景中，随着互联网用户的增多，一个网络应用的在线用户数量动辄达到千万级甚至亿万级的量级，受到单台服务器的处理速度以及内存容量的制约，传统的单机统计方式无法支持如此庞大的用户量。而且，这种基于内存存储的单机统计方式也无法支持扩展：如果将用于统计用户在线状态的服务器扩展到两台或多台，由于各台服务器分别通过各自的内存来存储用户在线状态信息，所以，当需要查询某用户的在线状态时，无法确定该从哪台服务器中进行查询。由此可见，传统的单机统计方式无法满足互联网用户大规模增长的需求。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的用户在线状态统计系统及方法。

依据本发明的一个方面，提供了一种用户在线状态统计系统，包括：多台前端打点服务器，以及供多台前端打点服务器共享的后端存储数据库，其中，每台前端打点服务器适于接收来自在线用户终端的打点请求，并将根据打点请求中包含的打点数据获得的用户在线状态信息发送给后端存储数据库；后端存储数据库适于对各台前端打点服务器发来的用户在线状态信息进行统计及存储，其中，后端存储数据库通过一台或多台SSDB服务器实现。

依据本发明的另一方面，提供了一种用户在线状态统计方法，包括：通过多台前端打点服务器并行接收来自各个在线用户终端的打点请求；每台前端打点服务器将根据打点请求中包含的打点数据获得的用户在线状态信息发送给供多台前端打点服务器共享的后端存储数据库；由后端存储数据库对用户在线状态信息进行统计及存储。

在本发明提供的用户在线状态统计系统及方法中，通过多台前端打点服务器接收来自各个在线用户终端的打点请求，并将根据打点请求中包含的打点数据获得的用户在线状态信息存储到供多台前端打点服务器所共享的后端存储数据库中。由此可见，在本发明中，一方面，前端打点服务器的数量为多台，从而能够以并行方式处理各个在线用户终端发来的打点请求，大幅提高了打点服务器的处理速度，缩短了响应时间，能够同时服务于更多的用户终端。另一方面，通过后端存储方式代替了传统的内存存储方式，其中后端存储数据库通过一台或多台SSDB服务器实现，且能够供多台前端打点服务器所共享。由于SSDB服务器本身是一种高性能的数据库服务器，其存储容量远大于普通服务器的内存容量，且SSDB服务器还能够支持扩容，当一台SSDB服务器的存储容量不够用时，能够再挂接一个SSDB服务器，从而实现存储容量的自由扩展，由此能够存储海量的用户在线状态信息。因而，本发明中的用户在线状态统计系统及方法能够适应互联网用户大规模增长的需求。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明一个实施例提供的用户在线状态统计系统的功能框图；

图2示出了本发明另一实施例提供的用户在线状态统计系统的功能框图；

图3示出了本发明一个实施例提供的用户在线状态统计方法的流程图；

图4示出了本发明一个具体实施例提供的用户在线状态统计方法的流程图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明实施例提供了一种用户在线状态统计系统及方法，至少能够解决传统的单机统计方式因受限于单台服务器的处理速度以及内存容量而无法满足互联网用户大规模增长需求的技术问题。

图1示出了本发明一个实施例提供的用户在线状态统计系统的功能框图。如图1所示，该用户在线状态统计系统包括：多台前端打点服务器11，以及供多台前端打点服务器11共享的后端存储数据库12。其中，每台前端打点服务器11接收来自在线用户终端的打点请求，并将根据打点请求中包含的打点数据获得的用户在线状态信息发送给后端存储数据库12。后端存储数据库12对各台前端打点服务器11发来的用户在线状态信息进行统计及存储，其中，后端存储数据库12通过一台或多台SSDB服务器120实现。

具体地，每个在线用户终端每隔预设时间间隔发送一次打点请求，各台前端打点服务器11相互并行地处理来自各个在线用户终端的打点请求。通过多台前端打点服务器并行处理的方式能够提高服务器的处理速度，缩短服务器的响应时间，从而更好地服务于更多的用户终端。

后端存储数据库12为一台或多台SSDB服务器，由于SSDB服务器为高性能数据库服务器，其能够提供内存式存储服务，且支持扩容，能够在存储容量不足时通过挂接一台SSDB服务器来实现扩容存储方案，从而实现存储容量的自由扩展。因此，通过后端存储数据库12能够存储海量的用户在线状态信息。

由此可见，本发明中一方面通过多台相互并行工作的前端打点服务器提高了处理打点请求的速度，另一方面通过可扩容的后端存储数据库实现了用户在线状态信息的无限量存储。正是由于本发明中存储的用户在线状态信息的数据量不再受到内存存储容量的制约，因此，优选地，为了使本发明中所获取到的用户在线状态信息能够更加全面地反映用户的当前在线情况，可以使用户终端发送的打点请求中包含更多内容的打点数据，例如每个打点请求中的打点数据包括：用户终端标识以及该用户终端当前在线的应用类型标识；其中，用户终端当前在线的应用类型标识为一个或多个，且每个应用类型标识中进一步包含一种或多种应用信息。其中，通过用户终端标识能够对在线用户的身份进行识别；通过用户终端当前在线的应用类型标识能够了解该在线用户当前正在使用的应用类型，例如能够知晓该用户当前是在玩游戏还是在看直播；通过每个应用类型标识中进一步包含的应用信息可以了解关于该应用的更多具体内容，例如该用户正在玩何种游戏或是正在看哪类直播节目等。

图2示出了本发明一个具体实施例提供的用户在线状态统计系统的功能框图。如图2所示，该用户在线状态统计系统包括：多台在线用户终端20、一台或多台分发服务器21、多台与分发服务器21相连的前端打点服务器22、供多台前端打点服务器22共享的后端存储数据库23、以及提供查询服务的查询服务器24。其中，后端存储数据库23进一步包括多台SSDB服务器230。

其中，用户终端包括手机终端、电脑终端等各类终端设备，每当一个用户终端联网后，只要该用户终端启动了本系统中指定的应用，即为本系统中的一个在线用户终端。例如，在本实施例中，本系统中指定的应用包括网络游戏应用以及网络直播应用。因此，每当一个联网的用户终端启动了网络游戏应用和/或网络直播应用时，即成为一个需要统计在线状态的在线用户终端。

在本发明中，每个在线用户终端20在其在线期间，每隔预设时间间隔(例如每隔240秒)发送一次打点请求，服务器根据接收到的打点请求中包含的打点数据获得该在线用户终端的用户在线状态信息。例如，假设一个在线用户终端于上午9：00时启动了网络游戏“黑暗之光”以及网络直播“熊猫直播”，并在9：30时退出了网络游戏“黑暗之光”，继续观看网络直播“熊猫直播”，并在9：40时退出了网络直播“熊猫直播”。因此，在9：00-9：30的这段时间里，该在线用户终端每隔240秒向服务器发送一次打点请求，每次发送的打点请求中所包含的打点数据包括如下内容：(1)该在线用户终端的用户终端标识，用以唯一识别该用户，例如为用户名或用户ID；(2)该用户终端当前在线的应用类型标识一：网络游戏“黑暗之光”，在该应用类型标识中，进一步包括下述多种应用信息：游戏名称“黑暗之光”、游戏区服S1、游戏平台二；(3)该用户终端当前在线的应用类型标识二：网络直播“熊猫直播”，在该应用类型标识中，进一步包括下述应用信息：房间号四；(4)发送本次打点请求时的时间戳信息。在9：30-9：40的这段时间里，该在线用户终端仍然每隔240秒向服务器发送一次打点请求，但每次发送的打点请求中包含的打点数据中仅包括如下内容：(1)该在线用户终端的用户终端标识，用以唯一识别该用户，例如为用户名或用户ID；(2)该用户终端当前在线的应用类型标识：网络直播“熊猫直播”，在该应用类型标识中，进一步包括下述一种应用信息：房间号四；(3)发送打点请求时的时间戳信息。

前端打点服务器对每次接收到的打点请求中包含的打点数据进行处理即可得到该在线用户终端的在线状态：由于在9：00-9：30的这段时间里，该在线用户终端每隔240秒向服务器发送一次打点请求，且在每次发送的打点请求中均包含网络游戏“黑暗之光”以及网络直播“熊猫直播”的应用类型标识，因此，前端打点服务器确定该用户终端在9：00-9：30的这段时间里处于网络游戏“黑暗之光”以及网络直播“熊猫直播”同时在线状态；在9：30-9：40的这段时间里，该在线用户终端仍每隔240秒向服务器发送一次打点请求，但在每次发送的打点请求中仅包含网络直播“熊猫直播”的应用类型标识，因此，服务器确定该用户终端在9：30-9：40的这段时间里处于网络直播“熊猫直播”在线状态；在9：40之后，该用户终端不再向服务器发送打点请求，服务器判断该用户终端长时间没有发送打点请求，因而确定其已处于离线状态。具体地，服务器可以预先设定一个超时阈值(例如10分钟)，将超过该超时阈值没有发送打点请求的用户终端确定为离线状态。

另外，由于本系统中同时在线的用户终端数量很多，相应地，前端打点服务器所要处理的打点请求的并发量也非常大。因此，在本发明中同时设置了多台前端打点服务器，这些前端打点服务器能够相互并行地处理来自各个在线用户终端的打点请求，从而在请求量非常大的情况中能够显著提高处理速度、降低系统时延。另外，多台前端打点服务器之间除了采用并行工作方式之外，还可以采用主备工作方式，或者，也可以将并行工作方式与主备工作方式相结合。例如，假设前端打点服务器的数量为4台，可以将其中的3台设置为相互并行工作的主用服务器，剩余的一台设置为备用服务器，当某一主用服务器出现故障时可平滑切换至该备用服务器，从而提高系统的鲁棒性。当多台前端打点服务器相互并行工作时，需要采用一定的策略来确定每个在线用户终端每次发送的打点请求由哪台前端打点服务器处理。为此，在本实施例中设置有一台或多台分发服务器21，其与各个前端打点服务器22相连，用于接收各个在线用户终端20发来的打点请求，并根据预设策略将每次接收到的打点请求分发给其中的一台前端打点服务器处理。其中，预设策略可以是以下策略中的一个或多个：(1)按照预设顺序将各次接收到的打点请求轮流发送给各台前端打点服务器。例如，假设并行工作的前端打点服务器为A、B、C三台服务器，预设顺序可以是A-B-C依次循环。(2)按照随机方式将各次接收到的打点请求随机发送给各台前端打点服务器。具体地，可以通过一定的随机算法来确定随机发送的目的地址。(3)预先设置各个用户终端和/或各类应用与各台前端打点服务器之间的映射关系，根据映射关系将打点请求发送给对应的前端打点服务器。例如，可以根据用户终端所处的地域性或用户等级等特征将用户终端划分为多个类别，每一前端打点服务器固定负责设定类别的用户终端发来的打点请求；和/或，也可以根据打点请求中包含的应用类型标识对打点请求进行分类，每一前端打点服务器固定负责包含设定应用类型标识的打点请求。上述几种策略既可以单独使用，也可以结合使用。除上述三种策略外，本领域技术人员还可以灵活设定其他策略，只要能够使每一次发送的打点请求落在多台前端打点服务器中的某一台上即可。另外，在本发明其他的实施例中，也可以省略分发服务器，直接由用户终端在发送打点请求时根据上述几种策略中的至少一种来确定接收本次打点请求的前端打点服务器，并将本次打点请求发送给对应的前端打点服务器。

前端打点服务器每次接收到打点请求并进行处理时，可以通过设置在本台服务器内存中的定时器来确定本次接收到打点请求的时间信息，并将该时间信息一并保存在该用户的用户在线状态信息中。具体地，在某一用户的用户在线状态信息中包括：该用户终端标识以及与该用户终端标识对应的在线时间段信息、在线应用类型标识等。前端打点服务器22将生成的各个用户的用户在线状态信息发送给后端存储数据库23，由后端存储数据库23进行统一存储。

后端存储数据库23为多台能够扩容的SSDB服务器230，供各台前端打点服务器22所共享。由于SSDB服务器能够将原本存储在内存中的数据内容存储在磁盘上，因此避免了对内存的大量占用，且存储容量也不再受到内存容量的制约，能够存储更多的数据内容。而且，SSDB服务器可支持扩容，当一台SSDB服务器的容量不够用时，可以通过挂接一台SSDB服务器的方式实现扩容。因此，通过SSDB服务器实现的后端存储数据库能够存储海量的用户在线状态信息，使本系统能够统计的同时在线的用户数量不再受到内存容量的制约。具体存储时，后端存储数据库可以通过键值对(key-value)的方式来存储用户在线状态信息，例如，将用户终端标识作为键(key)，将该用户终端标识对应的在线状态作为值(value)，通过这种方式来存储数据能够提高查询速度。

为了便于查询用户在线状态，本系统中还设置有查询服务器24，该查询服务器24能够接收用户终端和/或应用提供商发来的用于查询某一用户是否在线的查询请求，通过查询后端存储数据库中存储的用户在线状态信息来反馈该用户是否在线的响应消息。具体地，该查询服务器能够向用户终端和/或应用提供商提供多维度、多粒度的查询内容。所谓多维度是指：通过查询请求能够查询某一用户终端在指定时间段内对应的所有在线应用，例如，能够查询到某一用户终端何时玩游戏、何时看直播等。所谓多粒度是指：针对用户终端在指定时间段内对应的一个在线应用而言，能够查询到该应用的各种具体信息，例如，能够查询到该用户终端在哪个游戏平台玩游戏、在哪个区服玩游戏等。由此可见，本发明能够提供更加全面的查询。除此之外，查询服务器还能够对查询结果进行各种统计，例如，能够统计某一用户终端在指定游戏平台的在线时间、在指定游戏区服的在线时间、在指定直播节目的在线时间等；还能够统计某一应用在指定时间段内所拥有的同时在线用户数量等。

由此可见，在本发明实施例中，一方面，前端打点服务器的数量为多台，从而能够以并行方式处理各个在线用户终端发来的打点请求，大幅提高了打点服务器的处理速度，缩短了响应时间，能够同时服务于更多的用户终端。另一方面，通过后端存储方式代替了传统的内存存储方式，其中后端存储数据库通过一台或多台SSDB服务器实现，且能够供多台前端打点服务器所共享。由于SSDB服务器本身就是一种高性能的数据库服务器，其存储容量远大于普通服务器的内存容量，且SSDB服务器还能够支持扩容，当一台SSDB服务器的存储容量不够用时，能够再挂接一个SSDB服务器，从而实现存储容量的自由扩展，由此能够存储海量的用户在线状态信息。

另外，本领域技术人员还可以对上述实施例中的技术细节进行各种改进和变形：

例如，在上述举例中，以一个打点请求中同时包含多个应用类型标识为例进行说明，此时，发送打点请求的操作可以由用户终端上安装的预定客户端软件，例如手机助手或应用宝等进行触发。在本发明其他的实施例中，也可以在一个打点请求中仅包含一个应用类型标识，此时，发送打点请求的操作可以由每种应用所对应的客户端程序相互独立地进行触发，因此，当某一用户终端同时启动两种应用时，两种应用在其在线期间分别发送各自的打点请求，因而服务器在同一时段内会接收到来自该用户终端的两条打点请求。

又如，在上述实施例中，前端打点服务器主要面向用户，用于提供对外服务，可以通过80端口提供服务；查询服务器主要面向应用提供商所在的服务器(例如应用客服服务器)，用于提供对内服务，可以通过8360端口提供服务。除此之外，本领域技术人员还可以对前端打点服务器和查询服务器的端口信息进行灵活更改。而且，查询服务器所具有的部分功能，例如统计功能(如统计某一用户在指定应用的在线时间、统计某一应用在指定时间段内拥有的在线用户数等)也可以由后端存储数据库来实现。总之，本领域技术人员能够对上述实施例中的技术细节进行灵活更改，以适应具体的业务需求。

图3示出了本发明一个实施例提供的用户在线状态统计方法的流程图。如图3所示，该方法包括如下步骤：

步骤S310：通过多台前端打点服务器并行接收来自各个在线用户终端的打点请求。

具体地，每个在线用户终端每隔预设时间间隔发送一次打点请求，各台前端打点服务器相互并行地处理来自各个在线用户终端的打点请求。通过多台前端打点服务器并行处理的方式能够提高服务器的处理速度，缩短服务器的响应时间，从而更好地服务于更多的用户终端。

步骤S320：每台前端打点服务器将根据打点请求中包含的打点数据获得的用户在线状态信息发送给供多台前端打点服务器共享的后端存储数据库。

其中，打点请求中包含的打点数据可以包括：用户终端标识以及该用户终端当前在线的应用类型标识；其中，所述用户终端当前在线的应用类型标识为一个或多个，且每个应用类型标识中进一步包含一种或多种应用信息。

步骤S330：由后端存储数据库对用户在线状态信息进行统计及存储。

其中，后端存储数据库为一台或多台SSDB服务器，由于SSDB服务器为高性能数据库服务器，其能够提供内存式存储服务，且支持扩容，能够在存储容量不足时通过挂接一台SSDB服务器来实现扩容存储方案，从而实现存储容量的自由扩展。因此，通过后端存储数据库能够存储海量的用户在线状态信息。

图4示出了本发明一个具体实施例提供的用户在线状态统计方法的流程图。该具体实施例可应用于图2所示的系统中。如图4所示，该方法包括如下步骤：

步骤S410：每个在线用户终端在其在线期间，每隔预设时间间隔发送一次打点请求。

例如，假设一个在线用户终端于上午9：00时启动了网络游戏“黑暗之光”以及网络直播“熊猫直播”，并在9：30时退出了网络游戏“黑暗之光”，继续观看网络直播“熊猫直播”，并在9：40时退出了网络直播“熊猫直播”。因此，在9：00-9：30的这段时间里，该在线用户终端每隔240秒向服务器发送一次打点请求，每次发送的打点请求中所包含的打点数据包括如下内容：(1)该在线用户终端的用户终端标识，用以唯一识别该用户，例如为用户名或用户ID；(2)该用户终端当前在线的应用类型标识一：网络游戏“黑暗之光”，在该应用类型标识中，进一步包括下述多种应用信息：游戏名称“黑暗之光”、游戏区服S1、游戏平台二；(3)该用户终端当前在线的应用类型标识二：网络直播“熊猫直播”，在该应用类型标识中，进一步包括下述应用信息：房间号四；(4)发送本次打点请求时的时间戳信息。在9：30-9：40的这段时间里，该在线用户终端仍然每隔240秒向服务器发送一次打点请求，但每次发送的打点请求中包含的打点数据中仅包括如下内容：(1)该在线用户终端的用户终端标识，用以唯一识别该用户，例如为用户名或用户ID；(2)该用户终端当前在线的应用类型标识：网络直播“熊猫直播”，在该应用类型标识中，进一步包括下述一种应用信息：房间号四；(3)发送打点请求时的时间戳信息。

步骤S420：分发服务器接收各个在线用户终端发来的打点请求，并根据预设策略将每次接收到的打点请求分发给多台前端打点服务器中的一台前端打点服务器处理。

其中，预设策略可以是以下策略中的一个或多个：(1)按照预设顺序将各次接收到的打点请求轮流发送给各台前端打点服务器。例如，假设并行工作的前端打点服务器为A、B、C三台服务器，预设顺序可以是A-B-C依次循环。(2)按照随机方式将各次接收到的打点请求随机发送给各台前端打点服务器。具体地，可以通过一定的随机算法来确定随机发送的目的地址。(3)预先设置各个用户终端和/或各类应用与各台前端打点服务器之间的映射关系，根据映射关系将打点请求发送给对应的前端打点服务器。例如，可以根据用户终端所处的地域性或用户等级等特征将用户终端划分为多个类别，每一前端打点服务器固定负责设定类别的用户终端发来的打点请求；和/或，也可以根据打点请求中包含的应用类型标识对打点请求进行分类，每一前端打点服务器固定负责包含设定应用类型标识的打点请求。上述几种策略既可以单独使用，也可以结合使用。除上述三种策略外，本领域技术人员还可以灵活设定其他策略，只要能够使每一次发送的打点请求落在多台前端打点服务器中的某一台上即可。

步骤S430：前端打点服务器根据分发服务器发来的打点请求中包含的打点数据获取用户在线状态信息，并将获取到的用户在线状态信息发送给后端存储数据库。

继续参照步骤S410中提到的例子来描述前端打点服务器获取用户在线状态信息的方式：由于在9：00-9：30的这段时间里，上述在线用户终端每隔240秒向服务器发送一次打点请求，且在每次发送的打点请求中均包含网络游戏“黑暗之光”以及网络直播“熊猫直播”的应用类型标识，因此，前端打点服务器确定该用户终端在9：00-9：30的这段时间里处于网络游戏“黑暗之光”以及网络直播“熊猫直播”同时在线状态；在9：30-9：40的这段时间里，该在线用户终端仍每隔240秒向服务器发送一次打点请求，但在每次发送的打点请求中仅包含网络直播“熊猫直播”的应用类型标识，因此，服务器确定该用户终端在9：30-9：40的这段时间里处于网络直播“熊猫直播”在线状态；在9：40之后，该用户终端不再向服务器发送打点请求，服务器判断该用户终端长时间没有发送打点请求，因而确定其已处于离线状态。具体地，服务器可以预先设定一个超时阈值(例如10分钟)，将超过该超时阈值没有发送打点请求的用户终端确定为离线状态。

另外，前端打点服务器每次接收到打点请求并进行处理时，可以通过设置在本台服务器内存中的定时器来确定本次接收到打点请求的时间信息，并将该时间信息一并保存在该用户的用户在线状态信息中。具体地，在某一用户的用户在线状态信息中包括：该用户终端标识以及与该用户终端标识对应的在线时间段信息、在线应用类型标识等。前端打点服务器将生成的各个用户的用户在线状态信息发送给后端存储数据库，由后端存储数据库进行统一存储。

步骤S440：后端存储数据库对前端打点服务器发来的用户在线状态信息进行存储。

其中，后端存储数据库为多台能够扩容的SSDB服务器，供各台前端打点服务器所共享。由于SSDB服务器能够将原本存储在内存中的数据内容存储在磁盘上，因此避免了对内存的大量占用，且存储容量也不再受到内存容量的制约，能够存储更多的数据内容。而且，SSDB服务器可支持扩容，当一台SSDB服务器的容量不够用时，可以通过挂接一台SSDB服务器的方式实现扩容。因此，通过SSDB服务器实现的后端存储数据库能够存储海量的用户在线状态信息，使本系统能够统计的同时在线的用户数量不再受到内存容量的制约。具体存储时，后端存储数据库可以通过键值对(key-value)的方式来存储用户在线状态信息，例如，将用户终端标识作为键(key)，将该用户终端标识对应的在线状态作为值(value)，通过这种方式来存储数据能够提高查询速度。

步骤S450：通过查询服务器接收查询请求，查询后端存储数据库中存储的用户在线状态信息，并返回与该查询请求相对应的查询结果。其中，查询请求包括：用于查询指定用户终端当前是否在线的查询请求、用于查询指定用户终端在线时间段的查询请求、以及用于查询指定应用在指定时间段内的在线用户数的查询请求等。

在本发明提供的用户在线状态统计系统及方法中，通过多台前端打点服务器接收来自各个在线用户终端的打点请求，并将根据打点请求中包含的打点数据获得的用户在线状态信息存储到供多台前端打点服务器所共享的后端存储数据库中。由此可见，在本发明中，一方面，前端打点服务器的数量为多台，从而能够以并行方式处理各个在线用户终端发来的打点请求，大幅提高了打点服务器的处理速度，缩短了响应时间，能够同时服务于更多的用户终端。另一方面，通过后端存储方式代替了传统的内存存储方式，其中后端存储数据库通过一台或多台SSDB服务器实现，且能够供多台前端打点服务器所共享。由于SSDB服务器本身就是一种高性能的数据库服务器，其存储容量远大于普通服务器的内存容量，且SSDB服务器还能够支持扩容，当一台SSDB服务器的存储容量不够用时，能够再挂接一个SSDB服务器，从而实现存储容量的自由扩展，由此能够存储海量的用户在线状态信息。因而，本发明中的用户在线状态统计系统及方法能够适应互联网用户大规模增长的需求。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明还提供了A8、一种用户在线状态统计方法，包括：

通过多台前端打点服务器并行接收来自各个在线用户终端的打点请求；

每台前端打点服务器将根据所述打点请求中包含的打点数据获得的用户在线状态信息发送给供所述多台前端打点服务器共享的后端存储数据库；

由所述后端存储数据库对所述用户在线状态信息进行统计及存储。

A9、根据A8所述的方法，其中，每个在线的用户终端每隔预设时间间隔发送一次打点请求，所述打点请求中包含的打点数据包括：用户终端标识以及该用户终端当前在线的应用类型标识；其中，所述用户终端当前在线的应用类型标识为一个或多个，且每个应用类型标识中进一步包含一种或多种应用信息。

A10、根据A8或A9所述的方法，其中，每当一个用户终端发送一次打点请求时，通过预设策略从所述多台前端打点服务器中确定一台用以接收本次打点请求的前端打点服务器，所述预设策略包括：

按照预设顺序将各次接收到的打点请求轮流发送给各台前端打点服务器；

按照随机方式将各次接收到的打点请求随机发送给各台前端打点服务器；

预先设置各个用户终端和/或各类应用与各台前端打点服务器之间的映射关系，根据所述映射关系将所述打点请求发送给对应的前端打点服务器。

A11、根据A8-A10任一所述的方法，其中，进一步包括：

根据接收到的查询请求查询所述后端存储数据库中存储的用户在线状态信息，并返回与该查询请求相对应的查询结果。

A12、根据A11所述的方法，其中，所述查询请求包括：用于查询指定用户终端当前是否在线的查询请求、用于查询指定用户终端在线时间段的查询请求、以及用于查询指定应用在指定时间段内的在线用户数的查询请求。

Claims (10)

1.一种用户在线状态统计系统，包括：多台前端打点服务器，以及供所述多台前端打点服务器共享的后端存储数据库，其中，

每台前端打点服务器适于接收来自在线用户终端的打点请求，并将根据所述打点请求中包含的打点数据获得的用户在线状态信息发送给所述后端存储数据库；

所述后端存储数据库适于对各台前端打点服务器发来的用户在线状态信息进行统计及存储，其中，所述后端存储数据库通过一台或多台SSDB服务器实现。

2.根据权利要求1所述的系统，其中，每个在线用户终端每隔预设时间间隔发送一次打点请求，各台前端打点服务器相互并行地处理来自各个在线用户终端的打点请求。

3.根据权利要求1或2所述的系统，其中，所述打点请求中包含的打点数据包括：用户终端标识以及该用户终端当前在线的应用类型标识；其中，所述用户终端当前在线的应用类型标识为一个或多个，且每个应用类型标识中进一步包含一种或多种应用信息。

4.根据权利要求1-3任一所述的系统，其中，进一步包括：分发服务器，其与所述多台前端打点服务器分别相连，适于接收各个在线用户终端每隔预设时间间隔发送的打点请求，并在每次接收到打点请求后，根据预设策略从所述多台前端打点服务器中确定一台用以处理本次打点请求的前端打点服务器，其中，所述预设策略包括以下策略中的一个或多个：

按照预设顺序将各次接收到的打点请求轮流发送给各台前端打点服务器；

按照随机方式将各次接收到的打点请求随机发送给各台前端打点服务器；

预先设置各个用户终端和/或各类应用与各台前端打点服务器之间的映射关系，根据所述映射关系将所述打点请求发送给对应的前端打点服务器。

5.根据权利要求1-4任一所述的系统，其中，进一步包括：查询服务器，适于根据接收到的查询请求，查询所述后端存储数据库中存储的用户在线状态信息，并返回与该查询请求相对应的查询结果。

6.根据权利要求5所述的系统，其中，所述查询请求包括：用于查询指定用户终端当前是否在线的查询请求、用于查询指定用户终端在线时间段的查询请求、以及用于查询指定应用在指定时间段内的在线用户数的查询请求。

7.根据权利要求1-6任一所述的系统，其中，所述后端存储数据库中存储的用户在线状态信息通过键值对的方式存储。

8.一种用户在线状态统计方法，包括：

通过多台前端打点服务器并行接收来自各个在线用户终端的打点请求；

每台前端打点服务器将根据所述打点请求中包含的打点数据获得的用户在线状态信息发送给供所述多台前端打点服务器共享的后端存储数据库；

由所述后端存储数据库对所述用户在线状态信息进行统计及存储。

9.根据权利要求8所述的方法，其中，每个在线的用户终端每隔预设时间间隔发送一次打点请求，所述打点请求中包含的打点数据包括：用户终端标识以及该用户终端当前在线的应用类型标识；其中，所述用户终端当前在线的应用类型标识为一个或多个，且每个应用类型标识中进一步包含一种或多种应用信息。

10.根据权利要求8或9所述的方法，其中，每当一个用户终端发送一次打点请求时，通过预设策略从所述多台前端打点服务器中确定一台用以接收本次打点请求的前端打点服务器，所述预设策略包括：

按照预设顺序将各次接收到的打点请求轮流发送给各台前端打点服务器；

按照随机方式将各次接收到的打点请求随机发送给各台前端打点服务器；

预先设置各个用户终端和/或各类应用与各台前端打点服务器之间的映射关系，根据所述映射关系将所述打点请求发送给对应的前端打点服务器。