# StackExchange 体系结构更新-平稳运行，Amazon 4x 更昂贵 > 原文： [http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html)  我们已经发表了几篇关于 [StackOverlflow Architecture](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) 和 [Stack Overflow Architecture Update 的文章-每月浏览量为 9500 万页](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html)。 是时候进行另一次更新了。 这次来自播客。 杰夫，乔尔（Jeff，Joel）和客人每星期大约坐在一起交谈。 结果是[播客](http://blog.stackoverflow.com/category/podcasts/)。 在最近的[播客](http://blog.stackoverflow.com/2011/09/se-podcast-17/)中，他们讨论了他们最近的一些体系结构问题，问题和更新。 自从我在休假前写这篇文章以来，他们还发布了新的体系结构更新文章： [The Stack Exchange Architecture – 2011 Edition，Episode 1](http://blog.serverfault.com/post/the-stack-exchange-architecture-2011-edition-episode-1/) 。 我的总体印象是他们在一个舒适的地方，添加了新的网站，添加了新的功能，使房屋成为了家。 以他们的向上扩展架构而闻名，您可能会期望随着他们的成长，他们会撞墙。 不是这样 他们已经能够通过增加更多的 CPU 和 RAM 来扩展单个服务器的功能。 在某些情况下已添加 SSD。 甚至他们的旗舰产品 StackOverflow 产品都在单个服务器上运行。 已经购买了新机器，但数量很少。 因此，StackOverflow 实验表明，即使是规模较大的站点，也都应按比例放大策略。 没错，就像早期的 Facebook 一样，他们的产品自然按照主题分开，但是摩尔定律和质量工程是您的朋友。 他们估计亚马逊将花费他们四倍的钱。 这是 StackExchange 所做的： * 他们在俄勒冈州有一个机架，在纽约的 Peer1 有两个笼子。 * 检查电源并不会全部故障转移到单个电源，如果实际发生故障，该电源将发生故障 * 新建了 10 台服务器 约克。 9 个生产服务器。 1 个质量检查服务器。 * 堆栈溢出具有大型服务器，SSD 和更多 RAM。 他们在某些计算机上添加了更多的处理器和更多的 RAM，以便可以运行 Lucene * Oregon 运行数据浏览器并进行聊天。 如果您无法到达纽约，您仍然可以聊天。 堆栈交换博客在俄勒冈运行，所有其他博客在纽约。 * 机架非常狭窄，尤其是具有大量用于冗余电源和网络连接的电缆。 * 应该在 Peer1 处购买机架而不是笼子。 那会给更多的空间。 * 纽约的存在使他们更接近欧洲用户。 * 保留俄勒冈州的位置，因为它很便宜，而且拥有另一个位置很方便。 * 考虑具有故障转移模式，以便所有 NY 通信量都可以只读模式故障转移到俄勒冈州。 您不能提出新的问题，但是由于该站点的大部分价值都来自于阅读，因此只读站点具有价值。 * 他们具有以下只读模式： * 当他们将 Stack Overflow 移至其自己的数据库服务器时。 * 当他们从俄勒冈州移居到纽约时。 * 具有两个站点都可以处理写入的双活体系结构太复杂了。 * 您不知道与主服务器的连接将关闭多长时间。 找出错误原因可能需要很长时间。 因此，在备份服务器上进入只读模式是正确的事情。 如果您在备用服务器上进入读写模式，那么您将更不愿意返回主服务器，直到您确定它完全死了。 * 他们在代码中写入数据库的每个地方都实现了只读模式。 * 运行状况仪表板提供了所有系统的总体状态。 从 SQL 数据库查询。 将所有内容存储在 SQL 中，使构建工具变得更加容易，并且可以针对当前的流量负载进行适当扩展。 * 三个图形：CPU，内存，网络。 * 运行大部分网络的 10 台服务器几乎未加载。 一种是峰值 16％。 即使翻了一番，他们也被严重超支。 * 它们一次没有被过度配置。 * 服务器已经重新配置了很多。 * 他们已将 CPU 添加到 Web 层。 他们达到了 60％的峰值，这令人不舒服。 * 在 Web 层中添加了 SSD，因此它们可以： * 提高 Lucene 索引速度。 * 加快启动 Web 层时的启动时间。 * 固态硬盘在生命周期中处于起步阶段，要轻而易举。 * SSD 不应使您的计算机运行得更快，因为您应该已经在 RAM 中运行了。 当数据库太大而无法放入 RAM 时，则不适用。 希望您最活跃的数据可以放入 RAM。 * 使用商业 Orion 网络监视器。 从本质上讲，它是在为时间付费，因为它比 Nagios 更容易设置和使用。 * 将所有数据保留在 SQL Server 上。 * SQL 意味着很容易访问和查询。 * Web 日志也存储在 SQL Server 中。 * 在 SQL Server 中拥有所有数据的长期趋势。 * 买了一台重型服务器，只是为了保存所有这些数据并能够执行实时查询。 2 个处理器，大量 RAM。 放入 13TB 的存储空间，这是一年的日志文件。 每天有 20 个演出进入 SQL Server。 * 之所以提供帮助，是因为他们可以实时告知正在发生的事情。 当他们推出一项新功能时，他们可以知道使用了多少功能，从而告诉他们是否需要保留该功能。 他们可以通过简单的查询来完成此任务，而无需查看日志或访问 Google Analytics（分析）。 * 他们每天创建 1 张表格来存储统计信息。 * 他们都知道 SQL，因此可以相对轻松地提出要回答的问题。 * Redis 服务器 * 用作 10 个服务器之间的共享状态缓存。 可以跨服务器平衡请求。 他们不想每次都访问数据库，因此它将进入缓存。 * 仍然是网络热议。 他们将处理粘性 IP，以便请求可以使用 Web 服务器上的内存中缓存。 这样可以消除网络命中的速度，该命中要快得多，可以直接在内存中使用它。 * 将所有内容都放入缓存时，会遇到网络可伸缩性问题。 这不是一个无限快的管道。 * 网络启示录 * [微爆](http://blog.serverfault.com/post/per-second-measurements-dont-cut-it/)出现问题。 在很短的时间内爆发高达千兆位的速度，这使队列充满了。 * 从未找到根本原因。 * 改变了网络架构的方式。 所有网络都集中路由。 Web 服务器和数据库/ redis 服务器位于不同的网络上，因此它们摆脱了两侧之间的路由器和防火墙。 * 他们更改了 NIC 配置。 他们联手进行了故障转移。 他们将配置更改为双活模式，并通过 NIC 负载均衡请求。 他们希望不再使用单个网卡来防止微爆。 * 导致成本增加的原因是，如果它们从交换机运行了 10 条网络线，因为您按端口付费。 * 令人惊讶的是，他们的流量混合了 40％的读取和 60％的写入。 * 他们的观众中有 60％是国际观众。 * StackExchange 大约有 45 个人。 * CDN 使您可以处理在多个区域中运行的国际用户的 80％的方式。 * 拥有 CDN 服务器的大部分静态资源。 * 两个数据中心中的实时数据太难了。 需要足够的 DBA 24x7 覆盖，并在支持方面进行了大量代码更改。 * 进入两个数据中心可能需要一个客户端引擎，例如 Facebook。 * 客户与 10 台服务器进行对话，并说您有什么需要帮助的。 * 客户端合并数据并显示一些结果。 * HTML 页面是几个 div。 每个 div 独立出去都会获取页面的该部分。 页面的每个部分可能来自不同的服务器，并且全部集中在客户端。 * StackExchange 并不是高度定制的，用户可以看到大致相同的站点，因此这并不是一个大赢家。 * 迁移到亚马逊并不是一个好主意： * 无法相信亚马逊的故障。 * 亚马逊的[价格将比](http://meta.stackoverflow.com/questions/73969/what-would-stack-exchanges-yearly-expenses-be-if-it-were-to-be-using-a-third-par/73978#73978)高出 3 倍以上。 亚马逊最初购买硬件后，每月需要花费 17,000 美元，而现在每月需要支付 4,000 美元。 * 亚马逊拥有 2007 年的旧技术，因此要实现类似的性能，他们将需要比现在更多的服务器。 * 期望从每台计算机获得 5 年的服务。 较旧的计算机将投入使用或承担较少的任务。 * 如果去了亚马逊，他们是否需要另一个系统管理员？ 他们可能没有想到。 亚马逊存在许多无法追踪的随机网络延迟问题。 对于高容量服装，并非全都是玫瑰。 * 对于控制怪胎，这不是最好的模型。 他们想知道网络中正在发生的一切。 他们不断观察性能，调整 NIC 配置等。无法控制所有内容并不适合他们的工作方式。 * 想要最好的硬件并关心每个小细节。 当您去亚马逊时，您说的是我不在乎。 * 云是一个冗余的故事。 这就像买一千个汉堡包，而不关心 5 个腐烂的汉堡包。 那不是他们选择的模型。 * 他们有一个重要的故事，尤其是在数据库方面。 大铁还没死。 摩尔定律还没有死。 您实际上不必花费太多时间来获得功能更强大的服务器。 不断前进。 * 他们真正担心的唯一事情是，如果数据库中的 RAM 用完了。 他们按主题有单独的数据库，但是 Stack Overflow 太大了，它装满了一台机器，无法分片。 他们可以获得一台具有 256GB RAM 的服务器。 StackExchange 令人耳目一新。 他们有意识地尝试通过在[他们的博客](http://blog.serverfault.com/)中发布​​或在其[网站](http://serverfault.com/)之一上提问来公开问题。 也许您的组织可能想效仿他们的榜样？ 这是一种建立意识和信任的好方法。 感谢您的出色总结-非常有趣。 AWS 上的成本计算不是最新的或完全正确的。 我已经对原始的 SO 问题发布了更新的细分：http://meta.stackoverflow.com/questions/73969/what-would-stack-exchanges-yearly-expenses-be-if-it-were-to-be- 使用三分之一 pa / 110201＃110201 因此，一旦 SO 工作集通过 256GB 而又不分割所有内容，则进一步扩展工作是一个有趣的思想实验。 也许您要分解数据库，但要按功能而不是按哈希-这里是全文索引，这里是详细的表决/用户/统计数据，此处显示问题页面所需的计数和文本。 或者，如果有很多鲜为人知的档案数据，则可能在其他地方。 或者，也许您发现站点的一个或两个方面比分片*一切*（投票，统计？）更容易分片，并且减轻了关系母权带来的大量负载/ RAM 压力。 Randall，我同意，当数据集太大时，分离数据（而不是分片）是一种更好/更容易的启动方法。 Netflix 不久前就这样做了，这就是为什么他们的网站会因服务故障而正常降级的原因。 例如，“评论”可能不会显示在电影页面上，但是您仍然可以流式传输。 看到此博客上的“无法相信亚马逊的故障”，真是令人震惊。 首先，您是否真的要宣称可以比 AWS 建立更多的冗余和更多的容错能力？ 您了解如何在所有 AWS 数据中心之间进行分配吗？ 其次，该声明是不真实的，事实是您不能 100％信任任何系统。 你建立宽容。 您是否声称无法在 AWS 上建立容忍度？ 让我们进行讨论。 这是另一个更新： http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/