116.md

# 缩放 Pinterest-两年内每月从 0 到十亿的页面浏览量

> 原文： [http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html)

![](img/824ae269f3bd907a2a05b2053f990ad9.png)

Pinterest 一直处于指数增长曲线，每个月半翻倍。 两年来，他们的浏览量已经从每月 0 增至 100 亿，从 2 位创始人和一位工程师到 40 多位工程师，从一台小型 MySQL 服务器到 180 个 Web 引擎，240 个 API 引擎，88 个 MySQL DB（cc2。 8xlarge），每个+ 1 个从属，110 个 Redis 实例和 200 个 Memcache 实例。

惊人的增长。 那么 Pinterest 的故事是什么？ 告诉他们的故事，我们有我们的吟游诗人，Pinterest 的 [Yashwanth Nelapati](http://www.linkedin.com/in/yashh) 和 [Marty Weiner](http://pinterest.com/martaaay/) ，他在 [Scaling Pinterest](http://www.infoq.com/presentations/Pinterest) 演讲中讲述了 Pinterest 架构演变的戏剧性故事。 这是一年半前他们想要快速扩展并且有很多选择的时候他们希望听到的演讲。 他们做出了许多错误的选择。

这是一个很棒的话题。 它充满了惊人的细节。 它也是非常实用，扎根的，并且包含几乎任何人都可以采用的策略。 强烈推荐。

我在演讲中最喜欢的两个课程：

1.  当可以通过添加更多相同的东西来处理增长时，体系结构就做对了。 您希望能够通过在问题上投入资金来扩展规模，这意味着您可以根据需要在问题上投入更多的资金。 如果您的架构能够做到这一点，那么您就很聪明。
2.  当您将某些事情推到极限时，所有技术都会以自己的特殊方式失败。 这导致他们在评估工具选择时偏向于成熟的工具； 真的很好，很简单； 众所周知和喜欢 良好的支持； 始终表现出色； 尽可能无故障； 自由。 他们使用这些条件选择了：MySQL，Solr，Memcache 和 Redis。 卡桑德拉（Cassandra）和蒙哥（Mongo）被撤职。

这两个课程是相互关联的。 遵循（2）中原理的工具可以通过添加更多框来扩展。 随着负载的增加，成熟的产品应该会遇到更少的问题。 当您遇到问题时，至少会有一个社区来解决问题。 这是因为您的工具过于棘手又太挑剔，以至于撞到了很高的墙壁，无法攀爬。

在整个讨论中，我认为这是最好的部分，在讨论分片为什么比群集更好的过程中，您会看到通过增加资源，少量故障模式，成熟，简单和良好的支持来实现增长的主题， 取得成果。 请注意，他们选择的所有工具都是通过添加分片而不是通过集群来扩展的。 关于为什么他们更喜欢分片以及如何分片的讨论确实很有趣，并且可能涵盖了您以前从未考虑过的领域。

现在，让我们看看 Pinterest 如何扩展：

## 基础知识

*   引脚是一幅包含其他信息位的图像，描述了对用户重要的内容，并链接回其找到位置。

*   Pinterest 是一个社交网络。 您可以关注他人和董事会。

*   数据库：他们的用户拥有板，板具有引脚； 追踪并保持关系； 认证信息。

## 于 2010 年 3 月推出-寻找自我的时代

此时，您甚至都不知道要制造什么产品。 您有想法，因此可以快速迭代和更改。 因此，您最终遇到了许多奇怪的小 MySQL 查询，这些查询在现实生活中是永远不会做的。

此早期日期的数字：

*   2 位创始人

*   1 位工程师

*   机架空间

*   1 个小型网络引擎

*   1 个小型 MySQL 数据库

## 2011 年 1 月

仍处于隐身模式，并且该产品正在根据用户反馈发展。 数字：

*   Amazon EC2 + S3 + CloudFront

*   1 个 NGinX，4 个 Web 引擎（用于冗余，而不是用于负载）

*   1 个 MySQL DB + 1 个读从站（以防主机崩溃）

*   1 个任务队列+ 2 个任务处理器

*   1 个 MongoDB（用于计数器）

*   2 个工程师

## 到 2011 年 9 月-实验时代

他们疯狂地奔跑着，他们每个月都翻一番。 疯狂的增长。

*   当您快速成长时，每个晚上和每个星期都会崩溃。

*   此时，您阅读了许多白皮书，说仅是一个盒子，您就完成了。 因此，他们开始增加很多技术。 他们都坏了。

*   结果，您最终得到了非常复杂的图片：

    *   Amazon EC2 + S3 + CloudFront

    *   2NGinX，16 个 Web 引擎+ 2 个 API 引擎

    *   5 个功能明确的 MySQL DB + 9 个读取从站

    *   4 个 Cassandra 节点

    *   15 个 Membase 节点（3 个独立的群集）

    *   8 个 Memcache 节点

    *   10 个 Redis 节点

    *   3 个任务路由器+ 4 个任务处理器

    *   4 个弹性搜索节点

    *   3 个 Mongo 群集

    *   3 个工程师

*   仅针对数据的 5 种主要数据库技术。

*   增长如此之快，以至于 MySQL 变得炙手可热，所有其他技术也被推向了极限。

*   当您将某些技术推向极限时，所有这些技术都会以自己的特殊方式失败。

*   开始放弃技术并问自己自己真正想要成为什么。 对所有内容进行了大规模的重新架构。

## 2012 年 1 月-成熟期

*   重新整理一切之后，系统现在看起来像：

    *   亚马逊 EC2 + S3 + Akamai，ELB

    *   90 个 Web 引擎+ 50 个 API 引擎

    *   66 个 MySQL DB（m1.xlarge）+每个从站 1 个

    *   59 个 Redis 实例

    *   51 个 Memcache 实例

    *   1 个 Redis 任务管理器+ 25 个任务处理器

    *   碎片 Solr

    *   6 位工程师

*   现在使用分片的 MySQL，Redis，Memcache 和 Solr。 而已。 优势在于它是非常简单和成熟的技术

*   Web 流量一直以相同的速度增长，而 iPhone 流量开始上升。

## 2012 年 10 月 12 日-回归的时代

大约是一月份的四倍。

*   The numbers now looks like:
    *   3 级，Akamai，Amazon EC2 + S3 + Edge Cast

    *   180 个 Web 引擎+ 240 个 API 引擎

    *   88 个 MySQL DB（cc2.8xlarge）+每个 1 个从数据库

    *   110 个 Redis 实例

    *   200 个 Memcache 实例

    *   4 个 Redis 任务管理器+ 80 个任务处理器

    *   碎片索尔

    *   40 名工程师（并且正在不断增长）

*   请注意，该架构正在做正确的事情。 增长是通过添加更多相同的东西。 您希望能够通过花钱解决问题来扩展规模。 您只需要在需要时就可以扔出更多盒子。

*   现在移至 SSD

## 为什么选择 Amazon EC2 / S3？

*   相当不错的可靠性。 数据中心也会崩溃。 多租户会增加一些风险，但这还不错。

*   良好的报告和支持。 他们的架构师非常好，他们知道问题

*   不错的外围设备，尤其是在您成长的时候。 您可以启动 App Engine 并与他们的托管缓存，负载平衡，地图缩减，托管数据库以及您无需自己编写的所有其他部分进行对话。 您可以引导亚马逊的服务，然后在拥有工程师的情况下对其进行改进。

*   数秒内即可使用新实例。 云的力量。 特别是有了两名工程师，您不必担心容量规划或等待两周来获取内存缓存的情况。 只需几分钟即可添加 10 个内存缓存。

*   缺点：选择有限。 直到最近，您才能获得 SSD，并且无法获得大容量 RAM 配置。

*   优点：选择有限。 您最终不会得到很多配置不同的盒子。

## 为什么选择 MySQL？

*   真的很成熟。

*   非常牢固。 对于他们来说，它永远不会失败，并且永远不会丢失数据。

*   您可以租用它。 许多工程师都了解 MySQL。

*   对请求速率的响应时间线性增加。 当请求率达到峰值时，某些技术的响应也不会很好。

*   很好的软件支持-XtraBackup，Innotop，Maatkit

*   很棒的社区。 回答问题很容易。

*   Percona 等公司提供了很好的支持。

*   免费-当您最初没有任何资金时很重要。

## 为什么使用 Memcache？

*   非常成熟。

*   真的很简单。 这是一个哈希表，其中插入了一个套接字。

*   始终表现出色

*   众所周知，很喜欢。

*   始终表现良好。

*   永不崩溃。

*   免费

## 为什么要使用 Redis？

*   还不成熟，但确实非常好，非常简单。

*   提供各种数据结构。

*   具有持久性和复制性，可以选择实现它们的方式。 如果您想要 MySQL 样式的持久性，可以拥有它。 如果您不需要持久性，可以拥有它。 或者，如果您想要 3 个小时的持久性，则可以拥有它。

    *   您的家庭供稿位于 Redis 上，每 3 小时保存一次。 没有 3 小时的复制。 他们仅每 3 小时备份一次。

    *   如果将数据存储在模具上的盒子中，则它们仅备份了几个小时。 它并不完全可靠，但更简单。 您不需要复杂的持久性和复制。 它的架构更简单，更便宜。

*   众所周知，很喜欢。

*   Consistently good performance.

*   少数故障模式。 您需要了解一些微妙的故障模式。 这就是成熟的源头。只是学习它们并超越它。

*   Free

## Solr

*   很棒的起床型产品。 安装它，几分钟后您将建立索引。

*   不能超过一个框。 （最新版本并非如此）

*   尝试了弹性搜索，但从规模上看，它遇到了很多小文档和很多查询的麻烦。

*   现在使用 Websolr。 但是他们有一个搜索小组，并且会自己动手。

## 聚类与分片

*   在快速增长期间，他们意识到他们将需要平均分布数据以应对不断增长的负载。

*   定义了一个讨论该问题的频谱，他们提出了“聚类”和“分片”之间的一系列选择。

### 群集-一切都是自动的：

*   示例：Cassandra，MemBase，HBase

*   判决：太可怕了，也许在将来，但是现在它太复杂了，故障模式太多了。

*   属性：

    *   数据自动分发

    *   数据可以移动

    *   重新平衡以分配容量

    *   节点相互通信。 大量的串扰，闲聊和谈判。

*   优点：

    *   自动扩展您的数据存储。 白皮书至少是这样说的。

    *   易于设置。

    *   在空间上分布和放置数据。 您可以将数据中心放置在不同的区域，而数据库则由它来处理。

    *   高可用性

    *   负载平衡

    *   没有单点故障

*   缺点（根据第一手经验）：

    *   还很年轻。

    *   从根本上讲复杂。 整个节点必须对称一致，这是生产中很难解决的问题。

    *   较少的社区支持。 社区的产品线不同，因此每个阵营的支持都较少。

    *   具有工作知识的工程师更少。 可能大多数工程师都没有使用 Cassandra。

    *   困难而令人恐惧的升级机制。 可能与它们都使用 API​​并相互之间进行交谈有关，所以您不希望它们混淆。 这导致复杂的升级路径。

    *   集群管理算法是 SPOF。 如果有错误，它将影响每个节点。 这使他们失望了 4 次。

    *   群集管理器是在具有以下故障模式的所有节点上复制的复杂代码：

        *   数据重新平衡中断。 带来一个新盒子，数据开始复制，然后被卡住。 你是做什么？ 没有工具可以弄清楚发生了什么。 没有社区可以帮助，所以他们陷入了困境。 他们回到了 MySQL。

        *   所有节点上的数据损坏。 如果存在一个错误，该错误会在所有日志中将错误注入到写入日志中，并且压缩或其他机制停止了，该怎么办？ 您的阅读延迟会增加。 您所有的数据都被搞砸了，数据消失了。

        *   无法轻松解决的不正确平衡。 很常见的。 您有 10 个节点，并且注意到所有节点都在一个节点上。 这是一个手动过程，但是它将负载重新分配回一个节点。

        *   数据授权失败。 群集方案非常聪明。 在一种情况下，他们带来了新的中学。 大约 80％的辅助节点表示它是主要节点，而主要节点转到辅助节点，您已经丢失了 20％的数据。 丢失 20％的数据比丢失所有数据更糟糕，因为您不知道丢失了什么。

### 分片-一切都是手动的：

*   裁决：获胜者。 注意，我认为它们的分片架构与 [Flickr 架构](http://highscalability.com/blog/2007/11/13/flickr-architecture.html) 有很多共同点。

*   Properties:

    *   摆脱所有您不喜欢的聚类属性，即可进行分片。

    *   手动分发的数据

    *   数据不动。 尽管有些人这样做，但他们从未移动数据，这使它们在频谱上处于更高的位置。

    *   拆分数据以分配负载。

    *   节点彼此之间不认识。 一些主节点控制一切。

*   Pros:

    *   可以拆分数据库以增加容量。

    *   在空间上分配和配置您的数据

    *   High availability

    *   Load balancing

    *   放置数据的算法非常简单。 主要原因。 有 SPOF，但只有半页代码，而不是非常复杂的 Cluster Manager。 在第一天之后，它会起作用或不起作用。

    *   ID 生成很简单。

*   缺点：

    *   无法执行大多数加入。

    *   失去了所有交易功能。 成功写入另一个数据库时，对一个数据库的写入可能会失败。

    *   必须将许多约束移到应用程序层。

    *   模式更改需要更多计划。

    *   报表需要在所有分片上运行查询，然后自己执行所有聚合。

    *   联接在应用程序层中执行。

    *   您的应用程序必须容忍所有这些问题。

### 什么时候分片？

*   如果您的项目将有几 TB 的数据，则应尽快分片。

*   当 Pin 表达到 10 亿行时，索引用完了内存，它们正在交换到磁盘。

*   他们选择了最大的表并将其放在自己的数据库中。

*   然后它们在单个数据库上用完了空间。

*   然后他们不得不分片。

### 转换为分片

*   从冻结功能开始过渡过程。

*   然后，他们决定了如何分片。 想要执行最少数量的查询并转到最少数量的数据库以呈现单个页面。

*   删除了所有 MySQL 连接。 由于可以将表加载到单独的分区中，因此联接将不起作用。

*   添加了大量的缓存。 基本上每个查询都必须被缓存。

*   步骤如下：

    *   1 个 DB +外键+加入

    *   1 个 DB +规范化+缓存

    *   1 个 DB +读取从站+缓存

    *   几个功能分区的 DB +读取从站+缓存

    *   ID 分片的 DB +备份从属+缓存

*   由于奴隶滞后，较早读取的奴隶成为一个问题。 读取将发送给从属设备，而主设备尚未复制记录，因此看起来好像丢失了记录。 解决这个问题需要缓存。

*   他们具有后台脚本，该脚本重复了数据库过去的工作。 检查完整性约束，参考。

*   用户表未分片。 他们只是使用大型数据库，并且对用户名和电子邮件具有唯一性约束。 如果不是唯一的，则插入用户将失败。 然后，他们在分片数据库中进行了大量写操作。

### 如何分割？

*   看了 Cassandra 的戒指模型。 看着 Membase。 并看着 Twitter 的 Gizzard。

*   确定：跨节点移动的数据最少，体系结构就更稳定。

*   Cassandra 存在数据平衡和权限问题，因为节点不确定谁拥有数据的哪一部分。 他们决定应用程序应该决定数据应该去哪里，所以永远不会有问题。

*   预测了他们未来五年的增长，并牢记这一容量计划。

*   最初创建了许多虚拟分片。 8 台物理服务器，每个服务器有 512 个 DB。 所有数据库都有所有表。

*   为了获得高可用性，它们始终在多主复制模式下运行。 每个主服务器都分配到一个不同的可用区。 发生故障时，切换到另一个主节点，并引入一个新的替换节点。

*   当数据库上的负载增加时：

    *   查看代码提交，以查看是否发生了新功能，缓存问题或其他问题。

    *   如果只是增加负载，他们就会拆分数据库，并告诉应用程序在新主机上查找数据。

    *   在拆分数据库之前，它们会启动这些主服务器的从服务器。 然后，他们用新的数据库分配交换应用程序代码。 在过渡期间的几分钟内，写入仍将写入旧节点，并被复制到新节点。 然后在节点之间切割管道。

### ID 结构

*   64 位：

    *   分片 ID：16 位

    *   类型：10 位-引脚，板，用户或任何其他对象类型

    *   本地 ID-表中 ID 的其余位。 使用 MySQL 自动递增。

*   Twitter 使用映射表将 ID 映射到物理主机。 这需要查找。 由于 Pinterest 在 AWS 上并且 MySQL 查询花费了大约 3 毫秒，因此他们决定这种额外级别的间接操作将不起作用。 他们将位置内置到 ID 中。

*   新用户随机分布在各个分片上。

*   用户的所有数据（引脚，板等）都位于同一分片上。 巨大的优势。 例如，呈现用户个人资料不会进行多个交叉分片查询。 它很快。

*   每个板都与用户并置，因此可以从一个数据库中呈现板。

*   足以容纳 65536 个分片的分片 ID，但最初它们仅打开 4096，它们将水平扩展。 用户数据库用完后，他们将打开更多的分片，并允许新用户访问新的分片。

### 查找

*   例如，如果他们有 50 个查询，他们将拆分 ID 并并行运行所有查询，因此等待时间是最长的等待时间。

*   每个应用程序都有一个配置文件，该文件将分片范围映射到物理主机。

    *   “ sharddb001a”：：( 1，512）

    *   “ sharddb001b” ：：（513，1024）-备份热备机

*   如果要查找 ID 属于 sharddb003a 的用户：

    *   将 ID 分解为各个部分

    *   在分片图中执行查找

    *   连接到分片，转到类型的数据库，然后使用本地 ID 查找合适的用户并返回序列化的数据。

### 对象和映射

*   所有数据都是对象（引脚，面板，用户，注释）或映射（用户具有面板，引脚具有点赞）。

*   对于对象，本地 ID 映射到 MySQL Blob。 Blob 格式以 JSON 开头，但现在已转为序列化节俭。

*   对于映射，有一个映射表。 您可以要求用户提供所有板。 这些 ID 包含时间戳记，因此您可以查看事件的顺序。

    *   有一个反向映射（多对多表），用于回答该类型的查询，这给了我所有喜欢此引脚的用户。

    *   模式命名方案为 noun_verb_noun：user_likes_pins，pins_like_user。

*   查询是主键或索引查找（无联接）。

*   数据不会像集群一样在数据库中移动。 例如，一旦用户登陆到分片 20，并且所有用户数据都并置在一起，它将永远不会移动。 64 位 ID 包含分片 ID，因此无法移动。 您可以将物理数据移动到另一个数据库，但仍与同一分片关联。

*   所有表都存在于所有分片上。 没有特殊的分片，不计算用于检测用户名冲突的庞大用户表。

*   无需更改架构，并且新索引需要新表。

    *   由于键的值为 blob，因此您可以添加字段而不会破坏架构。 每个 Blob 上都有版本控制，因此应用程序将检测版本号，并将记录更改为新格式并写回。 无需一次更改所有数据，将在读取时进行升级。

    *   巨大的胜利，因为更改桌子需要数小时或数天的锁定。 如果要新索引，只需创建一个新表并开始填充它。 当您不再需要时，请将其放下。 （没有提及这些更新如何确保交易安全）。

### 呈现用户个人资料页面

*   从 URL 获取用户名。 转到单个大型数据库以查找用户 ID。

*   获取用户 ID 并将其拆分为各个组成部分。

*   选择分片并转到该分片。

*   来自用户的 SELECT 正文，其中 id = < local_user_id >

*   从 user_has_boards 中选择 board_id，其中 user_id = < user_id >

*   从 ID 为 IN 的板子中选择主体（< boards_ids >）

*   从 board_has_pins 中选择 pin_id，而 board_id = < board_id >

*   从 ID 为 IN 的引脚（PIN_ID）中选择主体

*   大多数调用是通过缓存（内存缓存或 Redis）提供的，因此实际上并没有很多数据库查询。

### 脚本编写

*   迁移到分片式架构时，您有两种不同的基础结构，一种是旧的非分片系统，另一种是新的分片系统。 脚本是将旧内容转移到新内容的所有代码。

*   他们移动了 5 亿个引脚和 16 亿个追随者行，等等

*   低估了项目的这一部分。 他们认为将数据放入碎片中需要 2 个月，而实际上需要 4-5 个月。 记住，这是在功能冻结期间。

*   应用程序必须始终写入新旧基础结构。

*   一旦确定所有数据都在新的基础架构中，然后将您的读取指向新的基础架构，然后慢慢增加负载并测试后端。

*   建立了脚本农场。 动员更多的工人来更快地完成任务。 他们将执行诸如将这些表移至新基础架构之类的任务。

*   窃取了 Pyres 副本，这是 Github Resque 队列的 Python 接口，该队列基于 Redis 构建。 支持优先级和重试。 太好了，他们用 Pyres 代替了 Celery 和 RabbitMQ。

*   该过程中有很多错误。 用户发现错误，例如缺少板。 必须多次运行该过程，以确保没有暂时性错误阻止数据正确移动。

## 开发

*   最初尝试为开发人员提供系统的一部分。 每个服务器都有自己的 MySQL 服务器等，但是事情变化如此之快，因此无法正常工作。

*   转到 Facebook 的模式，每个人都可以访问所有内容。 因此，您必须非常小心。

## 未来方向

*   基于服务的体系结构。

    *   随着他们开始看到大量的数据库负载，他们开始产生许多应用程序服务器和许多其他服务器。 所有这些服务器都连接到 MySQL 和内存缓存。 这意味着内存缓存上有 30K 连接，占用了数 GB 的 RAM，并导致内存缓存守护进程交换。

    *   作为解决方法，它们正在迁移到服务体系结构。 例如，有一个追随者服务，它将仅回答追随者查询。 这样可以将访问数据库和缓存的计算机数量限制为 30，从而减少了连接数量。

    *   帮助隔离功能。 帮助围绕服务和支持这些服务组织团队。 开发人员无法访问其他服务，从而提高了安全性。

## 获得的经验教训

*   将失败。 把事情简单化。

*   保持乐趣。 有很多新人加入这个团队。 如果您只是给他们一个庞大的复杂系统，那将不会很有趣。 保持架构简单是一个巨大的胜利。 从第一周开始，新工程师就开始提供代码。

*   When you push something to the limit all these technologies fail in their own special way.

*   当可以通过添加更多相同的东西来处理增长时，体系结构就做对了。 您希望能够通过在问题上投入更多盒子来解决问题，从而根据需要扩展规模。 如果您的架构能够做到这一点，那么您就很聪明。

*   Cluster Management Algorithm is a SPOF. If there’s a bug it impacts every node. This took them down 4 times.

*   要应对快速增长，您需要平均分配数据以应对不断增长的负载。

*   跨节点移动的数据最少，体系结构就更稳定。 这就是为什么他们在群集上进行分片。

*   面向服务的体系结构规则。 它隔离功能，帮助减少连接，组织团队，组织支持并提高安全性。

*   问自己，你真正想要成为什么。 即使您必须重新构建所有架构，也要删除符合该愿景的技术。

*   不要害怕丢失一些数据。 它们将用户数据保留在内存中并定期将其写出。 丢失意味着仅丢失了几个小时的数据，但是最终的系统却变得更加简单和强大，这才是重要的。

## 相关文章

*   [讨论黑客新闻](https://news.ycombinator.com/item?id=5552504)
*   [Pinterest 体系结构更新-1800 万访问者，增长 10 倍，拥有 12 名员工，410 TB 数据](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html)
*   [用于处理 3 百万以上用户的 Pinterest 堆栈中的一个短项](http://highscalability.com/blog/2012/2/16/a-short-on-the-pinterest-stack-for-handling-3-million-users.html)
*   [Pinterest 通过自动关闭系统将费用从每小时 54 美元降低到 20 美元](http://highscalability.com/blog/2012/12/12/pinterest-cut-costs-from-54-to-20-per-hour-by-automatically.html)
*   [Instagram 体系结构更新：Instagram 有何新功能？](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html)
*   [Facebook 过去曾增长到 5 亿用户的 7 种扩展策略](http://highscalability.com/blog/2010/8/2/7-scaling-strategies-facebook-used-to-grow-to-500-million-us.html)和 [Facebook](http://highscalability.com/blog/2010/6/10/the-four-meta-secrets-of-scaling-at-facebook.html) 扩展的四个元秘密-我认为您会在他们的方法中找到一些相似之处。

一个小的更正，“ Web Solr”应实际读取为“ Websolr”，如 http://websolr.com/

非常感谢你的这篇文章。 简单明了地指出了每个方面：）

没有提及实际的 Web 应用程序使用什么编程语言和框架。 请告诉我他们没有在 PHP 中执行此操作...

Python ... Pinterest 一直被吹嘘为 DJango 实现。 看到这里：http://www.quora.com/Pinterest/What-technologies-were-used-to-make-Pinterest

有人知道他们是否仍将 Nginx 用作应用服务器负载平衡器吗？

在“为什么要 Amazon EC2 / S3”部分下，提到了“ App Engine”。 这让我感到困惑（因为 App Engine 是 Google，而不是 Amazon）。 有人可以澄清吗？

交换？ 删除交换，交换比失败诱饵更糟糕。
停机服务器比 ssssllllllooooooowwwww 服务器更好。

绕开 CDN 的原因是什么？

有人知道他们如何存储图像吗？ 在 mysql，磁盘还是其他地方？
例如，URL“ http://media-cache-ec4.pinimg.com/736x/cf/d7/49/cfd74959947950dd0c3c1ef8ef2f1582.jpg”中的 imageid 可能包含一些信息？ 谢谢

很想知道更多有关 Mongo 为什么被删除的信息，以支持在 MySQL 中存储无模式的 Blob。 这仅仅是错误，性能低下的问题吗？ 好像 Mongo 是为这种 BASE 体系结构设计的，如果它可以很好地运行，则无需在应用程序层手动管理索引的开销。

小修正：在您喜欢的讲座的 2 课中的第 1 课中，您说“您是建筑”而不是“您的建筑”。

非常有趣的阅读。

谁能解释：
对于对象，本地 ID 映射到 MySQL Blob。 Blob 格式以 JSON 开头，但现在已转为序列化节俭。

为什么本地 ID 映射到 mysql Blob？

感谢您发布此信息。 看到架构的潮起潮落总是让人着迷。 但是，我不同意本文的最后一点。

> 不要害怕丢失一些数据。

该陈述完全取决于所讨论数据的使用。 在 Pinterest 的情况下，我可以看到它完全可以实现。 所涉及的数据没有货币价值，如果丢失了任何人的生命都不会受到特别的影响。 但是，我认为区分不重要的数据丢失和重要的数据非常重要。

当您说“ Web Engine”时，您指的是什么？ 这是否意味着另一个克隆了主应用程序的云实例？

你好

我很好奇，当一个用户数据过大而又无法容纳一个分片时，会发生什么？

此致
拉希德

有人能粗略估计一下这些设置每个月要花费多少吗？

为什么同时使用 Memcache 和 Redis？ Redis 几乎可以完成 Memcache 可以做的所有事情，还有其他用途。

即使在这些年之后，这篇文章也很有意义。 感谢您抽出宝贵的时间，并详细说明了构建简单的可伸缩 Web 平台需要花费的一切！