2000以上并发用户的游戏服务器框架

tfisher

对于游戏服务器设计者而言，一台游戏服务器能支持的并发用户越多越好。首先可以大大减少硬件的投资，其次可以降低服务器管理的成本，第三，如果使用的是WINDOWNS系统，还可以大大减少软件的版权费用。当然使用Linux就没有这种问题。
目前，据我获得的不完整资料，一般在线游戏的一组服务器能支持的并发用户大约在600左右，若每个用户每秒发出两个请求，则一组服务器每秒处理的请求仅仅为1200。这无疑是一个相当低的性能。根据我的经验，一台DELL 2650 2.0G 双XEON的服务器可以非常轻松地达到并发2000用户每秒处理4000个请求。
以下我简要地介绍一些服务器的要点和框架(见附件)
[em19]

sujialin

看来你对网络游戏服务器方面的知识还了解甚少,游戏服务器在设计时就要按最大网络流量来设计,你所说的一秒种两个包显然太少.游戏服务器不单是要处理客户端来的IP包，更多是要在服务器在保持整个游戏数据的最新COPY，也就是说所有的逻辑判断都要在服务器上进行然后返回结果，500-600个用户基本上能让服务器CPU在90%左右的负载，你所谓的2000用户一定会让你的游戏客户端全部在玩慢动作游戏.

tfisher

给你一点实际测试的数据：2000个连接,文中提及的服务器器,CPU利用率60-70,每秒处理的请求数13000。

sorceress

现在搞网络游戏的好像都挺富的
大约不太在乎服务器的钱吧
很多会搞的，服务器还是电信什么的提供的
自己根本不化钱

又，
服务器好像不仅仅是要收发数据这么简单吧

..

sea_bug

这个关系实在太多方面，网路带宽也会服务器在接收相应的速度和性能，可能我们所能讨论的只是在一些理论数值的基础之上。

SevenCat

Re: 2000以上并发用户的游戏服务器框架

给你一点实际测试的数据：2000个连接,文中提及的服务器器,CPU利用率60-70,每秒处理的请求数13000

这个服务器端做了些什么事情，要不要进行各项判断？假如要进行判断和计算的话，CPU60－70是不太可能是事情。

我的模型差不多就是这个样子。用线程池来处理需要时间长或者有阻塞的处理，用select来管理所有套接字的读写。
一开始基本上将所有的游戏资料都从数据库中读出，在运行过程中很少操作数据库，用户在开始和最后读写一下用户数据库。


服务器端基本上不用new,malloc,我从连接到packet全是用的pool,

谜の名侦探

我想,服务器程序的重点在网络传输效率和稳定性上,还有就是数据处理效率.
接受网络请求和网络发送的那部分,我是用完成端口做的.基本上CPU越多,效率越高.
线程,我用的很少,基本上是跟CPU数量挂钩.线程池是用不到了,因为线程管理很容易应付少量线程.
关于数据库操作,使用外部服务器来做,之间通过千兆网来连接.
内存管理,没有用内存池,因为,既然运行时不用动态分配内存,那就不需要那么复杂的东西.
平台使用WIN2000,
在P41.8/512上基本很流畅.
因为目前测试的人数可能较少吧,所以,基本上CPU占用率为0, 内存占用为 90M

SevenCat

TO：楼上
能讲一下广播包的做法吗？完成端口我也用过，不过觉得广播包太多的时候完成端口蛮烦的。

我内存池主要是发送包的那块用的。

谜の名侦探

每个角色有一个发送队列,
逻辑处理时产生的消息放到这里,
当一个发送请求结束的时候,或者,到达最大的消息积累时间的时候,
从发送队列取出最大量的数据,发出一个SEND请求,
当完成端口处理完请求,发回一个完成信号,进行下一次请求.

无论是什么消息,
都在逻辑处理中进行发送,广播包是在一个刷新循环中进行设置的,存在一个全局的广播包队列,每次刷新的时候,取出N条消息,然后,放到每个角色的发送队列里面.
基本上,内存拷贝多快,效率就多高了.

基于未来考虑,会采用多个线程承载不同数量的人和地图,还有怪物,外部采用N台物理服务器承载一个游戏世界.

关于效率方面,现在还只是内部测试,未来什么样子,还有待测试...

SevenCat

我的SELECT也是一个发送队列。

本来想考虑完成端口的，后来想到比如一个人的移动啦，讲话啦，之些广播包都要lock住被广播的所有人员，还有对特定的某人讲话，还要查找并LOCK再ADDREF。就改用了SELECT。

主要觉得广播包太频繁了，老要LOCK不太好。

现在我的广播就是每次SELECT开始的时候搞一下，基本不会用到临界区。而且广播包用的是引用计数，每个广播包的内存只要一个。