WebGame游戏服务器技术要点

(一)服务器技术实现方案选择的问题?

(1)选择标准WebServer+CGI开发(偏轻)
【优点】
    1)快速开发:WebServer都是现成的,如:Nginx和Apache;CGI程序能也快速编程;
    2)灵活开发:整个后台服务可由多个CGI程序组成,一个CGI程序可以对应一项或多项业务功能,增加新功能时则增加新的CGI程序即可;
    3)不停机更新:部署新的CGI程序,不影响已运行的CGI程序;
    4)可适合处理SNS类玩家异步(离线)交互数据的情形;
【不足】
    1)CGI程序如果过多,可能会加大维护的难度;
    2)业务需求如果要涉及到多个CGI程序之间的通信,即有状态的关联依赖,可能会有较复杂的逻辑和可能的性能瓶;
(2)选择自定义通信服务器+GameSvr开发(偏重)
【优点】
    1)可应对复杂业务逻辑的处理,如:业务需求之间的关联依赖较深等;
    2)可轻松处理玩家之间同步数据的需求;
【不足】
    1)开发复杂度较大,需要较多的开发资源;

(二)游戏服务器Cache设计方案

【背景】
    1)游戏服务器cache数据可大大缓解数据存取时压力;
    2)多台分布式游戏服务器作Cache,可有效利用硬件资源;
【实现方案】
    1)基于共享内存的对象池设计;
【注意事项】
    1)数据一致性:对于SNS强交互类游戏,需要作多玩家修改同一数据的设计;
    2)数据同步的时机:根据业务数据的重要程度,分级设计同步时间,越重要的数据,同步时间越短;

(三)游戏服务器数据分类设计方案

【基本思想】
    把业务数据按重要程度进行分类,每类数据采用不同的存储和逻辑处理策略;
 
【应用说明】
    SNS类游戏需要重点考虑

(四)游戏服务器全局锁的设计

【背景】
    1)同一玩家数据会被多玩家修改;
    2)某一Cache数据会被多个应用修改;
【方案一】:热点数据分布在各个游戏服务器的Cache中
    1)数据被修改点(热点数据)设置一个全局Seq,如:玩家数据修改,则在玩家身上设置一个Seq;
    2)当Client读热点数据时,则直接返回数据给Client,并将Seq一齐带上;
    3)当Client写热点数据时,会在写数据请求里带上上次请求获得的该热点数据的Seq,热点数据的处理逻辑先比较写数据请求的Seq,是否与当前热点数据的Seq一致,若不一致(该请求来之前已被其它Client修改过),则有如下两种异步处理方案:
        1. 直接报错给请求Client,此时Client可能需要提示玩家重新刷新浏览器;
        2. 返回当前最新热点数据给请求Client,Client需要重新处理一遍之前的业务逻辑,再提交写数据请求;
    4)每次写热点数据成功后,热点数据本身的Seq加1;
    5)数据修改的逻辑统一在热点数据所在的游戏服务器处理;
【方案二】:热点数据集中在一个全局公共服务器的Cache中
    实现方法与【方案一】类似
【两个方案的比较】
    1)【方案一】:Cache分布在每台游戏服务器中,可以有效利用硬件资源,但SS交互逻辑复杂一些;
    2)【方案二】:可以减少一些SS协议的交互,但需要单独的全局Cache服务器;
【注意事项】
    1)需要分别考虑玩家在线和离线数据的修改;

 (五)如何有效利用机器的多核CPU

1)多个通信服务器+1个游戏服务器;

    2)多个通信服务器+多个游戏服务器;
 

(六)如何评估网络I/O的瓶颈

    1)网卡(1000M bit/100M bit)本身的极限处理能力:理论处理包的数量:网卡带宽[1000M bit]/(最小包大小[64Byte] * 8);
    2)游戏业务对包的数量较包的大小更敏感,因为每个网络包在CPU处理时,会产生IO中断,因此,常用的策略是,合并多个请求包为一个包,提高带个包的信息量;
 

(七)深入了解MySQL的存储性能

    1)Mysql5.5+InnoDB1.1;
    2)Mysql的Cache解决方案;
【声明:若有摘录,请注明来自http://gameislife.info/archives/109】

发表评论

电子邮件地址不会被公开。 必填项已用*标注