CN103685357A - 一种账号多开消息处理方法及*** - Google Patents

Abstract

本发明是关于一种账号多开消息处理方法及***，所述的方法包括：数据中心接收应用***发送给目标账号的消息，检测所述目标账号是否有至少两个客户端同时使用，所述数据中心用于维护***账号当前的在线状态；在所述目标账户有至少两个客户端同时使用时，数据中心确定对与所述的至少两个客户端分别对应的至少两个消息转发器；所述至少两个消息转发器分别将发送给目标账号的消息转发给所述的至少两个客户端。本发明实施例提供的账号多开消息处理方法及***可以让使用同一账号同时登陆的多台客户端同时受到应用***发给目标账号的消息，保证用户不会漏接消息，提高了用户体验。

Description

一种账号多开消息处理方法及***

技术领域

本发明是关于通信技术领域，尤其是关于消息处理技术领域，具体来说是关于一种账号多开消息处理方法及***。

背景技术

随着通信技术的发展，网络游戏业也在迅猛发展。在网络游戏和其他通信应用中，用户通过注册账号登录至服务器，通常，同一账号只能在一台客户端登录至服务器，如果其他客户端使用相同的账号登陆，则会提示无法登陆或将断开与之前登陆的客户端的链接。随着通信应用的不断发展，现有技术可以允许不同客户端使用同一账号同时登陆，以满足通信应用的需要，然而，当多个客户端使用同一账号进行登陆时，如果此时应用***需要向该账号发送消息，则同时登陆的多个客户端中只有一台客户端可以收到该消息，其他客户端无法收到该消息，这就造成了应用***发送的消息无法及时有效的发送至目标账号，用户会漏接重要的消息。

发明内容

为克服现有技术中存在的问题，本发明提供一种账号多开消息处理方法及***。

本发明提供一种账号多开消息处理方法，所述的方法包括：数据中心接收应用***发送给目标账号的消息，检测所述目标账号是否有至少两个客户端同时使用，所述数据中心用于维护***账号当前的在线状态；在所述目标账户有至少两个客户端同时使用时，数据中心确定对与所述的至少两个客户端分别对应的至少两个消息转发器；所述至少两个消息转发器分别将发送给目标账号的消息转发给所述的至少两个客户端。

本发明还提供一种同账号多开消息处理***，所述的***包括数据中心、消息转发器和客户端，其中：数据中心接收应用***发送给目标账号的消息，检测所述目标账号是否有至少两个客户端同时使用，所述数据中心用于维护***账号当前的在线状态；在所述目标账户有至少两个客户端同时使用时，数据中心确定对与所述的至少两个客户端分别对应的至少两个消息转发器；所述至少两个消息转发器分别将发送给目标账号的消息转发给所述的至少两个客户端

本发明实施例提供的账号多开消息处理方法及***可以让使用同一账号同时登陆的多台客户端同时受到应用***发给目标账号的消息，保证用户不会漏接消息，提高了用户体验。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是本发明实施例同账号多开消息处理***的架构图；

图2是本发明实施例提供的一种账号多开消息处理方法流程图；

图3是本发明实施例提供的发送离线消息的处理流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。

本发明实施例提供一种账号多开消息处理方法及***，以下结合附图对本发明进行详细说明。

实施例一

图1是本发明实施例同账号多开消息处理***的架构图。如图1所示，该***包括三大部分：数据中心（Data Center，DC），消息转发器（Message Broker，MB）以及负载均衡器（Load Balance，LB）。数据中心连接应用***（APP）和消息转发器；消息转发器连接数据中心、负载均衡器以及客户端；负载均衡器连接消息转发器和客户端。

数据中心，接收应用***发送给目标账号的消息，根据所述的消息获取目标账号信息，检测是否有至少两个客户端同时使用所述的目标账号信息登陆，如果至少两个客户端同时使用所述的目标账号信息登陆，则将所述的消息同时发送至所述至少两个客户端。

在本发明实施例中，数据中心主要实现用户状态管理和数据选路分发等功能。消息转发器通过定时心跳消息告知和更新当前在线的账号状态，数据中心维护整个***的在线账号状态；应用***（App）产生消息发送至数据中心，如果数据需要存储，那么数据中心存储该消息，然后将消息分发给相应的消息转发器。如果消息转发器发送成功那么提示数据中心删除该消息。

消息传送方式有一对一和一对多两种。比如回复消息为一对一的传送方式，广播消息和被订阅的消息则为一对多的传送方式。其中，一对多的消息可以分为两大类：定向和非定向的。确切知道是传送给哪些用户的一对多的消息定义为定向的消息，不明确知道需要传送给哪些用户的一对多的消息则为非定向的。根据以上定义，广播***消息定义为非定向的；如果用户发布的消息被多人订阅了，那么该消息为定向的。

本实施例中***只会存储一对一的离线消息以及定向的一对多的离线消息，非定向的离线广播消息一般不存，但具有一定生命周期的离线广播消息除外，例如：给一定时间段内的登录用户发送的离线广播消息会被存储，直至生命周期结束后将被删除。

在本发明实施例中，消息转发器接收数据中心发送的所述的消息，将所述的消息发送至所述至少两个客户端。消息转发器更新账号当前的在线状态，并将账号当前的在线状态告知所述数据中心；所述数据中心维护整个***中账号当前的在线状态，以提供查询账号状态的接口，并根据***中的账号当前的在线状态对来自所述应用***的消息进行处理。当用户登录时，消息转发器根据用户的session id（会话标识）向认证服务器进行验证，验证通过那么就建立与该用户的通信，否则拒绝该用户登录。

在本发明实施例中，负载均衡器根据链路状况以及消息转发器的负载情况，为客户端分配对应的消息转发器，具体来说，负载均衡器与首次登录的客户端建立连接，根据链路状况以及消息转发器的负载情况，为客户端分配最优的消息转发器；并在已分配的消息转发器出现故障时，为客户端重新分配消息转发器。消息转发器向负载均衡器注册，和定时通报其自身的负载。客户端会向负载均衡器发送获取消息转发器请求，负载均衡器会选择一台消息转发器回复给客户端，然后客户端与相应的消息转发器进行通信。

可选地，所述***还包括：连接不同机房内的多个数据中心的代理托管模块；所述数据中心，还用于将存储的离线消息通过所述代理托管模块同步至其它机房；当用户当前的在线状态发生变化时，通知所述代理托管模块进行用户状态更新。数据中心之间由代理托管模块（Proxy）对接，以完成数据跨***处理。在实际网络应用中，数据中心可分为电信和网通两个，分别用两台服务器，保持总量200万以上的客户端并可继续扩充。

可选地，本实施例中，App与DC之间采用基于TCP的字符串型通信协议，类似于http协议，分为消息头部和消息体。消息头和消息体使用CRLF（回车换行，carriagereturn/line feed）分割。消息头部中的字段名和值使用空格分割，字段之间使用CRLF分割。除App与DC之外，其它通信协议是二进制通信协议。其中Message Broker与DC及Load balance之间的通信是基于TCP传输协议，而与客户端有关的通信都是基于UDP传输协议。当使用UDP传输协议，需要考虑可靠性，当数据包丢失时，需要重传，并且当数据包较大时（大于512字节），就需要分包。

可选地，本实施例中，客户端的心跳包大小为16+46=62Byte。假设100万用户每隔30秒发送心跳包，那么Message Broker端总使用带宽大约为62Mbyte/30s*8=16.5Mbit/s。消息转发器与客户端的通信数据都采用某种加密算法进行加密，如：AES。

账号多开的消息实现方法：

以单机房考虑，数据存储结构设计如下：

1）Data Center上的存储结构

Data Center需要存储的数据主要有离线消息数据和在线用户信息。其中离线消息数据是持久化存储在硬盘上，而在线用户信息是存储在内存上的。定义消息接收者的ID为usrid，消息发送者的ID为sndrid，消息的内容表示为content，同时每一条消息都有全局唯一的编号uid，以及过期时间expire。其中uid可以由Data Center生成的UUID表示，或者由应用程序生成。如果消息是由应用程序多写到多服务器的话，那么应该由应用程序生成uid。

存储打算使用TC数据库来实现。离线消息数据采用B+树数据库来存储，分两个数据库文件存储，一个存储索引，一个存储实体数据。设计如下：

索引结构：

实体数据存储结构：

uid1	content1
		uid2	content2
uidN	contentN

在线用户信息使用hashmap来存储，由于需要支持用户多开，允许同一usrid登录到多个机房的多台机器上，那么存储每台机器对应的ip地址和端口。故设计存储结构如下：

2）Message Broker上的存储结构

Message Broker需要维持用户连接信息，存储至内存。由于可能用户使用一个账号，在多处同时登录，那么每一个登录的客户端使用session表示，每一个session都有一个id号。即每一个客户端连接对应一个sessionid，记为sid，那么每一个usrid可能对应多个sid。每一个客户端保存其“连接”地址，记为sockaddr。设计存储结构如下：

当一个客户端退出时，删除对应session的信息，当一个usrid的所有session都退出后，那么删除该usrid的信息，并通知Data Center变更用户状态。Data center删除该usrid与该Message Broker的对应信息，当usrid与Message Broker的对应关系为空时，那么表示该用户是离线的，删除该usrid对应的在线用户信息。

用户订阅列表：每类应用消息可以使用一个特定的ID表示，用id表示，当用户订阅了该类消息时，那么会将消息推送给用户。每个ID可能都有许多用户订阅，故对应于该ID有一个用户列表userlist存储结构如下：

id1	userlist1
		id2	userlist2
idN	userlistN

在本发明的另一实施例中，数据中心在目标账号离线时将所述消息作为离线消息统一存储和备份，并根据所述消息转发器的请求，向所述消息转发器发送对应的离线消息；消息转发器在客户端使用目标账号登录时，向所述数据中心发起获取离线消息的请求，接收所述数据中心返回的离线消息，将所述离线消息发送给对应的客户端。消息转发器在成功发送所述离线消息给客户端之后，向所述数据中心返回成功发送通知；数据中心根据所述成功发送通知，删除已成功发送的离线消息。

本发明实施例提供的同账号多开消息处理***可以让使用同一账号同时登陆的多台客户端同时受到应用***发给目标账号的消息，保证用户不会漏接消息，提高了用户体验。

离线消息处理过程：首先用户登录至Message Broker，然后Message Broker向Datacenter发送获取对应用户的离线消息请求；然后DC查询是否存在对应用户的离线消息，如果存在那么进行下一步，否则结束该操作过程；DC将离线消息推送给对应的MessageBroker，然后又Message Broker发送给对应的用户，如果发送成功，那么Message Broker通知DC删除存储的对应的离线消息并结束该操作过程，否则不删除离线消息并结束该过程。

实施例二

基于前述实施例的同账号多开消息处理***，本发明实施例还提供一种账号多开消息处理方法。图2是本发明实施例提供的一种账号多开消息处理方法流程图，图3是本发明实施例提供的发送离线消息的处理流程图，如图2和图3所示，所述的方法包括：

S201，数据中心接收应用***发送给目标账号的消息，检测所述目标账号是否有至少两个客户端同时使用，所述数据中心用于维护***账号当前的在线状态。

S202，在所述目标账户有至少两个客户端同时使用时，数据中心确定对与所述的至少两个客户端分别对应的至少两个消息转发器。

S203，所述至少两个消息转发器分别将发送给目标账号的消息转发给所述的至少两个客户端。

在本发明实施例中，数据中心可以将所述的消息发送至消息转发器，通过所述消息转发器将所述的消息发送至所述至少两个客户端。

在本发明实施例中，所述消息转发器更新账号当前的在线状态，并将账号当前的在线状态告知所述数据中心；所述数据中心维护整个***中账号当前的在线状态，以提供查询账号状态的接口，并根据***中的账号当前的在线状态对来自所述应用***的消息进行处理。

在本发明的另一实施例中，所述的方法还包括：

负载均衡器根据链路状况以及消息转发器的负载情况，为客户端分配对应的消息转发器。具体来说，负载均衡器与首次登录的客户端建立连接，根据链路状况以及消息转发器的负载情况，为客户端分配最优的消息转发器；并在已分配的消息转发器出现故障时，为客户端重新分配消息转发器。

在本发明的另一实施例中，所述的方法还包括：

如果目标账号离线，则数据中心将所述消息作为离线消息统一存储和备份；

当客户端使用目标账号登录时，与所述客户端对应的消息转发器向所述数据中心发起获取离线消息的请求；

所述数据中心根据所述消息转发器的请求，向所述消息转发器发送对应的离线消息；

所述消息转发器接收所述数据中心返回的离线消息，将所述离线消息发送给对应的客户端。

在本发明的另一实施例中，所述方法还包括：

在成功发送所述离线消息给客户端之后，所述消息转发器向所述数据中心返回成功发送通知；

所述数据中心根据所述成功发送通知，删除已成功发送的离线消息。

本发明实施例的账号多开消息处理方法与***具有以下特点：

1、可以让使用同一账号同时登陆的多台客户端同时受到应用***发给目标账号的消息，保证用户不会漏接消息，提高了用户体验；

2、消息由数据中心集中统一管理，便于备份和防止数据丢失；

3、数据中心可扩展，数据中心之间由Proxy托管模块对接；

4、用户链接分类，初次登录用户或者与消息转发器连接失败的用户由负载均衡器进行消息转发器的再分配，消息转发器仅用于维护用户的网络连接以及推送离线消息给用户；具体地，负载均衡器用于与第一次登录的用户建立连接，为用户选择链路最优的消息转发器，同时，在消息转发器出现问题时，为用户再分配消息转发器建立链路。

本发明实施例的离线消息集中处理方法与***，通过对离线消息进行统一管理和备份，避免了现有技术中离线消息分散存储所带来的弊端，提升了用户的使用体验。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种账号多开消息处理方法，其特征在于，所述的方法包括：

数据中心接收应用***发送给目标账号的消息，检测所述目标账号是否有至少两个客户端同时使用，所述数据中心用于维护***账号当前的在线状态；

在所述目标账户有至少两个客户端同时使用时，数据中心确定对与所述的至少两个客户端分别对应的至少两个消息转发器；

所述至少两个消息转发器分别将发送给目标账号的消息转发给所述的至少两个客户端。

2.根据权利要求1所述的账号多开消息处理方法，其特征在于，

所述消息转发器更新相同目标账号下客户端的会话记录的当前在线状态，在所有客户端都退出消息转发器时通知所述数据中心，数据中心删除无客户端连接的消息转发器。

3.根据权利要求1所述的账号多开消息处理方法，其特征在于，所述的方法还包括：

负载均衡器根据链路状况以及消息转发器的负载情况，为客户端分配对应的消息转发器；

所述负载均衡器根据链路状况以及消息转发器的负载情况，为用户分配对应的消息转发器具体包括：

所述负载均衡器与首次登录的客户端建立连接，根据链路状况以及消息转发器的负载情况，为客户端分配最优的消息转发器；并在已分配的消息转发器出现故障时，为客户端重新分配消息转发器。

4.根据权利要求1所述的账号多开消息处理方法，其特征在于，所述的方法还包括：

如果目标账号离线，则数据中心将所述消息作为离线消息统一存储和备份；

当客户端使用目标账号登录时，与所述客户端对应的消息转发器向所述数据中心发起获取离线消息的请求；

所述数据中心根据所述消息转发器的请求，向所述消息转发器发送对应的离线消息；

所述消息转发器接收所述数据中心返回的离线消息，将所述离线消息发送给对应的客户端。

5.根据权利要求4所述的账号多开消息处理方法，其特征在于，所述方法还包括：

在成功发送所述离线消息给客户端之后，所述消息转发器向所述数据中心返回成功发送通知；

所述数据中心根据所述成功发送通知，删除已成功发送的离线消息。

6.一种账号多开消息处理***，其特征在于，所述的***包括数据中心、消息转发器和客户端，其中：

数据中心接收应用***发送给目标账号的消息，检测所述目标账号是否有至少两个客户端同时使用，所述数据中心用于维护***账号当前的在线状态；在所述目标账户有至少两个客户端同时使用时，数据中心确定对与所述的至少两个客户端分别对应的至少两个消息转发器；

所述至少两个消息转发器分别将发送给目标账号的消息转发给所述的至少两个客户端。

7.根据权利要求6所述的账号多开消息处理***，其特征在于，

所述消息转发器更新相同目标账号下客户端的会话记录的当前在线状态，在所有客户端都退出消息转发器时通知所述数据中心；

所述的数据中心删除无客户端连接的消息转发器。

8.根据权利要求6所述的账号多开消息处理***，其特征在于，所述的***还包括：

负载均衡器，用于根据链路状况以及消息转发器的负载情况，为客户端分配对应的消息转发器；

所述负载均衡器根据链路状况以及消息转发器的负载情况，为用户分配对应的消息转发器具体包括：

所述负载均衡器与首次登录的客户端建立连接，根据链路状况以及消息转发器的负载情况，为客户端分配最优的消息转发器；并在已分配的消息转发器出现故障时，为客户端重新分配消息转发器。

9.根据权利要求6所述的账号多开消息处理***，其特征在于，

如果目标账号离线，则数据中心将所述消息作为离线消息统一存储和备份；

当客户端使用目标账号登录时，与所述客户端对应的消息转发器向所述数据中心发起获取离线消息的请求；

所述数据中心根据所述消息转发器的请求，向所述消息转发器发送对应的离线消息；

所述消息转发器接收所述数据中心返回的离线消息，将所述离线消息发送给对应的客户端。

10.根据权利要求9所述的账号多开消息处理***，其特征在于，

在成功发送所述离线消息给客户端之后，所述消息转发器向所述数据中心返回成功发送通知；

所述数据中心根据所述成功发送通知，删除已成功发送的离线消息。

Images