1、Q 的架构问题 -sodme 大宝 hi, all: 我把第一个问题选为：QQ 的架构。呵呵，题目是不是有点大？ QQ 现在的最高在线用户数是 1900 万，我们来讨论一下要作一个这样的架构如何来作更好，大家积极发言，这也是我这个周末为自己选择的思考题，呵呵。大家积极畅所欲言。 我们讨论的问题可以包括但不限于这些内容： .登录时的负载如何解决的 .服务器主要作哪些事，负载如何解决 .数据库负载如何解决 . - Arbow 我来这看热闹的，也没做过啥大系统，随便说两句啊:) 按照我们的设想，对于 3，是不会使用数据库来撑大访问量的，特别是一些不需要实时更新的数据，会通过一个的 Server 对数
2、据进行汇总，然后在数据库比 较空闲的时间段进行批量更新。而客户端查询相关信息，也不会直接查询数据库，而是直接连接 Server 来获取。对于这些 Server 群的负载，就有很多方 法了，没做过，就不纸上谈兵啦。 另外说说 Web 负载，根据 HTTP 协议返回的信息， QQ 是使用 Apache 来实现 Web 负载的，Apache 虽然定制非常方便，扩展性强，但是性能并不是最优的。Google 就实现了它自己的 WebServer GWS (Gmail 中是 GFE？) ，跟它的 GFS 紧密结合起来，性能做到最好。 好了，搬个小板凳看老大们发言啊_ -tingya QQ 的后台用的是 M
3、ySQl 数据库哦，呵呵，是不是不可思议啊？不过整个 MySqL 都是面目全非了，被 QQ 的人修改的不成人形。性能非常的高，尤其数据的读取和存储。 QQ 的服务器技术号称世界领先，呵呵， -Donald 只知道 QQ 的广告服务器是分省的，广告下发要一到两天，其他的就不知道了 登陆和登出确实是个比较麻烦的事情，要通知到所有的好友，所以用户数据必须是集中的，登陆有时候通知会失效，不知道是不是 UDP 的协议，听大家说说 - Roger Chen 以前对 MSN Messenger 协议有所研究，MSN Messenger 服务器可以分为三类：Dispatch Server(DS)、Notifi
4、cation Server(NS)、Switchboard Server(SB)。 DS 是 Messenger 登陆时首先连接的服务器。然后 DS 指定一个 NS 的 IP 返回给客户端，然后关闭连接。 Messenger 接着连接到得到的 NS IP 地址，所有的操作信息，比如添加好友、删除好 友，更名等等都是通过 NS 的这个连接完成。只要 Messenger 在线，该连接会一直保 持。 如果要开始对话，发起人发送指定指令到 NS，NS 返回一个指定的 SB IP，接受者会 在其 NS 连接上也收到该 SB IP 的通知。然后双方均连接到该 SB 上进行对话，对话完 成后关闭连接。 以下
5、是我对这三种服务器的看法： DS 采用的负载均衡方式应该比较简单，通过 DNS 解析来做负载均衡。并且由于在DS 上的连接都是短连接，保持时间非常短，所以应该 DS 服务器的数量应该不会很多。 由于 DS 必须要返回一个可用的 NS IP，那么内部应该还有其他种类的服务器来保存 当前所有可用的 NS 服务器，以及这些 NS 服务器上的负载。通过 DS 这一层来为接下来 的 NS 做负载均衡。 NS 连接均为长连接，所以在这一层上的负载由 DS 来调节。如果 NS 负载太大，新客户 连接上 DS 时会返回其他相对空闲的 NS 服务器。当然 NS 服务器之间也有相互通讯的机 制也是少不了的，比如上
6、下线通知、对话发起等等。 SB 连接的时间介于 NS 和 DS 之间，其负载由 NS 来作控制。对话完成后和 SB 之间的连接 就关闭了。不过由于所有的对话都在 SB 上进行，MS 的服务器资源再强也会吃紧，所 以现在新版的 MSN Messenger 都加入了 P2P Message 类型，在发起对话的时候会判断 如果双方都支持 P2P Message，则会直接点对点连接连接，绕过 SB 这一层。 -anders lin 我认为 qq 登录也是差不多这样。 其登录采用 udp（默认登录方式） ， 登录服务器（相当于 NS）不需要保持连接的，负载很好做。 至于对话，qq 和 msn 一样，都是
7、 P2P 消息（可以打开 msn 的连接日志看到） ，不过msn 在 8.0 之前，不支持离线消息。 所以，我很关键的技术问题，应该在于数据库上，一些表必须违反范式，做特别的冗余。 -zhuam 接触网络编程有一年多了， 感触颇深啊， 在此我要感谢 Roger Chen ，他帮我解答过不少的问题，谢了， 我一直在做 XMPP Server 端的开发工作， 是基于 Jive wildfire 来做二次开发， 由于 Jabber 是采用 TCP 的方式来交换信息，也有用 HTTP 的方式，那是在 5222 端口被封的情况下，我们会通过 HTTP 的 80 断口来交换信息，基于 TCP 的 Serv
8、er 有一个缺点，那就是必须要保持连接，这是很浪费资源的，当达到十万 - 百万级的在线后，我认为最好的方式是基于 UDP 的 Server ，那也是最灵活的，做 P2P 的 IM Client 也是最灵活的。 Skype 是做 P2P IM 最好的一个， 他的方式是我最为欣赏的，不是 QQ MSN 的架构能比的，真的，这种 IM 的架够才是我们需要实现与学习的。 - top( 木) 象 QQ 这样的规模是采用分布构价的,有点象 DNS 服务器不是完全一样，但是可以用来理解巨大的访问量可以被复数的服务器分担。QQ 的服务器也应该分 DS、 NS、SB 三种或其他若干，其实就是在实际应用中服务器设
9、置的比例不同,我不知道非会员是否服务器需要记录聊天记录如果不要 NS 负荷也不大，在线也不用实 时连接的这样 NS 的负荷就大幅度下降了。而 P2P 是 QQ 用户之间交换数据于服务器无关忽略不计。而离线问题，只有在一位用户已经不在线的情况下，才向服务 器发送聊天记录，或者该用户是会员在向对方发送记录的同时在向服务器发送记录，这样服务器只需要处理会员的聊天记录和暂时无法到达的聊天记录。一台服务器 用 10 万的并发流量来说（理论）,而且 10W 个用户并非同时向服务器发送记录。用户登陆由 DS NS 负责的，通知到所有的好友。这个由其他服 务器负责，登陆、离线发生的频率更加稀疏。这样负载不会很
10、大。其实不够了再加服务器。关键是构架可以扩展。对于数据库我觉得他们是采用分布式数据库。QQ 对用户没有汇总式查询。将一些用户的数据放在树的某的节点上。可以把每个节点设置成数据服务器。这样就把查询量分散了。所有数据并不在一台服务器上，QQ 应该是分布式的因为理论上不需要汇总数据，除非需要高效的汇总查询。 -大宝(sodme) 很高兴能看到大家积极讨论,这两天针对于这个问题,我也有了一些自己的初步想法,拿出来与大家共享. 前两周,听杭州研究院的同事介绍了海量数据存储方面的东西,这个讲座对我还是有点启发的.其中,在介绍有关 GFS(GOOGLE 自己的文件系统)的内容 时,他阐述了这样一个思想:高性
11、能的应用系统,并不全是由高性能的硬件服务器来支持的,甚至,他们有时更多的就是一些普通的服务器,而再甚至,他们可能是 目前已经不是市场主流的废旧机器,我们就是要在这些廉价的硬件基础上,通过我们的架构设计和软件设计完成可观的高性能应用,这才是我们所应该追求的目标, 也是符合绝大多数网络公司发展现状的选择,因为网络应用系统所承载的未来用户数是不可预期的,它只会不断增大. 如果有需要的朋友,我可以给你们发一份当时讲座用到的 GFS 资料.在谈到 GFS 的时候,我觉得对于我而言,收获最大的就是 chunk server 与 master server 之间的分工,让我很受启发.简单地说,chunk s
12、erver 才是负责作真正逻辑的地方,而 master server 只是作了一个中介者,传递了一个信息而已,在具体的应用环境中,GFS client 会向master server 询问所要查询的数据文件在哪个 chunk server 上,然后 GFS client 就会与 chunk server 之间直接进行通信. 说到 QQ 的架构,我想我们现在更多的是站在自己已有的知识架构上去想象和理解它 ,或者说,这个讨论的主题是这样更为合适些:“如果让你作 QQ 的网络架 构, 你会怎么作?“不然,当我们在这时煞有介事地讨论 QQ 架构的时候,腾讯的朋友看到了 ,可能会觉得我们讨论的与他们实现
13、的差别太大.所以,我想,我下面的发 言内容,将会以这个主题来进行:如果让我来作 QQ 的架构,我会怎么作? OK,现在我就把自己当作是一个 QQ 架构的设计者,我想象一下我会怎样在廉价的硬件服务器基础上去搭建这样的一个海量用户的网络应用系统. 在讨论问题时,我喜欢把问题细化.我们先看一下 QQ 在聊天(请注意:先只谈聊天)方面具有哪些大致的功能.对于一个网络聊天程序而言,它会具有以下大致功能: 1.账号管理(包括注册,登录验证等 ) 2.好友管理(包括好友的增 ,删,黑名单的增,删) 3.消息通知(用户上下线信息的转发 ,离线消息转发) 总体而言,我把 QQ 系统的设计难点归纳为两个: 一是应
14、用服务器如何部署,二是数据库如何部署.下面,是我的设计思路. 我的基本设计思想是:把 QQ 号按分段的思想进行管理( 比如每 100 万是一个号段),每段是一个单独的 QQ 管理集群(暂且称为 QQ server cluster),每个集群之间通过分布式架构支持海量用户在线.同时,会有一个全局唯一的 QQ master server 存放全局索引信息,这些信息将主要包括:号段所对应的服务器信息及状态 . QQ cluster 的主要组成,将同时包括: 应用服务器(称为 QQ chat server)和数据库服务器(QQ db server).我的可扩展架构设想是: 当发现现有的用户数已经接近饱
15、和状态时,只要增加一个相对独立的 cluster,并把这个新的 cluster 的相关信息注册到全局唯一的 QQ master server 上即可. 每一个 QQ server cluster 应该提供哪些基本服务: 1.对于客户端,每个 cluster 是一个相对独立的逻辑组,它承担了用户需要服务器支持的大多数逻辑,比如:好友上下线消息通知 ,离线消息转发等. 2.同时,对于其它的 cluster,要向它们提供这样的接口:好友在线状态查询,用户详细信息查询等. 3.为了实现 P2P,还要打通两个客户端之间的 UDP 通信通道 . 4.当客户端选择采用 TCP 进行通信时,还要负责消息的转发
16、 . 那么,每一个 cluster 里的 db 都存放了哪些信息呢? 1.存放属于本段用户的详细个人资料(包括除了必要的昵称信息等之外,还包括诸如:年龄,住址等的详细信息) 2.存放好友名单及黑名单(而在这两个名单中,在本地的 db 上应该只包括必要的基本信息:好友 QQ 号,好友昵称等) 当客户端登录时,客户端首先只能获得好友的简单信息,如果要想获得详细详细,就需要向本号段的 cluster 查询,如果 cluster 发现好友的号不在本号段内,它会向其它 cluster 查询好友的详细信息(当然,这里的查询方法也是有多种方式的 ). 说到这里,还有很重要的一点,QQ 的登录又该如何来处理呢
17、 ? 1.首先,我会设置若干个(假设 n 个) 对外开放的登录域名 (比如),这些域名中的每一个是可以同时指向多个登录服务器( 称为QQ login server)IP 的,这样可以有效分担连接负载; 2.当客户端连接到 login server 之后,login server 将对用户进行账号认证,成功后,会向客户端发送一个 cluster server 的 ip,将客户端引导到 cluster 上去; 3.一旦客户端连接到 cluster 上成功后,所有的逻辑就由 cluster 来控制了. 当然,这里仍然还有很多细节问题要考虑,比如:对于这样的分段管理,每个 cluster 中的QQ c
18、hat server 可能一个还不行,那这些 chat server 之间就要考虑还要加一个 chat master 了.不过,这样的话,分层是不是多了一点呢? 还有待更进一层的细想,等我想清楚了详细设计方案的时候,会以附件的形式配以图表发上来,此文全当一个引子. 关于我的思路的优缺点: 优点是: 这样的思路类似于现实生活中电话号码的管理,它是分地区的,也就是分段的,我个人认为这样以后的扩展相对来说可能简单一点. 缺点是: 作为一个解决方案,这个思路并没有充分考虑到根据当前用户在线数来实现动态平衡的目标.比如说 1100 万内的在线人数很少,而 100 万200 万号内在线的人很多,那么这两个
19、不同号段的服务器负载就会完全不一样,从而浪费了服务器资源. 克服缺点的办法: 如果要实现完全根据当前在线用户数来实现服务器负载的动态平衡,那就得将 chat server 与 db server 拨离, 让 chat server 这一层完全按动态均衡的思路来作, 而 db 这一块的工作,可以抽象成一个数据管理层来作,但具体的用户数据存储仍然采用分段存储的方式,为不同的号段作不同的数据库存储. 而 chat server 这一层的思路, 基本上也是 master + chunk 的方式,客户端最终仍然是与 chat 保持长连接. -top(木) 一个必要考虑的问题是登陆时要以地域就近的原则,提
20、供最快的网络响应,所以实际服务应用层应与数据层耦合的.分段式管理可以运用在数据存储的分布式构架 中,这是一个数据层的概念,即如何有效的组织分布式数据.因为 QQ 在实际操作中在即时通讯中需要查询的数据量极少,写入数据层的信息量在所有通讯量中也占 很小的比重.所以考核负载可从服务应用层和数据层两方面来考虑.服务应用层主要考虑用户的时实性与服务器负载平衡问题.数据层主要考虑如何提供更有效的分 布式存储方案.即采用黑盒的想法,我们在设计服务层时,可意想的认为我们象一个虚拟的数据服务器提出数据请求必然会获得响应.至于服务层如何实现认为是一 个黑盒,无须考虑.接着我们只需考虑在服务层的各服务器上如何存储转发暂存取得的数据以提高效率（减少向虚拟数据服务器的查询量,减少与客户端的通讯量, 减少服务层各服务器之间的通讯量为目的） top(木) 说: 其实我们只是说了一个大框架,其实在服务器的配置功能的划分服务层网络的构架上有很多细节问题.这些要针对实际运用需求而分别配置,所以,在设计之前最好先将需求梳理归纳.不过这个工程玩大了，呵呵 我(sodme)的观点: 与 top 想法一样, 数据层是个黑盒 , 相对独立. 至于其内部, 采用分段管理.
