# StackOverflow 更新：一个月有 5.6 亿次网页浏览，25 台服务器，而这一切都与性能有关 > 原文： [http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html](http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html)  Stack Overflow 的员工对于他们的工作以及原因仍然保持着开放的态度。 因此，该进行另一个[更新](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html)了。 堆栈溢出到底在做什么？ 构成[，StackExchange](http://stackexchange.com/) 的站点网络（包括 StackOverflow）在全球流量中排名第 54； 它们有 110 个站点，并且以每月 3 或 4 个的速度增长； 400 万用户； 4000 万个答案； 每月有 5.6 亿次网页浏览。 这只有 25 台服务器。 为了一切。 那就是高可用性，负载平衡，缓存，数据库，搜索和实用程序功能。 全部都有相对少数的员工。 现在就是质量工程。 此更新基于 Marco Cecconi 的 [StackOverflow](http://www.dev-metal.com/architecture-stackoverflow/) 的体系结构（视频）和 Nick Craver 的[进行 Stack Overflow](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/) 的体系结构。 此外，我还合并了来自各种来源的评论。 毫无疑问，某些细节已经过时了，就像我早在写这篇文章时所说的那样，但它仍然具有代表性。 堆栈溢出仍使用 Microsoft 产品。 Microsoft 基础架构可以正常运行且价格便宜，因此没有令人信服的理由进行更改。 SO 是务实的。 他们在合理的地方使用 Linux。 没有纯粹的动力来使所有 Linux 或保留所有 Microsoft。 那不会有效。 堆栈溢出仍使用放大策略。 网站上没有云。 由于其 SQL Server 装有 384 GB 的 RAM 和 2TB 的 SSD，AWS 会付出巨大的代价。 云还会降低它们的速度，从而更难优化和解决系统问题。 另外，SO 不需要水平扩展策略。 可以在横向扩展中使用的最大峰值负载没有问题，因为它们在正确调整系统大小方面非常成功。 因此，杰夫·阿特伍德（Jeff Atwood）的话似乎很：“硬件便宜，程序员昂贵”，这似乎仍然是该公司的绝大部分。 Marco Ceccon 在演讲中说，在谈论体系结构时，您需要首先回答这个问题：正在解决哪种问题？ 首先是简单的部分。 StackExchange 做什么？ 它需要主题，在主题周围创建社区，并创建很棒的问答站点。 第二部分涉及规模。 就像我们将看到的那样，StackExchange 的增长非常快，可以处理大量流量。 它是如何做到的？ 让我们来看看...。 ## 统计资料 * StackExchange 网络有 110 个站点，并且每月以 3 或 4 的速度增长。 * 400 万用户 * 800 万个问题 * 4000 万答案 * 作为全球排名第 54 的网络流量站点 * 同比增长 100％ * 每月 5.6 亿次网页浏览 * 在大多数工作日，高峰更像是 2600-3000 请求/秒。 编程是一种职业，意味着工作日比周末要忙得多。 * 25 台服务器 * 2 TB SQL 数据全部存储在 SSD 上 * 每个 Web 服务器在 RAID 1 中具有 2 个 320GB SSD。 * 每个 ElasticSearch 盒都有 300 GB，也使用 SSD。 * 堆栈溢出的读写比率为 40:60。 * 数据库服务器平均 10％的 CPU 使用率 * 11 个 Web 服务器，使用 IIS * 2 个负载均衡器，其中 1 个处于活动状态，并使用 HAProxy * 4 个活动数据库节点，使用 MS SQL * 3 个应用服务器实现标签引擎，任何通过标签命中进行搜索 * 3 台机器使用 ElasticSearch 进行搜索 * 2 台使用 Redis 进行分布式缓存和消息传递的机器 * 2 个网络（每个 Nexus 5596 +光纤扩展器） * 2 个 Cisco 5525-X ASA（认为防火墙） * 2 个 Cisco 3945 路由器 * 2 个只读 SQL Server，主要用于 Stack Exchange API * 虚拟机还执行诸如部署，域控制器，监视，用于系统管理员的操作数据库等功能。 ## 平台 * 弹性搜索 * 雷迪斯 * HAProxy * MS SQL * [观察者](https://github.com/opserver/Opserver) * 团队城市 * [Jil](https://github.com/kevin-montrose/Jil) -基于 Sigil 构建的快速.NET JSON 序列化器 * [Dapper](https://code.google.com/p/dapper-dot-net/) -微型 ORM。 ## UI [ * UI 具有消息收件箱，当您获得新徽章，收到消息，重大事件等时，将向该消息收件箱发送消息。使用 WebSockets 完成并由 Redis 驱动。 * 搜索框由 ElasticSearch 使用 REST 接口提供动力。 * 由于有如此多的问题，因此不可能仅显示最新的问题，它们会变化得太快，每秒都会出现一个问题。 开发了一种算法来查看您的行为方式，并向您显示您最感兴趣的问题。它使用了基于标签的复杂查询，这就是开发专门的标签引擎的原因。 * 服务器端模板用于生成页面。 ## 服务器 * 这 25 台服务器的工作量不大，即 CPU 负载低。 据估算，SO 只能在 5 台服务器上运行。 * 数据库服务器的利用率为 10％，除非在执行备份时服务器突然崩溃。 * 有多低 数据库服务器具有 384GB 的 RAM，Web 服务器的 CPU 使用率为 10％-15％。 * 放大仍然有效。 其他具有类似浏览量的横向扩展站点通常可以在 100、200，最多 300 台服务器上运行。 * 系统简单。 建立在.Net 上。 只有 9 个项目，其他系统有 100 个。 之所以拥有很少的项目，是因为编译如此迅速，这需要在开始时就进行规划。 在一台计算机上，编译需要 10 秒钟。 * 110K 行代码。 给出了它的作用的一小部分。 * 这种简约的方法存在一些问题。 一个问题是测试不多。 不需要测试，因为那里有一个很棒的社区。 Meta.stackoverflow 是社区的讨论站点，并且报告了错误。 Meta.stackoverflow 还是新软件的测试版站点。 如果用户发现任何问题，他们会报告所发现的错误，有时还会报告解决方案/补丁。 * 纽约已使用 Windows 2012，但正在升级到 2012 R2（俄勒冈已经在使用它）。 对于 Linux 系统，它是 Centos 6.4。 * 实际上，负载几乎遍布 9 台服务器，因为 10 台和 11 台仅用于 meta.stackexchange.com，meta.stackoverflow.com 和开发层。 这些服务器还运行约 10-20％的 CPU，这意味着我们还有很多可用空间。 ## 固态硬盘 * Intel 330 作为默认设置（网络层等） * 英特尔 520 用于中级写入，例如 Elastic Search * 用于数据库层的 Intel 710 & S3700。 S3700 只是高耐用性 710 系列的后继产品。 * 独家 RAID 1 或 RAID 10（10 是具有 4 个以上驱动器的任何阵列）。 故障已经不是问题，即使有数百个 intel 2.5 英寸固态硬盘投入生产，也没有一个故障。每种型号都保留一个或多个备件，但是多个驱动器故障并不是一个问题。 * 鉴于非常频繁的 SO 写/重新索引，ElasticSearch 在 SSD 上的性能要好得多。 * SSD [更改搜索](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/#comment-1201059884)的使用。 由于锁定问题，Lucene.net 无法处理 SO 的并发工作负载，因此将其转移到 ElasticSearch。 事实证明，在所有 SSD 环境中，实际上都不需要对二进制读取器进行锁定。 * 到目前为止，唯一的纵向扩展问题是 SQL 盒上的 SSD 空间，这是由于可靠性与非消费空间中的空间的增长方式所致，即驱动器具有用于功率损耗等的电容器。 ## 高可用性 [ * 主数据中心在纽约，备用数据中心在俄勒冈。 * Redis 具有 2 个从属，SQL 具有 2 个副本，标记引擎具有 3 个节点，elastic 具有 3 个节点-任何其他服务也具有高可用性（并且都存在于两个数据中心中）。 * 并非所有数据中心之间都存在从属关系（不需要通过同步来占用带宽的非常临时的高速缓存数据等），而是大数据项，因此在活动数据中心发生故障时，仍然存在共享的高速缓存。 没有缓存就可以开始，但这不是很优雅。 * Nginx 用于 SSL，但是已经过渡到使用 HAProxy 终止 SSL。 * 发送的 HTTP 总流量仅占发送总流量的 77％。 这是因为正在向俄勒冈州的辅助数据中心以及其他 VPN 通信进行复制。 这些流量的大部分是到俄勒冈州 SQL 复制副本和 Redis 从站的数据复制。 ## 数据库 * MS SQL Server。 * Stack Exchange 每个站点有一个数据库，因此 Stack Overflow 获取一个，超级用户获取一个，Server Fault 获取一个，依此类推。 这些的架构是相同的。 具有不同数据库的这种方法实际上是分区和水平缩放的一种形式。 * 在主要数据中心（纽约）中，每个集群通常有 1 个主数据库和 1 个只读副本。 在 DR 数据中心（俄勒冈州）中还有 1 个只读副本（异步）。 在俄勒冈州运行时，主要目录在那里，并且两个纽约副本均为只读且异步。 * 有一些皱纹。 有一个“网络范围的”数据库，其中包含登录凭据和聚合数据（主要通过 stackexchange.com 用户配置文件或 API 公开）之类的东西。 * 职业生涯 Stack Overflow，stackexchange.com 和 Area 51 都有各自独特的数据库架构。 * 所有架构更改将同时应用于所有站点数据库。 它们需要向后兼容，因此，例如，如果您需要重命名一列-最坏的情况-这是一个多步骤的过程：添加新列，添加适用于两列的代码，回填新列，更改 代码，使其仅适用于新列，请删除旧列。 * 不需要分区。 索引可以处理所有事情，并且数据还不够大。 如果需要过滤索引，为什么不提高效率呢？ 仅在 DeletionDate = Null 上建立索引，这是一个常见的模式，其他则是枚举中特定的 FK 类型。 * 每个项目 1 张表中有投票，例如 1 张表用于投票，1 张表用于评论投票。 我们大多数页面都是实时呈现的，仅为匿名用户缓存。 鉴于此，没有要更新的缓存，只需重新查询即可。 * 分数是非规范化的，因此经常需要查询。 所有的 ID 和日期，职位投票表目前只有 56,454,478 行。 由于建立索引，大多数查询仅需几毫秒。 * 标记引擎完全是独立的，这意味着不必依赖外部服务来获得非常核心的功能。 这是一个巨大的内存结构数组结构，针对 SO 用例和针对重击组合的预计算结果进行了优化。 这是一个简单的 Windows 服务，在冗余团队中的几个盒子上运行。 CPU 几乎总是占 2-5％。 负载不需要三个盒子，只是冗余。 如果所有这些操作一次都失败，则本地 Web 服务器将标记引擎加载到内存中并继续运行。 * 与传统的 ORM 相比，Dapper 缺少编译器来检查查询。 编译器正在检查您告诉数据库的内容。 这可以帮助很多事情，但是仍然存在运行时遇到的根本断开问题。 权衡的一个巨大问题是所生成的 SQL 令人讨厌，并且查找其来源的原始代码通常并非易事。 尝试优化查询时，缺乏提示查询，控制参数化等功能的问题也很大。 例如。 文字替换已添加到 Dapper，以帮助进行查询参数化，从而允许使用诸如过滤索引之类的内容。 Dapper 还拦截了对 Dapper 的 SQL 调用，并添加了 add 的确切来源。 它节省了很多时间来追踪事物。 ## 编码 * 过程： * 大多数程序员都在远程工作。 程序员在自己的蝙蝠洞中编码。 * 编译非常快。 * 然后运行他们已经进行的一些测试。 * 编译后，代码将移至开发登台服务器。 * 新功能通过功能开关隐藏。 * 在与其他站点相同的硬件上运行。 * 然后将其移至 Meta.stackoverflow 进行测试。 每天有 1000 个用户使用该网站，因此它是一个很好的测试。 * 如果通过，它将在网络上发布并由更大的社区进行测试。 * 大量使用静态类和方法，以简化操作并提高性能。 * 代码很简单，因为复杂的位打包在一个库中，并且是开源和维护的。 .Net 项目的数量保持较低，因为使用了社区共享的代码部分。 * 开发人员可以获得两到三个监视器。 屏幕很重要，它们可以帮助您提高工作效率。 ## 快取 * 缓存所有东西。 * 5 级缓存。 * 第一个：网络级缓存：在浏览器，CDN 和代理中进行缓存。 * 第二名：.Net 框架免费提供的，称为 HttpRuntime.Cache。 内存中的每个服务器缓存。 * 第三名：Redis。 分布式内存键值存储。 在为同一站点提供服务的不同服务器之间共享缓存元素。 如果 StackOverflow 有 9 台服务器，则所有服务器都将能够找到相同的缓存项。 * 第四：SQL Server 缓存。 整个数据库都缓存在内存中。 整个事情。 * 第五名：SSD。 通常仅在 SQL Server 缓存预热时命中。 * 例如，每个帮助页面都被缓存。 访问页面的代码非常简洁： * 重用了静态方法和静态类。 从 OOP 的角度来看，这确实很糟糕，但是对于简洁的代码却非常快速且非常友好。 所有代码都直接寻址。 * 缓存由 Redis 的库层和微型 ORM [Dapper](https://code.google.com/p/dapper-dot-net/) 进行处理。 * 为了解决垃圾回收问题，仅创建模板中使用的类的一个副本并将其保存在缓存中。 从统计数据中可以测量所有内容，包括 GC 操作，已知间接层会增加 GC 压力到明显的缓慢点。 * 由于查询字符串哈希值基于文件内容，因此 CDN 命中数有所不同，因此只能在构建中重新获取它。 300 至 600 GB 的带宽通常每天点击 30-50 百万次。 * CDN 不用于 CPU 或 I / O 负载，而是用于帮助用户更快地找到答案。 ## 部署 [ * 想要每天部署 5 次。 不要建立宏伟的宏伟的东西，然后再活下来。 重要原因： * 可以直接衡量性能。 * 被迫制造可能起作用的最小的东西。 * 然后，通过 Powershell 脚本构建 TeamCity，然后将其复制到每个 Web 层。 每个服务器的步骤是： * 告诉 HAProxy 通过 POST 使服务器停止旋转 * 延迟让 IIS 完成当前请求（约 5 秒） * 停止网站（通过以下所有操作使用相同的 PSSession） * Robocopy 文件 * 启动网站 * 通过另一个 POST 在 HAProxy 中重新启用 * 几乎所有内容都是通过 puppet 或 DSC 进行部署的，因此升级通常仅包括对 RAID 阵列进行核对并从 PXE 引导进行安装。 它的速度非常快，而且您知道它做得正确/可重复。 ## 团队合作 * 队伍： * SRE（系统可靠性工程）：-5 人 * 核心开发人员（Q & A 网站）：〜6-7 人 * 核心开发人员：6 人 * 仅针对 SO Careers 产品进行开发的职业团队：7 人 * Devops 和开发人员团队确实紧密相连。 * 团队之间有很多变动。 * 大多数员工都在远程工作。 * 办公室主要是销售部门，丹佛和伦敦则完全是这样。 * 在所有其他条件相同的情况下，在纽约市更喜欢有一些人，因为面对面的时间对于“完成任务”之间的偶然互动是加分的。 但是，这种设置可以进行实际工作，并且官方团队合作几乎可以完全在线进行。 * 他们了解到，亲自聘用能够在任何地方热爱该产品的最佳人才所带来的收益远远超过其个人收益，而不仅仅是愿意住在您所在城市的人才。 * 某人偏远的最常见原因是建立家庭。 纽约很棒，但宽敞却不是。 * 办公室在曼哈顿，那里有很多人才。 由于数据中心总是在不断完善，因此它不必离疯狂的距离。 与 NYC 位置的许多骨干网的连接速度也稍快-尽管我们在这里谈论的只是几毫秒（如果有的话）的差异。 * 组建一支很棒的团队：爱极客。 例如，早期的 Microsoft 充满了极客，他们征服了整个世界。 * 从 Stack Overflow 社区雇用。 他们寻求对编码的热情，对他人的热情以及对沟通的热情。 ## 预算 * 预算几乎是基于项目的。 仅在为新项目添加基础结构时才花钱。 利用率如此低的 Web 服务器与 3 年前建造数据中心时购买的 Web 服务器相同。 ## 测验 * 快速行动并破坏事物。 现场直播。 * 重大更改通过推送进行测试。 开发具有功能相同的 SQL Server，并且它在同一 Web 层上运行，因此性能测试也不错。 * 很少的测试。 由于 Stack Overflow 的活动社区和大量使用静态代码，因此它们不使用许多单元测试。 * 基础架构发生变化。 共有 2 种，因此只要有可能，就可以使用旧配置进行备份，并具有快速故障回复机制。 例如，keepalived 会在负载均衡器之间快速进行故障回复。 * 冗余系统通常只是为了进行定期维护而进行故障转移。 通过拥有专用的服务器来不断测试 SQL 备份，该服务器用于不断地还原它们（这是免费许可证，可以执行此操作）。 计划每 2 个月左右启动一次完整的数据中心故障转移-辅助数据中心在所有其他时间都是只读的。 * 每次推送都会运行单元测试，集成测试和 UI 测试。 所有测试必须成功，才能进行生产构建。 因此，关于测试的信息有些混杂。 * 显然应该进行测试的事物具有测试。 这意味着在 Careers 产品上涉及金钱的大多数事物，以及在 Core 端上易于进行单元测试的功能（具有已知输入的事物，例如标记，我们的新顶部栏等），而对于大多数其他事情，我们只是做一个功能 手动进行测试并将其推送到我们的孵化站点（以前称为 meta.stackoverflow，现在称为 meta.stackexchange）。 ## 监控/记录 * 现在考虑使用 http://logstash.net/进行日志管理。 当前，专用服务将 syslog UDP 通信插入 SQL 数据库。 网页添加了用于出站计时的标头，这些标头由 HAProxy 捕获并包含在 syslog 通信中。 * [Opserver](https://github.com/opserver/Opserver) 和 Realog。 有多少度量标准浮出水面。 Realog 是由 Kyle Brandt 和 Matt Jibson 在 Go 中构建的日志显示系统 * 通过 syslog 而不是 IIS 从 HAProxy 负载平衡器进行日志记录。 它比 IIS 日志具有更多的通用性。 ## 阴天 * 硬件比开发人员便宜且代码高效。 您的速度只有最慢的瓶颈，而且当前所有的云解决方案都具有基本的性能或容量限制。 [ * 如果从第一天开始构建云，您能否构建得那么好？ 最有可能。 您能否一致性地渲染所有页面，以执行多个最新查询并跨您无法控制的云网络缓存获取数据，并获得不到 50 毫秒的渲染时间？ 那是另一回事。 除非您谈论的是更高的成本（至少 3-4 倍），否则答案是否定的-SO 托管在自己的服务器中仍然更加经济。 ## 性能为特征 * StackOverflow 非常重视性能。 主页的目标是在 50 毫秒内加载，但可以低至 28 毫秒。 * 程序员热衷于减少页面加载时间并改善用户体验。 * 记录到网络的每个请求的时间。 借助这些指标，您可以决定改进系统的位置。 * 其服务器以如此低的利用率运行的主要原因是高效的代码。 Web 服务器的平均 CPU 率为 5-15％，使用的 RAM 为 15.5 GB，网络流量为 20-40 Mb / s。 SQL 服务器平均约有 5-10％的 CPU，365 GB 的 RAM 和 100-200 Mb / s 的网络流量。 这具有三个主要优点：一般的增长空间和升级的必要性； 当事情发疯时（查询错误，代码错误，攻击等等），可以保持在线的余地； 以及在需要时恢复供电的能力。 ## 经验教训 [ * **如果使用 MS 产品，为什么要使用 Redis？** [gabeech](http://www.reddit.com/r/programming/comments/1r83x7/what_it_takes_to_run_stack_overflow/cdkpv7w) ：这与 OS 宣传无关。 我们在运行效果最佳的平台上运行事物。 期。 C＃在 Windows 计算机上运行最好，我们使用 IIS。 Redis 在我们使用* nix 的* nix 机器上运行得最好。 * **作为策略过度杀伤**。 尼克·克雷弗（Nick Craver）解释了为什么他们的网络被过度配置了：20 Gb 大规模杀伤力大吗？ 您敢打赌，在 20 Gb 管道中，活动的 SQL 服务器平均大约 100-200 Mb。 但是，由于存在大量内存和 SSD 存储，因此备份，重建等操作可能会使它完全饱和，因此确实可以达到目的。 * **SSD 摇滚**。 数据库节点均使用 SSD，平均写入时间为 0 毫秒。 * [了解您的读/写工作量](http://sqlblog.com/blogs/louis_davidson/archive/2009/06/20/read-write-ratio-versus-read-write-ratio.aspx)。 * **保持高效运行意味着经常不需要新机器。 只有当由于某种原因需要不同硬件的新项目出现时，才添加新硬件。 通常会添加内存，但是除了该高效代码和低利用率以外，它不需要替换。 因此，通常谈论的是添加 a）SSD 以获得更多空间，或 b）为新项目添加新硬件。** * **不要害怕专长**。 SO 使用基于标签的复杂查询，这就是为什么要开发专门的标签引擎的原因。 * **仅执行需要做的事情**。 不需要测试，因为活跃的社区已经为它们进行了验收测试。 仅在需要时添加项目。 仅在必要时添加一行代码。 您没有需要它确实有效。 * **重新发明可以**。 通常的建议是不要重新发明轮子，例如，将其变成正方形只会使它变得更糟。 在 SO 上，他们不必担心制作“方轮”。 如果开发人员可以编写比已经开发的替代方案更轻巧的东西，那就去做。 * **转到裸机**。 进入 IL（.Net 的汇编语言）。 一些编码使用 IL，而不是 C＃。 查看 SQL 查询计划。 进行 Web 服务器的内存转储，以查看实际情况。 例如，发现拆分呼叫会产生 2GB 的垃圾。 * **没有官僚机构**。 您的团队总是需要一些工具。 例如，编辑器，Visual Studio 的最新版本等。只需进行很多操作即可。 * **垃圾收集驱动的编程**。 SO 竭尽全力减少垃圾收集成本，跳过诸如 TDD 之类的做法，避免抽象层，并使用静态方法。 虽然极端，但结果却是高性能的代码。 当您在短窗口中处理数亿个对象时，实际上可以测量 GC 运行时应用程序域中的暂停时间。 这些对请求性能有相当不错的影响。 * **低效代码的成本可能比您认为的**高。 高效的代码进一步扩展了硬件，减少了功耗，并使程序员更易于理解代码。 ## 相关文章 * [关于黑客新闻](https://news.ycombinator.com/item?id=8064534) * [运行堆栈溢出所需的时间[Nick Craver]](http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/) * [在 Reddit 上](http://www.reddit.com/r/programming/comments/1r83x7/what_it_takes_to_run_stack_overflow/) * 视频 [StackOverflow](http://www.dev-metal.com/architecture-stackoverflow/) 的体系结构，作者 Marco Cecconi * [关于 HackerNews](https://news.ycombinator.com/item?id=7052835) * [演示幻灯片](https://speakerdeck.com/sklivvz/the-architecture-of-stackoverflow-developer-conference-2013) * [Stackoverflow.com：通往 SSL 的道路](http://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/) * [哪些工具和技术用于构建 Stack Exchange 网络？](http://meta.stackexchange.com/questions/10369/which-tools-and-technologies-are-used-to-build-the-stack-exchange-network) * [被 GC 攻击](http://blog.marcgravell.com/2011/10/assault-by-gc.html) * [StackOverflow 上的 Microsoft SQL Server 2012 AlwaysOn AG](http://www.brentozar.com/archive/2012/09/microsoft-sql-server-alwayson-ags-at-stackoverflow/) * [为什么我们（仍然）相信远程工作](http://blog.stackoverflow.com/2013/02/why-we-still-believe-in-working-remotely/) * [运行堆栈溢出 SQL 2014 CTP 2](http://nickcraver.com/blog/2013/11/18/running-stack-overflow-sql-2014-ctp-2/) * 多年来，HighScalability 在 StackOverflow 上有几篇文章：[堆栈溢出体系结构](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html)， [StackOverflow 的扩展野心](http://highscalability.com/blog/2010/2/15/scaling-ambition-at-stackoverflow.html)，[堆栈溢出体系结构更新](http://highscalability.com/blog/2011/3/3/stack-overflow-architecture-update-now-at-95-million-page-vi.html)， [StackExchange 体系结构更新[](http://highscalability.com/blog/2011/10/24/stackexchange-architecture-updates-running-smoothly-amazon-4.html) 。 这里有 Stack 开发人员-还有一个单独的 Careers 团队，专门为 SO Careers 产品进行开发。 也大约有 7 位开发者。 有关首次出现在堆栈上的某些情况，请访问： [http://www.jonhmchan.com/blog/2014/1/16/my-first-six-weeks-working-at-stack-overflow](http://www.jonhmchan.com/blog/2014/1/16/my-first-six-weeks-working-at-stack-overflow) “快如闪电”？ 真？ 在称自己为作家之前，请先了解“闪电”和“闪电”之间的区别 我从来不知道他们在大多数网站上都使用 C＃编写代码，考虑到他们仅使用 25 台服务器，看到这样的项目进行扩展，真是令人震惊！ （哇） 我对数据库的低延迟感到惊讶，即使它全部在内存中，也有一些物理瓶颈无法让您处理超过 20gb / sec 的速度（不确定是什么，取决于内存速度） ）。 很棒的帖子，很惊讶地看到它们继续运行。 令我的公司感到羞耻的是，我们的服务器从左到右落在中间，仅运行了一部分 SO 运行！ 在 MS SQL 停止读取 不是.net 人，但是许多项目如何影响编译时间？ 非常有趣-感谢您的总结！ 很好的简历，它很棒的 stackoverflow 原理！ 高性能！ “下降到裸机。进入 IL”。 IL 中的 I 代表中级。 因此，也许应该将其改写为“更紧密地接近裸机”，但实际上并非如此。 “大多数程序员都在远程工作。程序员在自己的蝙蝠洞中编写代码。” 有点违背 “在其他所有条件相同的情况下，在纽约市更倾向于有人陪伴，因为面对面的时间是在“完成工作”之间进行的随意互动的加分。但是，这种设置可以进行真正的工作和 官方团队合作几乎完全在线上进行。” “他们已经了解到，亲自聘用能够在任何地方钟情于该产品的最优秀人才而获得的收益远远超过个人受益，而不仅仅是愿意住在您所居住的城市的人才。 ” 出色而翔实，因此令人大开眼界。 对于那些讨厌微软技术栈的人……包括我在内，这是有教益的。 真的很棒。 关于编译速度和项目数量。 如果在 Visual Studio 中“卸载项目”，则可以禁用该项目的编译。 我有一个包含 14 个项目的解决方案，而卸载我不从事的项目可以节省大量时间。 >看到这样的项目可以扩展，考虑到他们仅使用 25 台服务器，这真是令人震惊 >很棒的帖子，很高兴看到他们的运行量 你疯了吗？！ 他们在每个数据库服务器上都有 384GB 的内存。 他们甚至在 Web 服务器上都有 SSD。 他们每个月提供的访问量仅为 5.6 亿，这是整个服务的 560000000 / 30/24/3600 = 216 RPS，如果将其除以 Web 服务器数量，则每个 Web 服务器将为 19 RPS ，而且它不是廉价服务器，甚至在 Raid 1 和 shit 中甚至都有 SSD。 给定像这样的数字，我会很高兴我没有使用 IIS 或任何 Microsoft 软件来提供 Web 应用程序... 大量使用静态类和方法会产生代码异味 我发现 Marco Cecconi 在 SpeakerDeck 上有一些更新的幻灯片：[](https://speakerdeck.com/sklivvz "https://speakerdeck.com/sklivvz") @Nikita 哦，拜托，你知道数学很愚蠢。 流量显然遵循模式，几乎可以肯定，他们在峰值负载下的速度明显超过 216 RPS。 对于一个相当复杂，写繁重的网站而言，5.6 亿的页面浏览量是非常可观的。 >停止在 MS SQL 中阅读 当然可以 > 你疯了吗？！ 他们在每个数据库服务器上都有 384GB 的内存。 他们甚至在 Web 服务器上都有 SSD。 他们每个月提供的访问量仅为 5.6 亿，这是整个服务的 560000000 / 30/24/3600 = 216 RPS，如果将其除以 Web 服务器数量，则每个 Web 服务器将为 19 RPS ，而且它不是廉价服务器，甚至在 Raid 1 和 shit 中甚至都有 SSD。 给定像这样的数字，我会很高兴我没有使用 IIS 或任何 Microsoft 软件来提供 Web 应用程序... 您的计算基于以下假设：这是其硬件堆栈可以管理的最大数量。 它在文章中多次声明，所有内容都超量配置，正常运行负载约为 10％。 您所做的重大损害会导致类似的结论。 如果他们具有关于在最高性能下可以处理多少页面请求的任何统计信息，那将更加有趣。 即使这样，它也说明了他们特定的软件堆栈，将他们认为缺乏 RPS 归因于 IIS 是愚蠢的 正如 Nikita 所说，这些数字似乎并不令人印象深刻。 我在 SQL 部分中不知道，但是在 HTTP 部分中，只有一台具有 apache 和 php 的 1GB ram 双核服务器可以完成这项工作。 Nick Craver-此处的堆栈溢出系统管理员。 我以为我会在这些评论中消除一些混乱和不好的数字。 页面浏览量仅占我们负载的一小部分。 我们为许多 AJAX / JSON 路由和 API 请求提供服务，在任何给定的工作日总计超过 1.3 亿个请求。 例如，昨天我们处理了 150,091,472 个请求，平均约为 1730 RPS。 当然，我们有高峰时间与非高峰时间，所以这不是一个很好的指标。 在高峰期，我们通常会在 9 个主要 Web 服务器中的每一个上看到 2600-3000 RPS，负载约为 15％。 供参考：过去 30 天内，我们处理了 3,710,241,322（37 亿）个请求。 注意：这些 Web 服务器可能已经使用了 4 年，订购时并没有达到最高级的水平（Intel E5640 处理器）。 而且，这些数字不包括每个页面视图附带的我们的 Websocket 连接，它们将使数字甚至更高，并且它们由相同的 9 台 Web 服务器提供服务。 IIS 和 Microsoft 堆栈并不是所有时间都花在哪里（只有一小部分时间花在这里），它存在于我们的代码，API 调用，DB 查询，标签引擎请求等中。 对我们的网络的每个请求的*时序细分。 然后，每隔一段时间我们就会通过调整传递来发疯，并取得巨大的性能胜利……这是我们有一段时间没做过了。 在下一次优化通过之后，我将尝试发布更新的利用率数字。 同样值得注意的是，我们提供的几乎所有内容都不是静态内容，这些请求由我们的 CDN 处理的时间超过 99.97％。* @bob-托德是一位优秀作家。 但是他可能会考虑雇用编辑。 看来错别字已得到纠正。 您必须是一个很好的编辑才能赶上这一点。 也许你应该申请这份工作。 有人能解释为什么“堆栈溢出的读写比率为 40:60”吗？ 如何测量？ 什么构成读写操作？ 我对该统计数据感到非常惊讶。 我以为它将具有 99：1 的读写比。 与一小部分人发布新问题，答案，投票赞成/反对等等相比，不是大多数人只是查看答案而进行的操作。 很棒的帖子。 作为 stackoverflow 的粉丝，我只是喜欢这个极富启发性和内容丰富的博客。 很棒的文章，我很奇怪地从工程学的角度看待目前的体系结构。 11 万行和对抽象的厌恶通常不是成功的工程运动的先兆。 至少在一起时 我希望安装一些非常有趣的过程来帮助保持平稳运行。 但丁·埃里克（Dante Elrik） 谢谢。 很高兴看到有人放弃了他们的基础架构和方法论。 对于所有批评家：他们所做的都是有效的。 成功了 很稳定 谁在乎这是怎么做的。 他们就是这样做的，而且显然很成功。 我敢肯定，如果您想像这些人一样详细描述它，那么高可扩展性将发布您的“高级”技术堆栈和公司文化。 就我自己而言，从物理基础结构到开发人员与“站点可靠性工程师”的比例，我发现这是一本有趣的文章。