• 游戏服务器架构


    单服务器:单线程无阻塞套接字,主线程每隔一秒更新一次所有对象。数据持久化:本地磁盘。

    缺点:玩家下线时或者定时将数据存储在EXT磁盘中,这样的存储在逻辑上是没有问题的,但是玩家频繁的上下线会导致服务器频繁的I/O,导致负载越来越大,以及EXT磁盘分区比较脆弱,稍微停电容易发生数据丢失。

    多服务器:拆分成多个游戏逻辑服务器(Game),每个游戏逻辑服务器负责一定数量玩家的服务。

    多类型服务器:

          数据库拆分:数据持久化 --> 数据库

          数据库代理进程 DB:在游戏逻辑服务器(Game)和数据库之间增加一个数据代理进程(DB),数据代理进程同时提供内存的数据缓存,缓存一些热点数据,减少数据库的I/O。

          内存数据库:Radis、Memcached。DB不再缓存数据,变为玩家上线时从数据库加载到内存数据库中,和定时将内存数据库中的数据存储到数据库中。

          逻辑拆分:聊天服务器(IM)、匹配服务器(Match)、排行榜服务器(Rank)   优点:降低耦合、分摊压力; 

                  保证数据一致性:拆分队伍功能成组队服务器(Team),将队伍数据放到一个地方去。 

          网关服务器 Gateway:客户端统一连接Gateway,客户端发送的数据由网关服务器转发到后端各个类型的游戏服务器。而各个游戏服务器之间的数据交换也统一到网关服务器进行交换。 缺点:扩展性差。

          全局服务管理器 Master:唯一。用于服务器之间消息转发;存储和管理所有服务器的信息(IP、容量、增删),Master需要与每个服务器进行连接,用心跳维护服务器是否处在可用状态。

          分布式消息队列:kafka、rabbitmq、nats。自定义分布式消息队列(如Master转成分布式Master)作用:将单点的消息队列换成分布式消息队列,以减轻单个消息队列的压力。

          服务发现:作用:通知新服务器加入。服务发现中心会将服务器A的信息广播给所有老的服务器,通知老服务器有新的服务器加进来,同时也会向新服务器A发送所有老服务器的信息。

                  本质:数据库备份。  难点:保证数据一致性。  解决:paxos算法及其简化版raft算法,工业级软件实现是zookeeper和etcd。

          负债均衡:分区分服(王者);

               大服务器(吃鸡):登录时自动选择登录服,所有人共用同一组后端服务器和同一组数据库。

                                                                    登录服务器:逻辑少,账号验证、角色创建、角色数据加载 ________负载均衡算法(最小分配)______>   网关服务器:逻辑处理和转发____________>  登陆成功,断开登录服务器  

               战斗服务器:客户端——网关——战斗,这样的方式战斗反馈会比较慢,所以让客户端直连战斗服务器。

    分布式:在之前的基础上,DB 和 Radis 也换成分布式。

    云游戏:

    • 传统部署:各个游戏服务器以进程的方式直接运行在操作系统上。 优点:简单直接,没有额外运算。  缺点:存在资源分配争夺。
    • 虚拟机部署:一台服务器运行多个虚拟机。 优点:各个虚拟机互不干扰。  缺点:每个虚拟机都安装了完整的OS,非常笨重。
    • 容器部署:Docker、Kubernetes。容器不需要额外安装OS。Docker使用Linux隔离技术(CGroup和Namespace)来隔离各个服务,并直接调用操作系统的系统调用接口。 优点:每个容器开销低、启动快、资源占用小。降低交付成本。

      工作原理:

        画面截取:GDI 抓图、BitBit、DDA(Desktop Duplication API)、IDD(Indirect Display Driver)、DXGI等等,DXGI是Windows系统中用户模式下最底层的图形设备接口,可以直接获取显示器的内容。

        音视频编解码:H.264已经在手机、平板和浏览器上支持。音频一般使用opus或aac来编码。最新的是H.265编码。

        数据传输:UDP适合流视频;KCP适合竞技游戏;Google的Stadia直接使用WebRTC传输音视频数据。

        画面显示与输入采集:通过SDL实现,收集后将数据传给服务器。

        云游戏延迟:网络延时:客户端操作数据----> 服务器 ----> 客户端接收到音视频流  总时间。  解决:边缘计算(根据每个边缘节点的延时和负载量来选择延时最低的节点进行服务)

              播放延时:客户端解码数据+显示到屏幕  解决:负延时(Negative Latency)技术(使用马尔科夫链预测玩家在未来几帧内的输入,并且渲染对应的画面返回给客户端,如果在错判时给出补偿(快速隐藏错误的渲染)并且调整输入渲染)

              处理延时:服务器处理客户端发来的命令+返回视频流  解决:vGPU(将GPU计算资源分割成多个块,并在图形处理中引入CPU,以弥补GPU计算资源的损失)

              据研究表明,游戏延时需要保持在150ms以下才会有一个较好的体验。

    ——————————————————————————————————

    参考:https://zhuanlan.zhihu.com/p/500831183

  • 相关阅读:
    内存不足报错
    curl Command Download File
    How to POST JSON data with Curl from Terminal/Commandline to Test Spring REST?
    IOS常用手势详解
    OC中的NSNumber、NSArray、NSString的常用方法
    如何利用autolayout动态计算UITableViewCell的高度
    对AFN和ASI各自使用方法及区别的总结
    转:你真的懂iOS的autorelease吗?
    文件管理(续)
    IOS文件管理
  • 原文地址:https://www.cnblogs.com/tomatokely/p/16382829.html
Copyright © 2020-2023  润新知