百万级用户同时在线移动平台服务器架构的制作方法

百万级用户同时在线移动平台服务器架构的制作方法
【专利摘要】本发明提出一种百万级用户同时在线移动平台服务器架构，包括负载均衡服务器组，逻辑处理服务器组，高速数据缓存服务器组和数据库服务器；逻辑处理服务器组和高速数据缓存服务器组各自独立实现分布式结构，将数据存储功能和逻辑处理功能分离。本发明提出的平台服务器架构下的服务器运行时健壮度高，可伸缩性强，容错性好，是一种既可以承载大量在线玩家，同时又能够保持高稳定性和健壮性的网络游戏的服务器架构。可通过简单增加部署的机器数量的方式来使服务器承载人数达到百万级用户的程度。
【专利说明】百万级用户同时在线移动平台服务器架构
【技术领域】
[0001]本发明涉及短连接型网络游戏【技术领域】，特别涉及支持百万级用户同时在线的移动平台服务器架构。
【背景技术】
[0002]大型网络游戏服务器存在同时在线人数多，请求密度高，对响应速度要求高，对稳定性要求高等特点。现有服务器实现可分为长连接型和短连接型，长连接型可以方便做到诸如服务器主动通知等功能，但对网络稳定性要求更高，同时存在维护连接的成本，对于一些长时间不活跃的连接来说比较浪费资源，特别是对select和poll模型来说，本身就存在最大连接数限制，而且随着连接数上升，性能会线性下降。而短连接型则极大程度上解决此问题，因为每次连接只处理一个请求，所以每次连接保持的时间都非常短，对网络稳定性的要求极大降低了，同时单个玩家的连续操作相对于服务器处理能力来说是非密集的，不同玩家同时操作的概率很低，因此可以用相对少量的同时连接数来实现处理大量玩家的操作需求。当玩家进行一些不需要和服务器交互的操作的时候，玩家可以在网络不通畅的情况下继续玩而不会感知到这点。为了能快速响应请求以及利用多核服务器，目前主流的网游服务器一般采用多线程技术，但多线程服务器相对而言开发难度、代码复杂度和调试难度都更高，非常不利于开发周期短且需求变化大的项目。而单线程服务器则一般存在单服难以充分利用多核CPU机能的问题，以至于无法大量玩家在同一服务器上。因此，需要设计一种既可以承载大量在线玩家，同时又能够保持高稳定性和健壮性的网络游戏服务器架构。

【发明内容】

[0003]本发明针对现有技术存在的缺陷或不足，提出一种百万级用户同时在线的移动平台服务器架构，将数据存储和逻辑处理部分分离开来，数据存储部分封装一层分布式高速缓存以优化读取，而逻辑处理部分则采用分布式结构分布到多个不同进程上，同时采用负载均衡技术将处理请求分布到各个逻辑处理部分，以组成一个各部分都高度可伸缩性的服务器组来对外作为一个服务器进行服务。
[0004]本发明的技术方案:
[0005]百万级用户同时在线移动平台服务器架构，其特征在于，包括负载均衡服务器组，逻辑处理服务器组，高速数据缓存服务器组和数据库服务器；所述逻辑处理服务器组和所述高速数据缓存服务器组各自独立实现分布式结构，将包含数据缓存的数据存储功能和逻辑处理功能分离；
[0006]所述负载均衡服务器组连接所述逻辑处理服务器组，所述负载均衡服务器组用于接收发来的服务请求，所述逻辑处理服务器组利用所述负载均衡服务器组，采用分布式结构将所述服务请求按照指定策略分布到所述逻辑处理服务器组的多个不同进程上，并将处理请求分配到所述逻辑处理服务器组中的某一台逻辑服务器上；
[0007]所述逻辑处理服务器组还分别连接所述高速缓存服务器组和所述数据库服务器；所述逻辑处理服务器组中含有多个负责处理服务请求的逻辑服务器，构成分布式结构；被选中的某一台逻辑服务器通过某种分配算法找出对应的高速数据缓存服务器，尝试从高速数据缓存服务器组中获取所需数据；
[0008]所述高速缓存服务器组中含有多个负责处理服务请求的多台高速缓存服务器，多台所述高速缓存服务器构成分布式结构，可以在高速缓存服务器组运行时动态增删服务数量，对外表现为一个统一的数据缓存服务器组；
[0009]所述逻辑处理服务器组若从高速数据缓存服务器组中成功获取所需数据，则直接处理，处理后断开与客户端的连接；若获取所需数据失败则转向数据库服务器读取数据，所述逻辑处理服务器组得到所需数据之后会向高速数据缓存中再存储一遍该数据，以供下次读取；处理完毕后若被处理的数据有修改，则所述逻辑处理服务器组同时向所述数据库服务器和所述高速数据缓存服务器组存储修改后的数据。
[0010]所述某种分配算法是指依靠高速缓存的客户端的分配算法来决定的；可以是哈希算法或HASH算法或一致性HASH算法。
[0011]所述逻辑处理服务器组包含的每个逻辑服务器实现为单一线程的进程，部署在一台或多台所述逻辑服务器上，可以在所述逻辑服务运行时动态增删逻辑服务器数量，对外表现为一个统一的逻辑处理服务器组。
[0012]所述数据库服务器包含SQL服务器组和NDB数据节点服务器组。
[0013]所述SQL服务器组可以具有MySQL数据库。
[0014]客户端发来的服务请求以一个或多个请求包形式传输至所述逻辑处理服务器组，每个请求包皆包含包头部分和内容部分；所述包头部分是一个定长的数据结构，包含版本号、标记字段、包长和协议类型；所述内容部分紧接所述包头后面，用于记录请求包里真正附带的数据，以供所述逻辑处理服务器组使用。
[0015]所述逻辑处理服务器组能够根据实际需要传输的大小来决定是否需要对所述请求包进行压缩，若请求包大于预设值，可以采用LZO无损字典编码压缩算法；若请求包小于或等于预设值，则不对其进行压缩。
[0016]所述包头部分还包含用于标识是否已压缩的标记字段。
[0017]本发明的技术效果:
[0018]本发明提出的百万级用户同时在线移动平台服务器架构，其中逻辑处理服务器组和高速数据缓存服务器组各自独立实现分布式结构，将数据存储功能和逻辑处理功能分离，把所有游戏逻辑动态数据都存储在高速数据缓存和数据库中，每个逻辑服务器实现为一个单线程的进程，可以部署在同一台或多台机器上，互相之间互不依赖，可以在服务运行时对逻辑服务器的数量进行增减而不会对服务本身的正常运转造成影响。
[0019]本发明提出的平台服务器架构使用MySQL数据库，开发复杂度低，维护成本低。
[0020]本发明提出的平台服务器架构下的服务器运行时健壮度高，可伸缩性强，容错性好，是一种既可以承载大量在线玩家，同时又能够保持高稳定性和健壮性的网络游戏的服务器架构。可通过简单增加部署的机器数量的方式来使服务器承载人数达到百万级用户的程度。
【专利附图】

【附图说明】[0021]图1是本发明逻辑结构图。
[0022]图2是本发明逻辑服务器分布式结构示意图。
[0023]图3是本发明缓存服务器分布式结构示意图。
[0024]图4是本发明请求包结构示意图。
[0025]图5是本发明支持百万级用户同时在线移动平台服务器物理架构图。
【具体实施方式】
[0026]下面结合附图对本发明做进一步的说明。
[0027]图1是本发明逻辑结构图。如图1所示，本发明逻辑结构主要包含负载均衡服务模块、逻辑处理模块、高速数据缓存模块以及数据库模块四个部分，客户端(即用户)连接负载均衡服务模块，负载均衡服务模块连接逻辑处理模块，逻辑处理模块还分别连接高速缓存模块和数据库模块。图1中空心框标示的逻辑处理模块和高速数据缓存模块皆为分布式结构。客户请求先经过负载均衡服务分发给逻辑处理部分里的某一台逻辑服务器上，然后逻辑服务器尝试从高速数据缓存中获取所需数据，成功则直接处理，如果获取所需数据失败则转而向数据库里读取数据，得到所需数据之后会向高速数据缓存中再存储一遍该数据，以供下次读取。处理完毕后如果数据有修改，则同时向数据库和高速数据缓存存储修改后的数据。
[0028]图2是本发明逻辑服务器分布式结构示意图，是本发明逻辑处理部分。如图2所示，逻辑处理部分由多个负责处理请求的逻辑服务器构成分布式结构，每个逻辑服务器实现为一个单线程的进程，可以部署在同一台或多台机器上，互相之间互不依赖，可以在服务运行时对逻辑服务器的数量进行增减而不会对服务本身的正常运转造成影响。即使某一逻辑服务器出现严重问题造成崩溃，所造成的影响也仅限于该逻辑服务器正在处理的那一个请求出错，错误不会扩散到整个服务器组，实现高度的稳定性和可热拔插特性。实现此部分的分布式的一个重要组件就是负载均衡服务，用于实时监控各逻辑服务器状态并按照指定策略(此处指的是负载均衡的分派策略，比如:轮询，权重轮询，随机，权重随机，响应速度，最少连接，处理能力，DNS响应)将大量请求分发给不同的逻辑服务器。每个逻辑服务器都具有处理请求的能力，一个连接的生存期内只处理一条请求，处理完后就需要客户端主动断开连接，而逻辑服务器这边也定时清理过期未断开的连接。处理请求期间会向高速数据缓存部分请求所需数据，未能取到则再向数据库请求，同时将数据存到高速数据缓存部分，处理完毕后会将需要保存的数据存往高速数据缓存和数据库。负载均衡的主要应用就是利用多台服务器提供单一服务，负载均衡负责监听一个外部端口，大型网络游戏的玩家可以通过这个端口来访问服务，而负载均衡服务器则会将网络玩家的请求转发给后台的内网服务器，内网服务器再将请求的响应返回给负载均衡器，再由负载均衡服务器将响应发回给网游玩家，以此完成一次请求处理响应的流程。不但可以将大量请求分散给不同的服务器，同时向网络玩家隐藏了内网结构，阻止了用户直接访问内网服务器，使得服务器更加安全，同时在一部分内网服务器出现问题的情况可以继续提供服务，提高了容错能力。对于大型网络游戏服务器来说，复杂情况出现的可能比较多，我们就需要负载均衡服务器具有以下特征:1.不对称负载调节，可以对内网服务器设置权重因子，权重因子用于控制服务器的请求处理比重，进而控制服务器的负载。当后台服务器的处理能力不是等同的时候，这是一种控制服务器负载的简单办法。2.优先激活，当出现故障的服务器达到某个阈值，或者服务器负载过高时，备用服务器必须可以及时上线提供服务。3.服务器健康检查，负载均衡服务器可以检查后台服务器的健康状况并从服务器池中移除那些出现故障的服务器。
[0029]本发明负载均衡服务器用于实时监控各逻辑服务器状态并按照指定策略将大量请求分发给不同的逻辑服务器。每个逻辑服务器都具有处理请求的能力，一个连接的生存期内只处理一条请求，处理完后就需要客户端主动断开连接，而逻辑服务器这边也定时清理过期未断开的连接。处理请求期间会向高速数据缓存部分请求所需数据，未能取到则再向数据库请求，同时将数据存到高速数据缓存部分，处理完毕后会将需要保存的数据存往高速数据缓存和数据库。
[0030]图3是本发明缓存服务器分布式结构示意图，是本发明高速数据缓存部分。缓存处理部分由多个负责处理请求的高速缓存服务器构成分布式结构，可以在逻辑服务运行时动态增删服务器数量，对外表现为一个统一的数据缓存服务器组，提供服务。此处实现的分布式的方式可以采用哈希分配，将数据的键值经过哈希算法得到的结果再通过一个分配算法(例如下文中方法一或方法二)指定到一个特定缓存服务器上，只要保证使用此服务的客户端的算法一致，同一个键就能保证一直映射到同一台缓存服务器，以此来实现缓存服务器的分布式能力。使用这种模式时动态增删缓存服务器的时候有时会直接导致一段时间内命中率下降，因为缓存服务器的数量发生了变化，当删除时需要把指向被删除缓存服务器的那些键值指向给其他缓存服务器，当新增时需要将部分原本指向其他缓存服务器的的键值指向到新增的服务器上，最后都会导致一个键值对应到的缓存服务器可能产生变化。本发明在这个环节考虑到选择适合的分配算法，因为分配算法的选择会直接影响到增删缓存服务器后对现有键值的分配造成的变化程度。方法一:直接将哈希出来的结果作为数值和总缓存服务器数进行求余，以该结果作为分配到的缓存服务器的索引，比较简单直观的算法是但很容易造成该分配映射的剧烈变化，对一段时间内的性能影响很大。方法二:相比而言一致性HASH算法能很大程度上缓解方法一存在的问题，基本思路是将一段很大范围的连续数首尾相连映射地到一个圆环上，再将节点通过哈希算法映射到这个数值范围内的一个数上，再将这个数映射到圆环上，其中每个节点都会映射到一个缓存服务器上，这是多对一的关系，允许多个节点映射到同一台缓存服务器上，而数据的键值也是通过哈希算法映射到圆环上，然后挑选最近的一个节点，最后通过该节点映射到对应的缓存服务器上完成整个过程。平均而言只会影响到整体的l/η的键值的映射，比较适合大规模的缓存服务器组。
[0031]图4是本发明请求包结构示意图。用户请求先经过负载均衡服务分发给逻辑处理部分里的某一台逻辑服务器上，然后逻辑服务器尝试从高速数据缓存中获取所需数据。如图4所示，每个请求包的结构分为包头部分和内容部分，其中包头部分是一个定长的数据结构，分别是版本号、标记字段、包长和协议类型。
[0032]版本号字段里记录的是发出这个包的服务器或者客户端的版本号，用于和另外一端进行版本号比对校验。
[0033]标记字段可以用于标记多种该数据包(即数据包)的属性类型，比如是否已压缩之类的，此处是作为旗标位形式来使用的。[0034]包长字段则是记录整个数据包的长度，包括包头和内容的总长，此处是网络层用来提取完整的数据包的关键部分，只有事先知道数据包的长度才能从一个无边界的连续数据流中得知哪些数据属于该数据包。
[0035]协议类型则是用来标识该包代表的是何种处理请求，此处是逻辑层进行请求包的逻辑处理的关键判断部分。
[0036]在包头后紧接的就是包的数据内容，此处记录的是该包里真正附带的数据，以供逻辑层使用。
[0037]数据包的大小也是本发明考虑的方面，过大的数据包会消耗更多的流量和传送时间，处理不好同样会造成最大承载人数的下降。首先要避免让逻辑服务器给客户端传送非此次逻辑相关的动态数据，对于游戏中大量存在的常量数据可以在客户端中自带一份跟随客户端版本一起发布，而对于一些变化频率小于版本更新频率的少量数据再采用从webserver或ftp在线获取的方式。对于一些不得不用的比较大(大于预设值)的数据包的情况下，本发明设计为将该数据包进行压缩以达到缩小数据包体积的目的。压缩其实本身是按照一种特定算法将原来的数据变换成另外一种具有同样信息量的数据，这属于无损压缩，而有损压缩则会损失掉一部分信息量来保证压缩效果，本发明所涉及的实际应用场合采用无损压缩算法。信息冗余是指传输消息所用的数据位的数目与消息中所包含的实际信息的数据位的数目的差值。一般数据的信息冗余量都比较大，通过压缩来减少那部分冗余数据所占据的空间，但相对而言，压缩效果越好的算法一般都更耗费CPU。本发明采用LZO (Lempel Ziv Oberhumer)算法,它是一种无损的字典编码压缩算法,而且具有非常高的解压速度并且不需要额外内存，压缩的时候需要64k的内存而且速度同样非常快，可以选择以损失压缩速度为代价提高压缩率同时还不会降低解压速度。可以随意调节压缩级别来适应各种需求，还存在一个只需要8k内存即可进行压缩的压缩级别，以适应极端情况。LZO (Lempel Ziv Oberhumer)算法是一种块压缩算法,也就是说它是以块为单位进行压缩解压，所以压缩解压说用到的块必须一样大小。它将数据块压缩成匹配数据与非匹配数据的序列，它对于较长的匹配数据以及较长的非匹配数据序列有专门的处理，这样对于高度冗余的数据能够取得较好的效果，并且对于不可压缩数据也可得到预期效果。当处理不可压缩数据时，Lzo将每个1024字节的输入数据块扩展16字节。并不是所有的数据包都需要压缩，对于比较小或过小(小于或等于预设值)的数据包进行压缩未免有点得不偿失，即使是同一种协议包，也有大小不一致的可能，本发明根据实际需要传输的大小来决定是否需要对数据包进行压缩，并在包头的标记字段里来标识是否已压缩，另一端也仅根据这个标记来判断是否需要解压缩。
[0038]图5是本发明支持百万级用户同时在线移动平台服务器物理架构图。如图5所示，本发明的支持百万级用户同时在线移动平台服务器架构和其他传统服务器架构的主要区别就是逻辑处理部分和高速缓存部分都是分布式结构以及依靠负载均衡服务来分散用户请求，同时也是核心扩展能力。设计再好的服务器程序，其单个承载能力都是有限的，面对一个庞大且日益增长的网络用户群，要让架构能适应海量的同时活跃用户，则必须依靠负载均衡将这些用户的请求分散到每个单独的服务器程序上去，真正处理这些请求的就是底层的每个逻辑服务器程序，然后大量的逻辑服务器能够组成一个对外统一的服务器，来达成提高服务器性能的效果。由于每个用户并不一直和同一台实际逻辑服务器保持连接，每个请求都有可能由不同的逻辑服务器来处理，因此短连接模式则是本发明选用的模式。具体地，本发明支持百万级用户同时在线移动平台服务器物理架构包含负载均衡服务器组、逻辑处理服务器组(也称逻辑服务器组)、高速数据缓存服务器组(也称高速缓服务器组)和数据库服务器；数据库服务器包含SQL服务器组(例如MySQL数据库)和NDB数据节点服务器组。但并非必须MySql数据库，只要是能提供所需功能的数据库皆可，客户端(即用户)连接负载均衡服务器组，负载均衡服务器组连接逻辑处理服务器组，逻辑处理服务器组还分别连接高速缓存服务器组和数据库服务器，即连接SQL服务器组和NDB数据节点服务器组。用户向负载均衡服务器组发出服务请求，客户成功发出的请求先经过负载均衡服务器组中的vrrp主控路由和负载均衡服务器分发给逻辑处理服务器组里的某一台逻辑服务器上(例如图5中所示的逻辑服务器I或逻辑服务器2或…逻辑服务器5)，然后被选中的某一台逻辑服务器尝试从高速数据缓存服务器组中获取所需数据(通过分配算法来找出对应的高速缓存服务器)，高速缓存服务器组中含有多台高速缓存服务器，成功获取所需数据则直接处理，如果获取所需数据失败则转而向数据库里读取数据，得到所需数据之后会向高速数据缓存中再存储一遍该数据，以供下次读取。处理完毕后如果数据有修改，则同时向数据库和高速数据缓存存储修改后的数据。mySQL自4.1.x版本开始推出mySQLcluster功能。cluster简单地说,就是一组“节点”的组合。这里的节点是一个逻辑概念，一台计算机上可以存放一个节点，也可以存放多个节点。这些节点的功能各不相同，有的用来存储数据(数据结点)，有的用来存放表结构(SQL结点)，有的用来对其他节点进行管理(管理节点)。这些节点组合在一起，可以为应用提供具有高可用性，高性能和可缩放性的cluster数据管理。mySQL使用ndb存储引擎来对数据节点的数据进行存储，“NDB”是一种“内存中”的存储引擎，它具有可用性高和数据一致性好的特点。本发明图5中的数据节点服务器组包含数据节点服务器，用来存放Cluster里面的数据，可以有多个数据节点。每个数据结点可以有多个镜 像节点。任何一个数据节点发生故障，只要它的镜像节点正常，Cluster就可以正常运行。这种逻辑上不同节点物理上可以存放在不同的服务器上，也可以存放在相同的服务器上。
[0039]由于每个网络游戏玩家的请求都有可能由不同的逻辑服务器来处理，这就要求保证无论在哪台服务器上，玩家的数据必须保持同步，这就引出了数据存储部分的逻辑。此时本发明设计成直接将数据层直接独立出来，剥夺逻辑服务器自身存储游戏逻辑动态数据的责任。把所有游戏逻辑动态数据都存储在高速数据缓存和数据库中，当逻辑服务器需要时直接读取，处理完则直接释放，下次需要时继续从里面取。
[0040]本发明使用MySQL数据库的原因在于MySQL是开源软件，因此可以大大降低成本。MySQL还有如下特性:使用C和C++编写，并使用了多种编译器进行测试，保证源码的可移植性；支持多种主流操作系统；支持多种编程语言；支持多线程，充分利用CPU资源，支持多用户；既能作为一个单独的应用程序使用，也能作为一个库嵌入到其他软件中；提供多编码支持；提供TCP/IP、0DBC和JDBC等多种数据库连接途径；提供用于管理、检查、优化数据库操作的管理工具；可以处理拥有上千万条记录的大型数据库。
[0041]以上所述的本发明【具体实施方式】，并不构成对本发明保护范围的限定。任何在本发明的精神和原则之内所做的修改、等同替换和改进等，均应包含在本发明的权利要求保护范围之内。
【权利要求】
1.百万级用户同时在线移动平台服务器架构，其特征在于，包括负载均衡服务器组，逻辑处理服务器组，高速数据缓存服务器组和数据库服务器；所述逻辑处理服务器组和所述高速数据缓存服务器组各自独立实现分布式结构，将包含数据缓存的数据存储功能和逻辑处理功能分离； 所述负载均衡服务器组连接所述逻辑处理服务器组，所述负载均衡服务器组用于接收客户端发来的 服务请求，所述逻辑处理服务器组利用所述负载均衡服务器组，采用分布式结构将所述服务请求按照指定策略分布到所述逻辑处理服务器组的多个不同进程上，并将处理请求分配到所述逻辑处理服务器组中的某一台逻辑服务器上； 所述逻辑处理服务器组还分别连接所述高速缓存服务器组和所述数据库服务器；所述逻辑处理服务器组中含有多个负责处理服务请求的逻辑服务器，构成分布式结构；被选中的某一台逻辑服务器通过某种分配算法找出对应的高速数据缓存服务器，尝试从高速数据缓存服务器组中获取所需数据； 所述高速缓存服务器组中含有多个负责处理服务请求的多台高速缓存服务器，多台所述高速缓存服务器构成分布式结构，可以在所述高速缓存服务器组运行时动态增删服务数量，对外表现为一个统一的数据缓存服务器组； 所述逻辑处理服务器组若从高速数据缓存服务器组中成功获取所需数据，则直接处理，处理后断开与客户端的连接；若获取所需数据失败则转向数据库服务器读取数据，所述逻辑处理服务器组得到所需数据之后会向高速数据缓存中再存储一遍该数据，以供下次读取；处理完毕后若被处理的数据有修改，则所述逻辑处理服务器组同时向所述数据库服务器和所述高速数据缓存服务器组存储修改后的数据。
2.根据权利要求1所述的百万级用户同时在线移动平台服务器架构，其特征在于，所述某种分配算法是指依靠高速缓存的客户端的分配算法来决定的，可以是哈希算法或HASH算法或一致性HASH算法。
3.根据权利要求1所述的百万级用户同时在线移动平台服务器架构，其特征在于，所述逻辑处理服务器组包含的每个逻辑服务器实现为单一线程的进程，部署在一台或多台所述逻辑服务器上，可以在所述逻辑服务运行时动态增删逻辑服务器数量，对外表现为一个统一的逻辑处理服务器组。
4.根据权利要求1所述的百万级用户同时在线移动平台服务器架构，其特征在于，所述数据库服务器包含SQL服务器组和NDB数据节点服务器组。
5.根据权利要求1所述的百万级用户同时在线移动平台服务器架构，其特征在于，所述SQL服务器组可以是MySQL数据库。
6.根据权利要求1所述的百万级用户同时在线移动平台服务器架构，其特征在于，客户端发来的服务请求以一个或多个请求包形式传输至所述逻辑处理服务器组，每个请求包皆包含包头部分和内容部分；所述包头部分是一个定长的数据结构，包含版本号、标记字段、包长和协议类型；所述内容部分紧接所述包头后面，用于记录请求包里真正附带的数据，以供所述逻辑处理服务器组使用。
7.根据权利要求1所述的百万级用户同时在线移动平台服务器架构，其特征在于，所述逻辑处理服务器组能够根据实际需要传输的大小来决定是否需要对所述请求包进行压缩，若请求包大于预设值，可以采用LZO无损字典编码压缩算法；若请求包小于或等于预设值，则不对其进行压缩。
8.根据权利要求1所述的百万级用户同时在线移动平台服务器架构，其特征在于，所述包头部分还包含用于标识是否已压缩的标记字段。
【文档编号】H04L29/08GK103944993SQ201410171426
【公开日】2014年7月23日 申请日期:2014年4月25日 优先权日:2014年4月25日
【发明者】向兆松 申请人:北京乐动卓越信息技术有限公司