分布式游戏服务器设计

服务器解释

  • 网关服务器 Gateway Server,与客户端保持长连接并转发消息给中心服务器和游戏服务器
  • 登录服务器 Login Server,与网关服务器连接之前的登录业务
  • 中心服务器 Center Server,全局功能及消息推送
  • 游戏服务器 Game Server,游戏的核心场景实现
  • 存储服务器 Database Sever,数据库访问的连接代理

整体设计图

在这里插入图片描述

网关服务器

网络连接

  • 保持TCP连接
    • 实现多服特性时,客户端无需重新连接,提高切服的成功率和速度。
    • 对于无状态的Game Server,可以进行无感重启
    • 实现单点登录特性时,继承旧的会话,断开旧的连接,接入新的连接,无需下线
  • 流量限制
    • 防止用户通过单TCP连接内发出巨大流量,从而恶意消耗服务器的CPU资源
  • 横向扩展
    • 提高并发性能
    • 多个Gateway Server同时存在时,仍然实现单点登录特性,继承旧的会话,无需下线

消息处理

  • 消息内容压缩
    • 略微增加了CPU负载
    • 大量减少了服务器外网带宽消耗
    • 减少了传输延迟
  • 消息内容加密
    • 防止用户通过流量捕获软件获取数据包,识别内容涵义后,通过发包工具伪造数据包。
    • 消息内容中添加每次连接新生成的key,来防止用户通过录包软件发送固定的包序列充当机器人。
  • 消息序列(Sequence)验证
    • 判定客户端是否出现了发送消息的丢失或者异常
    • 防止用户通过录包软件重复发送单条消息
  • 消息完整性(CRC)验证
    • 判定切包正常
    • 判定数据包是否在通过网络层被更改过。
  • 消息时间戳验证
    • 检查消息包的时间戳,如果超时太久,则丢弃数据包。

权限管理

  • token验证
    • 通过客户端提供的token,验证接入权限
  • 黑名单
    • 获取玩家的用户id,查询用户权限,判定是否可以接入
  • 版本验证
    • 识别客户端多版本,提供多版本服务器路由支持
    • 识别客户端无效版本,提示升级客户端
  • 心跳
    • 心跳比TCP连接超时更为敏感,可覆盖更多类型的逻辑及网络异常,可及时释放连接。服务器负责监听会话的客户端心跳(PING),超时即主动断开,客户端会话也会监听服务器心跳(PONG),超时即主动断开
    • 通过心跳的时间戳来评估网络延迟,作为服务器故障判断的一种依据
    • 通过心跳的时间戳来评估网络延迟,在客户端显示网络信号状态
  • 强制下线
    • 当用户被判定为黑名单时,需要从Gateway Server上强制断开TCP连接,下次登录自动进入黑名单流程。

业务支持

  • 多级数据支持
    • 当Game Server仅拥有二级数据(比如游戏角色)的读写权限时,Gateway Server可以用来负责一级数据(比如账号昵称,创建角色)的读写业务。
  • 登录控制
    • 控制服务器的同时在线人数,尽量保证服务器的CPU使用率在50%以下,当同时在线人数超过阈值以后,不允许进入服务器,进入排队系统。
  • 排队系统
    • 玩家登录鉴权通过以后,如果当前在线人数过多,则保持登录连接,进入等待队列。
  • 在线统计
    • 通过有效连接数来统计总在线人数
  • 登录验证
    • Database登录,每次重连Gateway Server负责都去访问数据库中的账号数据表
    • Session登录, session过期前的第一次登录由Login Server访问数据库中的账号数据表,将session 键值对存入缓存。用户获得session key,在session过期前请求Gateway Server,服务器通过查询缓存进行鉴权
    • Token登录, session过期前第一次登录由Login Server访问数据库中的账号数据表,服务器不缓存token。用户获得token,在token过期前,请求Gateway Server,服务器通过算法获取token里面的加密信息进行鉴权

消息路由

  • 转发请求消息
    • 根据消息所带的组别,路由消息至对应的Game Server
    • 根据客户端所用版本,路由消息至对应的Game Server
  • 转发响应消息
    • 接收用户Id应该发出的消息,并向用户发出
    • 消息传输到错误的Gateway Server后,可以自动路由到正确的Gateway Server
    • 用户已经断开连接,丢弃数据包
  • 广播消息
    • 对于全局消息,接受消息后,遍历所有在线玩家进行发送
    • 对于特定的名单的消息,提供名单群体推送功能
    • 对于特定的频道的消息,提供频道群体推送功能

登录服务器

网络连接

  • Http服务器
    • 没有前置的Login Gateway Server,明文传输
  • TCP服务器
    • 前置Login Gateway Server,Login Gateway Server 是一个精简版的Gateway Server,仅仅用于数据包的编解码

用户注册

  • 创建新账号
    • 建立账号类型,账号名,账号id等信息
  • 支持多种用户类型
    • 游客账号
    • 自有平台账号
    • 手机账号,拥有短信验证绑定流程
    • 第三方登录,需要等待第三方服务器http验证,每一个渠道账号使用独立的mysql数据表

用户登录

  • 访问账号数据表
    • Session登录, Session过期前的第一次登录由Login Server访问数据库中的账号数据表,并将结果返回给客户端
    • Token登录,Token过期前的第一次登录由Login Server访问数据库中的账号数据表,并将结果返回给客户端

中心服务器

用户管理

  • 全局用户表
    • 所有Gateway Server和Game Server的登录都需要在Center Server注册,如果Center Server设计为多线程,则每次注册和反注册都要上锁。
  • 单点登录
    • 当相同玩家id从另一个Gateway节点登录的时候,通过全局用户表,寻找原来的用户的TCP连接所在的Gateway Server,重定向到原来的会话,取代旧的TCP连接

消息推送

  • 推送实现方式

    • 推送和全局用户表注册可以设计在一个线程当中,优势是可以不需要上锁,劣势是推送功能是非核心逻辑,全局用户表是核心逻辑,当推送达到性能瓶颈后,会影响核心逻辑的正常运行,降低了抗风险能力。
    • 推送和全局用户表不在同一个线程当中,优势是可以发挥多线程的逻辑优势,劣势是所有对全局表的访问需要上锁。
    • 推送独立进程,推送作为聊天服务器(Chat Server)独立存在,优势是和Center Server不会有性能影响,劣势是要达到数据实时互通,一种方式是Gateway Server同时注册到Center Server和Chat Server,另一种方式是Center Server主动同步数据给Chat Server
  • 全局广播

    • 标记类型为全局广播,发送给所有的Gateway Server,Gateway Server遍历所有连接,发送消息包。
  • 频道广播

    • 标记类型为频道广播,额外带上具体的频道号,频道数据保存在Gateway Server中,发送给所有Gateway Server,遍历所有连接,匹配频道,匹配成功发送消息包。
  • 名单广播

    • 维护特定的组织关系(例如公会),这个组织关系应当不在Game Server中体现,从Center Server中定位到具体Gateway Server,然后把名单和消息内容发给Gateway Server,Gateway Server比对名单内容,然后发送消息。
    • 私聊,指定特定玩家id进行通知,从Center Server中定位到具体Gateway Server,然后把名单和消息内容发给Gateway Server,Gateway Server比对名单内容,然后发送消息。

全局功能

  • 支付到账
  • 工会系统
  • 好友系统
  • 排行榜系统
  • 全局数据实时同步

游戏服务器

数据读取

  • 玩家数据读取
    • 当玩家进入Game Server时,注册到Center Server,同时Center Server通知原服务器把玩家数据在落地完成后清除,采用实时落地方案的话,则直接清除即可,Center Server通知当前服务器拉取玩家数据。
  • 游戏数据读取
    • 当进程启动时,从存储服务器中读取游戏场景需要的状态数据,数据与场景绑定,而不和玩家绑定

数据落地

  • 玩家数据落地
    • 非实时落地,则需要切换Game Server时,回存所有的玩家游戏数据,对数据库IOPS要求较低。
    • 定时落地,减少采用非实时落地方法在系统宕机后带来的回档损失。为了更加平稳的进行数据存储,在游戏业务允许的情况下,可以按照每秒存储一部分数据的分批存储模式。
    • 实时落地,数据发生修改后,立即异步通知存储服务器进行落地,对数据库IOPS要求较高。
  • 游戏场景的状态数据落地
    • 定时落地,每分钟或者每5分钟将数据整体落地一次。为了更加平稳的进行数据存储,在游戏业务允许的情况下,可以按照每秒存储一部分数据的分批存储模式。
    • 实时落地,当宕机发生以后带来的回档损失在1秒以内,对于玩家来说是无法感知回档的。

消息处理

  • 请求响应模式
    • 大部分消息满足一请求一返回的模式,玩家能在操作到达服务器后知道是否操作成功
  • 消息推送
    • Game Server的推送直接将消息转发给Gateway Server即可,Game Server需要记录玩家所在Gateway Server。
    • 一部分情况下,为了性能要求,放弃请求响应模式,定时推送消息,比如以服务器为中心的帧同步游戏。
    • 某些业务需要,一条请求多条返回,则第二条以后的消息都采用推送方式实现。
    • Game Server内业务广播,这里的广播范围往往和游戏逻辑挂钩,比如一个副本内的所有人,推送消息也往往和逻辑挂钩,直接遍历Game Server内的玩家列表推送至Gateway Server即可。

存储服务器

工作模式

  • 数据库直连型
    • 存储服务器,仅仅只是数据库集群,上层服务器,直接连接数据。
  • 线程池型
    • 存储服务器提供数据库连接,但是数据库操作的语句由上层服务器提供。
  • 业务代理型
    • 存储服务器接收自定义业务的命令,然后将命令转化为对应的数据库操作语句,操作完成以后返回结果
  • 数据缓存型
    • 在业务代理型的基础上,自身实现了一套缓存机制,在没有缓存的系统中,可以加速数据的存取效率。

数据一致性

  • 线程取模
    • 场景相关数据,按照场景或者子场景id取模选取读写线程,如何选取id取决于具体的子业务
    • 玩家相关数据,按照玩家id取模选取读写线程
  • 数据库上锁
    • mysql使用数据库行锁
    • mysql使用恰当的事务级别

依赖系统

服务发现

  • 注册服务被其他进程发现,被动建立连接
  • 通过服务发现寻找其他服务,主动建立连接

消息队列

  • 直连型
    • Zeromq
  • 服务型
    • Rocketmq
    • Rabbitmq

存储系统

  • 缓存型
    • Redis
    • Memcache
  • 存储型
    • Mongodb
    • Mysql
  • 混合型
    • Pika
    • Ssdb
相关推荐
pomelo 是由网易开发的基于node.js开发的高性能、分布式游戏服务器框架, 也可作为高实时web应用框架。 Pomelo的应用范围 pomelo最适合的应用领域是网页游戏、社交游戏、移动游戏的服务端,开发者会发现pomelo可以用如此少的代码达到强大的扩展性和伸缩性。当然还不仅仅是游戏,很多人断言未来的web时代是实时web应用的时代, 我们发现用pomelo开发高实时web应用也如此合适, 而且伸缩性比其它框架好。目前不推荐将pomelo用于大型的MMO rpg游戏开发,尤其是3d游戏, 还是需要象bigworld这样的商用引擎来支撑。 Pomelo的理念 pomelo的第一个理念是让游戏(高实时web应用)服务器的开发变得非常简单, 而不是解决某类算法或系统上的难题。这个设计理念跟rails是很类似的;第二个理念是重视性能和可伸缩性,用户用pomelo开发出来的游戏天生具有很强的伸缩性,扩展也很容易。我们在性能优化上也花了很多功夫,并且会持续进行;第三个理念是让第三方很容易扩展,框架用了很多插件式的设计, 组件component、路由规则、甚至管理控制台都可以完全由第三方扩展。 Pomelo的框架组成 pomelo包括三部分: 框架, pomelo的核心, 与以往单进程的游戏框架不同, 它是高性能、分布式的游戏服务器框架,并且使用很简单 库, 包括了开发游戏的常用工具库, 如人工智能(ai), 寻路, aoi等 工具包, 包括管理控制台, 命令行工具, 压力测试工具等 pomelo特性 快速、易上手的游戏开发模型和api 高可伸缩的多进程架构, 支持MMO的场景分区和其它各类分区策略 方便的服务器扩展机制,可快速扩展服务器类型和数量 方便的请求、响应、广播、服务器通讯机制, 无需任何配置 注重性能,在性能、可伸缩性上做了大量的测试、优化 提供了较多扩展组件,包括游戏开发常用的库和工具包 提供了完整的MMO demo代码(客户端html5),可以作为很好的开发参考 基于socket.io开发,支持socket.io支持的多种语言客户端 为什么使用pomelo? 高并发、高实时的游戏服务器的开发是很复杂的工作。跟web应用一样, 一个好的开源容器或开发框架可以大大减少游戏开发的复杂性,让开发变得更加容易。遗憾的是目前在游戏服务器开发领域一直没有太好的开源解决方案。 pomelo将填补这个空白, 打造一款完全开源的高性能(并发)游戏服务器框架。 pomelo的优势有以下几点: 架构的可伸缩性好。 采用多进程单线程的运行架构,扩展服务器非常方便, node.js的网络io优势提供了高可伸缩性。 使用非常容易, 开发模型与web应用的开发类似,基于convention over configuration的理念, 几乎零配置, api的设计也很精简, 很容易上手。 框架的松耦合和可扩展性好, 遵循node.js微模块的原则, framework本身只有很少的代码,所有component、库、工具都可以用npm module的形式扩展进来。任何第三方都可以根据自己的需要开发自定义module。 提供完整的开源MMO游戏demo参考(基于HTML 5)。 一个超过1万行代码的游戏demo,使开发者可以随时借鉴demo的设计与开发思路。 在线演示:http://pomelo.netease.com/demo.html 标签:开发框架  游戏框架
mqantmqant 是一款基于 Golang 语言的简洁,高效,高性能的分布式游戏服务器框架,研发的初衷是要实现一款能支持高并发,高性能,高实时性的游戏服务器框架,也希望 mqant 未来能够做即时通讯和物联网方面的应用。特性分模块机制基于 golang 协程,开发过程全程做到无 callback 回调,代码可读性更高RPC 支持本地和远程自动切换远程 RPC 默认使用 rabbitmq,未来可以添加更多种类的通信协议网关采用 MQTT 协议,无需再开发客户端底层库,直接套用已有的 MQTT 客户端代码库,可以支持IOS,Android,websocket,PC 等多平台通信现如今只有多进程的架构才能达到支撑较多在线用户,降低服务器压力,降低单点故障所带来的影响等要求,因此一个真正高可扩展的游戏运行架构必须是多进程的。然而在游戏的开发和运营也是按步骤阶段性进行的,尤其是现如今服务器硬件设备配置也越来越高的前提下,在游戏刚开始运营时单台服务器就足够支撑了,况且多进程部署所带来的运维成本也相对较高。mqant 的设计思想是在能用单台服务器时能让充分挖掘服务器的性能,而在需要多进程时再通过简单的配置就可以实现分布式部署。mqant 游戏服务器的运行架构mqant 服务器是按模块来划分功能模块的,例如 用户管理,在线聊天,战斗平台等等都应该划分为独立的模块模块之间通过 RPC 通讯,mqant 底层会根据实际情况选择 rpc 数据交互的通信渠道,在调用模块在同一个进程的情况下直接使用 golang chan 通讯,因此同进程内模块通信性能不受影响。 标签:mqant
©️2020 CSDN 皮肤主题: 1024 设计师:白松林 返回首页