用户状态统计系统及方法
【专利摘要】本发明公开了一种用户状态统计系统及方法，至少能够解决传统的单机统计方式因受限于单个服务器的处理速度以及内存容量而无法满足互联网用户大规模增长需求，以及不支持扩展、灾备效果不佳的技术问题。该用户状态统计系统包括：服务器集群，以及与服务器集群相连的SSDB数据库，其中，服务器集群包括多个服务器节点，各个服务器节点分别用于处理各个用户终端发送的打点请求，并根据打点请求生成用户状态消息，将用户状态消息提供给SSDB数据库；SSDB数据库用于对各个服务器节点提供的用户状态消息进行统计，根据统计结果生成并存储用户状态信息。
【专利说明】
用户状态统计系统及方法
技术领域
[0001]本发明涉及网络通信技术领域，具体涉及一种用户状态统计系统及方法。【背景技术】
[0002]随着互联网技术的日趋成熟，网络应用的种类和数量也越来越多，出现了多种多样的网络应用，例如网络游戏、网络直播等。为了更好地为用户提供服务，这些网络应用的提供商往往需要对用户状态进行统计。
[0003]目前，在统计用户状态时，是由一个单独的服务器节点接收来自在线用户终端的打点请求，获取其中包含的打点数据，并将根据打点数据得到的用户状态信息保存到内存中。当需要查询某用户的状态时，由该服务器节点从内存中读取用户状态信息并反馈查询结果。[〇〇〇4]由于目前的用户状态信息采用内存存储方式，因此，只能通过单机实现用户在线状态的统计。然而，单机统计的方式仅适用于用户量级较小的应用场景中，随着互联网用户的增多，一个网络应用的在线用户数量动辄达到千万级甚至亿万级的量级，受到单个服务器的处理速度以及内存容量的制约，传统的单机统计方式无法支持如此庞大的用户量。而且，这种基于内存存储的单机统计方式也无法支持扩展:如果将用于统计用户状态的服务器扩展到两个或多个，由于各个服务器分别通过各自的内存来存储用户状态信息，所以，当需要查询某用户的状态时，无法确定该从哪个服务器中进行查询。由此可见，传统的单机统计方式无法满足互联网用户大规模增长的需求。不仅如此，在单机统计的方式中，如果该服务器故障，将直接导致统计过程的中断。
[0005]由此可见，在传统的实现方式中，受到单个服务器的内存容量的制约，导致无法统计大量级的用户人数，且不支持扩展、灾备效果不佳。
【发明内容】
[0006]鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的用户在线状态统计系统及方法。
[0007]依据本发明的一个方面，提供了一种用户状态统计系统，包括:服务器集群，以及与服务器集群相连的SSDB数据库，其中，服务器集群包括多个服务器节点，各个服务器节点分别用于处理各个用户终端发送的打点请求，并根据打点请求生成用户状态消息，将用户状态消息提供给SSDB数据库;SSDB数据库用于对各个服务器节点提供的用户状态消息进行统计，根据统计结果生成并存储用户状态信息。
[0008]可选地，用户状态消息包括用户上线消息和用户下线消息，且各个用户终端在其在线期间，每隔预设时间间隔发送一次打点请求，则各个服务器节点具体用于:每当接收到用户终端发送的打点请求后，判断是否存储有对应于该用户终端的定时器，如果判断结果为是，则根据本次打点请求向对应于该用户终端的定时器发送延续指令;如果判断结果为否，则创建对应于该用户终端的定时器，并为该用户终端生成用户上线消息；其中，各个服务器节点持续地对本地存储的各个定时器进行监测，每当监测到在预设的超时时间阈值内未接收到延续指令的定时器时，将该定时器销毁，并为该定时器所对应的用户终端生成用户下线消息。
[0009]可选地，打点请求中包括应用信息字段，且应用信息字段进一步包括多个分别指示不同维度的应用信息的子字段，则对应于一个用户终端的定时器进一步包括多个子定时器，各个子定时器分别对应于不同维度的状态信息;并且，用户上线消息进一步包括各个维度所对应的用户上线消息，且用户下线消息进一步包括各个维度所对应的用户下线消息。
[0010]可选地，系统进一步包括:公共消息队列模块以及后端处理模块，其中，各个服务器节点用于将生成的用户状态消息存储到公共消息队列模块中，后端处理模块用于读取公共消息队列模块中的用户状态消息，并根据读取到的用户状态消息修改SSDB数据库中存储的用户状态信息。
[0011]可选地，服务器集群中进一步包括:至少一个反向代理模块，用于接收各个用户终端发送的打点请求，获取打点请求中包含的用户标识，通过预设的哈希算法对用户标识进行计算，根据计算结果将各个打点请求分配给各个服务器节点处理。
[0012]可选地，反向代理模块进一步用于:检测各个服务器节点的工作状态，当检测到出现故障的服务器节点时，停用出现故障的服务器节点；并在检测到故障恢复时，重新启用出现故障的服务器节点。
[0013]可选地，系统进一步包括:与SSDB数据库相连的查询服务器，用于根据接收到的查询请求，查询SSDB数据库中存储的用户状态信息，并返回与该查询请求相对应的查询结果； 并且，查询服务器进一步用于:监测各个应用和/或应用的各个维度的用户在线人数，当监测到的用户在线人数的变化率大于预设阈值时，发出报警提示信息。
[0014]可选地，打点请求中包括应用类型字段，则服务器节点进一步用于:根据应用类型字段将用户状态消息推送给对应类型的应用。
[0015]可选地，打点请求为异步请求消息。
[0016]依据本发明的另一方面，提供了一种用户状态统计方法，包括:通过服务器集群中的多个服务器节点处理各个用户终端发送的打点请求;根据打点请求生成用户状态消息， 将用户状态消息发送给SSDB数据库;通过SSDB数据库对各个服务器节点提供的用户状态消息进行统计，根据统计结果生成并存储用户状态信息。
[0017]可选地，用户状态消息包括用户上线消息和用户下线消息，且各个用户终端在其在线期间，每隔预设时间间隔发送一次打点请求，则根据打点请求生成用户状态消息的步骤具体包括:每当接收到用户终端发送的打点请求后，判断是否存储有对应于该用户终端的定时器，如果判断结果为是，则根据本次打点请求向对应于该用户终端的定时器发送延续指令;如果判断结果为否，则创建对应于该用户终端的定时器，并为该用户终端生成用户上线消息;其中，各个服务器节点持续地对本地存储的各个定时器进行监测，每当监测到在预设的超时时间阈值内未接收到延续指令的定时器时，将该定时器销毁，并为该定时器所对应的用户终端生成用户下线消息。
[0018]可选地，打点请求中包括应用信息字段，且应用信息字段进一步包括多个分别指示不同维度的应用信息的子字段，则对应于一个用户终端的定时器进一步包括多个子定时器，各个子定时器分别对应于不同维度的状态信息;并且，用户上线消息进一步包括各个维度所对应的用户上线消息，且用户下线消息进一步包括各个维度所对应的用户下线消息。
[0019]可选地，将用户状态消息发送给SSDB数据库的步骤具体包括:各个服务器节点将生成的用户状态消息存储到预设的公共消息队列模块中，由预设的后端处理模块将公共消息队列模块中的用户状态消息提供给SSDB数据库。
[0020]可选地，通过服务器集群中的多个服务器节点处理各个用户终端发送的打点请求的步骤具体包括:通过至少一个反向代理模块接收各个用户终端发送的打点请求，获取打点请求中包含的用户标识，通过预设的哈希算法对用户标识进行计算，根据计算结果将各个打点请求分配给各个服务器节点处理。
[0021]可选地，方法进一步包括步骤:通过反向代理模块检测各个服务器节点的工作状态，当检测到出现故障的服务器节点时，停用出现故障的服务器节点;并在检测到故障恢复时，重新启用出现故障的服务器节点。
[0022]可选地，方法包括:根据接收到的查询请求，查询SSDB数据库中存储的用户状态信息，并返回与该查询请求相对应的查询结果;并且，方法进一步包括:监测各个应用和/或应用的各个维度的用户在线人数，当监测到的用户在线人数的变化率大于预设阈值时，发出报警提示信息。
[0023]可选地，打点请求中包括应用类型字段，则方法进一步包括步骤:根据应用类型字段将用户状态消息推送给对应类型的应用。
[0024]可选地，打点请求为异步请求消息。
[0025]在本发明提供的用户状态统计系统及方法中，通过包含多个服务器节点的服务器集群接收来自各个用户终端的打点请求，并根据打点请求生成用户状态消息，将该用户状态消息提供给SSDB数据库，以供SSDB数据库根据用户状态消息维护用户状态信息。由此可见，在本发明中，服务器节点通过集群形式实现，且数量为多个，因而能够并行处理各个用户终端发来的打点请求，大幅提高了服务器节点的处理速度，缩短了响应时间，能够同时服务于更多的用户终端。另外，由于用户状态信息存储在SSDB数据库内，而非存储在服务器节点的内存中，因此，上述服务器集群中所包含的服务器节点的数量可以灵活调整:当用户数量多时，可以通过挂接一个服务器节点来服务于更多的用户；当用户数量少时，可以摘除一个服务器节点以节约成本。由此可见，本申请提供的方式具有较强的可扩展性，系统设计较为灵活。除此之外，当某一个服务器节点故障时，其他服务器节点依然能够确保整个系统的正常运行，因此，本申请提供的方式具有较强的灾备功能。
[0026]上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段， 而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的【具体实施方式】。【附图说明】
[0027]通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中:
[0028]图1示出了本发明一个实施例提供的用户状态统计系统的结构图；
[0029]图2示出了本发明另一具体实施例提供的用户状态统计系统的结构图；
[0030]图3示出了本发明一个实施例提供的用户状态统计方法的流程图；[〇〇31 ]图4示出了本发明一个具体实施例提供的用户状态统计方法的流程图。【具体实施方式】
[0032]下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
[0033]本发明实施例提供了一种用户状态统计系统及方法，至少能够解决传统的单机统计方式因受限于单个服务器的处理速度以及内存容量而无法满足互联网用户大规模增长需求，以及不支持扩展、灾备效果不佳的技术问题。
[0034]图1示出了本发明一个实施例提供的用户状态统计系统的功能框图。如图1所示， 该用户状态统计系统包括:服务器集群11，以及与服务器集群11相连的SSDB数据库12。其中，服务器集群11包括多个服务器节点10,各个服务器节点10分别用于处理各个用户终端发送的打点请求，并根据打点请求生成用户状态消息，将用户状态消息提供给SSDB数据库 12;SSDB数据库12用于对各个服务器节点10提供的用户状态消息进行统计，根据统计结果生成并存储用户状态信息。
[0035]由此可见，在本发明中，服务器节点通过集群形式实现，且数量为多个，因而能够并行处理各个用户终端发来的打点请求，大幅提高了服务器节点的处理速度，缩短了响应时间，能够同时服务于更多的用户终端。另外，由于用户状态信息存储在SSDB数据库内，而非存储在服务器节点的内存中，因此，上述服务器集群中所包含的服务器节点的数量可以灵活调整:当用户数量多时，可以通过挂接一个服务器节点来服务于更多的用户；当用户数量少时，可以摘除一个服务器节点以节约成本。由此可见，本申请提供的方式具有较强的可扩展性，系统设计较为灵活。除此之外，当某一个服务器节点故障时，其他服务器节点依然能够确保整个系统的正常运行，因此，本申请提供的方式具有较强的灾备功能。
[0036]图2示出了本发明一个具体实施例提供的用户状态统计系统的结构示意图。如图2 所示，该系统包括:服务器集群20、公共消息队列模块21、后端处理模块22、SSDB数据库23以及查询服务器24。其中，服务器集群20又进一步包括:第一反向代理模块201、第二反向代理模块202、第一服务器节点203、第二服务器节点204以及第三服务器节点205。下面结合图2 详细介绍该系统的各个部件/模块的具体结构和功能:[〇〇37]服务器集群20能够通过多个服务器节点并行处理大量用户终端发来的打点请求， 并根据打点请求生成用户状态消息。具体地，在本实施例中，由第一反向代理模块201和第二反向代理模块202来接收大量用户终端发送的打点请求。其中，每个用户终端在其在线期间，每隔预设时间间隔发送一次打点请求，以表明其当前处于在线状态。第一反向代理模块 201和第二反向代理模块202可以通过两台单独的Nginx反向代理服务器来实现。反向代理模块的功能主要是接收来自前端的用户终端的打点请求，并将打点请求发送给服务器集群中的各个服务器节点。另外，本领域技术人员也可以对反向代理模块的数量和具体形式进行灵活更改，例如，可以设置一个或更多个反向代理模块，另外，反向代理模块也可以采用其他形式的网络服务器来实现。而且，反向代理模块除了采用单独的网络服务器来实现之夕卜，也可以直接集成在各个服务器节点上，例如，将第一反向代理模块201直接集成在第一服务器节点203上，将第二反向代理模块202直接集成在第二服务器节点204上。另外，在本发明其他的实施例中，本领域技术人员也可以省略第一反向代理模块201和第二反向代理模块202,直接由各个服务器节点来接收用户终端的打点请求。[〇〇38]反向代理模块的功能至少包括如下两点:第一，反向代理模块可以将多个用户终端发来的打点请求按照一定的规则分配给各个服务器节点，以使各个服务器节点相互并行工作，从而能够同时处理海量用户终端的请求，提高系统吞吐量，降低处理时延，并近似实现负载均衡的效果。为此，各个反向代理模块接收到用户终端发送的打点请求后，获取本次打点请求中包含的用户标识，通过预设的哈希算法对该用户标识进行计算，并根据计算结果将各个打点请求分配给各个服务器节点处理。除了采用哈希算法外，也可以采用随机算法来分配打点请求，或者，也可以将各次接收到的打点请求依次发给各个服务器节点处理。 另外，由于各个服务器节点需要对用户终端的状态进行持续维护，因此，优选地，同一用户终端发送的各次打点请求应分配给同一服务器节点处理，例如，假设用户终端A首次发送的打点请求由第一服务器节点203处理，则该用户终端A后续发送的打点请求都应由第一服务器节点203处理，如果由于分发错误或网络传输错误等各类原因导致用户终端A后续发送的某一次打点请求分配给了第二服务器节点204,则第二服务器节点204通过预设的哈希算法对该用户标识进行计算后，确认该打点请求应由第一服务器节点203处理，则第二服务器节点204将本次打点请求转发给第一服务器节点203。由此可见，在本实施例中，各个服务器节点本身还具备对打点请求中的用户标识进行计算的能力，因此能够确保同一用户终端发送的各次打点请求均由同一服务器节点处理，从而便于服务器节点对用户终端的状态进行持续维护。[〇〇39]第二，反向代理模块还可以检测各个服务器节点的工作状态，当检测到出现故障的服务器节点时，停用出现故障的服务器节点；并在检测到该故障恢复时，重新启用之前出现故障的服务器节点。由此，能够提高系统的鲁棒性，防止因某一服务器节点出现故障而影响整个系统的正常运行，使系统具备较好的灾备效果。例如，反向代理模块201向服务器节点发送打点请求后，要求服务器节点返回确认数据包，若某一服务器节点在规定时间内未返回确认数据包，则反向代理模块确定相应的服务器节点出现故障，从而暂时停用该服务器节点，将原本由该服务器节点处理的打点请求切换到其他的服务器节点处理。另外，也可以通过服务器节点定期向反向代理模块发送心跳包的方式来检测各个服务器节点是否出现故障。
[0040]各个服务器节点接收到打点请求后，根据打点请求对相应的用户终端的状态进行维护，并根据用户终端的状态生成用户状态消息。具体地，服务器节点可以根据用户状态文件来维护各个用户终端的状态。其中，用户状态文件可以通过字典、日志等多种形式实现， 其中记录了所有处于在线状态的用户终端所对应的状态记录。当服务器节点接收到用户终端发送的打点请求后，获取打点请求中包含的用户标识，并在预设的用户状态文件中查询是否包含该用户标识所对应的状态记录。如果在预设的用户状态文件中查询到了该用户标识所对应的状态记录，说明该用户终端已经上线并处于在线状态；如果在预设的用户状态文件中未查询到该用户标识所对应的状态记录，说明该用户终端刚刚上线，相应地，为该用户终端生成的用户状态消息为用户上线消息。
[0041]除了通过用户状态文件来维护各个用户终端的状态之外，为了更加有效地监测各个用户终端的上线动作和下线动作，在本实施例中，也可以通过定时器来记录各个用户终端的状态。相应地，每当服务器节点接收到用户终端发送的打点请求后，判断是否存储有对应于该用户终端的定时器，如果判断结果为是，说明该用户终端已经处于在线状态，则根据本次打点请求向对应于该用户终端的定时器发送延续指令;如果判断结果为否，说明该用户终端刚刚上线，则创建对应于该用户终端的定时器，并为该用户终端生成用户上线消息； 其中，各个服务器节点持续地对本地存储的各个定时器进行监测，每当监测到在预设的超时时间阈值内未接收到延续指令的定时器时，将该定时器销毁，并为该定时器所对应的用户终端生成用户下线消息。由此可见，通过定时器能够监测到各个用户终端的上线动作和下线动作，并在用户终端上线时生成用户上线消息，在用户终端下线时生成用户下线消息。 用户状态消息除包含上述的用户上线消息和用户下线消息外，还可以进一步包含用于指示用户终端目前处于在线状态的用户在线消息等。
[0042]在本实施例中，各个服务器节点将生成的用户状态消息存储到公共消息队列模块 21中。其中，公共消息队列模块用于通过公共消息队列对用户状态消息进行有序存储，其可以通过一台单独的服务器实现，也可以集成在SSDB数据库上。公共消息队列是一种先进先出的分布式消息队列，能够在消息传输过程中作为保存消息的容器，从而为程序或组件提供异步的通信机制，使发送方和接收方不必同时在线，也不必了解对方，就可以相互传输消息。在本实施例中，通过公共消息队列模块21对各个服务器节点生成的用户状态消息进行统一存储。存储在公共消息队列模块21中的用户状态消息由后端处理模块22负责处理。具体地，后端处理模块22可以通过服务器上的一个进程来实现。后端处理模块22与公共消息队列模块21之间可以通过订阅模式或点对点模式等多种方式进行通信。每当公共消息队列模块21中存储了新的用户状态消息时，后端处理模块22负责读取该用户状态消息，并根据该用户状态消息修改SSDB数据库中存储的用户状态信息。例如，当后端处理模块读取到的用户状态消息为用户上线消息时，则在SSDB数据库中增加相应用户终端的上线状态信息； 当后端处理模块读取到的用户状态消息为用户下线消息时，则在SSDB数据库中删除相应用户终端的上线状态信息。[〇〇43] SSDB数据库23负责根据后端处理模块发送的指令对用户状态信息进行存储及维护。在SSDB数据库中记录了各个用户终端的上线时间、下线时间、在线时长等具体信息。由于SSDB服务器为高性能数据库服务器，其能够提供内存式存储服务，且支持扩容，能够在存储容量不足时通过挂接一个SSDB服务器来实现扩容存储方案，从而实现存储容量的自由扩展。因此，通过SSDB数据库能够存储海量的用户状态信息。[〇〇44]查询服务器24能够根据接收到的查询请求，查询SSDB数据库23中存储的用户状态信息，并返回与该查询请求相对应的查询结果。其中，查询服务器不仅能够查询各个用户终端的当前状态、在线时长等信息，还能够进行多维度、多类型的查询。
[0045]所谓多维度的查询，是指能够查询某一具体应用的各个维度的信息。例如，以游戏应用为例来说，该应用至少包含平台、游戏和区服这三个不同维度的应用信息；又如，以熊猫直播应用为例来说，该应用至少包含终端类型(如PC web端和安卓端)、房间号这两个不同维度的应用信息。为了能够提供多个维度的查询，首先，需要在上文提到的用户终端发送的打点请求中包含多个维度的信息，例如，打点请求为“/Hit/Proc?uid = &loc = &prj = &sec = &0ther=”，其中，“loc”字段为应用信息字段，该字段进一步包括多个分别指示不同维度的应用信息的子字段。
[0046]假设某用户终端A在上午10:00发送的打点请求中的应用信息字段为l〇C = y〇Uxi dzz| si，该字段内包含三个子字段，各个子字段之间用竖线分隔，第一个子字段“youxi”用于表示发送本次打点请求的用户终端A目前处于游戏平台在线状态，第二个子字段“dzz”用于表示发送本次打点请求的用户终端目前在线的游戏名称为“大主宰”，第三个子字段“si” 用于表示发送本次打点请求的用户终端目前在线的区服为“si区服”。服务器节点接收到本次打点请求后，需要为用户终端A创建对应的定时器A，以指示用户终端A处于在线状态，为了清楚地显示出用户终端A在应用的各个维度的在线情况，服务器节点所创建的定时器A还需要进一步包括三个子定时器，其中，子定时器A1用于记录用户终端A在上午10:00时处于游戏平台在线状态，子定时器A2用于记录用户终端A在上午10:00时处于游戏平台中的“大主宰”游戏在线状态，子定时器A3用于记录用户终端A在上午10:00时处于游戏平台的“大主宰”游戏中的“s 1”区服在线状态。
[0047]假设该用户终端A在上午10:10发送的打点请求中的应用信息字段为l〇C = y〇Uxi dzz|S2,由此可以看出，用户终端A处于游戏平台中的大主宰游戏的s2区服在线状态。服务器节点接收到本次打点请求后，为用户终端A对应的定时器A发送延续指令，以延续定时器A 的生命周期，从而指示用户终端A仍然处于在线状态。另外，由于用户终端A依然处于游戏平台在线状态，因此，为子定时器A1发送延续指令，从而指示用户终端A仍然处于游戏平台在线状态。由于用户终端A依然处于游戏“大主宰”在线状态，因此，为子定时器A2发送延续指令，从而指示用户终端A仍然处于游戏平台中的“大主宰”游戏的在线状态。但是，由于用户终端A从si区服换到了 s2区服，因此，将子定时器A3销毁，以表明用户终端A已不在si区服， 并重新创建子定时器A3’，子定时器A3’用于记录用户终端A在上午10:10时处于游戏平台的 “大主宰”游戏中的“s2”区服在线状态。
[0048]又假设该用户终端A在上午10: 20发送的打点请求中的应用信息字段为loc = youxi | hazg | si，由此可以看出，用户终端A处于游戏平台中的“黑暗之光”游戏的si区服在线状态。服务器节点接收到本次打点请求后，为用户终端A对应的定时器A发送延续指令，以延续定时器A的生命周期，从而指示用户终端A仍然处于在线状态。另外，由于用户终端A依然处于游戏平台在线状态，因此，为子定时器A1继续发送延续指令，从而指示用户终端A仍然处于游戏平台在线状态。由于用户终端A已退出游戏“大主宰”，因此，将子定时器A2销毁， 并重新创建子定时器A2’，子定时器A2’用于记录用户终端A处于游戏平台中的“黑暗之光” 游戏的在线状态。同理，由于用户终端A已退出大主宰游戏的s2区服，因此，将子定时器A3’ 销毁，并重新创建子定时器A3”，子定时器A3”用于记录用户终端A在上午10:20时处于游戏平台的“黑暗之光”游戏中的“s2”区服在线状态。
[0049]相应地，在上述过程中，服务器节点生成的用户状态消息也进一步包括多个维度的状态消息。例如，当接收到用户终端A在上午10:00发送的打点请求后，服务器节点生成用于指示用户终端A上线的用户上线消息，同时，在该用户上线消息中进一步包括多个维度的子消息，例如，第一子消息用于指示用户终端A在游戏平台上线，第二子消息用于指示用户终端A在游戏平台的大主宰游戏上线，第三子消息用于指示用户终端A在游戏平台的大主宰游戏的si区服上线。当接收到用户终端A在上午10:10发送的打点请求后，服务器节点进一步生成用于指示用户终端A在游戏平台的大主宰游戏的si区服下线的子消息，以及用于指示用户终端A在游戏平台的大主宰游戏的s2区服上线的子消息。同理，当接收到用户终端A 在上午10:20发送的打点请求后，服务器节点进一步生成用于指示用户终端A在游戏平台的大主宰游戏下线的子消息以及在游戏平台的大主宰游戏的s2区服下线的子消息，以及用于指示用户终端A在游戏平台的黑暗之光游戏上线的子消息以及用于指示用户终端A在游戏平台的黑暗之光游戏的si区服上线的子消息。由此可见，SSDB数据库中存储了应用的各个维度的上下线状态信息，因此，查询服务器可以查询某一具体维度所对应的用户状态信息， 例如，可以查询某用户终端在游戏平台的在线时间、在大主宰游戏(或黑暗之光等其他游戏)的在线时间、以及在某一游戏的si区服或s2区服的在线时间等。
[0050]所谓多类型的查询，是指本系统支持对多种应用类型所对应的用户状态进行统计和查询，为此，需要在打点请求中进一步包含应用类型字段。例如，本系统支持游戏应用、熊猫直播应用、聊天应用等多种应用类型，当打点请求为“/Hit/Proc?uid = &loc = &prj = & sec = &other = ”时，通过其中的“pr j”字段来表示具体应用的类型。服务器节点可以通过 uhttp: //hulk.corp.qiho0.net: 8360/console/service/qconf，；地址中的 “qconf” 字段来设置应用类型所对应的配置信息，例如，当“qconf”字段的值为1时，表示需要向对应类型的应用推送用户状态消息；当“qconf”字段的值为0时，表示不需要向对应类型的应用推送用户状态消息。具体地，可以根据应用提供商的具体需求来配置“qconf”字段的值，例如，假设游戏应用提供商希望了解用户的实时状态，则可以通过服务器节点向游戏应用实时推送用户上/下线消息。
[0051]另外，本系统中的查询服务器除了支持多维度、多类型的查询之外，还可以进一步监测系统中其他模块的工作状态，例如，查询服务器持续监测各个应用和/或应用的各个维度的用户在线人数，当监测到某一应用或某一应用的某一维度的用户在线人数的变化率大于预设阈值时，则发出报警提示信息。例如，当大主宰游戏的用户在线人数在常规时段(如白天)内突然发生较大的波动时，例如，从1万人在线突然跌至1〇〇人在线，则可以推测该系统中的某一模块，例如某一台服务器节点出现了故障，因此，通过监测在线人数的实时变化率还能够起到报警提示的作用。[〇〇52]综上所述，在本实施例提供的用户状态统计系统中，能够实时统计大量用户终端的在线状态，并且，能够进行多维度、多类型的状态统计和查询。另外，在本系统中，用户状态信息并非存储在服务器节点的内存中，而是存储在后端的SSDB数据库中，因此，系统容量不必受限于单台服务器节点的内容，且服务器节点的数量可以根据实际需要进行灵活地增加或删减，使系统设计更为灵活。另外，在本系统中，通过公共消息队列模块实现了前端的用户终端和服务器节点与后端的SSDB数据库之间的异步处理，用户终端可以通过异步方式发送打点请求，后端SSDB数据库通过异步方式进行处理，从而使用户终端及服务器节点能够更加高效地运行。
[0053]图3示出了本发明另一实施例提供的用户状态统计方法的流程图。如图3所示，该方法具体包括如下步骤:[〇〇54]步骤S310:通过服务器集群中的多个服务器节点处理各个用户终端发送的打点请求。
[0055]具体实现时，可以由各个服务器节点直接接收并处理各个用户终端的打点请求。也可以通过至少一个反向代理模块接收各个用户终端发送的打点请求，反向代理模块获取打点请求中包含的用户标识，通过预设的哈希算法对用户标识进行计算，根据计算结果将各个打点请求分配给各个服务器节点处理。总之，通过多个服务器节点能够实现并行处理、 冗余备份等多重效果。
[0056]步骤S320:根据打点请求生成用户状态消息，将用户状态消息发送给SSDB数据库。 [〇〇57]其中，用户状态消息包括用户上线消息和用户下线消息，且各个用户终端在其在线期间，每隔预设时间间隔发送一次打点请求。具体地，该步骤可以通过如下方式实现:每当接收到用户终端发送的打点请求后，判断是否存储有对应于该用户终端的定时器，如果判断结果为是，则根据本次打点请求向对应于该用户终端的定时器发送延续指令;如果判断结果为否，则创建对应于该用户终端的定时器，并为该用户终端生成用户上线消息；其中，各个服务器节点持续地对本地存储的各个定时器进行监测，每当监测到在预设的超时时间阈值内未接收到延续指令的定时器时，将该定时器销毁，并为该定时器所对应的用户终端生成用户下线消息。除采用定时器的实现方式外，还可以灵活采用日志、字典等多种方式来维护用户状态信息。[〇〇58]步骤S330:通过SSDB数据库对各个服务器节点提供的用户状态消息进行统计，根据统计结果生成并存储用户状态信息。
[0059]具体地，可以由SSDB数据库直接接收各个服务器节点发送的用户状态消息，也可以由各个服务器节点将生成的用户状态消息存储到预设的公共消息队列模块中，然后由预设的后端处理模块将公共消息队列模块中的用户状态消息提供给所述SSDB数据库。总之， 本领域技术人员可以灵活采用多种方式实现本步骤。
[0060]上述步骤的具体实现细节可参照上一实施例中相应部分的描述，此处不再赘述。
[0061]图4示出了本发明另一具体实施例提供的用户状态统计方法的流程图。如图4所示，该方法具体包括如下步骤:[〇〇62]步骤S410:反向代理模块接收到用户终端发送的打点请求后，将打点请求分配给一台服务器节点中的框架接口模块。
[0063]其中，用户终端的数量为多个，各个用户终端可以通过异步通信的方式向反向代理模块发送打点请求。其中，用户终端发送的打点请求的形式可以是“online:80(rid)”。 [〇〇64]具体地，可以参照图2所示的系统框图来理解本实施例中的方法。反向代理模块根据打点请求中包含的用户标识将各个打点请求分配给各个服务器节点。例如，假设本次打点请求分配给第一服务器节点，则反向代理模块将本次打点请求发送给第一服务器节点中的框架接口模块(例如hero框架接口接口)，该框架接口模块通过预设的端口，例如“9010” 端口来接收反向代理模块发来的打点请求，例如，反向代理模块发来的打点请求的形式为 “9010(rid)”，表示该打点请求的目的地址为9010端口。另外，框架接口模块还可以向反向代理模块返回响应消息或心跳包，以表明其所在的服务器节点处于正常工作状态。[〇〇65]步骤S420:框架接口模块将打点请求发送给该框架接口模块所在的服务器节点。 [〇〇66]具体地，第一服务器节点上的框架接口模块通过9010端口接收到来自反向代理模块的打点请求“9010(rid)”后，将其发送给该框架接口模块所在的第一服务器节点进行处理，框架接口模块发送的打点请求的形式可以是hit(rid)。其中，框架接口模块的主要作用在于向反向代理模块提供统一的通信接口，因此，各台服务器节点通过框架接口模块来接收打点请求能够显著节约开发人员的开发成本。
[0067]步骤S430:服务器节点对接收到的打点请求进行处理，以生成用户状态消息，并将用户状态消息发送给公共消息队列模块。
[0068]具体地，服务器节点接收到打点请求后，可以通过字典、日志、定时器等多种方式来维护用户状态。例如，每当服务器节点接收到用户终端发送的打点请求后，判断是否存储有对应于该用户终端的定时器，如果判断结果为是，说明该用户终端已经处于在线状态，则根据本次打点请求向对应于该用户终端的定时器发送延续指令;如果判断结果为否，说明该用户终端刚刚上线，则创建对应于该用户终端的定时器，并为该用户终端生成用户上线消息;其中，各个服务器节点持续地对本地存储的各个定时器进行监测，每当监测到在预设的超时时间阈值内未接收到延续指令的定时器时，将该定时器销毁，并为该定时器所对应的用户终端生成用户下线消息。由此可见，通过定时器能够监测到各个用户终端的上线动作和下线动作，并在用户终端上线时生成用户上线消息，在用户终端下线时生成用户下线消息。用户状态消息除包含上述的用户上线消息和用户下线消息外，还可以进一步包含用于指示用户终端目前处于在线状态的用户在线消息等。[〇〇69]步骤S440:公共消息队列模块将存储的用户状态消息提供给后端处理模块。
[0070]其中，公共消息队列模块用于对用户状态消息进行有序存储。公共消息队列是一种先进先出的分布式消息队列，能够在消息传输过程中作为保存消息的容器，从而为程序或组件提供异步的通信机制，使发送方和接收方不必同时在线，也不必了解对方，就可以相互传输消息。后端处理模块与公共消息队列模块之间可以通过订阅模式或点对点模式等多种方式进行通信。具体地，可以由后端处理模块订阅公共消息队列中的内容，相应地，每当公共消息队列进行更新后，后端处理模块自动获取到更新消息，并根据更新消息来读取公共消息队列中的内容。
[0071]步骤S450:后端处理模块根据读取到的用户状态消息更新SSDB数据库中存储的用户状态信息。[〇〇72]具体地，当后端处理模块读取到的用户状态消息为用户上线消息时，则在SSDB数据库中增加相应用户终端的上线状态信息；当后端处理模块读取到的用户状态消息为用户下线消息时，则在SSDB数据库中删除相应用户终端的上线状态信息。[〇〇73]步骤S460:查询服务器根据接收到的查询请求，查询SSDB数据库中存储的用户状态信息，并返回与该查询请求相对应的查询结果。
[0074]其中，查询服务器不仅能够查询各个用户终端的当前状态、在线时长等信息，还能够进行多维度、多类型的查询。具体的查询过程可以参照上一实施例中相应部分的描述，此处不再赘述。
[0075]在本发明提供的用户状态统计系统及方法中，通过包含多个服务器节点的服务器集群接收来自各个用户终端的打点请求，并根据打点请求生成用户状态消息，将该用户状态消息提供给SSDB数据库，以供SSDB数据库根据用户状态消息维护用户状态信息。由此可见，在本发明中，服务器节点通过集群形式实现，且数量为多个，因而能够并行处理各个用户终端发来的打点请求，大幅提高了服务器节点的处理速度，缩短了响应时间，能够同时服务于更多的用户终端。另外，由于用户状态信息存储在SSDB数据库内，而非存储在服务器节点的内存中，因此，上述服务器集群中所包含的服务器节点的数量可以灵活调整:当用户数量多时，可以通过挂接一个服务器节点来服务于更多的用户；当用户数量少时，可以摘除一个服务器节点以节约成本。由此可见，本申请提供的方式具有较强的可扩展性，系统设计较为灵活。除此之外，当某一个服务器节点故障时，其他服务器节点依然能够确保整个系统的正常运行，因此，本申请提供的方式具有较强的灾备功能。
[0076]在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。 各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。[〇〇77]在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。[〇〇78]类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此， 遵循【具体实施方式】的权利要求书由此明确地并入该【具体实施方式】，其中每个权利要求本身都作为本发明的单独实施例。[〇〇79]本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
[0080]此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
[0081]本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
[0082]应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中， 不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
[0083]本发明还公开了 B10、一种用户状态统计方法，包括:
[0084]通过服务器集群中的多个服务器节点处理各个用户终端发送的打点请求；[〇〇85]根据所述打点请求生成用户状态消息，将所述用户状态消息发送给SSDB数据库；
[0086]通过SSDB数据库对各个服务器节点提供的用户状态消息进行统计，根据统计结果生成并存储用户状态信息。
[0087]B11、根据B10所述的方法，其中，所述用户状态消息包括用户上线消息和用户下线消息，且各个用户终端在其在线期间，每隔预设时间间隔发送一次打点请求，
[0088]则所述根据所述打点请求生成用户状态消息的步骤具体包括:每当接收到用户终端发送的打点请求后，判断是否存储有对应于该用户终端的定时器，如果判断结果为是，则根据本次打点请求向对应于该用户终端的定时器发送延续指令;如果判断结果为否，则创建对应于该用户终端的定时器，并为该用户终端生成用户上线消息;其中，各个服务器节点持续地对本地存储的各个定时器进行监测，每当监测到在预设的超时时间阈值内未接收到延续指令的定时器时，将该定时器销毁，并为该定时器所对应的用户终端生成用户下线消息。
[0089]B12、根据B11所述的方法，其中，所述打点请求中包括应用信息字段，且所述应用信息字段进一步包括多个分别指示不同维度的应用信息的子字段，则对应于一个用户终端的定时器进一步包括多个子定时器，各个子定时器分别对应于不同维度的状态信息;并且， 所述用户上线消息进一步包括各个维度所对应的用户上线消息，且所述用户下线消息进一步包括各个维度所对应的用户下线消息。
[0090]B13、根据B10-12任一所述的方法，其中，所述将所述用户状态消息发送给SSDB数据库的步骤具体包括:
[0091]各个服务器节点将生成的用户状态消息存储到预设的公共消息队列模块中，由预设的后端处理模块将所述公共消息队列模块中的用户状态消息提供给所述SSDB数据库。 [〇〇92]B14、根据B10-13任一所述的方法，其中，所述通过服务器集群中的多个服务器节点处理各个用户终端发送的打点请求的步骤具体包括:
[0093]通过至少一个反向代理模块接收各个用户终端发送的打点请求，获取所述打点请求中包含的用户标识，通过预设的哈希算法对所述用户标识进行计算，根据计算结果将各个打点请求分配给各个服务器节点处理。[〇〇94]B15、根据B14所述的方法，其中，所述方法进一步包括步骤:通过反向代理模块检测各个服务器节点的工作状态，当检测到出现故障的服务器节点时，停用所述出现故障的服务器节点;并在检测到所述故障恢复时，重新启用所述出现故障的服务器节点。[〇〇95]B16、根据B10-15任一所述的方法，其中，所述方法包括:根据接收到的查询请求，查询所述SSDB数据库中存储的用户状态信息，并返回与该查询请求相对应的查询结果；
[0096]并且，所述方法进一步包括:监测各个应用和/或应用的各个维度的用户在线人数，当监测到的用户在线人数的变化率大于预设阈值时，发出报警提示信息。[〇〇97]B17、根据B10-16任一所述的方法，其中，所述打点请求中包括应用类型字段，则所述方法进一步包括步骤:根据所述应用类型字段将用户状态消息推送给对应类型的应用。 [0〇98]B18、根据B10-17任一所述的方法，其中，所述打点请求为异步请求消息。
【主权项】
1.一种用户状态统计系统，包括:服务器集群，以及与所述服务器集群相连的SSDB数据 库，其中，所述服务器集群包括多个服务器节点，各个服务器节点分别用于处理各个用户终端发 送的打点请求，并根据所述打点请求生成用户状态消息，将所述用户状态消息提供给所述 SSDB数据库；所述SSDB数据库用于对各个服务器节点提供的用户状态消息进行统计，根据统计结果 生成并存储用户状态信息。2.根据权利要求1所述的系统，其中，所述用户状态消息包括用户上线消息和用户下线 消息，且各个用户终端在其在线期间，每隔预设时间间隔发送一次打点请求，则各个服务器节点具体用于:每当接收到用户终端发送的打点请求后，判断是否存储 有对应于该用户终端的定时器，如果判断结果为是，则根据本次打点请求向对应于该用户 终端的定时器发送延续指令;如果判断结果为否，则创建对应于该用户终端的定时器，并为 该用户终端生成用户上线消息；其中，各个服务器节点持续地对本地存储的各个定时器进 行监测，每当监测到在预设的超时时间阈值内未接收到延续指令的定时器时，将该定时器 销毁，并为该定时器所对应的用户终端生成用户下线消息。3.根据权利要求2所述的系统，其中，所述打点请求中包括应用信息字段，且所述应用 信息字段进一步包括多个分别指示不同维度的应用信息的子字段，则对应于一个用户终端 的定时器进一步包括多个子定时器，各个子定时器分别对应于不同维度的状态信息;并且， 所述用户上线消息进一步包括各个维度所对应的用户上线消息，且所述用户下线消息进一 步包括各个维度所对应的用户下线消息。4.根据权利要求1-3任一所述的系统，其中，所述系统进一步包括:公共消息队列模块 以及后端处理模块，其中，各个服务器节点用于将生成的用户状态消息存储到所述公共消 息队列模块中，所述后端处理模块用于读取所述公共消息队列模块中的用户状态消息，并 根据读取到的用户状态消息修改所述SSDB数据库中存储的用户状态信息。5.根据权利要求1-4任一所述的系统，其中，所述服务器集群中进一步包括:至少一个 反向代理模块，用于接收各个用户终端发送的打点请求，获取所述打点请求中包含的用户 标识，通过预设的哈希算法对所述用户标识进行计算，根据计算结果将各个打点请求分配 给各个服务器节点处理。6.根据权利要求5所述的系统，其中，所述反向代理模块进一步用于:检测各个服务器 节点的工作状态，当检测到出现故障的服务器节点时，停用所述出现故障的服务器节点;并 在检测到所述故障恢复时，重新启用所述出现故障的服务器节点。7.根据权利要求1-6任一所述的系统，其中，所述系统进一步包括:与所述SSDB数据库 相连的查询服务器，用于根据接收到的查询请求，查询所述SSDB数据库中存储的用户状态 信息，并返回与该查询请求相对应的查询结果；并且，所述查询服务器进一步用于:监测各个应用和/或应用的各个维度的用户在线人 数，当监测到的用户在线人数的变化率大于预设阈值时，发出报警提示信息。8.根据权利要求1-7任一所述的系统，其中，所述打点请求中包括应用类型字段，则所 述服务器节点进一步用于:根据所述应用类型字段将用户状态消息推送给对应类型的应 用。9.根据权利要求1-8任一所述的系统，其中，所述打点请求为异步请求消息。10.—种用户状态统计方法，包括:通过服务器集群中的多个服务器节点处理各个用户终端发送的打点请求；根据所述打点请求生成用户状态消息，将所述用户状态消息发送给SSDB数据库；通过SSDB数据库对各个服务器节点提供的用户状态消息进行统计，根据统计结果生成 并存储用户状态信息。
【文档编号】H04L12/24GK106027289SQ201610304635
【公开日】2016年10月12日
【申请日】2016年5月9日
【发明人】段兵营
【申请人】北京奇虎科技有限公司, 奇智软件（北京）有限公司