QQ的架构讨论

QQ的架构讨论

 

网址：http://groups.google.com/group/dev4server/browse_thread/thread/0d72668d11c4886b/a6d202489cabf285#a6d202489cabf285

 

hi, all:
    top说他那里现在无法访问google网站, 不知道各位能否正确访问?
    下面是代top发的他关于QQ架构的理解:

top(木……) 说:
    一个必要考虑的问题是登陆时要以地域就近的原则,提供最快的网络响应,所以实际服务应用层应与数据层耦合的.分段式管理可以运用在数据存储的分布式构架中,这是一个数据层的概念,即如何有效的组织分布式数据.因为QQ在实际操作中在即时通讯中需要查询的数据量极少,写入数据层的信息量在所有通讯量中也占很小的比重.所以考核负载可从服务应用层和数据层两方面来考虑.服务应用层主要考虑用户的时实性与服务器负载平衡问题.数据层主要考虑如何提供更有效的分布式存储方案.即采用黑盒的想法,我们在设计服务层时,可意想的认为我们象一个虚拟的数据服务器提出数据请求必然会获得响应.至于服务层如何实现认为是一个黑盒,无须考虑.接着我们只需考虑在服务层的各服务器上如何存储转发暂存取得的数据以提高效率（减少向虚拟数据服务器的查询量,减少与客户端的通讯量,减少服务层各服务器之间的通讯量为目的）

top(木……) 说:
    其实我们只是说了一个大框架,其实在服务器的配置功能的划分服务层网络的构架上有很多细节问题.这些要针对实际运用需求而分别配置,所以,在设计之前最好先将需求梳理归纳.不过这个工程玩大了，呵呵

    我(sodme)的观点:
    与top想法一样, 数据层是个黑盒, 相对独立. 至于其内部, 采用分段管理.

On 2/19/06, 大宝(sodme) <sodme.... @gmail.com> wrote:

> 关于我的思路的优缺点:

> 优点是:
> 这样的思路类似于现实生活中电话号码的管理,它是分地区的,也就是分段的,我个人认为这样以后的扩展相对来说可能简单一点.

> 缺点是:
> 作为一个解决方案,这个思路并没有充分考虑到根据当前用户在线数来实现动态平衡的目标.比如说1~100万内的在线人数很少,而100万~200万号内在线的人很多,那么这两个不同号段的服务器负载就会完全不一样,从而浪费了服务器资源.

> 克服缺点的办法:
> 如果要实现完全根据当前在线用户数来实现服务器负载的动态平衡,那就得将chat server与db server拨离, 让chat
> server这一层完全按动态均衡的思路来作,
> 而db这一块的工作,可以抽象成一个数据管理层来作,但具体的用户数据存储仍然采用分段存储的方式,为不同的号段作不同的数据库存储. 而chat
> server这一层的思路, 基本上也是master + chunk的方式,客户端最终仍然是与chat保持长连接.

> 在 06-2-19，大宝(sodme)<sodme.... @gmail.com> 写道：
> > 很高兴能看到大家积极讨论,这两天针对于这个问题,我也有了一些自己的初步想法,拿出来与大家共享.

> > 前两周,听杭州研究院的同事介绍了海量数据存储方面的东西,这个讲座对我还是有点启发的.其中,在介绍有关GFS(GOOGLE自己的文件系统)的内容时,他阐述了这样一个思想:高性能的应用系统,并不全是由高性能的硬件服务器来支持的,甚至,他们有时更多的就是一些普通的服务器,而再甚至,他们可能是目前已经不是市场主流的废旧机器,我们就是要在这些廉价的硬件基础上,通过我们的架构设计和软件设计完成可观的高性能应用,这才是我们所应该追求的目标,也是符合绝大多数网络公司发展现状的选择,因为网络应用系统所承载的未来用户数是不可预期的,它只会不断增大.

> > 如果有需要的朋友,我可以给你们发一份当时讲座用到的GFS资料.在谈到GFS的时候,我觉得对于我而言,收获最大的就是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了.不过,这样的话,分层是不是多了一点呢?还有待更进一层的细想,等我想清楚了详细设计方案的时候,会以附件的形式配以图表发上来,此文全当一个引子.

> > 2006/2/19, top(木) <zergseptem... @gmail.com>:

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