CN110580257A - 数据共享方法、服务器及介质 - Google Patents

Abstract

本申请实施例提供一种数据共享方法、服务器及介质。本申请实施例提供的数据共享方法，通过公用存储转发服接收数据查询请求，再根据数据查询请求中的查询条件从存储有全服数据的全服数据库中获取对应的查询数据，然后再利用数据查询请求中服务器标识信息将相应的查询数据反馈至对应的游戏服中。本申请实施例提供的数据共享方法，可以使发起用户查询请求的用户设备可以接收到对应的查询数据反馈，从而实现全服的数据共享。

Description

数据共享方法、服务器及介质

技术领域

本申请涉及游戏技术领域，尤其涉及一种数据共享方法、服务器及介质。

背景技术

随着游戏技术的快速发展，大型多人在线角色扮演游戏(Multiplayer OnlineRole-Playing Game，简称MMORPG)也越来越受到玩家的欢迎，玩家可以扮演成一个虚拟角色并在虚拟世界中活动。

这类游戏具有一个持续运行的虚拟世界，即使玩家离开游戏，这个虚拟世界仍在网络游戏运营商提供的服务器里继续存在并随着时间的发展会产出各种策划设定的物品和怪物，所以这类游戏会对消息处理的速度和响应速度有着极高的要求。因此，在现有的MMORPG中，为了保证游戏的运行性能，需要设置多个服务器。

但是，在此类游戏中，玩家的许多用户行为(例如：社交需求)并不局限于同一服务器，为了让玩家有更好的社交体验，需要满足不同服玩家的全服数据共享(例如：实现全服社交数据共享，以满足社交需求)。

发明内容

本申请提供一种数据共享方法、服务器及介质，以解决无法满足用户的全服数据共享的技术问题。

第一方面，本申请提供一种数据共享方法，包括：

接收数据查询请求，所述数据查询请求包括查询条件以及服务器标识信息；

根据所述查询条件从全服数据库中获取查询数据，所述全服数据库用于存储全服数据，所述全服数据包括多个服务器上传的用户数据；

根据所述服务器标识信息发送所述查询数据。

在一种可能的设计中，所述的数据共享方法，还包括：

根据预设接收规则接收所述用户数据；

将所述用户数据上传至所述全服数据库。

在一种可能的设计中，所述根据预设接收规则接收所述用户数据，包括：

根据预设周期对所述用户数据进行接收。

在一种可能的设计中，所述根据预设接收规则接收所述用户数据，包括：

接收特定服务器发送的所述用户数据，所述特定服务器为所述多个服务器中的其中一个服务器，所述特定服务器用于接收所述多个服务器中的其他服务器发送的用户数据。

在一种可能的设计中，所述根据所述查询条件从全服数据库中获取查询数据，包括：

根据所述查询条件从预设非关系型数据库和/或预设缓存数据库中获取所述查询数据，所述全服数据库包括所述预设非关系型数据库以及所述预设缓存数据库。

在一种可能的设计中，所述的数据共享方法还包括：

获取注册请求，所述注册请求包括需要建立连接的服务器所对应的服务器标识信息；

注册所述服务器标识信息。

第二方面，本申请还提供一种数据共享方法，包括：

接收用户查询请求，所述用户查询请求包括查询条件；

发送数据查询请求，所述数据查询请求包括所述查询条件以及服务器标识信息；

接收查询数据，所述查询数据为根据所述查询条件从全服数据库中获取的数据，所述全服数据库用于存储全服数据，所述全服数据包括多个服务器上传的用户数据。

在一种可能的设计中，所述的数据共享方法，还包括：

根据预设选取规则确定所述多个服务器中的其中一个服务器作为特定服务器，所述特定服务器用于接收所述多个服务器中的其他服务器发送的用户数据，并根据预设发送规则发送所述用户数据。

在一种可能的设计中，所述预设发送规则，包括：

按照预设周期对所述用户数据进行发送。

在一种可能的设计中，所述预设选取规则，包括：

选取所述多个服务器中空闲内存最大的服务器作为所述特定服务器；或者，

选取所述多个服务器中用户数量最少的服务器作为所述特定服务器。

在一种可能的设计中，所述的数据共享方法，还包括：

获取在预设时长内，接收到的所述用户查询请求的请求数量；

若所述请求数量大于预设数量阈值，则暂停接收所述用户查询请求。

在一种可能的设计中，在所述暂停接收所述用户查询请求之后，还包括：

发送暂停接收指令，所述暂停接收指令用于指示用户暂停输入所述用户查询请求。

第三方面，本申请还提供一种服务器，包括：

请求接收模块，用于接收数据查询请求，所述数据查询请求包括查询条件以及服务器标识信息；

数据获取模块，用于根据所述查询条件从全服数据库中获取查询数据，所述全服数据库用于存储全服数据，所述全服数据包括多个服务器上传的用户数据；

数据发送模块，用于根据所述服务器标识信息发送所述查询数据。

在一种可能的设计中，所述服务器，还包括：

数据接收模块，用于根据预设接收规则接收所述用户数据；

数据上传模块，用于将所述用户数据上传至所述全服数据库。

在一种可能的设计中，所述数据接收模块，具体用于：

根据预设周期对所述用户数据进行接收。

在一种可能的设计中，所述数据接收模块，具体用于：

接收特定服务器发送的所述用户数据，所述特定服务器为所述多个服务器中的其中一个服务器，所述特定服务器用于接收所述多个服务器中的其他服务器发送的用户数据。

在一种可能的设计中，所述数据获取模块，具体用于：

根据所述查询条件从预设非关系型数据库和/或预设缓存数据库中获取所述查询数据，所述全服数据库包括所述预设非关系型数据库以及所述预设缓存数据库。

在一种可能的设计中，所述请求接收模块，还用于获取注册请求，所述注册请求包括需要建立连接的服务器所对应的服务器标识信息；

所述服务器，还包括：

信息注册模块，用于注册所述服务器标识信息。

第四方面，本申请还提供一种服务器，包括：

查询接收模块，用于接收用户查询请求，所述用户查询请求包括查询条件；

请求发送模块，用于发送数据查询请求，所述数据查询请求包括所述查询条件以及服务器标识信息；

数据接收模块，用于接收查询数据，所述查询数据为根据所述查询条件从全服数据库中获取的数据，所述全服数据库用于存储全服数据，所述全服数据包括多个服务器上传的用户数据。

在一种可能的设计中，所述的数据共享方法，还包括：

服务器确定模块，用于根据预设选取规则确定所述多个服务器中的其中一个服务器作为特定服务器，所述特定服务器用于接收所述多个服务器中的其他服务器发送的用户数据，并根据预设发送规则发送所述用户数据。

所述预设发送规则，包括：按照预设周期对所述用户数据进行发送。

在一种可能的设计中，所述服务器确定模块，具体用于：

选取所述多个服务器中空闲内存最大的服务器作为所述特定服务器；或者，

选取所述多个服务器中用户数量最少的服务器作为所述特定服务器。

在一种可能的设计中，所述服务器，还包括：

数量确定模块，用于获取在预设时长内，接收到的所述用户查询请求的请求数量；

请求暂停模块，用于当所述请求数量大于预设数量阈值时，暂停接收所述用户查询请求。

在一种可能的设计中，所述服务器，还包括：

指令发送模块，用于发送暂停接收指令，所述暂停接收指令用于指示用户暂停输入所述用户查询请求。

第五方面，本申请还提供一种服务器，包括：

处理器；以及

存储器，用于存储所述处理器的计算机程序；

其中，所述处理器被配置为通过执行所述计算机程序来实现第一方面中任意一种所述的数据共享方法。

第六方面，本申请还提供一种服务器，包括：

处理器；以及

存储器，用于存储所述处理器的计算机程序；

其中，所述处理器被配置为通过执行所述计算机程序来实现第二方面中任意一种所述的数据共享方法。

第七方面，本申请还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现第一方面中任意一种所述的数据共享方法。

第八方面，本申请还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现第二方面中任意一种所述的数据共享方法。

本申请实施例提供的数据共享方法、服务器及介质，通过公用存储转发服接收数据查询请求，再根据数据查询请求中的查询条件从存储有全服数据的全服数据库中获取对应的查询数据，然后再利用数据查询请求中服务器标识信息将相应的查询数据反馈至对应的游戏服中，以使发起用户查询请求的用户设备可以接收到对应的查询数据反馈，从而实现全服的数据共享。

附图说明

图1为本申请根据一实施例提供的数据共享方法的应用场景图；

图2为图1所示应用场景的服务器架构图；

图3是本申请中第一实施例提供的数据共享方法的信令交互图；

图4是本申请中第二实施例提供的社交信息查看方式的信令交互图；

图5是本申请中第三实施例提供的社交信息发布方式的信令交互图；

图6是本申请中第四实施例提供的服务器的结构示意图；

图7是本申请中第五实施例提供的服务器的结构示意图；

图8是本申请中第六实施例提供的服务器的结构示意图；

图9是本申请中第七实施例提供的服务器的结构示意图；

图10是本申请中第八实施例提供的服务器的结构示意图；

图11是本申请中第九实施例提供的服务器的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

BigWorld为MMORPG开发商提供成熟的中间件平台，由于其安全性以及稳定性等优势，其速度成为了行业标杆，这一中间件平台正迅速成为行业标准。目前市面上有多款MMORPG使用BigWorld引擎，玩家可以扮演成一个虚拟角色并在虚拟世界中活动，这类游戏具有一个持续运行的虚拟世界，即使玩家离开游戏，这个虚拟世界仍在网络游戏运营商提供的服务器里继续存在并随着时间的发展会产出各种策划设定的物品和怪物，所以这类游戏会对消息处理的速度和响应速度有着极高的要求。

在现有的各种游戏中，普遍存在着大量不同的服务器，不同游戏开多个服务器的原因不同。但是，对于MMORPG游戏而言，主要是出于对性能的考虑，运营以及其他方面的要求都是次要的。

当一名玩家做出了操作之后，在他附近的玩家都应该被广播看到，当同一个服务器玩家过多时，会对服务器负载产生巨大的压力，因此需要开放多个服务器来分散过多数量的玩家，所以存在不同的服务器对于MMORPG游戏而言是必要的。

但在游戏中人们的社交需求又不仅局限于同一服务器，对于这类游戏而言，玩家可以在游戏中认识很多朋友，更加希望将游戏中的一些激烈的打斗场景或是自己取得的成就分享给更多的人，可以分享给不同服务器的玩家，这会给予玩家更高的成就感；同样广交朋友或扩大公会势力等情况，也希望发出给其余服务器的玩家看一看信息，因此实现全服社交网络对于玩家而言可以有更好的游戏体验，可以让更多志同道合的朋友一起在游戏里开心的游戏。

由于MMORPG游戏的硬性战斗需求，因此不同服务器的玩家数据存放在不同的位置。基于这样的现有情况，本申请提供一种数据共享方法，用于实现基于BigWorld引擎在多服务器架构的游戏内下实现全服社交数据共享的目的。

图1为本申请根据一实施例提供的数据共享方法的应用场景图，图2为图1所示应用场景的服务器架构图。如图1-图2所示，本实施例提供的数据共享方法应用于全服数据共享系统。其中，全服数据共享系统，包括：多台用户设备100、多个普通游戏服务器200、从多个普通游戏服200中确定出的特定游戏服201、公用存储转发服300、以及预设公用存储转发服300进行数据交互的预设非关系型数据库400和预设缓存数据库500。

其中，预设非关系型数据库400可以为Mongos数据库。通过选择非关系型数据库(Not Only SQL，简称NoSQL)作为主存储，优势在于支持海量数据的自动分片，例如，包括分片A401、分片B402尤以及分片C403，尤其适合社交系统数据的存储。此外，Mongos数据库自带的分片和复制集，这里是数据库的部署，配置分片支持海量数据的存储，配置复制集支持主要数据节点查询(primary查询)和次要数据节点查询(secondary查询)。

各个玩家通过用户设备100与对应的普通游戏服务器200进行数据交互。并且，普通游戏服务器200可以使用的BigWorld服务器组，由多个第一进程(base进程)和第二进程(cell进程)组成的多进程服务框架，其中base进程用于维持玩家连接。此处，值得理解的，可以在每个base进程上建立与公共存储转发服300的连接，在需要读取数据时，从多个已经建立好连接的base进程中随机一个进行查询，主要用来社交系统的查询功能。

对于特定游戏服201，同样可以采用BigWorld的服务器组，该服务器组可以会缓存玩家的写操作，然后再定时将玩家缓存数据中操作过的数据写入预设非关系型数据库400，从而避免玩家频繁更新数据给预设非关系型数据库400所带来的压力。可选的，特定游戏服201可以是从多个普通游戏服务器200中根据预设选取规则所选取的其中一个服务器，从而可以理解为普通游戏服务器200包括特定游戏服201。

对于公用存储转发服300，可以使用例如go语言进行开发，其中，go语言的高并发和易维护性比较适合作为公用存储转发服务的开发语言。另外，还可以支持protobuf序列化，使得网络流量得到较好的压缩。并且，公用存储转发服300还可以同时支持Mongos数据库和Redis缓存数据库的功能，从而为高并发查询提供缓存支持。

此外，对于预设缓存数据库(例如：Redis缓存数据库)，则可以对于允许查询缓存的相关数据进行存储，例如一些并不需要进行长期保存的数据。通过添加Redis缓存数据库，可以减轻Mongos数据库查询的压力。值得说明的，一般缓存是一个比较短的时间(例如：几秒时间)，主要是用于解决高并发查询时所带来的压力，而像社交信息(例如：朋友圈，微博等)的更新是可以接受缓存带来的几秒延时。

图3是本申请中第一实施例提供的数据共享方法的信令交互图。如图3所示，本实施例提供的数据共享方法，包括：

S101、发送用户查询请求。

当用户(例如：游戏玩家)需要查看相关数据，例如，需要对游戏中的社交数据(例如：个性签名、当前头像以及人气值等)进行查看时，可以在用户设备(例如：个人计算机、智能手机以及平板电脑等)上发起查询请求。在用户设备上发起用户查询请求之后，将查询请求发送至普通游戏服务器，而普通游戏服务器200可以使用BigWorld服务器组。

S102、发送数据查询请求。

在普通游戏服接收用户查询请求，普通游戏服务器向公用存储转发服发送数据查询请求，其中，数据查询请求包括查询条件以及服务器标识信息。值得说明的，查询条件可以为单独一个条件的形式，也可以为多个条件的形式，在本实施例中不作具体限定。

此外，本步骤中的服务器标识信息用于表征各个普通游戏服的身份信息。其中，在将普通游戏服接入公用存储转发服时，会向公用存储转发服发起注册请求，而注册请求包括需要建立连接的服务器所对应的服务器标识信息，以使得在公用存储转发服中注册服务器标识信息。

在一种可能的实现中，可以是基于protobuf的Service和Channel概念，在公用存储转发服中实现一套通用的rpc框架，从而在此rpc框架上提供了RegServer，UnregServer，GetService接口，当普通游戏服务器启动会把自己的服务器名通过rpc协议注册到公用存储转发服，然后通过serverMap维护，以便后续的消息转发特定游戏服操作。

而对于公用存储转发服，由于它是除以无业务状态的，一旦服务出现故障，则只需重启即可恢复服务，其中，普通游戏服务器在发现与公用存储转发服断开连接会请求进行重新连接。

S103、根据查询条件获取查询数据。

在公用存储转发服获取到数据查询请求之后，公用存储转发服会根据其中的查询条件从全服数据库中获取对应的查询数据。值得说明的，全服数据库用于存储全服数据，其中，全服数据包括多个服务器上传的用户数据。

S104、发送查询数据。

在全服数据库中根据查询条件获取查询数据之后，将查询数据先发送至公用存储转发服中。

值得理解的，公用存储转发服主要功能是转发消息和数据库存储，它提供了数据库存储的远程过程调用(Remote Procedure Call，简称RPC)接口。具体的，可以包括插入、查询、更新、删除、创建索引、获得数量、聚合查询以及查询缓存。从而作为对mongo和redis操作的一个封装并提供相应的服务接口，以满足社交系统的增删改查需求。

S105、发送查询数据。

在公用存储转发服获取到查询数据之后，可以根据服务器标识信息将查询数据发送至对应的普通游戏服中。

在一种可能的实现中，由于需要支持跨服聊天的消息实时性，公用存储转发服与各种游戏服需要建立可靠长连接。又由于游戏服组的多进程框架，这里基于游戏服的服务器标识信息，例如服务器的名字，公用存储转发服则维护了游戏服连接与服务器名字的关联。考虑到公用存储转发服的高并发和可维护性，可以选择go语言实现，并且，同时支持mysql和mongodb数据库。

此外，由于公用存储转发服提供实时转发消息和数据库功能，考虑到用户转发消息的数据量大，在转发服务中对查询做缓存cache，另外对于消息序列化的高效要求，可以选用高效的数据编码压缩方式protobuf实现。游戏服内，作为公用存储转发服的客户端，在建立长连接时注册本服务器名字，保证本组服务器在公用存储转发服上的唯一性。而为了分摊请求压力，可选的，组内多进程中可以根据权重算法选出其中一个进程进行hub服务的数据库操作请求。

S106、发送查询数据。

并且，在普通游戏服接收到查询数据之后，可以进一步将查询数据发送至发起查询请求的用户设备中，以向用户(例如：游戏玩家)进行相应数据的反馈。

在本实施例中，通过公用存储转发服接收数据查询请求，再根据数据查询请求中的查询条件从存储有全服数据的全服数据库中获取对应的查询数据，然后再利用数据查询请求中服务器标识信息将相应的查询数据反馈至对应的游戏服中，以使发起用户查询请求的用户设备可以接收到对应的查询数据反馈，从而实现全服的数据共享。

图4是本申请中第二实施例提供的社交信息查看方式的信令交互图。如图4所示，本实施例提供的数据共享方法中的社交信息查看方式包括：

S201、发送查看社交消息请求。

在玩家设备中可以发起查看社交消息请求，例如，查看玩家的空间动态。在游戏玩家通过玩家设备空间动态之后，玩家设备就会将查看社交消息请求发送至对应的普通游戏服中。

S202、发送数据查询请求。

在普通游戏服接收查看社交消息请求之后，普通游戏服务器向公用存储转发服发送数据查询请求，其中，数据查询请求包括查询条件以及服务器标识信息。值得说明的，查询条件可以为单独一个条件的形式，也可以为多个条件的形式，在本实施例中不作具体限定。

此外，本步骤中的服务器标识信息用于表征各个普通游戏服的身份信息。其中，在将普通游戏服接入公用存储转发服时，会向公用存储转发服发起注册请求，而注册请求包括需要建立连接的服务器所对应的服务器标识信息，以使得在公用存储转发服中注册服务器标识信息。

S203、发送数据查询请求。

S204、根据查询条件获取查询数据。

公用存储转发服在接收到数据查询请求之后，可以先通过在预设缓存数据库中查询是否具备符合查询条件的查询数据。

S205、发送查询数据。

若在预设缓存数据库中查询能够获取到具备符合查询条件的查询数据，则通过缓存将查询数据反馈至公用存储转发服。从而通过支持缓存查询，以满足高并发的访问查询。

S206、发送数据查询请求。

此外，公用存储转发服还可以在接收到数据查询请求之后，通过在预设非关系型数据库中查询是否具备符合查询条件的查询数据。

S207、发送查询数据。

若在预设非关系型数据库中查询能够获取到具备符合查询条件的查询数据，则通过缓存将查询数据反馈至公用存储转发服。

S208、发送查询数据。

公用存储转发服无论是接收到从预设非关系型数据库还是预设缓存数据库中所获取到的查询数据，在公用存储转发服获取到查询数据之后，可以根据服务器标识信息将查询数据发送至对应的普通游戏服中。

S209、发送查询数据。

并且，在普通游戏服接收到查询数据之后，可以进一步将查询数据发送至发起查询请求的用户设备中，以向游戏玩家反馈相应的社交消息。

可选的，在上述的预设非关系型数据库(例如：Mongos数据库)中所存储的社交数据可以通过空间动态表、个人数据表以及时间线表进行维护。

其中，对于空间动态表，维护的是全服所有玩家的空间动态，也就是每发出一条动态这个表会新增一条记录；对于个人数据表，则维护的是玩家的个人空间数据，可以是一个玩家对应一条记录；而对于时间线表，则可以是维护的是全服所有玩家的空间动态时间线，玩家每发出一个动态，就会往发出者的所有朋友的时间线上写入一条记录，也就是进行了一个写扩散。所以这个表的数量是庞大的，需要利用mongo的海量存储特性。由于时间线表只记录了动态的ID，因此，当查询时间线时需要结合空间动态表做Mongos数据库的联表聚合查询。可见，通过支持联表的聚合查询，可以满足社交功能的复杂性。

图5是本申请中第三实施例提供的社交信息发布方式的信令交互图。如图5所示，本实施例提供的数据共享方法中的社交信息发布方式，包括：

S301、发布社交消息请求。

而当游戏玩家需要进行社交消息发布时，则可以通过玩家设备发起发布社交消息请求，例如，玩家发布新的空间动态。在游戏玩家通过玩家设备空间动态之后，玩家设备就会将发布社交消息请求发送至对应的普通游戏服中。

S302、发送发布社交消息请求。

在普通游戏服接收发布社交消息请求之后，普通游戏服务器向特定游戏服发送发布社交消息请求。

可选的，可以根据预设选取规则确定多个普通游戏服务器中的其中一个服务器作为特定服务器，即特定游戏服，其中，特定服务器可以用于接收多个普通游戏服务器中的其他普通游戏服务器发送的用户数据，并根据预设发送规则发送用户数据。例如：选取多个服务器中空闲内存最大的服务器作为特定服务器，或者，选取多个服务器中用户数量最少的服务器作为特定服务器。

而在另一种可能的实现中，还可以是选取普通游戏服务器中的其中一个固定的服务器作为特定服务器，都可以通过使用BigWorld服务器组进行实现。

S303、缓存用户数据。

S304、按照预设周期对用户数据进行发送。

在特定游戏服接收到用户数据之后，特定游戏服先对用户数据进行缓存，然后按照预设周期将用户数据发送至公用存储转发服中。而对于公用存储转发服，则根据预设周期对所述用户数据进行接收。

可选的，接收预设规则包括：接收特定服务器发送的用户数据，特定服务器为多个服务器中的其中一个服务器，特定服务器用于接收多个服务器中的其他服务器发送的用户数据。

S305、上传用户数据。

其中，公用存储转发服根据预设接收规则接收用户数据，并将用户数据上传至全服数据库。

对于写操作，指定特定服务器进行玩家数据的写操作，目的是在特定服务器内先做一次缓存，大大增加数据库对玩家频繁更新数据的容忍性。再定时将游戏内改动的数据通过公用储存服写回全服数据库。而对于玩家来说这是透明的，从而进一步增强了玩家的游戏体验。

此外，对于读操作，任意一组普通游戏服均可以进行玩家数据的读操作，直接请求公用储存服来拉数据库或缓存数据，由于大部分社交业务对数据更新的短时间延时是可以接受的，这里使用缓存可以提高请求并发量，减少数据库压力。而对于需要实时更新的业务，还是可以通过特定游戏服来拉取实时数据。

S306、存储用户数据。

在公用存储转发服上传用户数据之后，全服数据库对用户数据进行存储。值得说明的，由于各个普通游戏服以及特定游戏服均可以将用户数据上传至全服数据库中进行存储，因此，可以通过该全服数据库实现全服数据的共享。例如：满足了不同游戏服务器玩家之间的聊天、朋友圈、微博等社交需求，而玩家对此是透明的。同时，也可以让游戏设计者更好地掌握玩法节奏，基于这种通用的社交功能，设计更多的社交玩法，从而进一步提高玩家的游戏体验。

图6是本申请中第四实施例提供的服务器的结构示意图。如图6所示，本申请还提供一种服务器400，包括：

请求接收模块401，用于接收数据查询请求，所述数据查询请求包括查询条件以及服务器标识信息；

数据获取模块402，用于根据所述查询条件从全服数据库中获取查询数据，所述全服数据库用于存储全服数据，所述全服数据包括多个服务器上传的用户数据；

数据发送模块403，用于根据所述服务器标识信息发送所述查询数据。

在图6所示实施例的基础上，图7是本申请中第五实施例提供的服务器的结构示意图。如图7所示，本实施例提供的服务器400，还包括：

数据接收模块404，用于根据预设接收规则接收所述用户数据；

数据上传模块405，用于将所述用户数据上传至所述全服数据库。

在一种可能的设计中，所述数据接收模块404，具体用于：

根据预设周期对所述用户数据进行接收。

在一种可能的设计中，所述数据接收模块404，具体用于：

接收特定服务器发送的所述用户数据，所述特定服务器为所述多个服务器中的其中一个服务器，所述特定服务器用于接收所述多个服务器中的其他服务器发送的用户数据。

在一种可能的设计中，所述数据获取模块402，具体用于：

根据所述查询条件从预设非关系型数据库和/或预设缓存数据库中获取所述查询数据，所述全服数据库包括所述预设非关系型数据库以及所述预设缓存数据库。

在一种可能的设计中，所述请求接收模块401，还用于获取注册请求，所述注册请求包括需要建立连接的服务器所对应的服务器标识信息；

所述服务器400，还包括：

信息注册模块406，用于注册所述服务器标识信息。

值得说明的，图6-图7所示实施例提供的服务器，可用于执行上述任一方法实施例提供的数据共享方法中公用存储转发服侧的步骤，具体实现方式和技术效果类似，这里不再赘述。

图8是本申请中第六实施例提供的服务器的结构示意图。如图8所示，本实施例提供的服务器500，包括：

查询接收模块501，用于接收用户查询请求，所述用户查询请求包括查询条件；

请求发送模块502，用于发送数据查询请求，所述数据查询请求包括所述查询条件以及服务器标识信息；

数据接收模块503，用于接收查询数据，所述查询数据为根据所述查询条件从全服数据库中获取的数据，所述全服数据库用于存储全服数据，所述全服数据包括多个服务器上传的用户数据。

在图8所示实施例的基础上，图9是本申请中第七实施例提供的服务器的结构示意图。如图9所示，本实施例提供的服务器500，还包括：

服务器确定模块507，用于根据预设选取规则确定所述多个服务器中的其中一个服务器作为特定服务器，所述特定服务器用于接收所述多个服务器中的其他服务器发送的用户数据，并根据预设发送规则发送所述用户数据。

所述预设发送规则，包括：按照预设周期对所述用户数据进行发送。

在一种可能的设计中，所述服务器确定模块507，具体用于：

选取所述多个服务器中空闲内存最大的服务器作为所述特定服务器；或者，

选取所述多个服务器中用户数量最少的服务器作为所述特定服务器。

在一种可能的设计中，所述服务器500，还包括：

数量确定模块504，用于获取在预设时长内，接收到的所述用户查询请求的请求数量；

请求暂停模块505，用于当所述请求数量大于预设数量阈值时，暂停接收所述用户查询请求。

在一种可能的设计中，所述服务器，还包括：

指令发送模块506，用于发送暂停接收指令，所述暂停接收指令用于指示用户暂停输入所述用户查询请求。

值得说明的，图8-图9所示实施例提供的服务器，可用于执行上述任一方法实施例提供的数据共享方法中普通游戏服侧或者特定游戏服侧的步骤，具体实现方式和技术效果类似，这里不再赘述。

图10是本申请中第八实施例提供的服务器的结构示意图。如图10所示，本实施例提供的服务器600，包括：

处理器601；以及，

存储器602，用于存储所述处理器的可执行指令，该存储器还可以是flash(闪存)；

其中，所述处理器601配置为经由执行所述可执行指令来执行上述方法中公用存储转发服侧的各个步骤。具体可以参见前面方法实施例中的相关描述。

可选地，存储器602既可以是独立的，也可以跟处理器601集成在一起。

当所述存储器602是独立于处理器601之外的器件时，所述服务器600，还可以包括：

总线603，用于连接所述处理器601以及所述存储器602。

图11是本申请中第九实施例提供的服务器的结构示意图。如图11所示，本实施例提供的服务器700，包括：

处理器701；以及，

存储器702，用于存储所述处理器的可执行指令，该存储器还可以是flash(闪存)；

其中，所述处理器701配置为经由执行所述可执行指令来执行上述方法中普通游戏服侧或者特定游戏服侧的各个步骤。具体可以参见前面方法实施例中的相关描述。

可选地，存储器702既可以是独立的，也可以跟处理器701集成在一起。

当所述存储器702是独立于处理器701之外的器件时，所述服务器700，还可以包括：

总线703，用于连接所述处理器701以及所述存储器702。

本实施例还提供一种可读存储介质，可读存储介质中存储有计算机程序，当电子设备的至少一个处理器执行该计算机程序时，电子设备执行上述的各种实施方式提供的方法中公用存储转发服侧的步骤。

本实施例还提供一种程序产品，该程序产品包括计算机程序，该计算机程序存储在可读存储介质中。电子设备的至少一个处理器可以从可读存储介质读取该计算机程序，至少一个处理器执行该计算机程序使得电子设备实施上述的各种实施方式提供的方法中公用存储转发服侧的步骤。

本实施例还提供一种可读存储介质，可读存储介质中存储有计算机程序，当电子设备的至少一个处理器执行该计算机程序时，电子设备执行上述的各种实施方式提供的方法中普通游戏服侧或者特定游戏服侧的步骤。

本实施例还提供一种程序产品，该程序产品包括计算机程序，该计算机程序存储在可读存储介质中。电子设备的至少一个处理器可以从可读存储介质读取该计算机程序，至少一个处理器执行该计算机程序使得电子设备实施上述的各种实施方式提供的方法中普通游戏服侧或者特定游戏服侧的步骤。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或对其中部分或全部技术特征进行等同替换；而这些修改或替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (18)

1.一种数据共享方法，其特征在于，包括：

接收数据查询请求，所述数据查询请求包括查询条件以及服务器标识信息；

根据所述查询条件从全服数据库中获取查询数据，所述全服数据库用于存储全服数据，所述全服数据包括多个服务器上传的用户数据；

根据所述服务器标识信息发送所述查询数据。

2.根据权利要求1所述的数据共享方法，其特征在于，还包括：

根据预设接收规则接收所述用户数据；

将所述用户数据上传至所述全服数据库。

3.根据权利要求2所述的数据共享方法，其特征在于，所述根据预设接收规则接收所述用户数据，包括：

根据预设周期对所述用户数据进行接收。

4.根据权利要求2或3所述的数据共享方法，其特征在于，所述根据预设接收规则接收所述用户数据，包括：

接收特定服务器发送的所述用户数据，所述特定服务器为所述多个服务器中的其中一个服务器，所述特定服务器用于接收所述多个服务器中的其他服务器发送的用户数据。

5.根据权利要求1-3中任意一项所述的数据共享方法，其特征在于，所述根据所述查询条件从全服数据库中获取查询数据，包括：

根据所述查询条件从预设非关系型数据库和/或预设缓存数据库中获取所述查询数据，所述全服数据库包括所述预设非关系型数据库以及所述预设缓存数据库。

6.根据权利要求1-3中任意一项所述的数据共享方法，其特征在于，还包括：

获取注册请求，所述注册请求包括需要建立连接的服务器所对应的服务器标识信息；

注册所述服务器标识信息。

7.一种数据共享方法，其特征在于，包括：

接收用户查询请求，所述用户查询请求包括查询条件；

发送数据查询请求，所述数据查询请求包括所述查询条件以及服务器标识信息；

接收查询数据，所述查询数据为根据所述查询条件从全服数据库中获取的数据，所述全服数据库用于存储全服数据，所述全服数据包括多个服务器上传的用户数据。

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

根据预设选取规则确定所述多个服务器中的其中一个服务器作为特定服务器，所述特定服务器用于接收所述多个服务器中的其他服务器发送的用户数据，并根据预设发送规则发送所述用户数据。

9.根据权利要求8所述的数据共享方法，其特征在于，所述预设发送规则，包括：

按照预设周期对所述用户数据进行发送。

10.根据权利要求8或9所述的数据共享方法，其特征在于，所述预设选取规则，包括：

选取所述多个服务器中空闲内存最大的服务器作为所述特定服务器；或者，

选取所述多个服务器中用户数量最少的服务器作为所述特定服务器。

11.根据权利要求7-9中任意一项所述的数据共享方法，其特征在于，还包括：

获取在预设时长内，接收到的所述用户查询请求的请求数量；

若所述请求数量大于预设数量阈值，则暂停接收所述用户查询请求。

12.根据权利要求11所述的数据共享方法，其特征在于，在所述暂停接收所述用户查询请求之后，还包括：

发送暂停接收指令，所述暂停接收指令用于指示用户暂停输入所述用户查询请求。

13.一种服务器，其特征在于，包括：

请求接收模块，用于接收数据查询请求，所述数据查询请求包括查询条件以及服务器标识信息；

数据获取模块，用于根据所述查询条件从全服数据库中获取查询数据，所述全服数据库用于存储全服数据，所述全服数据包括多个服务器上传的用户数据；

数据发送模块，用于根据所述服务器标识信息发送所述查询数据。

14.一种服务器，其特征在于，包括：

查询接收模块，用于接收用户查询请求，所述用户查询请求包括查询条件；

请求发送模块，用于发送数据查询请求，所述数据查询请求包括所述查询条件以及服务器标识信息；

数据接收模块，用于接收查询数据，所述查询数据为根据所述查询条件从全服数据库中获取的数据，所述全服数据库用于存储全服数据，所述全服数据包括多个服务器上传的用户数据。

15.一种服务器，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的计算机程序；

其中，所述处理器被配置为通过执行所述计算机程序来实现权利要求1至6任一项所述的数据共享方法。

16.一种服务器，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的计算机程序；

其中，所述处理器被配置为通过执行所述计算机程序来实现权利要求7至12任一项所述的数据共享方法。

17.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6任一项所述的数据共享方法。

18.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求7至12任一项所述的数据共享方法。