规划一个支撑百万用户的体系是具有应战性的，这是一段需求不断改进和不断进步的旅程。在本章中，咱们将构建一个支撑单个用户的体系，并逐渐扩展以服务于数百万用户。阅读本章后，您将把握一些技巧，帮助您处理体系规划面试问题。
AI不会替代你,运用AI的人会。欢迎重视我的公众号：更AI。以程序员的视角来看AI能带给咱们什么~
单服务器设置
千里之行始于足下，构建一个杂乱的体系也是如此。为了从简略的东西开端，咱们将一切内容都运转在一个独自的服务器上。图1显现了一个单服务器设置的示意图，其间一切内容都在一个服务器上运转：Web运用程序、数据库、缓存等。
为了了解这个设置，有助于查询恳求流程和流量来历。让咱们首要看一下恳求流程（图1-2）。
- 用户经过域名拜访网站，例如api.mysite.com。一般，域名体系（DNS）是由第三方供给的付费服务，而不是由咱们的服务器保管。
- Internet协议（IP）地址回来给浏览器或移动运用。在本例中，回来的IP地址是15.125.23.214。
- 一旦获得IP地址，超文本传输协议（HTTP）[1]恳求将直接发送到您的Web服务器。
- Web服务器回来HTML页面或JSON呼应进行烘托。
接下来，让咱们来看一下流量来历。流向您的Web服务器的流量来自两个来历：Web运用程序和移动运用程序。
- Web运用程序：它运用一组服务器端言语（Java、Python等）来处理事务逻辑、存储等，以及客户端言语（HTML和JavaScript）来进行展现。
- 移动运用程序：HTTP协议是移动运用程序与Web服务器之间的通讯协议。因为其简略性，JavaScript目标表明法（JSON）一般用于传输数据的API呼应格式。下面是一个以JSON格式显现的API呼应示例：
GET /users/12 – 检索id为12的用户目标
数据库
跟着用户集体的增长，一个服务器现已不够用了，咱们需求多台服务器：一台用于处理网站和移动端的流量，另一台用于数据库（图1-3）。将网站和移动端流量（Web层）与数据库（数据层）服务器分离，能够使它们能够独立扩展。
运用哪种数据库？
您能够挑选传统联络型数据库或非联络型数据库。让咱们来看看它们的差异。
联络型数据库也被称为联络数据库办理体系（RDBMS）或SQL数据库。最流行的有MySQL、Oracle数据库、PostgreSQL等。联络型数据库运用表和行来表明和存储数据。您能够运用SQL在不同的数据库表之间履行联接操作。
非联络型数据库也被称为NoSQL数据库。流行的有CouchDB、Neo4j、Cassandra、HBase、Amazon DynamoDB等[2]。这些数据库分为四类：键值存储、图存储、列存储和文档存储。非联络型数据库一般不支撑联接操作。
关于大多数开发者来说，联络型数据库是最佳挑选，因为它们现已存在了40多年，而且在历史上表现杰出。但是，假如联络型数据库不适合您特定的运用情况，探索逾越联络型数据库是至关重要的。假如满意以下情况，非联络型数据库或许是正确的挑选：
-
您的运用程序需求超低的推迟。
-
您的数据对错结构化的，或者您没有任何联络数据。
-
您只需求对数据进行序列化和反序列化（JSON、XML、YAML等）。
-
您需求存储很多的数据。
笔直扩展与水平扩展
笔直扩展，也称为“纵向扩展”，是指向服务器添加更多的处理才能（CPU、RAM等）的进程。水平扩展，也称为“横向扩展”，答应您经过向资源池中添加更多的服务器来进行扩展。
当流量较低时，笔直扩展是一个很好的挑选，笔直扩展的简略性是其首要长处。不幸的是，它也存在一些严峻的局限性。
- 笔直扩展有一个硬性约束。不或许向单个服务器添加无限的CPU和内存。
- 笔直扩展没有毛病搬运和冗余。假如一个服务器宕机，网站/运用将彻底无法拜访。
因为笔直扩展的约束，关于大规模运用程序来说，水平扩展愈加理想。
在之前的规划中，用户直接连接到Web服务器。假如Web服务器脱机，用户将无法拜访网站。在另一种情况下，假如许多用户同时拜访Web服务器并到达Web服务器的负载约束，用户一般会遇到呼应变慢或无法连接到服务器的问题。负载均衡器是处理这些问题的最佳技能。
负载均衡器
负载均衡器会将传入的流量均匀分配给在负载均衡调集中界说的Web服务器。图1-4展现了负载均衡器的作业原理。
如图1-4所示，用户直接连接负载均衡器的公共IP。经过这种设置，Web服务器不再能直接被客户端拜访。为了更好的安全性，私有IP用于服务器之间的通讯。私有IP是一个只能在同一网络中的服务器之间拜访的IP地址，无法经过互联网拜访。负载均衡器经过私有IP与Web服务器进行通讯。
在图1-4中，当负载均衡器和第二个Web服务器添加后，咱们成功处理了毛病切换的问题，并进步了Web层的可用性。具体细节如下：
- 假如服务器1下线，一切流量将被路由到服务器2。这样能够防止网站宕机。咱们还能够向服务器池中添加一个新的健康Web服务器来平衡负载。
- 假如网站流量迅速增长，两个服务器无法处理流量，负载均衡器能够优雅地处理这个问题。您只需求向Web服务器池添加更多服务器，负载均衡器将自动开端将恳求发送给它们。
现在Web层看起来很好，那数据层呢？当时的规划只要一个数据库，因而不支撑毛病搬运和冗余。数据库仿制是处理这些问题的常见技能。让咱们来看一下。
数据库仿制
引用自维基百科：“数据库仿制能够在许多数据库办理体系中运用，一般在原始数据库（主数据库）和副本（从数据库）之间建立主/从联络。” [3]
主数据库一般仅支撑写操作。从数据库从主数据库获取数据的副本，仅支撑读操作。一切的插入、删去或更新等修正数据的命令有必要发送到主数据库。大多数运用程序需求更高份额的读操作与写操作，因而体系中从数据库的数量一般大于主数据库的数量。图1-5显现了一个具有多个从数据库的主数据库。
数据库仿制的优势：
- 更好的功能：在主从模型中，一切的写操作和更新操作都发生在主节点上，而读操作散布在从节点上。这种模型改进了功能，因为它答应更多的查询并行处理。
- 可靠性：假如你的数据库服务器之一被自然灾害（如台风或地震）炸毁，数据依然得以保留。你不需求担心数据丢掉，因为数据被仿制到多个方位。
- 高可用性：经过在不同的方位仿制数据，即使一个数据库离线，你的网站依然能够运转，因为你能够拜访存储在另一个数据库服务器中的数据。
在前一节中，咱们评论了负载均衡器怎么帮助进步体系的可用性。咱们在这里提出相同的问题：假如其间一个数据库离线了会怎么样？图1-5中评论的架构规划能够处理这种情况：
- 假如只要一个可用的从数据库，而且它离线了，读操作将暂时指向主数据库。一旦问题被发现，一个新的从数据库将替代旧的数据库。假如有多个可用的从数据库，读操作将被重定向到其他健康的从数据库。一个新的数据库服务器将替代旧的数据库。
- 假如主数据库离线了，一个从数据库将被进步为新的主数据库。一切的数据库操作将在新的主数据库上暂时履行。一个新的从数据库将立即替代旧的数据库进行数据仿制。在出产体系中，进步新的主数据库更为杂乱，因为从数据库中的数据或许不是最新的。需求经过运转数据恢复脚原本更新缺失的数据。虽然一些其他的仿制办法，如多主和环形仿制，能够供给帮助，但这些设置愈加杂乱，它们的评论超出了本书的规模。有爱好的读者能够参考所列的参考资料[4] [5]。
图1-6显现了添加了负载均衡器和数据库仿制后的体系规划。
让咱们来看一下规划：
- 用户从DNS获取负载均衡器的IP地址。
- 用户运用该IP地址连接到负载均衡器。
- HTTP恳求被路由到服务器1或服务器2。
- Web服务器从从数据库读取用户数据。
- Web服务器将任何修正数据的操作路由到主数据库。包含写入、更新和删去操作。
- 现在，你现已对Web和数据层有了扎实的了解，是时分经过添加缓存层并将静态内容（JavaScript/CSS/图画/视频文件）搬运到内容分发网络（CDN）来进步负载/呼应时刻了。
缓存
缓存是一个暂时存储区，用于在内存中存储贵重的呼应成果或常常拜访的数据，以便后续的恳求能够更快地得到服务。如图1-6所示，每次加载新的网页时，会履行一个或多个数据库调用来获取数据。重复调用数据库会严峻影响运用程序功能。缓存能够缓解这个问题。
缓存层
缓存层是一个比数据库快得多的暂时数据存储层。拥有独立的缓存层有以下好处：体系功能更好、能够削减数据库作业负载以及能够独立扩展缓存层。图1-7显现了一个或许的缓存服务器设置：
收到恳求后，Web服务器首要检查缓存中是否有可用的呼应。假如有，则将数据发送回客户端。假如没有，则查询数据库，将呼应存储在缓存中，并将其发送回客户端。这种缓存战略称为读取穿透缓存。依据数据类型、巨细和拜访形式，还能够运用其他缓存战略。一项曾经的研讨解释了不同的缓存战略怎么作业[6]。与缓存服务器的交互十分简略，因为大多数缓存服务器为常见的编程言语供给API。以下代码片段显现了典型的Memcached API：
运用缓存的注意事项
以下是运用缓存体系时应考虑的几个问题：
-
决定何时运用缓存。在数据常常被读取但很少被修正时，考虑运用缓存。因为缓存数据存储在易失性内存中，缓存服务器不适合用于持久化数据。例如，假如缓存服务器从头启动，内存中的一切数据都会丢掉。因而，重要的数据应保存在持久化数据存储中。
-
过期战略。施行过期战略是一个好的做法。一旦缓存数据过期，它将从缓存中删去。当没有过期战略时，缓存数据将永久存储在内存中。主张不要将过期日期设置得太短，不然体系会过于频繁地从数据库从头加载数据。同时，也不主张将过期日期设置得太长，防止数据变得陈腐。
-
一致性：这涉及坚持数据存储和缓存的同步。因为数据存储和缓存上的数据修正操作不在单个事务中，所以或许发生不一致。在跨多个区域进行扩展时，坚持数据存储和缓存之间的一致性是具有应战性的。有关详细信息，请参考Facebook宣布的题为《Scaling Memcache at Facebook》的论文[7]。
-
减轻毛病：单个缓存服务器代表潜在的单点毛病（SPOF），维基百科对其的界说如下：“单点毛病（SPOF）是体系的一部分，假如它发生毛病，将导致整个体系停止作业”[8]。因而，主张在不同的数据中心中运用多个缓存服务器，以防止单点毛病。另一个引荐的办法是经过一定百分比进行过量装备所需的内存。这样能够供给一个缓冲区，以应对内存运用量添加的情况。
- 筛选战略：一旦缓存已满，任何向缓存中添加项的恳求都或许导致现有项被移除。这被称为缓存筛选。最近最少运用（LRU）是最常见的缓存筛选战略。其他筛选战略，如最不常常运用（LFU）或先进先出（FIFO），可依据不同的运用情况选用。
内容分发网络（CDN）
CDN是一个由地舆散布的服务器组成的网络，用于传送静态内容。CDN服务器缓存像图画、视频、CSS、JavaScript文件等静态内容。
动态内容缓存是一个相对较新的概念，超出了本书的规模。它使得能够缓存依据恳求路径、查询字符串、cookie和恳求头的HTML页面。有关更多信息，请参考参考资料[9]中说到的文章。本书重点介绍怎么运用CDN来缓存静态内容。
以下是CDN的高档作业原理：当用户拜访网站时，距离用户最近的CDN服务器将传送静态内容。直观来说，用户离CDN服务器越远，网站加载速度就越慢。例如，假如CDN服务器坐落旧金山，洛杉矶的用户将比欧洲的用户更快地获取内容。图1-9是一个很好的示例，显现了CDN怎么进步加载时刻。
图1-10展现了CDN的作业流程。
- 用户A测验运用图画URL获取image.png。URL的域名由CDN供给商供给。以下两个图画URL是用来演示Amazon和Akamai CDN上图画URL的样例：
- mysite.cloudfront.net/logo.jpg
- mysite.akamai.com/image-manag…
- 假如CDN服务器没有image.png的缓存，CDN服务器会从源（能够是Web服务器或像Amazon S3这样的在线存储）恳求文件。
- 源将image.png回来给CDN服务器，其间包含可选的HTTP头部Time-to-Live（TTL），描述图画被缓存的时刻。
- CDN缓存图画并将其回来给用户A。图画会在CDN中缓存，直到TTL过期。
- 用户B发送恳求以获取相同的图画。
- 只要TTL未过期，图画将从缓存中回来。
CDN 运用的考虑因素
- 成本：CDN 由第三方供给商运营，您需求付出 CDN 表里的数据传输费用。关于不常常运用的资源，缓存并没有明显的好处，所以您应该考虑将其移出 CDN。
- 设置恰当的缓存过期时刻：关于时刻灵敏的内容，设置缓存过期时刻十分重要。缓存过期时刻既不能太长也不能太短。假如时刻太长，内容或许现已不新鲜。假如时刻太短，或许会导致重复从源服务器从头加载内容到 CDN。
- CDN 回退：您应该考虑您的网站/运用程序怎么应对 CDN 毛病。假如呈现暂时的 CDN 中止，客户端应该能够检测到问题并从源获取资源。
- 使文件失效：您能够在文件过期之前从 CDN 中移除文件，具体操作有以下几种：
- 运用 CDN 供应商供给的 API 使 CDN 目标失效。
- 运用目标版别操控来供给不同版别的目标。要对目标进行版别操控，能够向 URL 添加参数，比如版别号。例如，查询字符串中添加版别号 2：image.png?v=2。
图 1-11 展现了在添加 CDN 和缓存后的规划。
- 静态资源（JS、CSS、图片等）不再由 Web 服务器供给。它们从 CDN 获取以获得更好的功能。
- 经过缓存数据减轻了数据库的负载。
无状况的Web层
现在是考虑水平扩展Web层的时分了。为此，咱们需求将状况（例如用户会话数据）从Web层中移出。一个很好的做法是将会话数据存储在持久性存储中，如联络型数据库或NoSQL数据库。集群中的每个Web服务器都能够从数据库中拜访状况数据。这被称为无状况的Web层。
有状况架构
有状况服务器和无状况服务器有一些要害差异。有状况服务器会记住从一个恳求到下一个恳求的客户端数据（状况）。无状况服务器不保存任何状况信息。
图1-12显现了一个有状况架构的示例。
在图1-12中，用户A的会话数据和个人资料图片存储在服务器1中。要对用户A进行身份验证，HTTP恳求有必要路由到服务器1。假如恳求被发送到其他服务器，如服务器2，身份验证将失利，因为服务器2不包含用户A的会话数据。相同，来自用户B的一切HTTP恳求有必要路由到服务器2；来自用户C的一切恳求有必要发送到服务器3。
问题在于同一客户端的每个恳求有必要路由到同一台服务器。在大多数负载均衡器中，能够经过粘性会话来完成这一点[10]；但是，这会添加开支。运用这种办法愈加困难地添加或删去服务器。处理服务器毛病也是一项应战。
无状况架构
图1-13展现了无状况架构。
在这种无状况架构中，用户的HTTP恳求能够发送到任何Web服务器，这些服务器从同享数据存储中获取状况数据。状况数据存储在同享数据存储中，而且不保存在Web服务器中。无状况体系更简略、更健壮和可扩展。
图1-14展现了带有无状况Web层的更新规划。
在图1-14中，咱们将会话数据从Web层移出，并将其存储在持久数据存储中。同享数据存储能够是联络数据库、Memcached/Redis、NoSQL等。挑选NoSQL数据存储是因为它易于扩展。自动扩展意味着依据流量负载自动添加或删去Web服务器。在状况数据从Web服务器中移除后，依据流量负载添加或删去服务器轻松完成Web层的自动扩展。
您的网站快速增长，并吸引了很多世界用户。为了进步可用性并在更广泛的地舆区域供给更好的用户体验，支撑多个数据中心至关重要。
数据中心
图1-15显现了一个拥有两个数据中心的示例设置。在正常运转时，用户会依据地舆方位经过geoDNS路由到最近的数据中心，其间在美国东部的流量占x%，在美国西部的流量占*(100 – x)%*。geoDNS是一种DNS服务，依据用户所在地将域名解析为IP地址。
假如发生任何重大数据中心毛病，咱们会将一切流量引导到一个正常运转的数据中心。在图1-16中，数据中心2（美国西部）离线，100%的流量被路由到数据中心1（美国东部）。
要完成多数据中心设置，需求处理一些技能应战：
- 流量重定向：需求有效的东西将流量引导到正确的数据中心。依据用户所在地，能够运用geoDNS将流量引导到最近的数据中心。
- 数据同步：来自不同区域的用户或许运用不同的本地数据库或缓存。在毛病搬运情况下，流量或许会路由到一个数据中心，该数据中心的数据不可用。一种常见的战略是在多个数据中心之间仿制数据。一项先前的研讨展现了Netflix怎么完成异步多数据中心仿制[11]。
- 测验和部署：关于多数据中心设置，重要的是在不同的方位测验您的网站/运用程序。自动化部署东西关于坚持一切数据中心的服务一致至关重要[11]。
为了进一步扩展咱们的体系，咱们需求解耦体系的不同组件，使它们能够独立扩展。音讯行列是许多实践散布式体系用于处理这个问题的要害战略。
音讯行列
音讯行列是一种持久性组件，存储在内存中，用于支撑异步通讯。它作为缓冲区并分发异步恳求。音讯行列的根本架构很简略。称为出产者/发布者的输入服务创建音讯，并将其发布到音讯行列中。其他服务或服务器，称为顾客/订阅者，连接到行列并履行音讯界说的操作。模型如图1-17所示。
解耦使音讯行列成为构建可扩展和可靠运用程序的首选架构。运用音讯行列，当顾客无法处理音讯时，出产者能够将音讯发布到行列中。即使出产者不可用，顾客也能够从行列中读取音讯。
考虑以下用例：您的运用程序支撑照片定制，包含裁剪、锐化、含糊等操作。这些定制使命需求时刻来完成。在图1-18中，Web服务器将照片处理作业发布到音讯行列中。照片处理作业者从音讯行列中接纳作业，并异步履行照片定制使命。出产者和顾客能够独立扩展。当行列的巨细变大时，能够添加更多作业者以削减处理时刻。但是，假如行列大部分时刻为空，作业者的数量能够削减。
日志记载、目标、自动化
在处理只运转在几台服务器上的小型网站时，日志记载、目标和自动化支撑是杰出的实践，但并非必需。但是，现在你的网站现已开展成为一个为大型企业供给服务的网站，投资于这些东西是必不可少的。
日志记载：监控过错日志十分重要，因为它有助于识别体系中的过错和问题。您能够在每个服务器等级监控过错日志，也能够运用东西将它们聚合到一个集中式服务中，以便进行简略的查找和检查。
目标：收集不同类型的目标有助于咱们获取事务见解并了解体系的健康状况。以下是一些有用的目标：
- 主机等级的目标：CPU、内存、磁盘I/O等。
- 聚合等级的目标：例如整个数据库层、缓存层等的功能。
- 要害事务目标：每日活跃用户、留存率、收入等。
自动化：当体系变得庞大而杂乱时，咱们需求构建或利用自动化东西来进步出产效率。继续集成是一种杰出的实践，经过自动化验证每次代码提交，使团队能够前期发现问题。此外，自动化构建、测验、部署流程等能够明显进步开发人员的出产力。
添加音讯行列和其他东西
图1-19显现了更新后的规划。因为空间约束，图中只显现了一个数据中心。
- 规划中包含一个音讯行列，有助于使体系更松散耦合和具有容错性。
- 包含了日志记载、监控、目标和自动化东西。
跟着每天数据的增长，您的数据库负荷越来越重。是时分对数据层进行扩展了。
数据库扩展
数据库扩展有两种首要办法：笔直扩展和水平扩展。
笔直扩展
也称为纵向扩展，是经过向现有机器添加更多的功能（CPU、RAM、DISK等）来进行扩展。有一些功能强壮的数据库服务器。依据亚马逊联络数据库服务（RDS）[12]，你能够获得一台具有24 TB RAM的数据库服务器。这种强壮的数据库服务器能够存储和处理很多的数据。例如，2013年的stackoverflow.com每月有超过1000万的独立拜访者，但它只要1个主数据库[13]。但是，笔直扩展也存在一些严峻的缺点：
- 你能够为数据库服务器添加更多的CPU、RAM等，但存在硬件约束。假如你有很多的用户，单个服务器是不够的。
- 单点毛病的危险添加。
- 笔直扩展的总体成本较高。强壮的服务器愈加贵重。
水平扩展
也称为分片，是添加更多服务器的做法。图1-20比较了笔直扩展和水平扩展。
分片将大型数据库分割成更小、更易办理的部分，称为分片。每个分片同享相同的形式，尽管每个分片上的实践数据是仅有的。
图1-21展现了分片数据库的示例。用户数据依据用户ID分配到数据库服务器上。每当你拜访数据时，都会运用散列函数来找到相应的分片。在咱们的示例中，user_id % 4被用作散列函数。假如成果等于0，则运用分片0来存储和获取数据。假如成果等于1，则运用分片1。其他分片的逻辑也是相同的。
图1-22展现了分片数据库中的用户表。
在施行分片战略时，最重要的因素是挑选分片键。分片键（也称为分区键）由一个或多个列组成，用于确定数据的散布方法。如图1-22所示，“user_id”是分片键。分片键答应你经过将数据库查询路由到正确的数据库来高效地检索和修正数据。在挑选分片键时，最重要的一个标准是挑选一个能够均匀散布数据的键。
分片是扩展数据库的一种很好的技能，但远非完美的处理方案。它给体系引入了杂乱性和新的应战：
从头分片数据：当1）单个分片因为快速增长而无法再容纳更多数据时，需求从头分片数据。2）某些分片或许因为不均匀的数据散布而更快地耗尽分片。当分片耗尽时，需求更新分片函数并移动数据。一种常用的处理此问题的技能是一致性哈希，将在第5章中评论。
热门键问题：也称为明星问题。对特定分片的过度拜访或许导致服务器超载。幻想一下，Katy Perry、Justin Bieber和Lady Gaga的数据都终究存储在同一个分片上。关于交际运用来说，该分片将被读操作吞没。为了处理这个问题，咱们或许需求为每个名人分配一个分片。甚至每个分片或许还需求进一步分区。
连接和去规范化：一旦数据库被分片到多个服务器上，履行跨数据库分片的连接操作就变得困难。一个常见的处理办法是对数据库进行去规范化，以便能够在单个表中履行查询。
在图1-23中，咱们对数据库进行分片以支撑快速增长的数据流量。与此同时，一些非联络型功能被移到NoSQL数据存储中，以减轻数据库负载。这是一篇涵盖了NoSQL许多运用事例的文章[14]。
超过数百万用户的规模
体系的扩展是一个迭代的进程。依据本章学到的知识进行迭代或许会使咱们走得更远。为了逾越数百万用户，需求更多的优化和新战略。例如，您或许需求优化您的体系并将体系解耦为更小的服务。本章学到的一切技能应该为应对新的应战供给了杰出的基础。为了总结本章，咱们供给了怎么扩展咱们的体系以支撑数百万用户的摘要：
- 坚持 Web 层无状况
- 在每个层面上构建冗余性
- 尽或许地缓存数据
- 支撑多个数据中心
- 在 CDN 中保管静态资源
- 经过分片扩展数据层
- 将层级拆分为独立的服务
- 监控您的体系并运用自动化东西
祝贺您取得了如此大的进展！现在给自己一个鼓励。做得好！
AI不会替代你,运用AI的人会。欢迎重视我的公众号：更AI。以程序员的视角来看AI能带给咱们什么~
参考资料
[1] 超文本传输协议（Hypertext Transfer Protocol）: zh.wikipedia.org/wiki/超文本传输协…
[2] 你是否应该逾越联络型数据库？:
blog.teamtreehouse.com/should-you-…
[3] 仿制（Replication）: zh.wikipedia.org/wiki/仿制_(计算…
[4] 多主仿制（Multi-master replication）:
zh.wikipedia.org/wiki/多主仿制
[5] NDB 集群仿制：多主和环形仿制:
dev.mysql.com/doc/refman/…
[6] 缓存战略及怎么挑选适宜的战略:
codeahoy.com/2017/08/11/…
[7] R. Nishtala，“Facebook 的缓存扩展”，第十届 USENIX 网络体系规划与完成研讨会（NSDI ’13）。
[8] 单点毛病（Single point of failure）: zh.wikipedia.org/wiki/单点毛病
[9] Amazon CloudFront 动态内容传送:
aws.amazon.com/cloudfront/…
[10] 装备经典负载均衡器的黏性会话:
docs.aws.amazon.com/elasticload…
[11] 多区域容错性的自动-自动（Active-Active）:
netflixtechblog.com/active-acti…
[12] Amazon EC2 高内存实例:
aws.amazon.com/ec2/instanc…
[13] 运转 Stack Overflow 的所需条件:
nickcraver.com/blog/2013/1…
[14] 你到底在运用 NoSQL 做什么:
highscalability.com/blog/2010/1…
本文翻译自《System Design Interview: An Insider’s Guide》第一章，如有侵权，请联络本人删去
