ArchSummit 讲师专访：洪涛——难以预测的日均 1 亿 PV

编者按：由 InfoQ 中文站主办的首届 International ArchSummit 架构师峰会即将召开。我们也对一些专题的讲师进行了采访，谈谈他们要讲的议题。

洪涛是虎扑网的研发经理，负责虎扑网架构优化升级和核心设计工作。作为一个出生于87 年的年轻人，他有着“洪大师”的称号。本次采访就是围绕这他所参与的“如何处理瞬时增长”专题展开的，你可以通过邮箱联系到他。

InfoQ：虎扑网什么情况下会出现“瞬间增长”？是否可以预处理？在处理“瞬间增长”时，哪种或哪些技术起到了关键作用？

洪涛：虎扑网是一个体育网站，所提供的服务多数都和体育赛事有紧密的结合，比如在一场体育赛事比赛前，我们有线上产品提供用户查看各种赛程，在比赛过程前后，球迷会涌入我们的论坛积极讨论赛事，在比赛过程中，我们有文字直播产品，让那些无法收看赛事的上班族及时了解比赛信息等等。而由于赛事的影响力的不同，在一些重要的比赛或者产生激烈冲突或非常精彩的比赛场景出现时，我们网站的用户也会非常激动，这种体育赛事带来的激动情绪引发了他们更加活跃的使用我们的产品，甚至为了支持自己喜爱的队伍，双方球迷会把网站当成他们的战场，而这个时候，网站就会出现非常严重的瞬时流量增长。

虽然比赛的开始时间是可以预测的，但网站用户激动的行为是否随着赛事进行而越发变得活跃则是完全无法衡量的，谁也不知道一场普通的比赛会产生什么样精彩的画面，而这种体育赛事的不确定性加剧了我们判断瞬时增长的难度――往往有些很普通的赛事由于双方奋力拼搏的精彩动作而变得火热起来，而另一些火星撞地球级别的精彩赛事却反而没有碰出什么火花。比如上半年搞得我们技术团队很狼狈的林书豪，他造成的影响力数次让我们的系统负载爆表，谁让他得到了上帝的眷恋呢？

而除了赛事之外，体育界也经常有爆炸性的新闻或者事件发生，例如姚明突然宣布退役，又例如几个大球星的交易被爆出，这些突然发生的事件引起了用户强烈的兴趣，转而带来了极大的瞬时流量增长，而如果要预测这些事件的发生以做好准备，即使对我们这种专业的体育媒体来说，都是不可能做到的事情。 在处理瞬时流量增长时，我们主要用到如下几个技术：

a. 微缓存技术

和以往的一但写入就存放很长时间的缓存不同，在虎扑网更多的是使用缓存时间很短的微缓存技术。微缓存可以在提高系统性能的同时在如何确保动态内容能够及时更新上起到关键作用。由于缓存时间很短，往往 5 秒就会超时，所以业务逻辑能够很迅速的生成各种最新的数据而不用去考虑缓存控制的问题。这种技术在虎扑网的各种需要及时更新的业务逻辑上经常被使用到。

b. 消息队列

消息队列能够将业务逻辑解耦，调用方只需要下达命令而不用等待整个逻辑执行完毕。除此之外消息队列也可以抑制性能波峰的产生，在瞬时业务增长产生时保持性能曲线的平滑。

c. Edge Side include

经典的网络缓存模型除了 Server Side 和 Client Side 之外，其实还有一个容易被大家忽视的 Edge Side，ESI 提供对页面中部分元素的缓存，在动态内容和静态内容之间达到了一个的平衡。

d. NoSQL

和其他网站不同的是，虎扑网使用着多种 NoSQL 系统，之所以这样是因为我们认为不同的 NoSQL 可以符合我们不同的需求，合适的才是最好的。我们主要在使用 Memcache，Tokyo Tyrant 和 Redis 这三种。

Memcache：用在各种 Key-Value 式的缓存上，包括各种用户信息、热门数据等，这些数据被频繁读取
Tokyo Tyrant：主要用来持久化储存用户自定义网址、版块自定义网址、空间浏览数等等。
Redis：主要使用在各种需要缓存或存储复杂数据结构的应用中，Redis 特有的 List 和 Set 数据类型能够帮助我们简化数据结构。

据我们统计，这三种服务的实例比例大概是 Memcache 30%，Toyko Tyrant 40%，Redis 30%。由于目前 Redis 的发展很快，有逐渐成为行业内主导产品的趋势，而在架构中继续使用三种不同的 NoSQL 既显得没有必要，也增加了架构的复杂度，所以目前我们正在考虑将结构进行精简，统一使用 Redis 提供 NoSQL 服务。

e. 动态功能控制系统

当网站访问量持续增加并且将要超过系统能够提供的性能上线时，我们会有一个动态功能控制系统负责各项业务的开启关闭或调整，例如新闻系统的压力快到极限时我们会关闭评论功能，而直播的瞬时压力如果剧增，我们就会延长每次刷新比赛结果所用的时间。通过从提供全部服务改为提供基本服务，能够在最低程度降低用户体验的同时提供最高的性能，化解瞬时压力。

InfoQ：由于虎扑网会出现“瞬间增长”，并针对这种场景做出了很多软硬件的技术处理，那么当网络没有处于瞬间增长的情况下，如何合理利用这些软硬件资源？

洪涛：其实在架构上，虎扑网就一直在解决瞬时增长这个问题上采取了多种解决方案，而并没有全部靠硬件去支撑，所以也不会有太明显的硬件闲置问题。不过我可以补充一句，在游戏产品的技术架构上，我们预计会使用虚拟化来解决这个问题，我们认为虚拟化会是解决这个问题的一个重要发展方向。但由于如何实施虚拟化目前只是一个架构方案，不够成熟，也没有经过上线测试，所以目前还没有相关经验可以分享。

InfoQ：我们知道应对高密度并发最有效的方案就是充分利用内存，在使用缓存和 NoSQL 技术上你们是如何选择的，分别应对什么场景？

洪涛：没错，如何有效利用内存是系统能否够应对高密度并发的关键性问题。而在虎扑的架构中，内存的利用也是我们非常关心的问题，从上至下我们有多个应用内存作为缓存的场景，比如利用 apc 插件在内存中缓存 PHP 代码的 OPcode 节省下次编译时间，比如利用内存存储热门数据和系统配置，基于内存的 NoSQL 也被我们大量使用，例如 Reids，Memcache 等。不过需要注意的时，我们并没有用内存去存放 session，用户的 session 是做为 cookie 的一部分经过压缩和加密后存放在用户的本地浏览器上的，相比在服务端集中存放 session，这种 shard-nothing 的结构提供了在架构上扩展的可能性，通过这个例子我也想提醒大家，用内存解决问题是一个思路，但也并不是绝对的，需要分不同的场景。

InfoQ：为什么选择了 RabbitMQ 作为消息服务器？我们知道 RabbitMQ 是 ERLang 语言编写了，在实际使用的过程中是否对 RabbitMQ 进行了集群，是否需要进行扩展开发？如果需要扩展开发，你们采用了哪种语言？我们知道 RabbitMQ 支持多种语言…

洪涛：其实我们对消息队列的需求还是比较高的，一共有 5 点：一是能够提供多种消息分法的规则以匹配我们不同的业务类型，二是性能要高，三是需要支持多种语言的类库以便做接入，四是提供持久化，五是需要在未来支持集群。而同时满足这几个条件的成熟的消息队列系统其实并不多，RabbitMQ 是其中之一。另一个原因是我在之前公司工作时有一位来自乌拉圭的同事对 RabbitMQ 很有研究，当时经常和他讨论消息队列方面的问题，所以在众多消息队列中，对 RabbitMQ 比较熟悉，也对它比较认可，使用它作为消息队列自然也就不奇怪了。补充一句，这位同事叫 Alvaro Videla，他是市面上唯一一本 RabbitMQ 方面的书《RabbitMQ in Action》的作者之一，对消息队列很有研究，我的很多经验都来自和他的交流。

由于RabbitMQ 本身的性能就很高，我们运行到现在都没有遇到性能瓶颈，所以暂时没有对RabbitMQ 进行集群。但事实上RabbitMQ 本身对集群的支持性很好，一旦有需要可以很快速的进行升级和切换，正如我上面提到的，这也是我们选择RabbitMQ 的原因之一。

InfoQ：虎扑网在服务器端的 IO 优化方面做了什么处理？是否会采用 SSD？

洪涛：虎扑目前大量使用着 Intel 的 520 系列 SSD，选择这款型号的 SSD 也是我们经过多轮测试和线上验证后决定的，因为我们的测试结果显示在我们的应用上使用这个系列的 SSD 能够在价格、性能、稳定性上达到要最好的平衡。我们去年也曾经有过想一步到位使用 fusionio 的想法，但最终因为价格太高而搁置了。因为对于我们技术部门来说，更加关注的不是单纯的性能指标，而应该是 ROI，也就是投资回报率。谁在相同单位价格上提供的性能越多，我们就会选择哪种方案。

InfoQ：虎扑网是否采用了虚拟化技术？

洪涛：正如我在上文提到的，网站的生产环境还没有使用，而游戏则在准备中，不过在公司内部，我们则已经部署了大量的虚拟化技术。通过虚拟化技术，我们可以用很小的代价去模拟一整套线上环境作为开发和测试使用，而每个工程师都有机会接触到和线上几乎一模一样的环境，这为他们开发应用提供了很大的帮助，也促进了他们更加统一的去思考问题。例如以前项目的系统配置和代码是分别由系统运维和开发负责的，而现在开发人员会更多的考虑系统配置和整体架构，甚至提出优化的建议。

我们主要采用了 OpenVZ 和 KVM 两种虚拟化技术，OpenVZ 居多。我们应用虚拟化技术的场景主要是线下开发环境与测试环境，一些小项目的生产环境以及线上运维平台（例如 Puppet、SVN，以及一些自己开发的运维工具等等）。运用虚拟化技术的主要目的是提高服务器利用率和安全隔离性的同时不损失性能（与实体机 virtual-host 方式相比）。而 KVM 则主要应用在 OpenVZ 支持不够的地方，比如安装与 OpenVZ 操作系统内核不兼容的软件、操作系统（JDK、 ubuntu 11+ 等)。

而 VMWare 的 ESXi 我们也有小规模的使用，主要用于安装 windows 作为一些项目的测试环境使用，使用效果比 KVM 要好。经过我们系统部门的测试，vmware 的虚拟机产品对 windows 兼容度较高，例如其 vmtools 驱动可以加速 windows 访问网络、硬盘的速度（vmnet, pvscsi 半虚拟化 scsi 技术）等。KVM 虽然在这块也有所提高，但其 Virtio 驱动对 Windows 的支持还是较弱。所以这也是为什么我们在 windows 平台的虚拟化方案中大量使用 VMware 的虚拟化技术的原因。

InfoQ：虎扑网是否采用了 Hadoop 系列的基础？如果没有，未来是否打算采用？处理什么场景？

洪涛：我们目前没有使用 hadoop 系列，目前虎扑并没有需要大规模数据运算的应用，但将来可能会在游戏应用上开始试点，用来分析用户行为以及付费习惯等。

InfoQ：随着网站的发展，如果未来访问流量大大增加，现有的架构能否实现自动横向扩展？如何实现？

洪涛：从 11 年开始，我们所有新开发的应用已经对扩展做了很好的支持，所有应用都基于一个框架和系统开发。在传统的区分应用和服务器的架构中，某些应用和某几组服务器是绑定的，比如新闻性能差了，就扩充新闻的 app 服务器，论坛需要扩展了，就多加几台服务器给论坛这个应用。而在我们新的架构中，所有服务器都能够提供所有应用的访问，一台服务器上既有应用 A，也有应用 B、C、D 等等，每台服务器都能够提供完整的服务，而整个架构是 shared-nothing 的，允许横向扩充。需要扩充时，只要部署几台实体服务器，然后把应用复制到这些服务器上，在负载平衡池中增加这几台服务器的 ip，就能够增加所有使用这个架构的应用的性能，而一旦出现峰值时，也是所有的服务器一起提供运算，不会出现因为服务器上的应用不同导致一些服务器负载很高，另一些则负载很低的情况。

感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。