鸽鸽经验网

 找回密码
 立即注册
搜索
热搜: 经验 技巧 心得
开启左侧

【案例】如何用JAVA开发游戏服务器

[复制链接]
msmkmm2012VIP会员 发表于 2019-7-13 21:16 | 显示全部楼层 |阅读模式

背景  对于一台服务器而言,一个非常重要的方面就是它的“可用性”,即所选服务器能满足长期稳定工作的要求,不能经常出问题。其实就等同于Sun所提出的可靠性。因为服务器所面对的是整个网络的用户,而不是单个用户,在大中型企业中,通常要求服务器是永不中断的。据美国服务器租用介绍在一些特殊应用领域,即使没有用户使用,有些服务器也得不间断地工作,因为它必须持续地为用户提供连接服务,而不管是在上班,还是下班,也不管是工作日,还是休息、节假日。这就是要求服务器必须具备极高的稳定性的根本原因。

       

        A亲,俺们是做页游的

       

        B土豪,我们做朋友吧!

       

        随着游戏市场的兴起,特别是网游手游的崛起,对游戏开发技术的需求越来越多。网游开发是一个庞大的体系,总体来说是客户端与服务器端。客户端是玩家接触的游戏图像显示端,服务器是处理游戏运行中的各种数据,由于一台或多台服务器要支持众多玩家的请求,所以服务器的性能高低决定了同一个游戏的用户数量。
       

       

       

        开发语言

       

        网游开发可以选择好多语言,比如说++++,,,,,,,在这里小编推荐大家选择做服务器开发语言,原因主要有以下几点

       

        1J是跨平台的,方便部署;

       

        2J是安全的高级语言,可以提高开发效率;

       

        3J是面向对象的,代码可以重用;

       

        4J的分布式应用。

       

        服务器硬件

       

        CPU至强六核E5-2620 2

       

        内存8G DDR3 ECC

       

        主板ASUS Z9PA-D8

       

        硬盘ST 300G SAS 点击右侧QQ询价

       

        服务器架构

       

        服务器架构主要有以下几个模块

       

        登录服务器

       

        负责处理玩家登录的请求。一个登录服务器对应多个游戏逻辑分区。当玩家登录的时候,登录服务器向用户中心服务器发送登录信息。请求对登录信息的验证。通过验证之后,返回分区地址,之后,客户端与登录服务器断开,连接到游戏逻辑服务器。登录服务器是一个单独的J运行程序,当访问量增加大,可以增加部署到多个物理服务器上面,均衡负载访问压力。它通过使用J的NIO(非阻塞)方式与客户端进行通信。通过用户中心服务器提供的接口访问用户中心,进行数据处理。

       

        逻辑服务器

       

        对玩家的操作进行逻辑处理。逻辑服务器是整个游戏的心脏。它的工作效率直接影响玩家在游戏中的体验,所以对它的要求是速度,快速返回处理结果。为了达到满足要求的速度,逻辑服务器的大部分操作必须在内存中操作,避免IO操作,IO操作可以放到另外的线程中进行。说是大部分,是因为玩家在次登录的时候可能会从数据库加载所要用到的数据。在图中,大家看到了缓存,缓存的作用是把数据放在内存中。当玩家退出时,它的数据也会在缓存中保存一段时间,在一定时间内,玩家再次登录,将不会再重新从数据库加载数据。在逻辑服务器中对数据库的操作可以先放入一个J队列中,再另起一个J线程负责从这个队列取数据,并发送到数据库服务器,这是使用J的阻塞队列,快速实现一个生产者消费者模式,数据生产与处理相分离,这样既减轻了逻辑服务器的压力,也保证了数据处理的效率。逻辑服务器的日志也不在逻辑服务器入库,同样的发送到日志服务器处理。还有一种方法是以一种特定格式的方式,记录到本地文件中,再启动一个进程,读取这个文件,然后入库。

       

        用户中心服务器

       

        现在很多游戏都对用户进行了集中管理。这方便了对用户提供更好的服务,比如充值活动礼包领取新游戏导入用户等。有的游戏可能会用用户中心的数据发展游戏运营平台。这部分与游戏逻辑服务器分开,也减少了游戏逻辑服务器的压力。用户中心采用JW开发,它对游戏服务器只提供特定访问的接口,把数据与逻辑分离开来,方便管理,以及分布式部署,增强了架构的灵活性。

       

        充值服务器

       

        充值是游戏收入的方式,所以这个功能必须流畅,毫无压力。如果由于网络或服务器性能原因,导致玩家充值不了,会直接影响收益的。所以充值服务器部署在一台单独的物理机上面,也可以多个分区使用一个充值服务器,这要视游戏人数而定。

       

        数据库服务器

       

        负责对数据入库及更新的操作。把这部分操作从逻辑服务器分离出来,是为了减轻逻辑服务器的压力,减少逻辑服务器资源的占用。而且,如果逻辑服务器突然宕机的话,也能尽量保证数据少丢失。为了保证对数据的更新是顺序性的,这里把数据入库的操作使用队列单线程化。逻辑服务器与数据库服务器通过J的TCPIPS进行长连接,而且为了防止由于意外原因导致连接中断,在逻辑服务器与数据库服务器之间加入了一个心跳连接,这样短暂的中断可以被很快恢复,防止数据的丢失。

       

        日志服务器

       

        处理玩家日志的入库。日志入库方便游戏运营管理游戏,统计玩家信息。当玩家人数比较多的时候,日志也会占用很多资源。所以把日志从逻辑服务器也分开了,因为日志只是插入操作,所以可以开几个线程进行并发插入到数据库。线程数要根据你数据库的连接池的连接数进行设置,要不然会导致连接资源被占完,数据插入不了数据库。

       

        这些模块都是分开的,可以灵活地分布式部署到不同的物理服务器上。只需要修改一些配置文件即可,非常方便。

       

        注意事项

       

        在游戏服务器开发中,有几个需要注意的问题。

       

        通信协议

       

        开始的时候,我们为了快速开发,采用了JSON的变长协议处理方式,即把要传送的数据编码成的字符串,再把字符串转化为字节数据,传输过程中包的总结构为总包长度(四个字节)+消息长度(四个字节)+消息体,即数据长度,个字节。这样做的好处是可以快速开发,缺点是在传输过程中无效的字节太多。而且这部分完全可以用代码自动完成。后来我们采用J的反射机制,从定义好的描述协议文件中读取传输的内容格式,自动化生成传输的对象,在发送信息时,根据这个对象再把数据转化为二进制的数据流,解析的时候,同样也根据的描述文件,按顺序读取数据并转化为对象的JB对象。如果时间充足,在游戏开发前期应该把这个做好。

       

        多线程并发

       

        游戏服务器是一个多用户的环境,其中多线程是必不可少的,它可以提交程序对CPU的利用率,提高处理性能。但它也有一个致命的缺点,是在多线程下,数据同步的问题。因为在目前多核CPU下,线程算得上是可以并行执行的了。比如竞技场中的排行榜,每个玩家的名次变化都会对排行榜进行操作。如果不考虑数据同步的话,每个玩家可以随意更新排行榜,那这个排行榜的数据会非常乱,名次也不正确。这个时间需要保证在一个玩家更新排行的时候,其他玩家不能更新,只能阻塞等待。一般有两种方法可以解决1直接使用锁,当一个玩家更新排行榜时,使用锁锁定排行榜集合,让其他玩家不能再对排行榜操作,J有自带的两种方式,非常方便,一个是L接口,一个是S;2使用乐观同步,这种方式需要自己额外实现,之所以说是乐观,是因为它有可能执行失败。原理是当我取数据时,获得一个数据的一个版本号,而当写入数据时,如果版本一致,可写入,如果版本不一致,需要重新获取数据,执行逻辑,直到版本一致后写入。可以设定重复次数,达到这个次数后,还没有成功判定失败。根据我们目前的运行环境,我们采用了种方式。

       

        均衡负载

       

        一台物理服务器的处理能力是有限的,对于可能支持数据众多的游戏服务器来说,分布式部署和动态添加服务器是不可缺少的。在逻辑上,可以把需要集中处理,与逻辑运算关系不大的模块单独部署。比如登录服务器地图服务器聊天服务器数据库服务器等。像我们把登录服务器和数据库服务器分离开是为了减少逻辑服务器的压力。

       

        缓存的设计

       

        起初,为了快速敏捷开发,我们采用了一级缓存方式,即图1中的R缓存,它是一个分布式的缓存,内部通过S连接。在玩家次进入游戏的时候会把玩家数据从数据库加载到R缓存之中,再取数据只从缓存中取。后来为了更加提高处理速度,增加了二级缓存,即内存缓存,利用J提供的ML等集合保存数据,开发了一个基于内存的缓存构架MCT,对外只提供操作接口。由于是直接从内存中读取或写入数据,其速度相对于R提高大约20%左右。
回复

使用道具 举报

免责声明|联系我们|鸽鸽经验网 ( 豫ICP备17031277号 )

GMT+8, 2019-10-14 16:17

Powered by Discuz! 7.0

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表