海量数据存储.

GFS(GOOGLE自己的文件系统)阐述了这样一个思想:高性能的应用系统,并不全是由高性能的硬件服务器来支持的,甚至,他们有时更多的就是一些普通的服务器,而再甚至,他们可能是目前已经不是市-场主流的废旧机器,我们就是要在这些廉价的硬件基础上,通过我们的架构设计和软件设计完成可观的高性能应用,这才是我们所应该追求的目标,也是符合绝大多数网络-公司发展现状的选择,因为网络应用系统所承载的未来用户数是不可预期的,它只会不断增大.

chunk server 与 master server之间的分工,让我很受启发.简单地说,chunk server才是负责作真正逻辑的地方,而master server只是作了一个中介者,传递了一个信息而已,在具体的应用环境中,GFS client会向master server询问所要查询的数据文件在哪个chunk server上,然后GFS client就会与chunk server之间直接进行通信.

说到QQ的架构,我想我们现在更多的是站在自己已有的知识架构上去想象和理解它,或者说,这个讨论的主题是这样更为合适些:"如果让你作QQ的网络架构,你会怎-么作?"不然,当我们在这时煞有介事地讨论QQ架构的时候,腾讯的朋友看到了,可能会觉得我们讨论的与他们实现的差别太大.所以,我想,我下面的发言内容,将会-以这个主题来进行:如果让我来作QQ的架构,我会怎么作?

OK,现在我就把自己当作是一个QQ架构的设计者,我想象一下我会怎样在廉价的硬件服务器基础上去搭建这样的一个海量用户的网络应用系统.

在讨论问题时,我喜欢把问题细化.我们先看一下QQ在聊天(请注意:先只谈聊天)方面具有哪些大致的功能.对于一个网络聊天程序而言,它会具有以下大致功能:
1.账号管理(包括注册,登录验证等)
2.好友管理(包括好友的增,删,黑名单的增,删)
3.消息通知(用户上下线信息的转发,离线消息转发)

总体而言,我把QQ系统的设计难点归纳为两个:一是应用服务器如何部署,二是数据库如何部署.下面,是我的设计思路.

我的基本设计思想是:把QQ号按分段的思想进行管理(比如每100万是一个号段),每段是一个单独的QQ管理集群(暂且称为QQ server cluster),每个集群之间通过分布式架构支持海量用户在线.同时,会有一个全局唯一的QQ master server存放全局索引信息,这些信息将主要包括:号段所对应的服务器信息及状态. QQ cluster的主要组成,将同时包括:应用服务器(称为QQ chat server)和数据库服务器(QQ db server).我的可扩展架构设想是:当发现现有的用户数已经接近饱和状态时,只要增加一个相对独立的cluster,并把这个新的cluster的相关信息-注册到全局唯一的QQ
master server上即可.

每一个QQ server cluster应该提供哪些基本服务:
1.对于客户端,每个cluster是一个相对独立的逻辑组,它承担了用户需要服务器支持的大多数逻辑,比如:好友上下线消息通知,离线消息转发等.
2.同时,对于其它的cluster,要向它们提供这样的接口:好友在线状态查询,用户详细信息查询等.
3.为了实现P2P,还要打通两个客户端之间的UDP通信通道.
4.当客户端选择采用TCP进行通信时,还要负责消息的转发.

那么,每一个cluster里的db都存放了哪些信息呢?
1.存放属于本段用户的详细个人资料(包括除了必要的昵称信息等之外,还包括诸如:年龄,住址等的详细信息)
2.存放好友名单及黑名单(而在这两个名单中,在本地的db上应该只包括必要的基本信息:好友QQ号,好友昵称等)

当客户端登录时,客户端首先只能获得好友的简单信息,如果要想获得详细详细,就需要向本号段的cluster查询,如果cluster发现好友的号不在本号段内-,它会向其它cluster查询好友的详细信息(当然,这里的查询方法也是有多种方式的).

说到这里,还有很重要的一点,QQ的登录又该如何来处理呢?

1.首先,我会设置若干个(假设n个)对外开放的登录域名(比如login01.qq.com~login08.qq.com),这些域名中的每一个是可以同时-指向多个登录服务器(称为QQ login server)IP的,这样可以有效分担连接负载;
2.当客户端连接到login server之后,login server将对用户进行账号认证,成功后,会向客户端发送一个cluster server的ip,将客户端引导到cluster上去;
3.一旦客户端连接到cluster上成功后,所有的逻辑就由cluster来控制了.

当然,这里仍然还有很多细节问题要考虑,比如:对于这样的分段管理,每个cluster中的QQ chat server可能一个还不行,那这些chat server之间就要考虑还要加一个chat master了.不过,这样的话,分层是不是多了一点呢?还有待更进一层的细想,等我想清楚了详细设计方案的时候,会以附件的形式配以图表发上来,此文全当一个-引子.
象QQ这样的规模是采用分布构价的,有点象DNS服务器不是完全一样，但是可以用来理解巨大的访问量可以被复数的服务器分担。QQ的服务器也应该分DS、NS、-SB三种或其他若干，其实就是在实际应用中服务器设置的比例不同,我不知道非会员是否服务器需要记录聊天记录如果不要NS负荷也不大，在线也不用实时连接的这样-NS的负荷就大幅度下降了。而P2P是QQ用户之间交换数据于服务器无关忽略不计。而离线问题，只有在一位用户已经不在线的情况下，才向服务器发送聊天记录，或-者该用户是会员在向对方发送记录的同时在向服务器发送记录，这样服务器只需要处理会员的聊天记录和暂时无法到达的聊天记录。一台服务器用10万的并发流量来说（-理论）,而且10W个用户并非同时向服务器发送记录。用户登陆由DS NS负责的，通知到所有的好友。这个由其他服务器负责，登陆、离线发生的频率更加稀疏。这样负载不会很大。其实不够了再加服务器。关键是构架可以扩展。对于数据-库我觉得他们是采用分布式数据库。QQ对用户没有汇总式查询。将一些用户的数据放在树的某的节点上。可以把每个节点设置成数据服务器。这样就把查询量分散了。所-有数据并不在一台服务器上，QQ应该是分布式的因为理论上不需要汇总数据，除非需要高效的汇总查询