关于JAVA开发WEBGAME的架构

Yahle的blog:

http://www.cnblogs.com/yahle/category/122544.html

在yahle的blog看到其对webgame架构的一个构想,假设这个构想要用java来实现的话,有几个方面想请教下大家


以下是yahle的原文:
=========================================================================================
1 体系结构
1.1 传统的网站的架构
传统的网站一般都是以N层结构一般N为3,就是我们常说的三层架构。
3层架构分为数据层、业务逻辑层、页面显示层。
1.2 WebGame的架构
WebGame可以看作是网站和游戏的结合体,因此它具备了这两类系统的特性。我们不但可以把WebGame看作是一个网站,也可以把它看作是一个网络游戏。
的网站是B/S结构,网络游戏则是C/S结构,WebGame则是这两者的结合我们暂且称之为B/C/S结构。既在用户眼里,它是一个通过浏览器范围的网站。在服务器系统里,它又是一个传统的C/S结构的网络游戏。

从上图分析,用户通过浏览器访问服务器的时候,首先是访问网页服务器,如windows平台下的IIS,linux下的Apache。在通过网页服务器,以某种特殊的方式(分布式访问,如.net下的remoting)去访问游戏服务器,通知游戏逻辑服务器执行玩家操作,并从游戏逻辑服务器里获得游戏相关的信息,或者直接通过访问数据库而获得游戏数据。

1.2.1 为什么要将服务器分为游戏服务器和网页服务器
网页服务器的特点是触发执行,及当有用户访问网页的时候,才会执行该网页的程序代码。而我们常见的WebGame(Ogame,Travian)这些游戏实际上是需要24小时不间断执行的,因此网页服务器的执行方式并不适合与游戏。因此我们另外需要一个应用程序来执行这些24小时不间断要做的事情。这也就是我们需要增加一个游戏服务器的原因。
Webgame现在已经开始需要进入大统一服务器时代,每个游戏区域容纳的玩家数量将从现在的几万人发展到几十万人,因此在新的背景下,webgame如何处理大量用户的请求将成为问题。目前一台asp.net做的weggame服务器每秒能处理500~1000个页面请求,按照每个玩家每隔3~5秒做一次页面操作(页面请求),一台服务器能承受2k~4k的玩家在线,对于一个只有几万人的策略游戏来说,已经是足够了。但对于一个未来将承载几十万人的游戏来说远远不够。

通过分析,玩家在游戏过程中,有80%以上的访问仅仅只是查看玩家在游戏里的状态,实际上真正会对游戏运行状态及数据修改的的页面请求不足20%。因此,我们可以将呈现页面和处理游戏逻辑的功能拆分为2组服务器:页面服务器和逻辑服务器。两者之间可以通过remoting的方式进行数据通讯。将服务器分离后,随着页面服务器的增加,页面访问能力能应该能提升4~6倍。在往上逻辑服务器就会出现访问瓶颈。解决方法可以让页面服务器在读取玩家数据时直接访问数据库或者增加一个对象缓存服务器。页面服务器只有在必要的时候(需要进行逻辑运算时)才访问逻辑服务器,而逻辑服务器在玩家数据发生改变后更新对象缓存服务器和数据库。这样就可以大大降低逻辑服务器的访问次数,使页面访问能力进一步提升,轻松突破万人在线。如果访问量还需要继续扩大,可以用httpd做前台负责相应图片以及css等静态文件。


========================================================================================

1, 这里游戏逻辑服务器,是否有存在的必要?还是说和其他web结构一样,在tomcat实例上面部署一个完整的分层结构?
2, Webserver和 逻辑服务器之间,使用remoting来通信是否会成为高并发时的一个瓶颈?内网之间的服务器,能否通过一个其他的高效方式来连接?
3, 如果要用java开发这个游戏逻辑服务器,可否用spring 搭建一个socket server来实现?有什么好的实现方式?

4,假设采用flash作为客户端,纯粹基于http的话,flash可以通过xmlhttp和webserver的jsp进行通信。不要求纯粹的http的话,也可以用sokcet和webserver进行通信,不过这样的话不如直接和gameServer进行通信,而且socket相对http端口问题还是存在。如果该webgame主要框架就是大型聊天室的话,不知道采用哪种方式好点?基于纯http的话,就会产生大量的轮询请求,这种构架是否真能做到所谓万人同时在线呢?


 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MySQL Deadlock ERROR 1213 (40001)是一个常见的错误,通常发生在高并发的情况下。这个错误表示在一个事务中出现了死锁,也就是两个或多个事务相互等待对方释放资源的情况。下面是排查这个错误的一般步骤: 1. 查看错误日志 首先,查看MySQL的错误日志,以了解死锁的详细信息。可以使用以下命令查看错误日志: ``` sudo tail -f /var/log/mysql/error.log ``` 2. 查看死锁信息 在错误日志中,可以看到死锁的详细信息,包括哪些事务参与了死锁、哪些表和行受到了影响等。可以使用以下命令查看当前的死锁信息: ``` SHOW ENGINE INNODB STATUS; ``` 3. 分析死锁原因 分析死锁的原因非常重要,因为只有找到原因,才能采取相应的措施来避免死锁。通常,死锁的原因包括以下几个方面: - 并发访问同一行数据 - 事务执行顺序不当 - 事务中使用了不同的锁类型 4. 解决死锁问题 解决死锁问题的方法也有很多种,根据死锁的原因不同,采取的措施也会有所不同。以下是一些常用的解决方法: - 优化SQL语句,减少事务执行时间 - 使用合适的锁类型,例如行锁、表锁、读锁、写锁等 - 调整事务隔离级别 - 对于高并发的场景,可以考虑使用分布式数据库或者缓存等技术来降低单个数据库的压力 综上所述,排查MySQL Deadlock ERROR 1213 (40001)错误需要综合考虑多方面的因素,并采取相应的措施来解决问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值