# 堆栈溢出体系结构更新-现在每月有 9500 万页面浏览量
> 原文: [http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html)
![](https://img.kancloud.cn/cf/ab/cfab7bd4e70e5d75fa0490b3d1cdfb08_200x56.png)
自从我的第一篇关于 [Stack Overflow Architecture](/blog/2009/8/5/stack-overflow-architecture.html) 的文章以来发生了很多事情。 与上一篇文章的主题相反,该主题引起了人们对 Stack Overflow 致力于扩大规模战略的关注,但在过去的几年中,Stack Overflow 不断发展壮大。
Stack Overflow 的规模增长了两倍以上,超过 1600 万用户,其页面浏览量几乎翻了六倍,达到每月 9500 万页面浏览量。
堆栈溢出通过扩展到[堆栈交换网络](http://stackexchange.com/)而得以发展,该网络包括堆栈溢出,服务器故障和超级用户(总共 43 个不同站点)。 进行着很多富有成果的乘法。
不变的是,Stack Overflow 对他们正在做的事情持开放态度。 这就是促使进行此更新的原因。 最近的一系列帖子讨论了他们如何处理增长问题:[堆栈交换的体系结构以[项目符号]](http://blog.serverfault.com/post/stack-exchanges-architecture-in-bullet-points/) , [Stack Overflow 的纽约数据中心](http://blog.serverfault.com/2010/10/29/1432571770/),[为可伸缩性而设计 管理和容错](http://blog.serverfault.com/post/1097492931/),[堆栈溢出搜索-现在](http://blog.stackoverflow.com/2011/01/stack-overflow-search-now-81-less-crappy/),[堆栈溢出网络配置](http://blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/),[减少 81%StackOverflow 是否使用缓存?如果使用缓存,如何使用缓存?](http://meta.stackoverflow.com/questions/69164/does-stackoverflow-use-caching-and-if-so-how) ,[哪些工具和技术构建了堆栈交换网络?](http://meta.stackoverflow.com/questions/10369/which-tools-and-technologies-build-the-stack-exchange-network) 。
跨时间的一些更明显的差异是:
* **更多**。 更多用户,更多页面视图,更多数据中心,更多站点,更多开发人员,更多操作系统,更多数据库,更多机器。 的数量更多。
* **Linux** 。 堆栈溢出以其 Windows 堆栈而闻名,现在他们将更多的 Linux 机器用于 HAProxy,Redis,Bacula,Nagios,日志和路由器。 所有支持功能似乎都由 Linux 处理,这需要开发[并行发布过程](http://blog.serverfault.com/post/1097492931/)。
* **容错**。 现在,堆栈溢出(HTG2)由两个不同 Internet 连接上的两个不同交换机提供服务,它们添加了冗余计算机,并且某些功能已移至另一个数据中心。
* **NoSQL** 。 Redis 现在用作整个网络的[缓存层](http://meta.stackoverflow.com/questions/69164/does-stackoverflow-use-caching-and-if-so-how)。 之前没有单独的缓存层,所以这是一个很大的变化,就像在 Linux 上使用 NoSQL 数据库一样。
不幸的是,我找不到关于我上次遇到的一些未解决问题的报道,例如它们将如何处理这么多不同属性的多租户,但仍然有很多值得学习的地方。 这里汇总了一些不同的来源:
### 统计资料
* 每月 9500 万页面浏览量
* 每秒 800 个 HTTP 请求
* 180 个 DNS 请求每秒
* 每秒 55 兆位
* 1600 万用户-流量向堆栈溢出的流量在 2010 年增长了 131%,达到每月 1,660 万全球唯一身份用户。
### 数据中心
* 1 个带有 Peak Internet 的机架(或)(托管我们的聊天和数据资源管理器)
* 2 个在纽约拥有对等 1 的机架(托管其余的 Stack Exchange Network)
### 硬件
* 10 台 Dell R610 IIS Web 服务器(其中 3 台专用于堆栈溢出):
* 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz 四核,带 8 个线程
* 16 GB RAM
* Windows Server 2008 R2
* 2 台 Dell R710 数据库服务器:
* 2 个 Intel Xeon 处理器 X5680 @ 3.33 GHz
* 64 GB 内存
* 8 锭
* SQL Server 2008 R2
* 2 台 Dell R610 HAProxy 服务器:
* 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz
* 4 GB 内存
* Ubuntu 服务器
* 2 台 Dell R610 Redis 服务器:
* 2 个 Intel Xeon 处理器 E5640 @ 2.66 GHz
* 16 GB RAM
* CentOS 的
* 1 台运行 Bacula 的 Dell R610 Linux 备份服务器:
* 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz
* 32 GB 内存
* 1 台用于 Nagios 和日志的 Dell R610 Linux 管理服务器:
* 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz
* 32 GB 内存
* 2 个 Dell R610 VMWare ESXi 域控制器:
* 1 个 Intel Xeon 处理器 E5640 @ 2.66 GHz
* 16 GB RAM
* 2 个 Linux 路由器
* 5 个 Dell Power Connect 交换机
### 开发工具
* **C#**:语言
* **Visual Studio 2010 Team Suite** : IDE
* **Microsoft ASP.NET(4.0 版)** :框架
* **ASP.NET MVC 3** : Web 框架
* **剃刀** :视图引擎
* **jQuery 1.4.2** :浏览器框架:
* **LINQ to SQL,一些原始 SQL** :数据访问层
* **水银和窑** :源代码管理
* **Beyond Compare 3** :比较工具
### 使用的软件和技术
* 堆栈溢出通过 [BizSpark](http://blog.stackoverflow.com/2009/03/stack-overflow-and-bizspark/) 使用 [WISC](http://stackoverflow.com/questions/177901/what-does-wisc-stack-mean) 堆栈
* **Windows Server 2008 R2 x64** :操作系统
* **运行 **Microsoft Windows Server 2008 Enterprise Edition x64** 的 SQL Server 2008 R2** :数据库
* Ubuntu 服务器
* CentOS 的
* **IIS 7.0** :Web 服务器
* **HAProxy** :用于负载均衡
* **Redis** :用作分布式缓存层。
* **CruiseControl.NET** :用于构建和自动部署
* **Lucene.NET** :进行搜索
* **Bacula** :用于备份
* **Nagios** :(带有 [n2rrd](http://n2rrd.diglinks.com/cgi-bin/trac.fcgi) 和 drraw 插件)用于监视
* **Splunk:**用于日志
* **SQL Monitor:来自 Red Gate 的**-用于 SQL Server 监视
* **绑定**:用于 DNS
* **[Rovio](http://www.wowwee.com/en/products/tech/telepresence/rovio/rovio)** :一个小机器人(真正的机器人),允许远程开发人员“虚拟地”访问办公室。
* **Pingdom** :外部监视器和警报服务。
### 外部钻头
开发工具中未包含的代码:
* 验证码
* DotNetOpenId
* WMD-现在已开发为开源。 见 github 网络图
* 美化
* 谷歌分析
* 巡航控制.NET
* HAProxy
* 仙人掌
* 降价锐利
* 美丽
* Nginx 的
* 窑
* CDN:无,所有静态内容均由 [sstatic.net](http://sstatic.net/) 提供,这是一个快速,无 cookie 的域,用于将静态内容传递给 Stack Exchange 系列网站。
### 开发人员和系统管理员
* 14 个开发人员
* 2 个系统管理员
### 内容
* **许可:**知识共享署名-相同方式共享份额为 2.5
* **标准:** OpenSearch,Atom
* **主持人:** PEAK Internet
### 更多架构和经验教训
* 使用 HAProxy 而不是 Windows NLB,因为 HAProxy 便宜,简单,免费,可通过 Hyper-V 用作网络上的 512MB VM``设备''。 它也可以在盒子前面使用,因此对它们完全透明,并且更容易作为另一个网络层进行故障排除,而不必与所有 Windows 配置混在一起。
* 不使用 CDN 是因为,即使像亚马逊这样的“便宜” CDN 相对于捆绑到现有主机计划中的带宽而言也非常昂贵。 根据 Amazon 的 CDN 费率和带宽使用情况,他们每月至少可以支付 1000 美元。
* 备份到磁盘以进行快速检索,而备份到磁带以进行历史存档。
* SQL Server 中的全文本搜索集成度很差,有故障,非常不称职,因此他们选择了 Lucene。
* 人们对峰值 HTTP 请求数据最感兴趣,因为这是他们确保可以处理的需求。
* 现在,所有属性都在相同的 Stack Exchange 平台上运行。 这意味着堆栈溢出,超级用户,服务器故障,元,WebApp 和元 Web 应用都在同一软件上运行。
* 有单独的 StackExchange 网站,因为人们有不同的专业知识集,不应跨入不同的主题网站。 [您可以成为世界上最伟大的厨师,但这并不意味着您有资格修理服务器。](http://meta.stackoverflow.com/questions/69422/why-separate-stack-exchange-accounts)
* 他们积极地缓存一切。
* 通过[输出缓存](http://learn.iis.net/page.aspx/154/walkthrough-iis-70-output-caching/)缓存匿名用户访问(并随后提供给匿名用户)的所有页面。
* 每个站点都有 3 个不同的缓存:本地,站点,全局。
* **本地缓存**:只能从 1 个服务器/站点对访问
* 为了限制网络延迟,他们使用服务器上最近设置/读取的值的本地“ L1”缓存,基本上是 HttpRuntime.Cache。 这会将网络上的高速缓存查找开销减少到 0 字节。
* 包含用户会话和未决视图计数更新之类的内容。
* 它完全驻留在内存中,没有网络或数据库访问权限。
* **网站缓存**:单个网站的任何实例(在任何服务器上)都可以访问
* 大多数缓存的值都在这里,诸如热门问题 ID 列表和用户接受率之类的例子就是很好的例子
* 它驻留在 Redis 中(在一个单独的数据库中,纯粹是为了简化调试)
* Redis 是如此之快,以至于缓存查找最慢的部分就是花费的时间在网络上读写字节。
* 将值压缩后再将其发送到 Redis。 它们具有大量的 CPU,并且大多数数据是字符串,因此它们具有很高的压缩率。
* 他们的 Redis 计算机上的 CPU 使用率为 0%。
* **全局缓存**:在所有站点和服务器之间共享
* 收件箱,API 使用配额和其他一些真正的全局信息都在这里
* 它位于 Redis 中(在 DB 0 中,同样也便于调试)
* 缓存中的大多数项目会在超时时间(通常为几分钟)后过期,并且永远不会明确删除。 当需要特定的缓存失效时,他们使用 [Redis 消息](http://code.google.com/p/redis/wiki/PublishSubscribe)将删除通知发布到“ L1”缓存。
* 乔尔·斯波斯基(Joel Spolsky)不是 Microsoft 的忠实拥护者,他没有为 Stack Overflow 做出技术决策,并且认为 Microsoft 授权存在舍入错误。 考虑自己已更正 [Hacker News 评论员](http://news.ycombinator.com/item?id=2284900)。
* 他们为 IO 系统[选择了](http://blog.serverfault.com/post/our-storage-decision/) RAID 10 阵列,其中 [Intel X25 固态驱动器](http://www.intel.com/design/flash/nand/extreme/index.htm)。 RAID 阵列缓解了对可靠性的任何担忧,并且与 FusionIO 相比,SSD 驱动器的性能确实很好,且价格便宜得多。
* 他们的 Microsoft 许可的[全船费用](http://news.ycombinator.com/item?id=2285931)约为$ 242K。 由于 Stack Overflow 使用的是 Bizspark,因此他们所支付的价格接近全价,但这是他们所能支付的最高价。
* [英特尔 NIC 正在取代 Broadcom NIC](http://blog.serverfault.com/post/broadcom-die-mutha/) 及其主要生产服务器。 这解决了他们在连接丢失,数据包丢失和 arp 表损坏时遇到的问题。
## 相关文章
* [此帖子上的黑客新闻主题](http://news.ycombinator.com/item?id=2284900) / [Reddit 主题](http://www.reddit.com/r/programming/comments/fwpik/stackoverflow_scales_using_a_mixture_of_linux_and/)
* [项目符号中的堆栈交换体系结构](http://blog.serverfault.com/post/stack-exchanges-architecture-in-bullet-points/) / [HackerNews 线程](http://news.ycombinator.com/item?id=2207789)
* [Stack Overflow 的纽约数据中心](http://blog.serverfault.com/post/1432571770/)-各种计算机的硬件是什么?
* [设计用于管理和容错的可伸缩性](http://blog.serverfault.com/post/1097492931/)
* [堆栈溢出博客](http://blog.stackoverflow.com/)
* [堆栈溢出搜索-现在减少了 81%的废话](http://blog.stackoverflow.com/2011/01/stack-overflow-search-now-81-less-crappy/)-Lucene 现在正在未充分利用的集群上运行。
* [2010 年堆栈状态(您的 CEO 的来信)](http://blog.stackoverflow.com/2011/01/state-of-the-stack-2010-a-message-from-your-ceo/)
* [堆栈溢出网络配置](http://blog.stackoverflow.com/2010/01/stack-overflow-network-configuration/)
* [StackOverflow 是否使用缓存?如果使用缓存,如何使用缓存?](http://meta.stackoverflow.com/questions/69164/does-stackoverflow-use-caching-and-if-so-how)
* [Meta StackOverflow](http://meta.stackoverflow.com/)
* [StackOverflow 如何处理缓存失效?](http://meta.stackoverflow.com/questions/6435/how-does-stackoverflow-handle-cache-invalidation)
* [哪些工具和技术构建了堆栈交换网络?](http://meta.stackoverflow.com/questions/10369/which-tools-and-technologies-build-the-stack-exchange-network)
* [堆栈溢出如何处理垃圾邮件?](http://meta.stackoverflow.com/questions/2765/how-does-stack-overflow-handle-spam)
* [我们的存储决策](http://blog.serverfault.com/post/our-storage-decision/)
* [如何选择“热门”问题?](http://meta.stackoverflow.com/questions/4766/how-are-hot-questions-selected)
* [如何选择“相关”问题?](http://meta.stackoverflow.com/questions/20473/how-are-related-questions-selected) -标题,问题正文和标签。
* [堆栈溢出和 DVCS](http://blog.stackoverflow.com/2010/04/stack-overflow-and-dvcs/) -堆栈溢出选择 Mercurial 进行源代码控制。
* [服务器故障聊天室](http://chat.stackexchange.com/rooms/127/the-comms-room)
* [C#Redis 客户端](https://github.com/ServiceStack/ServiceStack.Redis)
* [Broadcom,Die Mutha](http://blog.serverfault.com/post/broadcom-die-mutha/)
他们是否解释了为什么使用 Redis 而不是 Memcached 进行缓存? 我听说很多人使用 Redis 进行缓存,只是想知道 Redis 做什么,而 Memcached 不会呢?
如果我没记错的话,Redis 不是分布式数据库,对吗? 使用 memcached 时,如果我添加新节点,客户端将自动重新分发缓存,以利用额外的容量。 Redis 不会那样做。 那么,为什么要使用 Redis?
> 备份到磁盘以进行快速检索,而备份到磁带以进行历史存档。
真? 人们还在这样做吗? 我知道一些组织在自动化的自动磁带备份上投入了大量资金,但是说真的,一个成立于 2008 年的网站正在备份磁带吗?
为什么有人会在 Linux / Linux 上使用 Windows / asp?
我真的很惊讶人们仍然在做这样的事情。
*为什么有人会在 Linux / Linux 上使用 Windows / asp?
确实让我感到惊讶的是,人们仍然在做这样的事情。*
因为.NET 是目前最好的开发框架之一。 而且用于网络的 linux 便宜,因此结合起来很有意义。
@约翰
使用 Redis 或 membase 之类的东西而不是 memcached 的优点之一是可以将缓存持久化到磁盘上,这样可以避免缓存脱机然后重新启动时出现缓存风暴问题。
我猜我们不知道 Redis 框的配置是什么 他们是分片,进行主/从复制等吗?
安迪
@Joe,如果您知道自己的想法,那么逻辑就很容易:Joel 是 MS Excel 团队的成员,该团队编写了 VBA 和 OLE 自动化。
@Joe-这是我在该网站上看到的最不明智的评论之一。
詹姆斯:备份到磁带意味着脱机/档案备份。 这通常是值得的花费和麻烦,特别是对于大型重要数据集。 一两三周后,我可以告诉您,Gmail 员工非常非常高兴他们备份到磁带上。 如果您的所有副本都在线,则总是存在一个错误或手指滑动同时擦拭它们的可能性。
从技术上讲,IIS 7.0:Web 服务器不正确,在 Windows Server 2008R2 下,它实际上是 IIS 7.5:Web 服务器。
@Sosh-请放轻松,不要提升自己对 Microsoft 产品的支持。 在最好和最新的开源公司及其社区中运行 MS 产品没有技术上的原因。 实际上,要真正推动这一点,StackOverflow 团队应该在各地使用更多*付费/许可*的 ms 产品来推动其发展。 还有一种观点认为,可以针对工作使用最佳工具组合,因此请参见此处。 答案很简单:StackOverflow 团队了解 MS 产品,Visual Studio,C#和.NET,因此(对于该团队而言)交付 StackExchange 系列站点是最便宜,最快的。 ^ M
他们有明确的绩效目标吗? 他们如何在负载下监视站点性能? 对于在 HighScalability.com 上进行介绍的任何网站,这些问题似乎都是重要的问题。
是的,大多数拥有重要数据的人仍然使用磁带。 另外,它们是 Windows,因为创始人是微软的老家伙!
**[仅使用更好的应用程序,您可以避免软件许可和网络硬件成本。 伺服器:](http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/ "You can avoid software license AND network hhardware costs by just using a better app. server")**
每秒服务器请求
---------------------------------------------
G-WAN Web 服务器....... 142,000
Lighttpd Web 服务器........ 60,000
Nginx Web 服务器............ 57,000
Varnish 缓存服务器....... 28,000
SQL Server 2008 R2 Standard 或 Enterprise Edition?
“现在他们正在为 HAProxy Redis 使用更多的 Linux 计算机,”
http://redis.io/clients
Windows 上运行的 C#如何与 Linux 上的 Redis 对话?
- 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 内容平台的经验教训