写点什么

杨卫华谈新浪微博架构

  • 2010-12-13
  • 本文字数:4235 字

    阅读完需:约 14 分钟

在 2010 年的 QCon 北京大会上,InfoQ 的编辑对杨卫华进行了采访,其中谈到了关于新浪微博系统平台应对各种问题的解决方案,以及正在开发中的新浪云。

杨卫华,新浪产品部技术经理,目前工作以新浪微博技术平台为主,曾负责过新浪 IM 等通讯服务端架构设计。对互联网后端技术,分布式,网络编程,XMPP 即时通讯等领域感兴趣。曾组织多次广州及珠三角技术沙龙活动。个人 blog 为: http://timyang.net/

InfoQ:大家都知道,在美国有一个非常有名的信息分享平台叫做 Twitter,而在中国,我们也有同样的方式,就是现在非常流行的新浪微博,它还有个非常温馨的名字,叫做围脖。而新浪微博的架构就是杨卫华先生主持开发的。

今天我有幸采访到杨卫华先生,让他来给大家谈一谈,在新浪微博的技术架构方面,他们是如何为用户提供更好的性能、更好的服务的。

卫华先生你好,我的第一个问题是,在新浪微博上有很多名人,名人的微博一般都是非常热的,对它们的访问量也特别高,那么对于这些微博,您采用了什么样的方式来支持这种大数据量的访问呢?

杨卫华(以下简称卫华):对于这个问题,我们做过专门的分析。因为最近新浪微博有名人扎堆的现象,我们根据这个现象,从以下几个角度来进行解决。

首先根据中国的网络现状,比如说网通和电信,之间的网络访问速度会比较慢,我们考虑让用户能够访问就近的服务器,这样使用体验、速度都能达到要求。我们根据新浪以往的经验,在全国部署了大量服务器,这样就为微博提供了硬件上的保证。

第二个方面,在程序优化的方面,在产品上线之前,我们进行了全方面的压力测试,如果系统在某个方面可能会出现瓶颈,比如名人的访问量比较高的话,我们就从那个角度去优化。比如说 Cache 是否够用,数据库访问是不是瓶颈,这方面我们预先都有对压力的估计,然后会针对那些方面去做优化。

第三个方面,对于那些静态资源,比如图片、视频、JS 脚本,我们有专业的 CDN 来解决的,这样就能够保证全国的用户在访问新浪微博时都能够得到比较好的体验。

InfoQ:现在的服务器大概都架设在哪几个部分?覆盖全国哪几个地区?

卫华:全国基本上大部分省份都有服务器,特别是一些比较核心的节点,比如北京、上海、广州,在这些核心的节点可能部署了更多的服务器,而在其它一些二线城市、其它省份也都有部署的。

InfoQ:您也是为这种大数据量做了充分的准备。最近大家都知道,玉树发生地震,对于这种突发事件,我们也会把微博作为一种信息交流、信息分享的平台,大家的访问也会造成大数据量访问,那么对于这种突发事件,您在技术架构上也做了相应的准备吗?

卫华:对,这种突发事件以及访问峰值,是微博上经常出现的现象。突发事件的访问峰值有两种,一种是可以预测的,比如说我们将来要搞的世界杯,比如春节,大家都相互拜年这种;另外一种是不可预测的,比如地震这种。对可以预测的这种,我们事先会做准备,比如说世界杯,我们要增加相关的服务器来完成。而面对这种不可预测的情况时,我们平时会有个数字,那就是我们平时的平均流量,硬件设备要比它高一定量,这样就能够应对这种峰值的请求。

另外从程序上来说,我们可能有一些专门的机制,比如说用户发表微博,并不是一发表就存到数据库中,简单地理解,他不是这样操作的。业界中微博之类的产品都有一种机制,叫做异步机制,也就是说,在发表的时候,我会把这个信息放到消息队列里面,然后再用另外一个专门的业务处理程序来处理它。当某一时刻发表量非常大,比如说地震了,很多人都会发表,那这个时候系统依然能够有条不紊的来处理这个业务,这样子就能让我们的系统稳定运行,并具有高可用性。

InfoQ:也就是要对整个事务的进行有效的控制?

卫华:对。

InfoQ:大家应该知道,因为有这么多的微博,有那么多名人,而且还有很多平民的、草根的微博,系统的数据量也是非常非常大的,而且还有很多很多的评论,很多很多的留言等等。那么对于这种海量存储,是不是也要做技术架构上的准备?

卫华:对,微博这个产品从技术上来说,有一个很大的特征,就是每天用户发表特别容易,这造成每天新增的数据量都是百万级的、上千万级的这样一个量。这样你经常要面对的一个问题就是增加服务器,因为一般一台 mySQL 服务器,它可能支撑的规模也就是几千万,或者说复杂一点只有几百万,这样,你可能每天都要增加服务器,从而解决所你面对的这些问题。你要考虑,如果每天要加服务器,你的程序上、访问上会不会有问题,会不会间断。

我们其实有一些优化的方法,比如说我们会考虑热点数据和冷数据,如果经常要访问的这个数据,也就是热数据,而过几天才会访问的就是冷数据,我们会把它们合并,这样就可以按这个时间来分段,也就是把热数据放在一起,冷数据放在一起,这样可以解决这个访问热点的问题。

另外业界还有种思路,刚才说的用 MySQL,我们采用 Shade 的技术会按时间分片,这是一种解决思路;另外还有一种解决思路,业界特别现在国外流行的一种方法,也就是 NoSQL 的方法。有一种比较好的产品,现在大家比较关注,叫 Cassandra,就可以解决这个问题。如果我们每天要加一台服务器的话,那么我们程序、运维这些能不能跟上呢,是否有一种产品可以让你程序不需要做丝毫改动呢?Cassandra 这个产品就可以帮你来解决这个问题,你只需要把服务器插进去,那它马上可以使用,那个产品内部就有这样的机制。

InfoQ:那样的话对我们整个产品的维护就比较方便了?

卫华:对,这个可能就是说以后业界发展的一种方向,使用这种分布式的存储来解决这种海量增长的问题。

InfoQ:你觉得 NoSQL 的数据库和传统的关系型的数据库,那种更适合微博这种形式的网站?

卫华:从长远来说,NoSQL 这个更适合一些,特别是分布式的 NoSQL,刚才我也讲了,如果能全部下来的话,那可能经常要面对这种扩充的困扰,需要的干扰,可能是说,如果要保证服务不间断,可能就会面临一种很大的挑战,NoSQL,特别是这些分布式的 NoSQL 产品在内部就解决了这种问题,你不用停机,就可以加服务器,加设备。

InfoQ:这会对我们用户造成很大的方便?

卫华:对。

InfoQ:那么在性能方面,还有一种我们常采用的方式就是 Cache 的方式,那么在新浪微博系统里面,Cache 方式有什么样的特点?

卫华:在像微博这样的 Web2.0 产品里面,技术界有一种很重要的说法,Cache 就是 RAM,RAM 就是 Memory 的意思,RAM 也就是 New Disk,内存已经成为新的磁盘,代替磁盘的访问了。当我们大量使用 Cache 的时候,可能会存在很多问题,比如很多那种 Web2.0 的产品,它在 Cache 的数量已经不是 G 的概念了,不是几 G、4G、8G 的,可能达到一个 TB 的概念了,一个 T 相当于 1024G,面对这样海量的数据,那我们访问的时候可能就会出现很多新的问题,比如我们的带宽,因为用户请求我的首页的时候,他会获取很多资源,比如有 50 个人关注你的微博,他需要从 Cache 里面把这 50 个人的数据都聚合起来,同时还会有很多人也在访问这个服务器,假如说,有一千个人访问,这一千个人里面,每个人都从五十个里面选,那么这个 Cache 的带宽将是一个比较大的问题,这是以前那种我们使用 Cache 时没有遇到过的。然后,为了解决这个带宽的问题,我们可以使用压缩的技术,我们保持 Cache 里面的数据,经过一种快速的压缩算法,比较传统的我们可以使用 GZip,那实际上在这种对时效性要求比较高的技术里面,我们是要求更快速的算法,比如说有一些 DOZO 算法,它对 CPU 消耗很小,但它压缩很快,效果也非常好。

另外的一个新问题,单点故障,我们非常依赖那个 Cache,假如某个时候它突然崩溃了,那么应用访问可能就会遇到很大的问题,也就是响应速度会出问题,为了解决这个问题,我推荐的做法是,使用一致性的哈希算法,就说送我一个业务,他可以用多个 Cache 服务器来完成,然后我们使用一致性的哈希算法,当一个 Cache 崩溃之后,它的请求就可以分散到其它的 Cache 来完成,总体的那个振荡不会太大,也就是说这个延迟会分散开来,让用户访问页面的时候感觉不到,实际上后台它可能有一台服务器,刚才经历一次 Crash,可能造成一次波动,经过我们这样改造之后,用户可能察觉不到这种变化。

InfoQ:用其它的服务器,同时来弥补这个地方的失误?

卫华:对,使用一致性的哈希算法,能够巧妙地达到这个目的。

InfoQ:您刚才提到了 NoSQL,另外在最近的业界还有一个流行的词就是 Cloud,云计算,我们是不是有计划以后会把微博系统推广到云平台上,或者说采用云计算的方式来处理呢?

卫华:没错,我们微博现在有一部分跟云计算结合比较密切,我们现在微博正打算推出一个开放平台,开放平台什么意思呢?就是说,第三方的开发者可以在我们上面写应用,可以连接到新浪微博,比如说可以获取信息,可以发表微博,而这些应用程序,可以放在我们的开发的另外一个服务上,叫新浪云。这个新浪云有什么好处呢?这些第三方开发的应用,可能他刚开发的时候,请求量不大,但有可能因为这个创意很好,忽然访问量大了。如果你用你自己的解决方案的话,可能就达不到这种要求。比如说最大的问题,可能就是全国访问不畅,或者访问量突然增长了,原来的服务器不够用,你要自己去加硬件,来不及处理。如果你放在那个新浪云上面的话,那我们系统自动会帮你解决这个问题,不管你的一个非常小的程序,比如一天只有几百个访问,还是一个海量的应用,我们都能够放在这个平台里面。在这个云应用里面,你不需要自己操心,系统自动会帮你把这个任务完成。另外它还有一个好处就是,这个云自动实现了全国分布,你只要 Host 在上面,全国的用户不管从哪里访问,他可以访问一个就近的服务器,这在速度比自己部署都具有很大的优势。

InfoQ:那咱们新浪云现在已经正式推出来,还是正在计划中?

卫华:我们现在还处于测试阶段,我们采用一种邀请式,希望邀请更多的开发者来试用它,我们根据开发者的反馈来改善它,等到一定程度,我们再去大规模地推广。

InfoQ:以后对于大家来维护自己的微博、访问别人微博,是不是也更方便,不一定非要到各种各样的网页上,或者是手机等等,可以在自己开发的程序上就可以做这些事了,对吧?

卫华:对,以后结合这个微博的开放平台,结合新浪云,可以形成一个良好的生态圈,第三方的开发者要有一个很好的环境,给微博增加各种创意,增加各种应用。

InfoQ:这应该是对开发者带来的一个福音。

卫华:对。

InfoQ:感谢杨卫华先生接受我们的采访。谢谢!


给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2010-12-13 01:1014441
用户头像

发布了 340 篇内容, 共 129.4 次阅读, 收获喜欢 13 次。

关注

评论

发布
暂无评论
发现更多内容

作业-第3周总结

arcyao

架构师训练营1期 第七周作业

谭明华

极客大学架构师训练营

架构师训练营 - 第七周作业

一个节点

极客大学架构师训练营

架构师训练营 作业3

Arthur

极客大学架构师训练营

极客大学架构师课程-第三周-作业

井中人

极客大学架构师训练营

架构师训练营 Week7 - 课后作业

压测 极客大学架构师训练营 LoadRunner

把打胜仗的决心作为信仰

吴晨曦

创业

Navicat无法连接MySQL怎么办?

MySQL从删库到跑路

MySQL navicat 3306端口

第七周学习性能优化1 总结

三板斧

架构师系列之4 手写单例

桃花原记

架构师训练营第 1 期第七周总结

Leo乐

极客大学架构师训练营

第三章学习笔记

博博

第七周

Geek_fabd84

Week3- 面向对象的设计模式(作业二)

Sean Chen

第七周作业

icydolphin

极客大学架构师训练营

架构师训练营 - 第七周总结

一个节点

极客大学架构师训练营

第三章总结

孤星

Web 性能压测工具

A p7+

2020.11.02-2020.11.08 学习总结

icydolphin

极客大学架构师训练营

架构师训练营 总结3

Arthur

极客大学架构师训练营

架构师训练营 Week7 - 性能优化 - 性能指标,分层,锁

极客大学架构师训练营

Week3总结

lggl

作业

iOS性能优化 — 四、内存泄露检测

iOSer

ios 性能优化 编程语言 ios开发 内存泄露检测

Week3-面向对象的设计模式(作业一)

Sean Chen

架构师训练营第七周学习总结

Gosling

极客大学架构师训练营

架构师训练营第三周作业

Sandman

第三章课后作业

博博

Week3 作业

lggl

作业

架构师训练营1期 第七周总结

谭明华

架构师训练营第 1 期第七周作业

Leo乐

极客大学架构师训练营

第三周作业

孤星

杨卫华谈新浪微博架构_QCon_侯伯薇_InfoQ精选文章