# 每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训
> 原文: [http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html](http://highscalability.com/blog/2010/5/17/7-lessons-learned-while-building-reddit-to-270-million-page.html)
![](https://img.kancloud.cn/e5/5e/e55ee2c60a36a8c6003997af6f358855_240x150.png) [社交新闻网站](http://en.wikipedia.org/wiki/Steve_Huffman) [Reddit](http://www.reddit.com/) 的共同创始人史蒂夫·霍夫曼做了出色的[演示文稿](http://vimeo.com/10506751)。([幻灯片](http://www.slideshare.net/carsonified/steve-huffman-lessons-learned-while-at-redditcom)和[文字](http://carsonified.com/blog/dev/steve-huffman-on-lessons-learned-at-reddit/) ),学习他在将 Reddit 建立和发展到每月有 750 万用户,每月有 2.7 亿页面浏览以及 20 多个数据库服务器的过程中吸取的教训。
史蒂夫(Steve)说,很多课程确实很明显,因此您可能在演示文稿中找不到很多全新的想法。 但是史蒂夫对他有一种真诚和真诚,这显然是建立在经验基础上的,以至于您不禁要深思一下自己可能会做些什么。 如果史蒂夫不了解这些课程,我敢打赌其他人也不会。
有七个课程,每个课程都有自己的摘要部分:第一课:经常崩溃; 第二课:服务分离; 第 3 课:开放式架构; 第四课:保持无状态; 第 5 课:内存缓存; 第 6 课:存储冗余数据; 第 7 课:脱机工作。
到目前为止,其体系结构最令人惊讶的功能是在第六课中,其基本思想是:速度的关键是预先计算所有内容并将其缓存。 他们将预计算[旋钮最多旋转 11](http://en.wikipedia.org/wiki/Up_to_eleven) 。 听起来您在 Reddit 上看到的几乎所有内容都已被预先计算和缓存,无论它们需要创建多少版本。 例如,当有人提交链接时,他们会预先计算所有 15 种不同的排序顺序(热门,新,热门,旧,本周等)以用于列表。 通常,开发人员会害怕走极端,浪费时间。 但是他们认为浪费前期总比拖延慢。 **浪费磁盘和内存比让用户等待**更好。 因此,如果您一直坚持下去,请转到 11,这是一个很好的先例。
## 第一课:经常崩溃
本课的实质是:**自动重新启动失败的癌性服务**。
在 colo 中运行自己的系统的不利之处在于您需要进行维护。 服务中断后,您必须立即修复,即使在凌晨 2 点。 这是您生活中持续不断的紧张感。 您必须随身携带一台计算机,并且您知道,任何时候只要有人打来电话,那都是您必须解决的另一场灾难。 它毁了你的生活。
缓解此问题的一种方法是重新启动过程,该过程已经死亡或变得癌变。 Reddit 使用[监督](http://cr.yp.to/daemontools/supervise.html)自动重启应用程序。 特殊的监视程序会杀死使用过多内存,使用过多 CPU 或无响应的进程。 不必担心,只需重新启动即可启动系统。 当然,您必须阅读日志并找到根本原因,但是在那之前,它会使您保持理智。
## 第 2 课:服务分离
本课的实质是:**将过程和数据分组在不同的盒子**上。
在一个盒子上做太多的工作会导致**在作业**之间进行大量上下文切换。 尝试使每个数据库服务器以相同的方式服务于相同类型的数据库。 这意味着您的所有索引都将被缓存,并且不会被调入和调出。 保持所有内容尽可能相似。 不要使用 Python 线程。 他们很慢。 他们将所有内容放在单独的多个流程中。 垃圾邮件,缩略图等服务可查询缓存。 它使您可以轻松地将它们放在不同的计算机上。 您已经解决了流程之间通信的问题。 一旦解决,它就可以保持体系结构整洁,并且易于扩展。
## 第 3 课:开放式架构
本课程的本质是:**不必担心模式**。
他们过去经常花费大量时间来担心数据库,以保持一切正常和正常。 **您不必担心数据库**。 当您变大时,架构更新将非常缓慢。 将一列添加到一千万行需要锁定,因此不起作用。 他们使用复制进行备份和扩展。 模式更新和维护复制是一件痛苦的事情。 他们将不得不重新启动复制,并且可能一天没有备份。 部署是一件痛苦的事情,因为您必须协调新软件和新数据库的升级方式。
相反,他们保留了事物表和数据表。 Reddit 中的所有内容都是事物:用户,链接,评论,subreddit,奖项等。事物具有共同的属性,例如上下投票,类型和创建日期。 数据表具有三列:事物 ID,键,值。 每个属性都有一行。 标题,URL,作者,垃圾邮件票等都有一行。当他们添加新功能时,他们不必再担心数据库了。 他们不必为新事物添加新表,也不必担心升级。 更易于开发,部署,维护。 代价是您不能使用很棒的关系功能。 数据库中没有联接,您必须手动执行一致性。 没有联接意味着将数据分发到不同的机器真的很容易。 您不必担心外键正在执行联接或如何拆分数据。 工作得很好。 使用关系数据库的烦恼已经成为过去。
## 第 4 课:保持无状态
目标是让每个应用服务器处理每种类型的请求。 随着他们的成长,他们拥有更多的计算机,因此他们不再依赖于应用内服务器缓存。 他们最初将状态复制到每个应用程序服务器,这浪费了内存。 他们无法使用内存缓存,因为它们保留了大量的细粒度文件,这太慢了。 他们重写使用内存缓存,并且不将任何状态存储在应用服务器中。 如果应用服务器发生故障,则很容易。 为了扩展,您可以添加更多应用服务器。
## 第 5 课:内存缓存
本课的实质是:**内存缓存所有内容**。
它们将所有内容存储在内存缓存中:1.数据库数据 2.会话数据 3.呈现的页面 4.记忆(记住以前计算的结果)内部功能 5.限制用户操作,爬网程序的速率 6.存储预先计算的列表/页面 7.全局 锁定。
他们现在在 Memcachedb 中存储的数据比 Postgres 多。 就像记忆快取一样,但是会储存在磁碟上。 非常快。 所有查询均由同一控件生成,并缓存在 memcached 中。 更改密码链接和关联状态被缓存 20 分钟左右。 验证码也一样。 用于他们不想永久存储的链接。
他们在其框架中内置了备忘录。 计算结果也将被缓存:标准化页面,列表,所有内容。
使用 memcache +到期日期对所有内容进行速率限制。 保护您的系统免受攻击的好方法。 没有速率限制子系统,单个恶意用户可能会破坏系统。 不好。 因此,对于用户和爬网程序,他们将很多内容保留在内存缓存中。 如果用户在一秒钟内再次出现,他们将被弹跳。 普通用户的点击速度不太快,因此他们希望引起注意。 Google 搜寻器会以您希望的速度打击您,因此,当速度变慢时,只需提高限速器的速度,即可使系统安静下来而不会伤害用户。
Reddit 上的所有内容都是清单:首页,方框中的评论页。 所有这些都预先计算并转储到缓存中。 当您获得列表时,它将从缓存中获取。 每个链接和每个注释可能都存储在 100 个不同的版本中。 例如,具有 30 秒钟旧 2 票的链接是单独呈现和缓存的。 播放 30 秒后会再次呈现。 等等。 HTML 的每个小片段都来自缓存,因此不会浪费 CPU 渲染时间。 当事情变慢时,只需添加更多缓存即可。
当弄乱他们脆弱的不一致数据库时,他们使用内存缓存作为全局锁。 为他们工作甚至认为这不是最好的方法。
## 第 6 课:存储冗余数据
本课程的实质是:**速度的关键是预先计算所有内容并将其缓存**。
建立慢速网站的方法是拥有一个完全标准化的数据库,按需收集所有内容,然后进行渲染。 它永远需要每个单独的请求。 因此,如果您有可能以几种不同格式显示的数据(例如首页,收件箱或个人资料中的链接),请分别存储所有这些表示形式。 因此,当有人来获取数据时,该数据已经存在。
每个列表都有 15 个不同的排序顺序(本周热门,新,热门,旧)。 当某人提交链接时,他们会重新计算该链接可能影响的所有可能的列表。 前期可能有点浪费,但前期浪费比缓慢要好。 浪费磁盘和内存比让用户等待更好。
## 第 7 课:脱机工作
本课程的本质是:**在后端上进行最少的工作,并告诉用户您已完成**。
如果您需要做某事,请在用户不在等您时进行。 放入队列中。 当用户对可更新列表的 Reddit 进行投票时,该用户的 Karma 以及许多其他内容。 因此,一经表决,数据库便会更新以知道发生了表决,然后将作业放入队列中,该作业知道需要更新的 20 件事。 当用户回来时,一切都已经为他们预缓存了。
他们离线进行工作:1.预计算清单 2.提取缩略图 3.检测作弊。 4.删除垃圾邮件 5.计算奖励 6.更新搜索索引。
用户正在等待您时,无需执行**这些操作。 例如,随着 Reddit 变得越来越大,现在作弊的动机越来越高,因此当人们投票检测作弊时,他们在后端花费了大量时间。 但是它们确实是在后台运行的,因此不会降低用户体验。 演示文稿中的体系结构图为:![](https://img.kancloud.cn/7f/d5/7fd5c8b78e5c87c282ec88b221d40247_500x313.png)**
蓝色箭头表示当请求进入时发生的情况。假设某人提交了链接或投票,它将转到高速缓存,主数据库和作业队列。 然后他们返回给用户。 然后其余的事件会离线发生,这些由粉红色箭头表示。 诸如 Spam,Precomputer 和 Thumnailer 之类的服务从队列中读取,进行工作并根据需要更新数据库。 关键技术是 RabbitMQ。
## 相关文章
* [关于可扩展性的队列相关文章](http://highscalability.com/blog/category/queue)
* [](http://highscalability.com/blog/category/queue)**[Reddit 于 2010 年 5 月发布的“服务器状态”报告](http://blog.reddit.com/2010/05/reddits-may-2010-state-of-servers.html)**
对我而言,最有趣的部分是数据库中糟糕的 EAV 解决方案。 不带模式和模式验证的所有内容都作为字符串。 这通常会导致维护和效率方面的一些可怕问题,但这一次它可以正常工作。 可能是因为该模型非常简单,在其他许多情况下却无法正常工作
很棒的文章! 绝对提供了一些非常新的性能思考方式。
“但是它们确实是在后台运行的,因此不会降低用户体验”
“但是他们活着”
“现场直播”
好文章! 很好读
对于那些喜欢数学的人来说,每月 2.7 亿的页面浏览量就是每秒 100 个页面浏览量。 绝对不会出现需要 20 台数据库服务器的情况。
请谨慎选择您的建议。 互联网上很少有网站像 Reddit 一样频繁出现故障或性能不佳。
我总觉得这些家伙在后台做些聪明的事。 感谢您告诉我更多有关我最喜欢的社交书签网站的信息!
哦,我只是喜欢这种性能知识。
我们在设计架构以及随后像 Reddit 一样更新它们时也遇到了很多麻烦。 但是我必须同意 Simon 的观点,Reddit 的解决方案在许多其他情况下都行不通。
我同意 Haugeland 先生的观点,即必须拥有 20 台数据库服务器来处理负载似乎太过分了。 通过阅读评论,我看来原始作者未能认识到真正的教训。 这样的设计通常是开发团队不了解如何为底层数据库进行设计和编码的结果。 也许根据预期的使用情况和负载来选择错误的基础数据库。
这个已经过期了。 reddit 迁移到 Cassandra。
http://www.reddit.com/r/programming/comments/bcqhi/reddits_now_running_on_cassandra/
记忆快取不见了
哇! 这是一项很好的工作!
换句话说,运行可伸缩网站不该做什么。 我键入此内容时,Reddit 尚未再次打开。
我是 Reddit 的粉丝,我希望它会改变其基础设施以提供更多可用性。
MySQL(尤其是 MyISAM)给 RDBMSes 起了一个不好的名字。
我有一个以 Poststars 为后盾的应用程序,该应用程序以“星型模式”组织,有一个主事件表,我们平均每秒对其进行 200 次 INSERT 插入,例如高峰时为 400 ish,有 24 列,其中大多数是外键 动态增长的查询表,我们在同一秒内结合在一起执行了十二打 INSERT / SELECT。 这些查询表之一具有超过 2.13 亿行。 向该表中添加另一列是即时的,并为应用程序带来了零延迟。 这是因为 Postgres 将列视为元数据。
在 MySQL 中尝试这样做确实会“自杀”,而且绝对不是一种选择,因为 MySQL 需要重建整个表。 我不确定你们使用的是哪个版本的 Postgres,但是我发现锁定声明令人惊讶。
如果您热衷于使用 MySQL,那么请尽一切可能不使用 MyISAM 的方法,尝试将所有基于文本的索引和搜索推迟到 Sphinx 之类。 并尽可能保留尽可能多的表。
实际上,“对所有内容进行预先计算”实际上是扩展应用程序的第一条规则。 他们只是把它带到了大多数人无法接受的地方。
很棒的帖子! 我喜欢这种东西。
因此,您基本上将简单的键值存储入侵了 MySQL? 为什么不使用 Cassandra,couchdb,东京暴君,redis?
我想知道 Reddit 使用什么队列解决方案,以及迁移到 Cassandra 后是否仍在使用它(我认为它仍然有用)
比较 Digg 和 Reddit 的加载时间,我想说 Digg 做得正确,而 Reddit 做错了。
您是否真的复制了本文的编辑内容? 它充满了尴尬的写作,就像您在演示过程中起草并发布时一样,没有进行编辑。 第 4 课几乎是难以理解的。
达克,我同意第 4 课不是很好。 我要做的是总结发言者的发言,使其更简短,更直接地适用。 有时我不知道该怎么做,所以我只保留原理图版本。有几条衬里我认为不值得在一个点上阐述,但我还是留了一点 如果您真的有兴趣,可以决定观看视频。
哦,瞧,又一家没有实际客户的网络创业公司,因此他们不必担心数据完整性,而且显然无力聘请知道数据库工作原理的人来决定适当的 RDBMS 设计是否起作用 首先,他们的问题显然不适合于关系模型。 现在他们有 40 台服务器从事 2 台服务器的工作,应该给我们留下深刻的印象吗? 伙计们,雇用 DBA 比重塑持久性存储便宜得多。
开放模式部分使它看起来像是 NoSql 的理想候选者...
chris h:只有确实要添加列时,Postgres 中的 no-locking 选项才可用。 如果要更改列的数据类型,或将列移到其他表,会发生什么?
ChronicDB 声称将实时模式更改应用于 Postgres。
@WayneB-digg 也不正确。 他们有 200 台服务器,现在处理的流量少于 reddit。
@John Haugeland:我完全同意你的看法。 这是一篇有关开发团队如何找到经验不足的解决方法的文章。
这是一篇很有帮助的文章。 感谢您分享所有这些很棒的技巧。 希望他们能对您有所帮助!
Reddit 太慢了……我想他们有一些新的挑战和教训要学习,因为在大多数情况下它似乎无法使用。
- LiveJournal 体系结构
- mixi.jp 体系结构
- 友谊建筑
- FeedBurner 体系结构
- GoogleTalk 架构
- ThemBid 架构
- 使用 Amazon 服务以 100 美元的价格构建无限可扩展的基础架构
- TypePad 建筑
- 维基媒体架构
- Joost 网络架构
- 亚马逊建筑
- Fotolog 扩展成功的秘诀
- 普恩斯的教训-早期
- 论文:Wikipedia 的站点内部,配置,代码示例和管理问题
- 扩大早期创业规模
- Feedblendr 架构-使用 EC2 进行扩展
- Slashdot Architecture-互联网的老人如何学会扩展
- Flickr 架构
- Tailrank 架构-了解如何在整个徽标范围内跟踪模因
- Ruby on Rails 如何在 550k 网页浏览中幸存
- Mailinator 架构
- Rackspace 现在如何使用 MapReduce 和 Hadoop 查询 TB 的数据
- Yandex 架构
- YouTube 架构
- Skype 计划 PostgreSQL 扩展到 10 亿用户
- 易趣建筑
- FaceStat 的祸根与智慧赢得了胜利
- Flickr 的联合会:每天进行数十亿次查询
- EVE 在线架构
- Notify.me 体系结构-同步性
- Google 架构
- 第二人生架构-网格
- MySpace 体系结构
- 扩展 Digg 和其他 Web 应用程序
- Digg 建筑
- 在 Amazon EC2 中部署大规模基础架构的六个经验教训
- Wolfram | Alpha 建筑
- 为什么 Facebook,Digg 和 Twitter 很难扩展?
- 全球范围扩展的 10 个 eBay 秘密
- BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展
- 《 FarmVille》如何扩展以每月收获 7500 万玩家
- Twitter 计划分析 1000 亿条推文
- MySpace 如何与 100 万个并发用户一起测试其实时站点
- FarmVille 如何扩展-后续
- Justin.tv 的实时视频广播架构
- 策略:缓存 404 在服务器时间上节省了洋葱 66%
- Poppen.de 建筑
- MocoSpace Architecture-一个月有 30 亿个移动页面浏览量
- Sify.com 体系结构-每秒 3900 个请求的门户
- 每月将 Reddit 打造为 2.7 亿页面浏览量时汲取的 7 个教训
- Playfish 的社交游戏架构-每月有 5000 万用户并且不断增长
- 扩展 BBC iPlayer 的 6 种策略
- Facebook 的新实时消息系统:HBase 每月可存储 135 亿条消息
- Pinboard.in Architecture-付费玩以保持系统小巧
- BankSimple 迷你架构-使用下一代工具链
- Riak 的 Bitcask-用于快速键/值数据的日志结构哈希表
- Mollom 体系结构-每秒以 100 个请求杀死超过 3.73 亿个垃圾邮件
- Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求
- Node.js 成为堆栈的一部分了吗? SimpleGeo 说是的。
- 堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量
- Medialets 体系结构-击败艰巨的移动设备数据
- Facebook 的新实时分析系统:HBase 每天处理 200 亿个事件
- Microsoft Stack 是否杀死了 MySpace?
- Viddler Architecture-每天嵌入 700 万个和 1500 Req / Sec 高峰
- Facebook:用于扩展数十亿条消息的示例规范架构
- Evernote Architecture-每天有 900 万用户和 1.5 亿个请求
- TripAdvisor 的短
- TripAdvisor 架构-4,000 万访客,200M 动态页面浏览,30TB 数据
- ATMCash 利用虚拟化实现安全性-不变性和还原
- Google+是使用您也可以使用的工具构建的:闭包,Java Servlet,JavaScript,BigTable,Colossus,快速周转
- 新的文物建筑-每天收集 20 亿多个指标
- Peecho Architecture-鞋带上的可扩展性
- 标记式架构-扩展到 1 亿用户,1000 台服务器和 50 亿个页面视图
- 论文:Akamai 网络-70 个国家/地区的 61,000 台服务器,1,000 个网络
- 策略:在 S3 或 GitHub 上运行可扩展,可用且廉价的静态站点
- Pud 是反堆栈-Windows,CFML,Dropbox,Xeround,JungleDisk,ELB
- 用于扩展 Turntable.fm 和 Labmeeting 的数百万用户的 17 种技术
- StackExchange 体系结构更新-平稳运行,Amazon 4x 更昂贵
- DataSift 体系结构:每秒进行 120,000 条推文的实时数据挖掘
- Instagram 架构:1400 万用户,1 TB 的照片,数百个实例,数十种技术
- PlentyOfFish 更新-每月 60 亿次浏览量和 320 亿张图片
- Etsy Saga:从筒仓到开心到一个月的浏览量达到数十亿
- 数据范围项目-6PB 存储,500GBytes / sec 顺序 IO,20M IOPS,130TFlops
- 99designs 的设计-数以千万计的综合浏览量
- Tumblr Architecture-150 亿页面浏览量一个月,比 Twitter 更难扩展
- Berkeley DB 体系结构-NoSQL 很酷之前的 NoSQL
- Pixable Architecture-每天对 2000 万张照片进行爬网,分析和排名
- LinkedIn:使用 Databus 创建低延迟更改数据捕获系统
- 在 30 分钟内进行 7 年的 YouTube 可扩展性课程
- YouPorn-每天定位 2 亿次观看
- Instagram 架构更新:Instagram 有何新功能?
- 搜索技术剖析:blekko 的 NoSQL 数据库
- Pinterest 体系结构更新-1800 万访问者,增长 10 倍,拥有 12 名员工,410 TB 数据
- 搜索技术剖析:使用组合器爬行
- iDoneThis-从头开始扩展基于电子邮件的应用程序
- StubHub 体系结构:全球最大的票务市场背后的惊人复杂性
- FictionPress:在网络上发布 600 万本小说
- Cinchcast 体系结构-每天产生 1,500 小时的音频
- 棱柱架构-使用社交网络上的机器学习来弄清您应该在网络上阅读的内容
- 棱镜更新:基于文档和用户的机器学习
- Zoosk-实时通信背后的工程
- WordPress.com 使用 NGINX 服务 70,000 req / sec 和超过 15 Gbit / sec 的流量
- 史诗般的 TripAdvisor 更新:为什么不在云上运行? 盛大的实验
- UltraDNS 如何处理数十万个区域和数千万条记录
- 更简单,更便宜,更快:Playtomic 从.NET 迁移到 Node 和 Heroku
- Spanner-关于程序员使用 NoSQL 规模的 SQL 语义构建应用程序
- BigData 使用 Erlang,C 和 Lisp 对抗移动数据海啸
- 分析数十亿笔信用卡交易并在云中提供低延迟的见解
- MongoDB 和 GridFS 用于内部和内部数据中心数据复制
- 每天处理 1 亿个像素-少量竞争会导致大规模问题
- DuckDuckGo 体系结构-每天进行 100 万次深度搜索并不断增长
- SongPop 在 GAE 上可扩展至 100 万活跃用户,表明 PaaS 未通过
- Iron.io 从 Ruby 迁移到 Go:减少了 28 台服务器并避免了巨大的 Clusterf ** ks
- 可汗学院支票簿每月在 GAE 上扩展至 600 万用户
- 在破坏之前先检查自己-鳄梨的建筑演进的 5 个早期阶段
- 缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量
- Facebook 的网络秘密
- 神话:埃里克·布鲁尔(Eric Brewer)谈银行为什么不是碱-可用性就是收入
- 一千万个并发连接的秘密-内核是问题,而不是解决方案
- GOV.UK-不是你父亲的书库
- 缩放邮箱-在 6 周内从 0 到 100 万用户,每天 1 亿条消息
- 在 Yelp 上利用云计算-每月访问量为 1.02 亿,评论量为 3900 万
- 每台服务器将 PHP 扩展到 30,000 个并发用户的 5 条 Rockin'Tips
- Twitter 的架构用于在 5 秒内处理 1.5 亿活跃用户,300K QPS,22 MB / S Firehose 以及发送推文
- Salesforce Architecture-他们每天如何处理 13 亿笔交易
- 扩大流量的设计决策
- ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行
- 如何制作无限可扩展的关系数据库管理系统(RDBMS)
- Bazaarvoice 的架构每月发展到 500M 唯一用户
- HipChat 如何使用 ElasticSearch 和 Redis 存储和索引数十亿条消息
- NYTimes 架构:无头,无主控,无单点故障
- 接下来的大型声音如何使用 Hadoop 数据版本控制系统跟踪万亿首歌曲的播放,喜欢和更多内容
- Google 如何备份 Internet 和数十亿字节的其他数据
- 从 HackerEarth 用 Apache 扩展 Python 和 Django 的 13 个简单技巧
- AOL.com 体系结构如何发展到 99.999%的可用性,每天 800 万的访问者和每秒 200,000 个请求
- Facebook 以 190 亿美元的价格收购了 WhatsApp 体系结构
- 使用 AWS,Scala,Akka,Play,MongoDB 和 Elasticsearch 构建社交音乐服务
- 大,小,热还是冷-条带,Tapad,Etsy 和 Square 的健壮数据管道示例
- WhatsApp 如何每秒吸引近 5 亿用户,11,000 内核和 7,000 万条消息
- Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延迟进行实时处理
- 关于 Disqus 的更新:它仍然是实时的,但是 Go 摧毁了 Python
- 关于 Wayback 机器如何在银河系中存储比明星更多的页面的简短说明
- 在 PagerDuty 迁移到 EC2 中的 XtraDB 群集
- 扩展世界杯-Gambify 如何与 2 人组成的团队一起运行大型移动投注应用程序
- 一点点:建立一个可处理每月 60 亿次点击的分布式系统的经验教训
- StackOverflow 更新:一个月有 5.6 亿次网页浏览,25 台服务器,而这一切都与性能有关
- Tumblr:哈希处理每秒 23,000 个博客请求的方式
- 使用 HAProxy,PHP,Redis 和 MySQL 处理 10 亿个请求的简便方法来构建成长型启动架构
- MixRadio 体系结构-兼顾各种服务
- Twitter 如何使用 Redis 进行扩展-105TB RAM,39MM QPS,10,000 多个实例
- 正确处理事情:通过即时重放查看集中式系统与分散式系统
- Instagram 提高了其应用程序的性能。 这是如何做。
- Clay.io 如何使用 AWS,Docker,HAProxy 和 Lots 建立其 10 倍架构
- 英雄联盟如何将聊天扩大到 7000 万玩家-需要很多小兵。
- Wix 的 Nifty Architecture 技巧-大规模构建发布平台
- Aeron:我们真的需要另一个消息传递系统吗?
- 机器:惠普基于忆阻器的新型数据中心规模计算机-一切仍在变化
- AWS 的惊人规模及其对云的未来意味着什么
- Vinted 体系结构:每天部署数百次,以保持繁忙的门户稳定
- 将 Kim Kardashian 扩展到 1 亿个页面
- HappyPancake:建立简单可扩展基金会的回顾
- 阿尔及利亚分布式搜索网络的体系结构
- AppLovin:通过每天处理 300 亿个请求向全球移动消费者进行营销
- Swiftype 如何以及为何从 EC2 迁移到真实硬件
- 我们如何扩展 VividCortex 的后端系统
- Appknox 架构-从 AWS 切换到 Google Cloud
- 阿尔及利亚通往全球 API 的愤怒之路
- 阿尔及利亚通往全球 API 步骤的愤怒之路第 2 部分
- 为社交产品设计后端
- 阿尔及利亚通往全球 API 第 3 部分的愤怒之路
- Google 如何创造只有他们才能创造的惊人的数据中心网络
- Autodesk 如何在 Mesos 上实施可扩展事件
- 构建全球分布式,关键任务应用程序:Trenches 部分的经验教训 1
- 构建全球分布式,关键任务应用程序:Trenches 第 2 部分的经验教训
- 需要物联网吗? 这是美国一家主要公用事业公司从 550 万米以上收集电力数据的方式
- Uber 如何扩展其实时市场平台
- 优步变得非常规:使用司机电话作为备份数据中心
- 在不到五分钟的时间里,Facebook 如何告诉您的朋友您在灾难中很安全
- Zappos 的网站与 Amazon 集成后冻结了两年
- 为在现代时代构建可扩展的有状态服务提供依据
- 细分:使用 Docker,ECS 和 Terraform 重建基础架构
- 十年 IT 失败的五个教训
- Shopify 如何扩展以处理来自 Kanye West 和 Superbowl 的 Flash 销售
- 整个 Netflix 堆栈的 360 度视图
- Wistia 如何每小时处理数百万个请求并处理丰富的视频分析
- Google 和 eBay 关于构建微服务生态系统的深刻教训
- 无服务器启动-服务器崩溃!
- 在 Amazon AWS 上扩展至 1100 万以上用户的入门指南
- 为 David Guetta 建立无限可扩展的在线录制活动
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿个通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训
- 缩放原理
- TripleLift 如何建立 Adtech 数据管道每天处理数十亿个事件
- Tinder:最大的推荐引擎之一如何决定您接下来会看到谁?
- 如何使用微服务建立财产管理系统集成
- Egnyte 体系结构:构建和扩展多 PB 分布式系统的经验教训
- Zapier 如何自动化数十亿个工作流自动化任务的旅程
- Jeff Dean 在 Google 进行大规模深度学习
- 如今 Etsy 的架构是什么样的?
- 我们如何在 Mail.Ru Cloud 中实现视频播放器
- Twitter 如何每秒处理 3,000 张图像
- 每天可处理数百万个请求的图像优化技术
- Facebook 如何向 80 万同时观看者直播
- Google 如何针对行星级基础设施进行行星级工程设计?
- 为 Mail.Ru Group 的电子邮件服务实施反垃圾邮件的猫捉老鼠的故事,以及 Tarantool 与此相关的内容
- The Dollar Shave Club Architecture Unilever 以 10 亿美元的价格被收购
- Uber 如何使用 Mesos 和 Cassandra 跨多个数据中心每秒管理一百万个写入
- 从将 Uber 扩展到 2000 名工程师,1000 个服务和 8000 个 Git 存储库获得的经验教训
- QuickBooks 平台
- 美国大选期间城市飞艇如何扩展到 25 亿条通知
- Probot 的体系结构-我的 Slack 和 Messenger Bot 用于回答问题
- AdStage 从 Heroku 迁移到 AWS
- 为何将 Morningstar 迁移到云端:降低 97%的成本
- ButterCMS 体系结构:关键任务 API 每月可处理数百万个请求
- Netflix:按下 Play 会发生什么?
- ipdata 如何以每月 150 美元的价格为来自 10 个无限扩展的全球端点的 2500 万个 API 调用提供服务
- 每天为 1000 亿个事件赋予意义-Teads 的 Analytics(分析)管道
- Auth0 体系结构:在多个云提供商和地区中运行
- 从裸机到 Kubernetes
- Egnyte Architecture:构建和扩展多 PB 内容平台的经验教训