Reddit: 从扩展到每月10亿页面浏览量的过程中的各种失误中...

winston

英文原文：Reddit: Lessons Learned From Mistakes Made Scaling To 1 Billion Pageviews A MonthReddit: 从扩展到每月10亿页面浏览量的过程中的各种失误中学到的经验教训Jeremy Edberg，reddit正式聘用的第一位员工，在RAMP大会上做了一个极其精彩的演讲，传授了许多如何创建一个成功社交网站的经验。各位可点击Scaling Reddit from 1 Million to 1 Billion–Pitfalls and Lessons（将reddit访问量从一百万提升到十个亿-陷阱与教训）的链接来观看演讲视频。
jeremy借用了褒贬参杂的方式来总结经验教训，他分享了在推广Reddit过程中所犯的比比错误，但也让我们看到他们做出的正确抉择。不过有点令人吃惊的是，jeremy现在是Netflix[3]的可靠性架构师。所以从他的演讲中也可感受Netflix的一些观点。
令我印象深刻的几个教训是：

• 把SSD看做是便宜的内存（RAM），而不是昂贵的硬盘。当reddit因为数据库的缘故从机械型硬盘升级到固态硬盘（SSD）后，其服务器数量从12台降为1台，且还有极大的空间富余。SSD虽比机械式硬盘贵了四倍，但是你会得到16倍的性能提升，真是物有所值。
  
  

• 给用户一点点权力，看看他们怎么做，然后把其中的好点子变为网站的功能。reddit从用户那里所学极为丰富，且其网站的流畅运作很大程度上倚赖其用户，这是我获得的最大收获。用户会告诉你很多你不知道的事情，reddit gold就是个很好的例子，刚开始它只是社区里大家开的玩笑，reddit将其兑现为产品，并深得用户喜爱。
  
  

• 项目开始时就建设一个可扩展性架构是不必要的。开始时你并不会知道网站将来的功能集，所以你也不会知道你有哪些扩展方面的问题。等到你的网站开始壮大时，你自然就可以了解网站会在哪些方面有扩展问题。
  
  

• 把未登录用户当作二等公民。通过总是给未登录用户返回缓存内容的做法，reddit将包袱扔给了Akamai而自身的流量畅通，这种做法使其网站性能大大提升。
  
  

Jeremy的分享远不止于此。从reddit扩展初期的错误中我们能学到的经验教训良多，这里是我对Jeremy演讲的一些释读：
统计数据

• 访问流量大约每15个月翻一番。
  
  

• 上个月，来自177个不同国家的 67,328,706名独立访客浏览了reddit网站上 4,692,494,641个页面。这个演讲是在reddit的第10亿页面浏览节点完成时进行的，其目前架构与之前架构的差异无法确认。
  
  

• 28名雇员。
  
  

• 每名雇员应对大约240万独立访客。（链接）
  
  

• 数以千计的志愿者版主。
  
  

• 在2012年时，他们用240台服务器来支撑每月20亿的页面浏览量和Postgres里的2TB数据。所有高访问率数据都从EBS转移到本地临时磁盘（以保证网站运行流畅）。
  
  

公司源起

• Reddit始于2005年。创始人首先带着“通过短信点餐”的点子去寻求Y Combinator的资金支持但被拒绝，他们回头和Paul Graham（Y Combinator的创始人，美国著名程序员、风险投资家、博客和技术作家）讨论并产生了开发互联网网页建设的点子，即reddit。那时他们并不知道掘客（Digg）的存在。
  
  

• 从数据中心开始，随后逐渐将功能转移至亚马逊弹性计算云（EC2）。
  
  

             2006年，开始通过EC2使用S3提供存储和服务标志。
             2007年，开始使用S3支持缩略图服务。
             2008年，以vpn通道连接数据中心的方式在EC2上进行批处理。
             2009年，整站使用EC2服务。网站停运整整一天，将数据全部迁移到EC2。这是《数据引力》的重大案例，随后还会谈到。
EC2

• 迁移到EC2的原因
  
  

• 不断堆叠机柜并不有趣。不想租用更多的机柜，买更多的服务器。
  
  
• 建立数据中心，早期数据的增长是无法预测的。
  
  
• 对于一个4人小组而言，成本相对降低了。亚马逊的EC2比他们在San Francisco的数据中心价格便宜了29%。
  
  

• EC2不是万能的。如果你受够了高网络延迟和邻居发出的噪音，考虑下迁移到EC2上。一个好处是网站可以自由的壮大。
  
  
• 熟悉EC2上的资源限制
  
  

• 所有的资源对每个帐号都有限制。
  
  
• 亚马逊也不清楚其中的一些限制是什么。
  
  
• 跟踪限制，在你需要的时候扩大限制范围。
  
  
• 捕获异常以发现何时临界条件被触发。
  
  

架构

• Reddit的架构是很直观的。**用户连接到一个可以与应用纽带直接通话的网络纽带。这个应用纽带又与memcache, Cassandra, 还有 Postgres通话，Postgres使用的是一个主从关系网络。这是一个使用Cassandra 和 Postgres的批处理系统。
  
  
• 相比较而言，Netfli使用的是一个服务型的架构，各部分通过REST API相互之间通话。
  
  
  
  
  • 优点：方便自适应规模，因为只有服务器需要调整规模；更容易规划容量；错误更容易找出，因为他们在REST框架里是独立的；变化效果十分精确；本地缓存更加高效。
    
    
  • 缺点：需要多个Dev或者Dev团队在多个服务器上工作，所以人工成本增加；需要一个公共开发平台避免重复工作；对于一个小团队来说，管理成本很大。
    
    
• Postgres是一个非常优秀的数据库**他可以创造出十分优秀，快速键值储存的数据库。
  
  
• 邮件系统是一个大问题** 信息传送很难弄好，开始的时候可以用他们自带的邮件系统，但是现在可能要用专门邮件系统提供商的服务了。
  
  
• 队列是救世主** 在组件至今传递任务的时候，放入一个队列里。你将会得到一个短小精悍的缓冲器。（Reddit用的是[RabbitMQ](http://www.rabbitmq.com/)）
  
  
• 混用HAProxy和Nginx** 有些阻塞是相互的。对于负载均衡尝试Nginx无效之后可以试试HAProxy（在负载均衡崩溃的时候）。他对于L7负载均衡很有用，Nginx仍然可以用来终止SSL和服务静态内容。
  
  

代码

• 框架。 使用Pylons (Django太慢了)，它就是一个基于Python的框架。从一开始，它就很容易上手。由于不匹配你的用例，最终它们总会出问题。Pylon最终做出了很多改变，（原来）它升级到新版本是很困难的（现在已经修复这个问题）。（现在）可以使用Pyramid （Pylons的新名字）。
  
  
• 基于线程的事件? 基于线程可以提前依大小排列，但是排列可能是错误的。基于事件可以处理更多的连接而不必在遇到瓶颈时继续陷在瓶颈中。你希望花更多的时间去规划线程池的尺寸或处理突然遭遇到的瓶颈吗？
  
  
• 开源有益。 Reddit是在开源代码上构建的。 不需要付费的软件不错，尤其是在开始的时候。
  
  

数据

• 数据将是你的公司最重要的资产。Facebook, Google和Flickr这样的公司的根本就是数据。
  
  
• 沉重的数据。当你把数据放在一个地方，你就需要在这个地方放置你的应用。所有的应用都是围绕数据进行的。数据形成了一个引力中心，其他东西都要向它靠近，因为数据最难移动，而且数据量越大越难移动。目前，把数据移出EC2非常的贵。这就是 EC2 存储数据免费，迁移数据收费的原因。他们想要你把所有的数据都存放在云服务器上。
  
  
• 关系型 VS 非关系型。reddit 的大部分数据都是键值对，存储在Postgres数据库中。所有涉及到金钱的数据存储在关系型的数据库中，因为可以使用事务和简便地分析。
  
  
• Postgres 是防弹的。它像岩石一样坚硬，它自己从未出过问题。即使有问题，也是其他它周边系统的问题，比如使用Python编写的复制系统。很难找到熟悉Postgres的专家（因为它不需要专家解决奇怪的问题）。
  
  
  
  
  • 键值存储选择了Postgres而不是Cassandra是因为Cassandra当时并不存在，而且Postgres速度非常快，还已经原生支持键值。
    
    
• 分库分表。写操作被拆分到四个主数据库中：连接、帐户、子自动、评论、投票、其它。
  
  
  
  
  • 每一个主数据库都有从数据库。投票数据库只有一个主库和一个从库。评论数据库有一个主库和十二个从库。
    
    
  • 如果可以，尽量避免直接从主库读取数据，从从库读取数据以使主库专用于写入数据。
    
    
  • 客户端代码负责从库间负载均衡。如果一个从库响应较慢，访问另一个从库。
    
    
  • 实现了一个数据访问层，名称为thing。
    
    
  • 这种方法已经使用了很长时间。混合使用数据库分库分表，主从读写分离，跟踪数据读取性能保持负载均衡。
    
    
• Cassandra
  
  
  
  
  • 快速写入，快速负查询，简单高可扩展性，无单点故障问题
    
    
  • 在 Netflix（美国一家视频网站），数据分散地存储在三个不同的区域。每一个区域都有全部区域的数据。即使一个区域的数据丢失了，网站仍然可以正常运行。
    
    
  • 把投票数据转换后存入Cassandra 是 reddit 一次巨大的进步。Cassandra 的 bloom 过滤器显著地提高了负查询的效率。比如它可以很快查询出你没有投票过的意见，因此负查询的结果显示很快。（详见这里）
    
    

社会

• 在2008年，reddit开源了
  
  
  
  
  • 用户可以阅读代码，从而知道没有人破坏投票结果
    
    
  • 用户可以增加他们早就想增加的功能，reddit会提供运行平台。开起来，用户并不是不想写代码。
    
    
  • 招聘。别人会了解代码，所以更容易招聘。推销自己的想法来更好地合作
    
    
• 蠕虫事故。 有人指出了如何在一个网页中注入多余的javascript代码来写一个蠕虫的方法。这个方法并没有打算被泄露出去，但是最终还是泄露了。在那一天，创始人之一正在结婚，整个团队都在从婚礼返回的飞机上。但是，一个用户已经快速响应，提交了一个阻止蠕虫传播的补丁。开源可以使得在危机时刻社区可以提供帮助。
  
  

reddit怎么赚钱？

• 侧边条广告，自助广告，推销，reddit币，市场。
  
  
• 注意，reddit还没有实现盈利 (链接)。这带来一个问题，像reddit这样的云端站点能否实现盈利？
  
  
• 另外，reddit现在不再属于Condé Nast，它是独立的 (link)。
  
  

错误

• 没有考虑迁移到EC2之后增加的延迟。 在数据中心，机器之间的访问时间都是亚毫秒级，所以加载一页可以调用1000次memcache。但是在EC2，情况发生了变化， Memcache的访问时间增加了十倍，导致原来的方法行不通了。解决方案是批量调用memcache，这样一次请求可以得到大量的结果。
  
  
• 过于相信承诺。 Amazon并不总是按照承诺交付，所以有时要圆滑一些处理。设计的时候就要考虑错误，而不是试图修复错误。（这里没有参考文献，也许EBS是个例子？）
  
  
• 在生产环境中使用最新的产品。当Cassandra还处于开发周期的早期的时候，我们就开始使用它了。它现在很棒，但是当时有很多问题。
  
  
• 早就应该把更多的工作量迁移到client端。 服务器端做了很多页面渲染的工作，但是这些工作应该被推到客户端。Facebook是这方面的大师。你会得到一个矩形，和很多空的div，然后通过API调用来填满这些div。这就是他们早就希望reddit可以做的事情。这可以让我们的规模更快地增长。而且这也对调试有好处，因为我们很容易知道哪个API出了问题。
  
  
• 没有足够的监控，而且用了一个可视化效果不太好的监控系统。 最开始我们使用Ganglia，它可以展示非常漂亮的图表，但是它比较难用，而且变化太快，尤其是在一个实例进进出出的虚拟机环境中。
  
  
• 没有让数据过期。 在reddit你能看到从最初开始的评论。后来他们开始增加一些限制，使得你不能对旧的评论投票，也不能回复旧的帖子。这会造成数据量越来越大，越来越难把热数据放在数据库里面。
  
  
• 没有使用一致性哈希算法。Not using consistent hashing. 当往cache中hash数据的时候，可能会出现这样的问题，当你增加更多的cache的时候，你的数据还会被hash到原来的cache中，不管你有多少chache。这样增加cache的时候，你无法保证负载均衡。一致性hash是解决问题的办法。我们迁移到Cassandra来解决这个问题。
  
  

教训总结

• 最关键的是在用户遇到问题之前就找到系统的瓶颈。
  
  
• 使用代理服务器不再是拓展的良方。过去可以根据用户访问的URL来分流。Reddit曾经也有过一个系统用于监控每个URL上系统服务的时间。用户请求会根据访问的URL的不同，进入到不同的响应通道。但是整个系统的响应速度总是此起彼伏。根据平均响应时间来分流以达到系统的巨大提升，已经完成成为过去时了。
  
  
• 让一切自动化。 如果你能对你的基础架构像对待你的代码周全，可以扩展的。那么所有事情都应该是其他的所有工作也应该是可以自动化配置的。
  
  
• 项目开始时就建设一个可扩展性架构是不必要的. 在项目开始的时候你不知道它会有什么特性，那么你只是想知道拓展会有什么问题。但是等到你的站点扩大后，你就能看到拓展的具体问题在什么地方。
  
  
• 不要一开始就使用面向服务的架构。记住，面向服务对一个中大型网站来说是很好的。但如果是起步期的站点就有点太超前了。
  
  
• 不要追求潮流。 只有一小部分的流行技术是可行的，比如，node.js这样的。
  
  
• 对所有的功能设限。 对所有会不断重复发生的事件设限制，必要的时候放宽或降低限制标准。如果添加限制，会排斥出一部分用户，但是保护了系统。举个子版块上传文件的例子。有用户指出他们上传的文件数多到可以损坏系统。也不要允许上传巨型文本。 其他人会教你怎么让你接受5GB的文本文件。
  
  
• 多手准备. 当在设计阶段的时候就假定以后系统要不断扩展的时候，那么开始的时候就不要只准备一台应用服务器，一台数据库和一个缓存了。那么以后做横向拓展的时候会容易的多。
  
  
• 用C语言重新Python代码。 随着reddit的不断拓展，大多数重复的功能都用C语言重写了原来的Python代码，且获得了很大的速度提升。特别是过滤器、markdown标签的渲染及memcache的调用。用C重写Python代码的优势是简单高效。
  
  
• 保证数据库设计尽可能的无模式。 这样会使得在添加新特性的时候变得简单。你所做的只是添加一些新的属性而不用修改表结构。
  
  
• 过期数据。 停用那些老旧的线程，创建好一个完整的页面并添加到缓存中。这就是处理那些可能导致你数据库奔溃的老旧数据的方式。同样的，不要允许对很久以前的评论点赞或者加平路，用户几乎不会注意到的。
  
  
• 把SSD看做是便宜的内存，而不是昂贵的硬盘。 当reddit把数据库的存储设备从机械型硬盘升级到固态硬盘（SSD）后，服务器数量从12台降为1台，且响应还更快。SSD虽比机械式硬盘贵了四倍，但是你会得到16倍的性能提升，真是物有所值。Netflix板块中的一些最大Cassandra节点都是采用的SSD存储，性能得到了巨大的提升。
  
  
• 每个工具都有不同的适用场景。 Memcache中的数据是不做持久化的，但是非常快，那么投票数据存在它里面可以是页面的渲染以最快速度完成。Cassandra是持久化的，而且快，布隆过滤器的使用也是它可以找出没有命中的查询，所以使得它很适合存储没有在memcache中存储的投票数据的副本。Postgres是非常可靠的关系型数据库，可以用来存放Cassandra中投票数据的备份（Cassandra中的所有数据在必要的情况下可以从Postgre中获取），在做批量操作的时候，有时也需要依赖关系数据库的功能。
  
  
• 把未登录用户当作二等公民。 过去80%的请求来自未登入的用户，现在是接近50%。通过总是给未登录用户返回缓存内容的做法，reddit将包袱扔给了Akamai而自身的流量畅通，这种做法使其网站性能大大提升。附带的好处是，如果reddit当机了，你没登入的话你也许就察觉不到。
  
  
• 使用队列。 投票、评论、缩略图、预查询、垃圾评论处理及纠错等等都放在队列中处理。通过监控队列的长度就能让你发现问题。附带好处是，使用队列后有些问题对用户会变得透明，像投票请求，即使系统没有即时响应，用户也不会察觉。
  
  
• 将数据放在多个可访问的域中。
  
  
• 避免在一个实例中保存状态。
  
  
• 频繁对EBS硬盘做数据快照。
  
  
• 不要在实例中保存秘钥。亚马逊现在提供实例秘钥服务（instance keys）.
  
  
• 按安全策略组分拆功能。
  
  
• 提供API。开发人员可以在你的平台上开发应用。像reddit手机应用，就是由公司外的开发人员通过调用API开发的。
  
  
• 在你自己的社区做一个积极分子。
  
  
• 让用户为你工作。 网上用户的输入总是充满欺骗性、无用的、伪造的，但是对于reddit，处理这些垃圾信息的大部分工作都由志愿者完成了。这就是reddit能保持小团队却能把工作完成的出奇的好的原因。
  
  
• 给用户一点点权力，看看他们怎么做，然后把其中的好点子变为网站的功能。比如，当子版块可以定制CSS的时候，他们看到用户在干吗，以及为其他所有用户提供的一些功能。这也使用户在reddit做一些事感到兴奋，因为他们喜欢控制的感觉。还有很多这样的例子。
  
  
• 倾听用户的声音。用户会告诉你许多你可能想知道但是又不知道的事情。比如，reddit币最开始就是社区里面的一句玩笑话。现在他们做成了产品，而且用户很喜欢。
  
  

本文地址：http://www.oschina.net/translate/reddit-lessons-learned-from-mistakes-made-scaling-to-1-billion
原文地址：http://highscalability.com/blog/2013/8/26/reddit-lessons-learned-from-mistakes-made-scaling-to-1-billi.html

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们