关于服务器的负载均衡

[Odysseus]

发信人: ecnegrevid (飞石世木), 信区: Mud_Builder
标 题: Re: 一般的mud最多可以上多少个人?
发信站: 一塌糊涂 BBS (Wed May 30 19:12:09 2001)


我是问能不能上到1000, 我编写程序时发现用现有的方法难以
实现好的进程间通讯,

大概的体系是, 上千个一般进程和若干个服务程序
一个一般进程和一个客户通讯, 并可以和任意一个服务程序通讯
一个服务程序可能同时要照管很多个一般进程的请求

如果用socket, 一个程序所管理的fd是有限的, 而且照看
大量fd很麻烦, 效能也值得怀疑, 这对服务程序很不利

如果用msq, 每个进程一个msq, 本来我以为是可以的, 但是后来
实际试验时才发现系统只能提供很有限的msq, 只有百多个, 这样
就需要若干一般进程共享msq, 可是问题在于, 如果一个一般进程
长期阻塞在输出上, 甚至异常退出, 就会导致msq爆满, 影响其它
进程. 没有合适的机制来判断一个进程耽搁了多少msg.

要么用shm加上sem, 这也很麻烦, sem的值可能因为反常退出而不
正确, 要么直接编写一个模块? sigh

【 在 lepton (大象,大象,你的鼻子为什么那么长?) 的大作中提到: 】
: faint 一两百就是大mud了
: 【 在 ecnegrevid (飞石世木) 的大作中提到: 】
: : 一般的mud通常可以上多少个人? 1000个人可以吗?


发信人: akuma (很不温柔), 信区: Mud_Builder
标 题: 关于服务器负载均衡
发信站: 一塌糊涂 BBS (Thu May 31 18:08:03 2001)

目前一些已有技术开发的网络图形游戏，比如联众游戏，虽然看起来是数万人同时在线
，但是事实上并不是真正的多人共同参与一个游戏，而是分成数个小用户组分别进行游
戏。这样，网络游戏多人参与的精神就被打了折扣。
我们的技术可以保障多用户的真正共同参与。当然，一台服务器的连接数量和计算能力
是有限的。因此，多服务器组件的负载平衡就成为我们技术的重要优势所在。见下图：
(略)
<1>服务器组件的实现
由于图形MUD游戏本身的特点所决定，我们在服务器组件的设计上采用伪负载平衡的方式
，即每个逻辑游戏服务器负责一个区域（区域概念可以理解为RPG游戏中的一个部分地图
）以及在区域中的用户所进性的行为计算。多个逻辑服务器的协调有主控服务器来完成
，同时用户的与游戏的握手也由主控服务器完成。
用户在区域之间的穿梭其"物理"实现是跨越不同的逻辑服务器，也即负载的服务器间转
移。
全部用户的数据信息集中存在于主数据库服务器当中，保证了用户数据的唯一性。而用
户在服务器上的数据完全存在于内存中，采用分时存服务器的方式进行数据存储。从而
带来了时间上的优势。
主聊天服务器负责控制整个服务器组件中用户的聊天行为。
<2>可预期的系统承载能力与硬件要求
作为一个多人的网路游戏，用户负载能力的扩展是我们所关心的，在上边我们已经讨论
过网络负担所决定的单台服务器承载能力，现在我们根据上图讨论服务器组件在计算量
上带来的优势。
从计算量角度分析，我们已经有的数据统计表明，一台中等性能服务器（物理概念上的
服务器）可以支撑两个到三个游戏服务器，每个游戏服务器（逻辑概念上的服务器）的
承载能力为1000人以上。
因此，综合计算负载和网络负载，可预期的单台服务器负载能力为2000人/台。
<3>所有上线用户实现真正的共同参与
根据以上分析，我们已经明白，从用户角度来说，他们所存在的虚拟世界－图形MUD是一
个统一的世界，不会出现服务器差异的问题。

发信人: akuma (很不温柔), 信区: Mud_Builder
标 题: 负载平衡的另外一个解决办法
发信站: 一塌糊涂 BBS (Tue Jun 12 21:57:56 2001)

我们以前提到过 用telnet方式实现负载均衡最大的问题在于重定向
因为在telnet方式下，无法象http方式一样方便的实现重定向
以前我们提到，可以用单独的客户端来实现重新login的过程

但是，如果是文字mud并且我们想使用通用的客户端比如zmud怎么办呢？


今天中午和olives突然想到，其实如果我们的login server 足够坚强
的话。完全可以在其上实现telnet proxy的功能，这样就可以象单独
客户端一样实现telnet重定向了。不过前提是。。。login server
足够坚强 足够坚强 足够。。。。 足够。。。