CN110898434B - 处理数据的方法、服务器、系统和计算机可读程序介质 - Google Patents

处理数据的方法、服务器、系统和计算机可读程序介质 Download PDF

Info

Publication number
CN110898434B
CN110898434B CN201911073558.1A CN201911073558A CN110898434B CN 110898434 B CN110898434 B CN 110898434B CN 201911073558 A CN201911073558 A CN 201911073558A CN 110898434 B CN110898434 B CN 110898434B
Authority
CN
China
Prior art keywords
data
player
server
redis
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201911073558.1A
Other languages
English (en)
Other versions
CN110898434A (zh
Inventor
程道雷
洪学海
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institute Of Big Data Cloud Computing Center Of Chinese Academy Shangrao
Original Assignee
Institute Of Big Data Cloud Computing Center Of Chinese Academy Shangrao
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Institute Of Big Data Cloud Computing Center Of Chinese Academy Shangrao filed Critical Institute Of Big Data Cloud Computing Center Of Chinese Academy Shangrao
Priority to CN201911073558.1A priority Critical patent/CN110898434B/zh
Publication of CN110898434A publication Critical patent/CN110898434A/zh
Application granted granted Critical
Publication of CN110898434B publication Critical patent/CN110898434B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/77—Game security or game management aspects involving data related to game devices or game servers, e.g. configuration data, software version or amount of memory
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70—Game security or game management aspects
    • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/5526—Game data structure
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55—Details of game data or player data management
    • A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例公开了一种处理数据的方法和服务器，其中方法包括：初始化服务器时，将玩家游戏数据储存在第一数据库中，服务器启动后，将玩家游戏数据载入到内存中的不同数据结构中；玩家发送玩家游戏数据到服务器后，服务器对玩家游戏数据进行分类，将分类后的数据发送到预先配置的分管各类玩家游戏数据的消息队列中；读取服务器的数据时，优先从内存的不同数据结构中读取，若读取失败，则从第二数据库中读取数据，若读取失败，则从第一数据库中读取；存储数据时，优先更新内存中数据，再更新第一数据库中的数据，最后更新第二数据库中的数据。本申请实施例对不同类数据使用不同的存储和读取策略，降低了获取数据的复杂度，提高了游戏体验。

Description

处理数据的方法、服务器、系统和计算机可读程序介质
技术领域
本申请涉及互联网技术领域，尤其是涉及一种处理数据的方法、服务器、系统和计算机可读程序介质。
背景技术
随着数字经济产业的发展，中国游戏市场规模近年来保持高速增长，行业销售规模迎来重大突破，随之而来的高并发、数据共享、数据安全问题成了特别需要关注的问题，许多公司因此遭受了巨大损失。为了实现高并发时，不同地域位置的游戏服务器共用一个数据库的情况下，玩家能够无障碍、安全地切换服务器登录，就需要实现不同服务器间的数据同步与共享。在生产环境中，假设A、B为游戏服务器、C为客户端、D为数据库服务器，要保证玩家通过C用同一个账号可以切换登录A、B服务器，并且数据保持一致性以及良好的用户体验。
对于网站平台，由于不同用户的数据相对独立，用户响应时间不是游戏中那么敏感，采用的手段是每次更新数据，都对数据库直接操作，每次提取数据也直接从数据库中提取，从而数据始终是一致的。在游戏系统中，玩家之间通过关注或者添加好友等方式相互关联，如果每次读取数据都从数据库中读取，势必导致嵌套查表，造成（N为玩家个数）的数据复杂度，导致游戏体验不佳。
发明内容
本申请实施例的主要目的在于提供一种处理数据的方法和服务器，对不同类玩家游戏数据使用不同的存储和读取策略，降低了获取玩家游戏数据的复杂度，提高了游戏体验。
第一方面，提供了一种处理数据的方法，包括：初始化服务器时，将玩家游戏数据储存在第一数据库中，服务器启动后，将所述玩家游戏数据载入到内存中的不同数据结构中；
玩家发送玩家游戏数据到服务器后，服务器对所述玩家游戏数据进行分类，将分类后的玩家游戏数据发送到预先配置的分管各类玩家游戏数据的消息队列中；
读取服务器的玩家游戏数据时，优先从所述内存的不同数据结构中读取，若读取失败，则从所述第二数据库中读取玩家游戏数据，若读取失败，则从所述第一数据库中读取；
存储玩家游戏数据时，优先更新内存中数据，再更新所述第一数据库中的玩家游戏数据，最后更新所述第二数据库中的玩家游戏数据。
其中一种设计中，所述第一数据库为Mysql数据库，第二数据库为Redis缓存数据库。
其中一种设计中，所述方法还包括步骤：按照预设帧率轮询所述消息队列中是否有新的玩家游戏数据，如果有新的玩家游戏数据，则将所述新的玩家游戏数据发给同一个房间内的所有玩家。
其中一种设计中，所述方法还包括步骤：通过玩家任务管理对象对所述玩家的任务进行管理，每个玩家ID对应一个玩家任务管理对象；当玩家数据更新时，通过邮件配置数据，生成一条邮件保存在玩家邮件管理对象中，供所述玩家加载查看，所述每个玩家ID对应一个玩家邮件管理对象。
第二方面，本申请实施例提供了一种服务器，该服务器包括：
存储单元，用于初始化服务器时，将玩家游戏数据储存在第一数据库中，服务器启动后，将所述玩家游戏数据载入到内存中的不同数据结构中；还用于存储玩家游戏数据时，优先更新内存中数据，再更新所述第一数据库中的玩家游戏数据，最后更新所述第二数据库中的玩家游戏数据
分类单元，用于玩家发送玩家游戏数据到服务器后，服务器对所述玩家游戏数据进行分类，将分类后的玩家游戏数据发送到预先配置的分管各类玩家游戏数据的消息队列中；
读取单元，用于读取服务器的玩家游戏数据时，优先从所述内存的不同数据结构中读取，若读取失败，则从所述第二数据库中读取玩家游戏数据，若读取失败，则从所述第一数据库中读取。
其中一种设计中，所述第一数据库为Mysql数据库，第二数据库为Redis缓存数据库。
其中一种设计中，所述的服务器还包括：
轮询单元，用于按照预设帧率轮询所述消息队列中是否有新的玩家游戏数据，如果有新的玩家游戏数据，则将所述新的玩家游戏数据发给同一个房间内的所有玩家。
其中一种设计中，所述的服务器还包括：
玩家任务管理对象单元，用于对所述玩家的任务进行管理，每个玩家ID对应一个玩家任务管理对象；
玩家邮件管理对象，用于当玩家数据更新时，通过邮件配置数据，生成一条邮件，保存在玩家邮件管理对象中，供所述玩家加载查看，所述每个玩家ID对应一个玩家邮件管理对象。
第三方面，提供了一种游戏系统，包括客户端以及如第二方面所述的服务器，游戏玩家通过所述客户端连接到所述服务器。
第四方面，提供了一种计算机可读程序介质，其存储有计算机程序指令，当所述计算机程序指令被计算机执行时，使计算机执行根据第一方面所述的方法步骤。
综上所述，本申请实施例通过将玩家游戏数据先分类，对不同类玩家游戏数据使用不同的存储和读取策略，并结合高效的消息队列和多线程技术，使本技术方案能够让处于不同地域位置的游戏服务器高效、准确的实现数据共享与同步，从而玩家可以用同一个账号在不同的服务器上登录游戏，游戏体验顺畅。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种处理数据的方法流程图；
图2（a）为本申请实施例提供的一种服务器的架构示意框图；
图2（b）为本申请实施例提供的另一种服务器的架构示意框图；
图2（c）为本申请实施例提供的另一种服务器的架构示意框图；
图3为本申请实施例提供的一种游戏服务器系统示意图；
图4是本申请实施例提供的一种游戏服务器系统示意图；
图5是本申请实施例提供的一种游戏服务器系统多线程处理原理的示意图；
图6是本申请实施例提供的一种游戏服务器系统多线程处理原理示意图。
实施方式
下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。
本说明书中的各个实施例示出了一种基于数据共享的高并发游戏服务器架构。通过将数据先分类，对不同类数据使用不同的存储和读取策略，并结合高效的消息队列和多线程技术，使本架构方案能够让处于不同地域位置的游戏服务器高效、准确的实现数据共享与同步，从而玩家可以用同一个账号在不同的服务器上登录游戏。
如图1所示，本申请实施例提供了一种处理数据的方法，至少包括以下步骤（以下所述第一数据库为Mysql数据库，所述第二数据库为Redis缓存数据库）：
步骤101：初始化服务器，将游戏初始数据储存在第一数据库中（初始数据包括但不局限于任务配置数据、邮件配置数据、玩家等级配置数据等）。当服务器启动时，将玩家游戏数据载入到内存中的不同数据结构。
步骤102：玩家发送玩家游戏数据到服务器后，服务器对相应数据进行分类，所述玩家游戏数据信息包括但不局限于：玩家信息、战斗匹配消息和战斗消息；将各类消息发送到预先配置的分管各类消息的消息队列中，再由对应的线程池进行消息处理。
步骤103：读取服务器数据时，优先从内存数据结构中读取，若无数据，则从第二数据库中读取玩家游戏数据，若无数据，则从第一数据库中读取。
步骤104：存储数据时，优先更新内存中数据，再更新第一数据库中的数据，最后更新第二数据库中的数据。
本实施例中在高并发情况下，实现不同服务器之间的数据共享与同步。结合内存、Mysql数据库和Redis数据库三种存储方案。初始服务器时，将初始数据分类存入内存、第一数据库和第二数据库，初始数据包括但不局限于任务配置数据、邮件配置数据。高并发是指在某一时刻访问量比较大。服务器接收多个客户端的请求，许多客户端同时请求形成高并发数据。将系统内数据分为三类，具体如下：
第一类：公共配置数据，例如任务配置数据、邮件描述信息等。这类数据是所有服务器都相同的，而且读取很频繁。这类数据在各个服务器启动时，分别载入自己的内存中。
第二类：玩家私有数据，例如玩家信件、玩家任务、玩家物品等。因为每个玩家的数据是独立的，所以当玩家对自己的数据操作时，并不会影响到别的玩家。因此这部分的数据同样需要载入内存中，当发生变化时，先更新内存中的数据，再修改数据库中的数据。
第三类：需要实时更新显示的数据，例如排行榜数据、玩家个人信息数据。将这类数据存放到Redis中，每次更新数据，先更新第一数据库Mysql中的数据，再更新第二数据库Redis中的数据，读取数据则直接从Redis中读取。
同时，本申请实施例还结合消息队列与多线程的技术方案实现以上的步骤方法流程。比如消息队列包括玩家信息消息队列，战斗匹配消息队列和战斗消息队列，多线程由线程池进行分配，线程池提供多线程处理数据并将数据进行分片推送到对应的本地队列，提升消息的处理速度。服务器利用线程池分配的多线程快速消费所述主数据队列中的高并发数据。其中，处理所述主数据队列中的高并发数据是指将主数据队列中的高并发数据移出该主数据队列。
本发明实施例通过将玩家游戏数据分类，对不同类玩家游戏数据使用不同的存储和读取策略，并结合高效的消息队列和多线程技术，使本架构方案能够让处于不同地域位置的游戏服务器高效、准确的实现数据共享与同步，从而玩家可以用同一个账号在不同的服务器上登录游戏。
如图2所示，本申请实施例公开了一种服务器，该服务器包括：
存储单元201，用于初始化服务器，将游戏初始数据储存在第一数据库中（初始数据包括但不局限于任务配置数据、邮件配置数据、玩家等级配置数据等）。当服务器启动时，将玩家游戏数据载入到内存中的不同数据结构。
分类单元202，用于玩家发送玩家游戏数据到服务器后，对相应数据进行分类，所述玩家游戏数据信息包括但不局限于：玩家信息、战斗匹配消息和战斗消息；将各类消息发送到预先配置的分管各类消息的消息队列中，再由对应的线程池进行消息处理。
读取单元203，用于读取服务器数据时，优先从内存数据结构中读取，若无数据，则从第二数据库中读取玩家游戏数据，若无数据，则从第一数据库中读取。
所述存储单元201还用于存储数据时，优先更新内存中数据，再更新第一数据库中的数据，最后更新第二数据库中的数据。
优选地，第一数据库为Mysql数据库，第二数据库为Redis缓存数据库。
另一实施例中，如图2（b）所示，服务器还可以包括：轮询单元204，用于按照预设帧率轮询所述消息队列中是否有新的玩家游戏数据，如果有新的玩家游戏数据，则将所述新的玩家游戏数据发给同一个房间内的所有玩家。
另一实施例中，如图2（c）所示，服务器还可以包括：玩家任务管理对象单元205，用于对所述玩家的任务进行管理，每个玩家ID对应一个玩家任务管理对象；玩家邮件管理对象，用于当玩家数据更新时，通过邮件配置数据，生成一条邮件，保存在玩家邮件管理对象中，供所述玩家加载查看，所述每个玩家ID对应一个玩家邮件管理对象。
下面以多人在线战术竞技游戏（Multiplayer Online Battle Arena，MOBA）服务器系统为例说明。如图3所示，本服务器的核心系统主要由战斗系统、排行系统、任务系统、好友系统构成。
如图4所示，本实施例中服务器至少包括网络通信框架Netty、设计层开源框架Spring、序列化通信协议Probuf、持久层框架 Mybatis，第一数据库Mysql和第二数据库Redis用于数据的持久化和缓存。有的数据直接对Mysql进行操作，有的数据需要先写入Redis并从Reids中进行读取，Mysql中的数据会用于更新Redis，而Redis中的数据不会用于更新Mysql。
具体的配置和部署方式如下：
Server1和Server2为两台地域位置不同的阿里云Centos7 64位系统服务器，在上面安装相同的Jdk版本，本实施例所用版本号为openjdk version 1.8.0_191(其它版本也可以,但或许部分逻辑接口要根据相应版本调整)，用于运行游戏服务端jar包。
Mysql和Redis安装在另外一台服务器中，本实施例中使用的版本分别为 Redis-4.0.10和Mysql-14.14 Linux (x86_64)，用于数据的持久化和缓存。
开发环境配置:服务端程序开发环境为Window 10 64位、Eclipse 2018, Jdk1.8.0_191，并通过maven发布jar包。
客户端发起连接后，以长连接的方式登录游戏，相应建立一个Channel，通过这个Channel进行通信。玩家上线时，Channel处于激活状态，玩家下线时，Channel则转为非激活状态。玩家登录以后，通过玩家的id检查该玩家是否为新用户，如果是新用户，创建玩家的User实例，并通过Map将Channel和玩家User映射。这样就可以通过Channel找到玩家；如果是老用户，同样要更新Channel和User对应关系。
任务和邮件的配置数据，建成对应的表格保存在Mysql中，并在服务器启动的时候加载到内存中作为缓存，对应的管理类为TaskManager和MailManager。加载在内存中的好处是，下次读取数据时，不用去Mysql中取数据，直接从内存中取数据，效率更高。而且这些配置数据量不是很大，不会占用太多内存。
如图5所示，当新注册的玩家登录游戏后，通过获取TaskManager中缓存的任务配置数据，生成玩家自己的任务（Task）数据，保存在UserTaskManager中，需要注意的是，每个User必须要拥有一个UserTaskManager对象，负责该玩家的Task管理。同理，每个User拥有一个UserMailManager对象，在玩家等级提升或者达成成就时，通过MailManager中的配置数据，生成一条玩家的Mail，保存在UserMailManager中，供玩家加载查看等操作。这部分的数据，既需要保存在内存中，并持久化到数据库中。玩家再次登录时，需要从数据库重新加载一次这些数据，从而保证玩家从不同服务器登录时的数据是同步的。
对于像排行榜数据、玩家个人信息数据等数据是需要实时更新显示的数据。每次更新这些数据，先更新Mysql中的数据，再更新Redis中的数据，读取数据则直接从Redis中读取。
如图6所示，本实施中游戏系统包括三个消息队列： UserMsgQueue、MatchMsgQueue和FightMsgQueue。同时设置三个线程去分别处理三个队列中的数据。UserMsgQueue保存玩家个人以及玩家之间的数据操作消息；MatchMsgQueue保存玩家战斗匹配相关消息；FightMsgQueue保存战斗中的操作数据。具体逻辑为：当玩家向服务器发送消息时，服务端通过channel进行传输到不同的handle中进行处理。首先进行解码，然后根据获取到的消息类型，对消息进行分类，添加到对应的三个消息队列中。对应的三个线程在系统启动时开始运行，检测到对应消息队列中的消息后就进行相应处理。结合Netty本身的NIO特性，该系统的并发性能够解决绝大多数游戏服务器的需求。
对于战斗系统，本实施例通过帧同步技术，实现同一个房间里的玩家数据同步。一种实现方式是在FightMsgQueue对应的线程中，设定好帧率，不断轮询FightMsgQueue中是否有新数据，如果有新数据，就封装成Frame，分发给房间内所有的玩家。玩家根据收到的数据，对界面进行刷新。在这个过程如果涉及到相对复杂的任务（如数据统计、分发消息给玩家），都需要异步处理，不能让复杂的运算阻塞了消息的同步。
对于排行榜，由于要支持成千上万玩家同时在线的实时得分排行，因此不能简单得通过O^2的算法实现，但是如果把数据加载到内存中，通过树形区间算法排序，同样会占用非常大的内存，而且是不能回收的内存，因此采用Redis，将排序功能做成一个单独的服务放在数据服务器上，玩家直接调用，就可以圆满解决上述问题。具体的做法是：
当玩家获得新的分数时，通过算法获得一个新的分数值作为要存入Redis的数据。关于算法，比如是首先获得当前时间的秒数，获得时间差，为了使相同分数的玩家，先获得者排在前面，后获得的玩家排在后面，所以先获得的玩家加一个较大数，后获得玩家加一个较小数。然后再获得redis要存放的分数值。通过玩家的uid区分不同玩家，再用RankKey字符串区分不同的排行榜（不同战斗模式对应不同），添加到Redis的SortedSet(有序集合)中。
调用的接口如下所示，参数Key对应RankKey,score对应redis_score，member对应uid。
通过如下算法获得排名在某区间内的玩家,根据玩家获得的分数从大到小排序。参数start 和 stop对应具体区间， key则对应不同的排行榜，由于Redis中数据索引从0开始，因此要进行减一操作。
在游戏服务器启动时，将玩家的排行数据载入Redis中，多个游戏服务器共用一个Redis，加载数据时，Redis会根据玩家的uid刷新Redis中已经存在的数据，所以不会造成数据的重复。 当玩家进行操作时产生了新的分数，那么将玩家的分数分别存入到Redis和Mysql中。当玩家需要获得排行榜数据时，直接从Redis中调用，这样所有玩家调用到的排行榜数据都是实时的。
读取玩家个人信息时，优先读取Redis，并保持与Mysql中的数据一致。在游戏中，玩家的权限只能通过排行榜或者好友列表查看其他玩家的个人基本信息，因此，玩家获取的数据，也是实时同步数据。如果玩家的好友很多，就通过分页加载的方式，这样客户端就不会出现卡顿的情况。
本申请实施例还公开了一种游戏系统，包括客户端和如图2(a)、或2(b)、或2(c)所示的服务器，游戏玩家通过所述客户端连接到所述服务器。
本申请实施例还公开了一种计算机可读程序介质，其存储有计算机程序指令，当所述计算机程序指令被计算机执行时，使计算机执行如图1所示的方法流程步骤。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (8)

1.一种处理数据的方法，其特征在于，包括：
初始化服务器时，将玩家游戏数据储存在第一数据库中，服务器启动后，将所述玩家游戏数据载入到内存中的不同数据结构中；
玩家发送玩家游戏数据到服务器后，服务器对所述玩家游戏数据进行分类，将分类后的玩家游戏数据发送到预先配置的分管各类玩家游戏数据的消息队列中；
读取服务器的玩家游戏数据时，优先从所述内存的不同数据结构中读取，若读取失败，则从第二数据库中读取玩家游戏数据，若读取失败，则从所述第一数据库中读取；
存储玩家游戏数据时，优先更新内存中数据，再更新所述第一数据库中的玩家游戏数据，最后更新所述第二数据库中的玩家游戏数据；
所述第一数据库为Mysql数据库，第二数据库为Redis缓存数据库；
所述服务器至少包括网络通信框架Netty、设计层开源框架Spring、序列化通信协议Probuf、持久层框架 Mybatis，第一数据库Mysql和第二数据库Redis用于数据的持久化和缓存；有的数据直接对Mysql进行操作，有的数据需要先写入Redis并从Reids中进行读取，Mysql中的数据会用于更新Redis，而Redis中的数据不会用于更新Mysql；具体的配置和部署方式如下：Server1和Server2为两台地域位置不同的阿里云Centos7 64位系统服务器，在上面安装相同的Jdk版本，所用版本号为openjdk version 1.8.0_191，用于运行游戏服务端jar包；Mysql和Redis安装在另外一台服务器中，使用的版本分别为 Redis-4.0.10和Mysql-14.14 Linux ，用于数据的持久化和缓存；
开发环境配置:服务端程序开发环境为Window 10 64位、Eclipse 2018, Jdk 1.8.0_191，并通过maven发布jar包；客户端发起连接后，以长连接的方式登录游戏，相应建立一个Channel，通过这个Channel进行通信；玩家上线时，Channel处于激活状态，玩家下线时，Channel则转为非激活状态；玩家登录以后，通过玩家的id检查该玩家是否为新用户，如果是新用户，创建玩家的User实例，并通过Map将Channel和玩家User映射；这样就可以通过Channel找到玩家；如果是老用户，同样要更新Channel和User对应关系；任务和邮件的配置数据，建成对应的表格保存在Mysql中，并在服务器启动的时候加载到内存中作为缓存，对应的管理类为TaskManager和MailManager；加载在内存中的好处是，下次读取数据时，不用去Mysql中取数据，直接从内存中取数据，效率更高；当新注册的玩家登录游戏后，通过获取TaskManager中缓存的任务配置数据，生成玩家自己的任务数据，保存在UserTaskManager中，需要注意的是，每个User必须要拥有一个UserTaskManager对象，负责该玩家的Task管理；同理，每个User拥有一个UserMailManager对象，在玩家等级提升或者达成成就时，通过MailManager中的配置数据，生成一条玩家的Mail，保存在UserMailManager中，供玩家加载查看等操作；这部分的数据，既需要保存在内存中，并持久化到数据库中；玩家再次登录时，需要从数据库重新加载一次这些数据，从而保证玩家从不同服务器登录时的数据是同步的；对于像排行榜数据、玩家个人信息数据等数据是需要实时更新显示的数据；每次更新这些数据，先更新Mysql中的数据，再更新Redis中的数据，读取数据则直接从Redis中读取；游戏系统包括三个消息队列： UserMsgQueue、MatchMsgQueue和FightMsgQueue；同时设置三个线程去分别处理三个队列中的数据；UserMsgQueue保存玩家个人以及玩家之间的数据操作消息；MatchMsgQueue保存玩家战斗匹配相关消息；FightMsgQueue保存战斗中的操作数据；具体逻辑为：当玩家向服务器发送消息时，服务端通过channel进行传输到不同的handle中进行处理；首先进行解码，然后根据获取到的消息类型，对消息进行分类，添加到对应的三个消息队列中；对应的三个线程在系统启动时开始运行，检测到对应消息队列中的消息后就进行相应处理；对于战斗系统，通过帧同步技术，实现同一个房间里的玩家数据同步；一种实现方式是在FightMsgQueue对应的线程中，设定好帧率，不断轮询FightMsgQueue中是否有新数据，如果有新数据，就封装成Frame，分发给房间内所有的玩家；玩家根据收到的数据，对界面进行刷新；在这个过程如果涉及到数据统计、分发消息给玩家的任务，都需要异步处理，不能让复杂的运算阻塞了消息的同步；当玩家获得新的分数时，通过算法获得一个新的分数值作为要存入Redis的数据；关于算法，比如是首先获得当前时间的秒数，获得时间差，为了使相同分数的玩家，先获得者排在前面，后获得的玩家排在后面，所以先获得的玩家加一个较大数，后获得玩家加一个较小数；然后再获得redis要存放的分数值；通过玩家的uid区分不同玩家，再用RankKey字符串区分不同的排行榜，添加到Redis的SortedSet中；在游戏服务器启动时，将玩家的排行数据载入Redis中，多个游戏服务器共用一个Redis，加载数据时，Redis会根据玩家的uid刷新Redis中已经存在的数据，所以不会造成数据的重复；当玩家进行操作时产生了新的分数，那么将玩家的分数分别存入到Redis和Mysql中；当玩家需要获得排行榜数据时，直接从Redis中调用，这样所有玩家调用到的排行榜数据都是实时的；读取玩家个人信息时，优先读取Redis，并保持与Mysql中的数据一致；在游戏中，玩家的权限只能通过排行榜或者好友列表查看其他玩家的个人基本信息，因此，玩家获取的数据，也是实时同步数据；如果玩家的好友很多，就通过分页加载的方式，这样客户端就不会出现卡顿的情况。
2.根据权利要求1所述的方法，其特征在于，还包括：
按照预设帧率轮询所述消息队列中是否有新的玩家游戏数据，如果有新的玩家游戏数据，则将所述新的玩家游戏数据发给同一个房间内的所有玩家。
3.根据权利要求1所述的方法，其特征在于，还包括：
通过玩家任务管理对象对所述玩家的任务进行管理，每个玩家ID对应一个玩家任务管理对象；
当玩家数据更新时，通过玩家邮件管理对象中的配置数据，生成一条邮件保存在玩家邮件管理对象中，供所述玩家加载查看，所述每个玩家ID对应一个玩家邮件管理对象。
4.一种服务器，其特征在于，包括：
存储单元，用于初始化服务器时，将玩家游戏数据储存在第一数据库中，服务器启动后，将所述玩家游戏数据载入到内存中的不同数据结构中；
分类单元，用于玩家发送玩家游戏数据到服务器后，服务器对所述玩家游戏数据进行分类，将分类后的玩家游戏数据发送到预先配置的分管各类玩家游戏数据的消息队列中；
读取单元，用于读取服务器的玩家游戏数据时，优先从所述内存的不同数据结构中读取，若读取失败，则从第二数据库中读取玩家游戏数据，若读取失败，则从所述第一数据库中读取；
所述存储单元，还用于存储玩家游戏数据时，优先更新内存中数据，再更新所述第一数据库中的玩家游戏数据，最后更新所述第二数据库中的玩家游戏数据；
所述第一数据库为Mysql数据库，第二数据库为Redis缓存数据库；所述服务器至少包括网络通信框架Netty、设计层开源框架Spring、序列化通信协议Probuf、持久层框架Mybatis，第一数据库Mysql和第二数据库Redis用于数据的持久化和缓存；有的数据直接对Mysql进行操作，有的数据需要先写入Redis并从Reids中进行读取，Mysql中的数据会用于更新Redis，而Redis中的数据不会用于更新Mysql；具体的配置和部署方式如下：Server1和Server2为两台地域位置不同的阿里云Centos7 64位系统服务器，在上面安装相同的Jdk版本，所用版本号为openjdk version 1.8.0_191，用于运行游戏服务端jar包；Mysql和Redis安装在另外一台服务器中，使用的版本分别为 Redis-4.0.10和Mysql-14.14 Linux，用于数据的持久化和缓存；
开发环境配置:服务端程序开发环境为Window 10 64位、Eclipse 2018, Jdk 1.8.0_191，并通过maven发布jar包；客户端发起连接后，以长连接的方式登录游戏，相应建立一个Channel，通过这个Channel进行通信；玩家上线时，Channel处于激活状态，玩家下线时，Channel则转为非激活状态；玩家登录以后，通过玩家的id检查该玩家是否为新用户，如果是新用户，创建玩家的User实例，并通过Map将Channel和玩家User映射；这样就可以通过Channel找到玩家；如果是老用户，同样要更新Channel和User对应关系；任务和邮件的配置数据，建成对应的表格保存在Mysql中，并在服务器启动的时候加载到内存中作为缓存，对应的管理类为TaskManager和MailManager；加载在内存中的好处是，下次读取数据时，不用去Mysql中取数据，直接从内存中取数据，效率更高；当新注册的玩家登录游戏后，通过获取TaskManager中缓存的任务配置数据，生成玩家自己的任务数据，保存在UserTaskManager中，需要注意的是，每个User必须要拥有一个UserTaskManager对象，负责该玩家的Task管理；同理，每个User拥有一个UserMailManager对象，在玩家等级提升或者达成成就时，通过MailManager中的配置数据，生成一条玩家的Mail，保存在UserMailManager中，供玩家加载查看等操作；这部分的数据，既需要保存在内存中，并持久化到数据库中；玩家再次登录时，需要从数据库重新加载一次这些数据，从而保证玩家从不同服务器登录时的数据是同步的；对于像排行榜数据、玩家个人信息数据等数据是需要实时更新显示的数据；每次更新这些数据，先更新Mysql中的数据，再更新Redis中的数据，读取数据则直接从Redis中读取；游戏系统包括三个消息队列： UserMsgQueue、MatchMsgQueue和FightMsgQueue；同时设置三个线程去分别处理三个队列中的数据；UserMsgQueue保存玩家个人以及玩家之间的数据操作消息；MatchMsgQueue保存玩家战斗匹配相关消息；FightMsgQueue保存战斗中的操作数据；具体逻辑为：当玩家向服务器发送消息时，服务端通过channel进行传输到不同的handle中进行处理；首先进行解码，然后根据获取到的消息类型，对消息进行分类，添加到对应的三个消息队列中；对应的三个线程在系统启动时开始运行，检测到对应消息队列中的消息后就进行相应处理；对于战斗系统，通过帧同步技术，实现同一个房间里的玩家数据同步；一种实现方式是在FightMsgQueue对应的线程中，设定好帧率，不断轮询FightMsgQueue中是否有新数据，如果有新数据，就封装成Frame，分发给房间内所有的玩家；玩家根据收到的数据，对界面进行刷新；在这个过程如果涉及到数据统计、分发消息给玩家的任务，都需要异步处理，不能让复杂的运算阻塞了消息的同步；当玩家获得新的分数时，通过算法获得一个新的分数值作为要存入Redis的数据；关于算法，比如是首先获得当前时间的秒数，获得时间差，为了使相同分数的玩家，先获得者排在前面，后获得的玩家排在后面，所以先获得的玩家加一个较大数，后获得玩家加一个较小数；然后再获得redis要存放的分数值；通过玩家的uid区分不同玩家，再用RankKey字符串区分不同的排行榜，添加到Redis的SortedSet中；在游戏服务器启动时，将玩家的排行数据载入Redis中，多个游戏服务器共用一个Redis，加载数据时，Redis会根据玩家的uid刷新Redis中已经存在的数据，所以不会造成数据的重复；当玩家进行操作时产生了新的分数，那么将玩家的分数分别存入到Redis和Mysql中；当玩家需要获得排行榜数据时，直接从Redis中调用，这样所有玩家调用到的排行榜数据都是实时的；读取玩家个人信息时，优先读取Redis，并保持与Mysql中的数据一致；在游戏中，玩家的权限只能通过排行榜或者好友列表查看其他玩家的个人基本信息，因此，玩家获取的数据，也是实时同步数据；如果玩家的好友很多，就通过分页加载的方式，这样客户端就不会出现卡顿的情况。
5.根据权利要求4所述的服务器，其特征在于，还包括：
轮询单元，用于按照预设帧率轮询所述消息队列中是否有新的玩家游戏数据，如果有新的玩家游戏数据，则将所述新的玩家游戏数据发给同一个房间内的所有玩家。
6.根据权利要求4所述的服务器，其特征在于，还包括：
玩家任务管理对象单元，用于对所述玩家的任务进行管理，每个玩家ID对应一个玩家任务管理对象；
玩家邮件管理对象，用于当玩家数据更新时，通过邮件配置数据，生成一条邮件，保存在玩家邮件管理对象中，供所述玩家加载查看，所述每个玩家ID对应一个玩家邮件管理对象。
7.一种游戏系统，其特征在于，包括客户端和如权利要求4-6任一所述的服务器，游戏玩家通过所述客户端连接到所述服务器。
8.一种计算机可读程序介质，其特征在于，其存储有计算机程序指令，当所述计算机程序指令被计算机执行时，使计算机执行根据权利要求1-4任一所述的方法。
CN201911073558.1A 2019-11-06 2019-11-06 处理数据的方法、服务器、系统和计算机可读程序介质 Active CN110898434B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911073558.1A CN110898434B (zh) 2019-11-06 2019-11-06 处理数据的方法、服务器、系统和计算机可读程序介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911073558.1A CN110898434B (zh) 2019-11-06 2019-11-06 处理数据的方法、服务器、系统和计算机可读程序介质

Publications (2)

Publication Number Publication Date
CN110898434A CN110898434A (zh) 2020-03-24
CN110898434B true CN110898434B (zh) 2023-07-25

Family

ID=69816229

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911073558.1A Active CN110898434B (zh) 2019-11-06 2019-11-06 处理数据的方法、服务器、系统和计算机可读程序介质

Country Status (1)

Country Link
CN (1) CN110898434B (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112015815B (zh) * 2020-08-27 2024-02-02 中国平安财产保险股份有限公司 数据同步方法、装置及计算机可读存储介质
CN112494954A (zh) * 2020-12-15 2021-03-16 网易（杭州）网络有限公司 数据处理方法、装置、设备及存储介质
CN112597163B (zh) * 2020-12-25 2024-05-28 珠海金山数字网络科技有限公司 数据处理系统、方法及装置
CN113032151B (zh) * 2021-03-31 2023-10-17 广州虎牙科技有限公司 业务消息的处理方法、电子设备、移动终端及存储介质
CN112867003B (zh) * 2021-04-25 2021-07-06 广州边在晓峰网络科技有限公司 一种无线通信的游戏数据通道通信连接系统
CN115193026A (zh) * 2022-09-16 2022-10-18 成都止观互娱科技有限公司 一种高并发全球同服游戏服务器架构及数据访问方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004008358A1 (ja) * 2002-07-16 2004-01-22 Konami Online, Inc. ネットワークサービスシステム及びポイント振替システム
CN103944993A (zh) * 2014-04-25 2014-07-23 北京乐动卓越信息技术有限公司 百万级用户同时在线移动平台服务器架构
CN105999702A (zh) * 2016-05-23 2016-10-12 浙江工业大学 一种基于数据重演机制的网页游戏存档还原方法
CN109408751A (zh) * 2018-09-27 2019-03-01 腾讯科技(成都)有限公司 一种数据处理方法、终端、服务器及存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI421118B (zh) * 2010-10-01 2014-01-01 Xpec Entertainment Inc Online gaming system and method of resources to handle online games
CN104135506B (zh) * 2014-06-25 2018-02-02 深圳市盛讯达科技股份有限公司 网络数据负载均衡设计系统及方法
CN105797381A (zh) * 2014-12-30 2016-07-27 博雅网络游戏开发（深圳）有限公司 游戏冷数据的存储、读取方法和装置
CN106031827B (zh) * 2015-03-18 2019-07-12 广州四三九九信息科技有限公司 基于redis的游戏服务器数据存储、读取方法及系统
CN105491029A (zh) * 2015-11-26 2016-04-13 盛趣信息技术（上海）有限公司 游戏服务器集群
CN108093017A (zh) * 2016-11-23 2018-05-29 上海冰穹网络科技有限公司 游戏数据后台操作方法及数据处理平台
CN107239306A (zh) * 2017-05-26 2017-10-10 黄晓咏 一种游戏通讯数据处理系统
CN108874903A (zh) * 2018-05-24 2018-11-23 中国平安人寿保险股份有限公司 数据读取方法、装置、计算机设备及计算机可读存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004008358A1 (ja) * 2002-07-16 2004-01-22 Konami Online, Inc. ネットワークサービスシステム及びポイント振替システム
CN103944993A (zh) * 2014-04-25 2014-07-23 北京乐动卓越信息技术有限公司 百万级用户同时在线移动平台服务器架构
CN105999702A (zh) * 2016-05-23 2016-10-12 浙江工业大学 一种基于数据重演机制的网页游戏存档还原方法
CN109408751A (zh) * 2018-09-27 2019-03-01 腾讯科技(成都)有限公司 一种数据处理方法、终端、服务器及存储介质

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
杨珂.多人同时在线网络游戏安全性和性能评估.中国优秀硕士学位论文全文数据库.2015,(第03期),全文. *
洪学海等.应用驱动的高效能计算机系统的研究与发展.计算机研究与发展.2007,(第10期),1633-1639. *
网络游戏服务器面临的技术挑战及对策;孙启;;电子技术与软件工程(第21期);30 *

Also Published As

Publication number Publication date
CN110898434A (zh) 2020-03-24

Similar Documents

Publication Publication Date Title
CN110898434B (zh) 处理数据的方法、服务器、系统和计算机可读程序介质
US11070637B2 (en) Method and device for allocating augmented reality-based virtual objects
US10463960B1 (en) System and method for determining and acting on a user's value across different platforms
US11890537B2 (en) System, method, and device for processing game
US20120238358A1 (en) Method and Apparatus for Virtual Location-Based Services
US8517838B2 (en) Online game system and method of data resource handling for an online game
CN111737012B (zh) 数据包的同步方法、装置、设备及存储介质
CN105641934B (zh) 一种同一账号内玩家角色实时切换的方法及装置
US20140325070A1 (en) Usage consumption for an invitee of a cloud system
JP6492198B2 (ja) 情報処理方法および端末、ならびにコンピュータ記憶媒体
US9569801B1 (en) System and method for uniting user accounts across different platforms
CN108452525A (zh) 一种游戏中聊天信息的监控方法及系统
CN112090074B (zh) 应用中的虚拟物品控制方法、装置、设备及介质
CN111330265A (zh) 计算机系统、虚拟区的登录方法、装置、设备及介质
US9021051B1 (en) Providing selective retrieval of data objects from a network service
US20170014713A1 (en) Substitution of game commands with different replacement commands at client devices using substitution reference sets
CN106232193A (zh) 使用检索到的部分用户数据的游戏进展
CN110113414B (zh) 一种管理副本的方法、装置、服务器及存储介质
CN110580257A (zh) 数据共享方法、服务器及介质
CN105610849B (zh) 分享标签的生成方法及装置、属性信息的显示方法及装置
CN109304032B (zh) 游戏系统的自适应进化方法、装置及服务器
CN111600858B (zh) 一种应用登录方法、装置及系统
US11241628B2 (en) Augmented gaming with item gifting and online gameplay
CN106621333B (zh) 一种网络游戏名片的生成方法及装置
US9511280B1 (en) Online gaming system including virtual items that transcend multiple character deaths

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant