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

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系统，成本偏高，研究的较少。

实际的应用中，还需要一些性能测试数据的配合和运营数据，才能得出比较优化了的架构。

谢岱唛 2008-06-23 22:46 发表评论