织梦CMS - 轻松建站从此开始!

罗索实验室

当前位置: 主页 > 啰嗦IT > 架构与思路 >

大规模多人在线系统的思考

罗索客 发布于 2008-08-22 16:47 点击:次 
目前的互联网应用,一个突出的焦点就是用户量非常大,给服务器开发和设计带来了许多挑战,这里想谈本人对这些问题的思考和体会.
TAG:

目前的互联网应用,一个突出的焦点就是用户量非常大,给服务器开发和设计带来了许多挑战,这里想谈本人对这些问题的思考和体会.

大规模的多人在线系统,我接触的比较多的,有一下几种:

1. p2p 系统,p2p直播软件.

在播放比较热点的节目时,会遇到数十万甚至上百万人同时观看的问题,由于p2p的特殊性质,一般不会去统一保持用户信息,
服务器需要的只是给p2p客户提供节目源, 以及为p2p 客户查找其他p2p节点提供tracker服务。所以p2p在对付大规模的人数在线时,只要简单的添加tracker
和界目源即可。这种多人在线是在软件设计时需要考虑的最少的一种。

2. 网游服务器系统。

网游服务器对付这种问题的方法是, 把整个用户空间隔离为n个世界, 譬如mmo中的某区某服, 或者休闲游戏中的房间。
当用户量不断增加时,只需不断的增加服务器组和房间服务器即可。 唯一麻烦的地方,就是在于一个用户的统一认证和经济系统这块。由于这两块负载不大,
逻辑也相对简单,实现起来难度不太大。

3. IM 系统

im系统的问题就在于,他的整个用户空间,是完全统一在一起的,没法采用区服,房间的方式来隔离。 当im服务器的在线人数突破10,20万之后,
设计一套集群系统就是势在必行的了。这个时候单台逻辑服务器,单台数据库已经无法满足系统的性能要求了。 必须采用把数据,服务,分散在各个物理服务器内,
采用集群的方式来进行管理。
当并发人数在100万以下时,我设计的一种做法是, 后台的db部分,采用一台或者几台类似mysql proxy的服务器来统一进行访问。
db 内的数据采用按照数字账号分段,或者按照某种hash 算法进行 分块的存储。 前台的逻辑服务器,不直接和db 打交道。而是通过DB Proxy来访问数据库,
这样可以保证数据库的存储策略不透明,可以于前台的逻辑部分进行独立的变化,前台逻辑服务器,连数据库的表结构都不需要知道,只需要发送请求,去DB Proxy请求指定条件的查询和结果集就可以了。 而逻辑服务器之间,当100万人以下同时在线时,逻辑服务器的数目并不会太多。这些逻辑服务器之间可以直接互联。每个逻辑服务器负责一段数字账号的逻辑处理,每个逻辑服务器向其他服务器通报自己负责的数字段范围。当遇到不是本服务器能处理的请求时,譬如给其他逻辑服务器上的用户发送文本消息时, 直接转发给其他逻辑服务器即可。
DB Proxy 在db server前端,单台DB Proxy的处理能力毕竟有限,这里可能还要考虑每几台DB服务器就配置一台DB Proxy。每几台前台逻辑服务器共享一台DB Proxy. im 系统的数据库访问非常频繁,在im系统中实现数据库cache,对于性能的提高是非常有帮助的。前台逻辑服务器,也应该尽量的cache数据,减少访问DB
Proxy的次数,以提高系统的整体性能。

这里为了把客户端指引到连接指定的逻辑服务器,前台需要有Dispatch 服务器,提供逻辑服务器的地址,端口。im 客户端连接逻辑服务器前必须查询Dispatch Server,来获知逻辑服务器地址。 为了增强灵活性,可以设置一台中心服务器,。来动态的提供逻辑服务器,DB Proxy等的配置信息。以及方便进行服务器组的后台管理。
这里的设计是针对udp 的im 系统来的。tcp 的im系统,成本偏高,研究的较少。
实际的应用中,还需要一些性能测试数据的配合和运营数据,才能得出比较优化了的架构。

(韦国华)
本站文章除注明转载外,均为本站原创或编译欢迎任何形式的转载,但请务必注明出处,尊重他人劳动,同学习共成长。转载请注明:文章转载自:罗索实验室 [http://www1.rosoo.net/a/200808/7104.html]
本文出处:网络博客 作者:韦国华
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片
栏目列表
将本文分享到微信
织梦二维码生成器
推荐内容