在 AWS 上设计支持百万级到千万级用户的系统 #31

AceLeeWinnie · 2017-05-26T06:19:35Z

No description provided.

0x4ec7 · 2017-06-06T08:05:37Z

solutions/system_design/scaling_aws/README.md

@@ -1,33 +1,62 @@
 # Design a system that scales to millions of users on AWS
+# 在 AWS 上设计支持百万级到千万级用户的系统


在AWS上设计可扩展到百万级用户的系统

这个是标题是之前已经定好了吗???

不是，有更好的也可以改

0x4ec7 · 2017-06-06T08:08:42Z

solutions/system_design/scaling_aws/README.md

 > Gather requirements and scope the problem.
 > Ask questions to clarify use cases and constraints.
 > Discuss assumptions.

+> 收集需求和问题域。


scope应该作动词讲, 调查/审视

0x4ec7 · 2017-06-06T08:09:18Z

solutions/system_design/scaling_aws/README.md

+> 收集需求和问题域。
+> 通过提问清晰用例和约束。
+> 讨论假设。
+
 Without an interviewer to address clarifying questions, we'll define some use cases and constraints.


全文的interviewer应该指的是: 面试官

0x4ec7 · 2017-06-06T08:13:04Z

solutions/system_design/scaling_aws/README.md

 Solving this problem takes an iterative approach of: 1) **Benchmark/Load Test**, 2) **Profile** for bottlenecks 3) address bottlenecks while evaluating alternatives and trade-offs, and 4) repeat, which is good pattern for evolving basic designs to scalable designs.

+解决这个问题是一个循序渐进的过程：1) **基准/负载 测试**， 2) 瓶颈 **概述**， 3) 当评估可选和折中方案时定位瓶颈，4) 重复，这是向可扩展的设计发展基础设计的好模式。


建议: 4) repeat, which is good pattern for evolving basic designs to scalable designs.
重复是从基础设计到可扩展设计的好模式

个人觉得后面的 which 从句修饰的是 an iterative approach 即这四个步骤组成的一系列过程。

0x4ec7 · 2017-06-06T08:17:00Z

solutions/system_design/scaling_aws/README.md

 **Clarify with your interviewer if you should run back-of-the-envelope usage calculations.**

+**如果你应该做一个粗略的使用计算，需要和你的访谈人员明确这一点**


建议: 向你的面试官厘清你是否应该做粗略的使用计算

0x4ec7 · 2017-06-06T08:18:57Z

solutions/system_design/scaling_aws/README.md

+* 250 万秒 / 月
+* 1 次请求 / 秒 = 250 万次请求 / 月
+* 40 次请求 / 秒 = 1 亿次请求 / 月
+* 400 请求 / 秒 = 10 亿请求 / 月


400 次请求 / 秒 = 10 亿次请求 / 月.
保持一致

0x4ec7 · 2017-06-06T08:23:51Z

solutions/system_design/scaling_aws/README.md

 Add a **DNS** such as Route 53 to map the domain to the instance's public IP.

+添加 **DNS** 服务，比如 53 号路由，将域映射到实例的公共 IP 中。


Route 53: https://aws.amazon.com/cn/route53/

0x4ec7 · 2017-06-06T08:27:37Z

solutions/system_design/scaling_aws/README.md

@@ -157,8 +303,18 @@ We've been able to address these issues with **Vertical Scaling** so far.  Unfor
    * Additional security measures must be taken to secure the new components
    * AWS costs could also increase, but should be weighed with the costs of managing similar systems on your own

+* 减轻单台服务器负载并且允许独立扩展
+    * 在 **对象存储中** 单独存储静态内容


在 对象存储 中单独存储静态内容

0x4ec7 · 2017-06-06T08:33:18Z

solutions/system_design/scaling_aws/README.md

@@ -169,36 +325,74 @@ We've been able to address these issues with **Vertical Scaling** so far.  Unfor
    * Images
    * Videos

+* 考虑使用托管像 S3 的 **对象存储** 来存储静态内容


考虑使用像 S3 这样可管理的 对象存储 服务来存储静态内容

0x4ec7 · 2017-06-06T08:34:10Z

solutions/system_design/scaling_aws/README.md

 * Consider using a service like RDS to manage the **MySQL Database**
    * Simple to administer, scale
    * Multiple availability zones
    * Encryption at rest

+* 考虑使用类似 RDS 的服务来管理 **MySQL 数据库**


上一段落翻译为像

0x4ec7 · 2017-06-06T08:35:04Z

solutions/system_design/scaling_aws/README.md

 * Consider using a service like RDS to manage the **MySQL Database**
    * Simple to administer, scale
    * Multiple availability zones
    * Encryption at rest

+* 考虑使用类似 RDS 的服务来管理 **MySQL 数据库**
+    * 简单的管理，扩展
+    * 多可用空间


建议: 多个可用区域

0x4ec7 · 2017-06-06T08:37:36Z

solutions/system_design/scaling_aws/README.md

+    * 为单个 **Web 服务器** 创建一个公共子网，这样就可以发送和接收来自 internet 的流量
+    * 为其他内容创建一个私有子网，禁止外部访问
+    * 在每个组件上只为白名单 IP 打开端口
+* 这些相同的模式在剩下的练习中应该同样为新组件实现


建议: 这些相同的模式应当在新的组件的实现中实践.

0x4ec7 · 2017-06-06T08:38:51Z

solutions/system_design/scaling_aws/README.md

@@ -214,22 +408,51 @@ Our **Benchmarks/Load Tests** and **Profiling** show that our single **Web Serve
    * For example, you can add **Application Servers** handling **Read APIs** while others handle **Write APIs**
 * Move static (and some dynamic) content to a [**Content Delivery Network (CDN)**](https://github.com/donnemartin/system-design-primer#content-delivery-network) such as CloudFront to reduce load and latency

+* 下面的目标试图用 **Web服务器** 解决伸缩性问题


scaling 在之前语段译作扩展

0x4ec7 · 2017-06-06T08:56:04Z

solutions/system_design/scaling_aws/README.md

+* 使用 [**横向扩展**](https://github.com/donnemartin/system-design-primer#horizontal-scaling) 来处理增加的负载和单点故障
+    * 添加 [**负载均衡器**](https://github.com/donnemartin/system-design-primer#load-balancer) 例如 Amazon 的 ELB 或 HAProxy
+        * ELB 是高可用的
+        * 如果你正在配置自己的 **负载均衡器**, 在多个可用性区域中设置多台服务器用于 [双活](https://github.com/donnemartin/system-design-primer#active-active) 或 [主被动活动](https://github.com/donnemartin/system-design-primer#active-passive) 将提高可用性


[主被动活动] > [主被]

0x4ec7 · 2017-06-06T08:58:08Z

solutions/system_design/scaling_aws/README.md

+        * 如果你正在配置自己的 **负载均衡器**, 在多个可用性区域中设置多台服务器用于 [双活](https://github.com/donnemartin/system-design-primer#active-active) 或 [主被动活动](https://github.com/donnemartin/system-design-primer#active-passive) 将提高可用性
+        * 终止在 **负载平衡器** 上的SSL，以减少后端服务器上的计算负载，并简化证书管理
+    * 在多个可用性区域中使用多台 **Web服务器**
+    * 在多个可用性区域的 [**主-从 故障转移**](https://github.com/donnemartin/system-design-primer#master-slave-replication) 模式中使用多个 **MySQL** 实例来改进冗余


可用性区域 > 可用区域

可用性区域感觉怪怪的

0x4ec7 · 2017-06-06T09:01:23Z

solutions/system_design/scaling_aws/README.md

 Our **Benchmarks/Load Tests** and **Profiling** show that we are read-heavy (100:1 with writes) and our database is suffering from poor performance from the high read requests.

+我们的 **性能/负载测试** 和 **性能测试** 显示我们读操作频繁（100:1 的读写比率），并且数据库在高读请求时表现很糟糕。


Profiling 与之前翻译段落不一致

0x4ec7 · 2017-06-06T09:08:03Z

solutions/system_design/scaling_aws/README.md

 * In addition to adding and scaling a **Memory Cache**, **MySQL Read Replicas** can also help relieve load on the **MySQL Write Master**
 * Add logic to **Web Server** to separate out writes and reads
 * Add **Load Balancers** in front of **MySQL Read Replicas** (not pictured to reduce clutter)
 * Most services are read-heavy vs write-heavy

+* 额外添加和扩展 **内存缓存**，**MySQL 读取副本**也能够帮助释放在 **MySQL 写线程** 的负载。


建议:
除了添加和扩展 内存缓存，MySQL 读副本服务器也能够帮助缓解在 MySQL 写主服务器 的负载。

0x4ec7 · 2017-06-06T09:08:49Z

solutions/system_design/scaling_aws/README.md

 * In addition to adding and scaling a **Memory Cache**, **MySQL Read Replicas** can also help relieve load on the **MySQL Write Master**
 * Add logic to **Web Server** to separate out writes and reads
 * Add **Load Balancers** in front of **MySQL Read Replicas** (not pictured to reduce clutter)
 * Most services are read-heavy vs write-heavy

+* 额外添加和扩展 **内存缓存**，**MySQL 读取副本**也能够帮助释放在 **MySQL 写线程** 的负载。
+* 添加逻辑到 **网络服务器** 来区分读和写操作


Web Server 前后翻译不一致

0x4ec7 · 2017-06-06T09:10:13Z

solutions/system_design/scaling_aws/README.md

 * In addition to adding and scaling a **Memory Cache**, **MySQL Read Replicas** can also help relieve load on the **MySQL Write Master**
 * Add logic to **Web Server** to separate out writes and reads
 * Add **Load Balancers** in front of **MySQL Read Replicas** (not pictured to reduce clutter)
 * Most services are read-heavy vs write-heavy

+* 额外添加和扩展 **内存缓存**，**MySQL 读取副本**也能够帮助释放在 **MySQL 写线程** 的负载。
+* 添加逻辑到 **网络服务器** 来区分读和写操作
+* 在 **MySQL 读取副本** 之前添加 **负载均衡** （不是为了减少混乱）


建议: 在MySQL 读副本服务器 之上添加 负载均衡器

0x4ec7 · 2017-06-06T09:13:36Z

solutions/system_design/scaling_aws/README.md

+* 额外添加和扩展 **内存缓存**，**MySQL 读取副本**也能够帮助释放在 **MySQL 写线程** 的负载。
+* 添加逻辑到 **网络服务器** 来区分读和写操作
+* 在 **MySQL 读取副本** 之前添加 **负载均衡** （不是为了减少混乱）
+* 大多数服务都是读取负载大于写入负载


-heavy, -intense

这里没看懂...

0x4ec7 · 2017-06-06T09:18:53Z

solutions/system_design/scaling_aws/README.md

+    * **总水平** - 检查负载均衡器统计数据
+    * **日志分析** - CloudWatch, CloudTrail, Loggly, Splunk, Sumo
+    * **外部站点的性能** - Pingdom or New Relic
+    * **处理消息事件** - PagerDuty


处理通知和时间

0x4ec7 · 2017-06-06T09:20:37Z

solutions/system_design/scaling_aws/README.md

@@ -295,37 +567,80 @@ Our **Benchmarks/Load Tests** and **Profiling** show that our traffic spikes dur
        * Autoscaling can introduce complexity
        * It could take some time before a system appropriately scales up to meet increased demand, or to scale down when demand drops

+* 考虑一个托管服务，比如AWS **自动扩展**


考虑使用一个托管服务，比如AWS 自动扩展

0x4ec7 · 2017-06-06T09:21:44Z

solutions/system_design/scaling_aws/README.md

@@ -295,37 +567,80 @@ Our **Benchmarks/Load Tests** and **Profiling** show that our traffic spikes dur
        * Autoscaling can introduce complexity
        * It could take some time before a system appropriately scales up to meet increased demand, or to scale down when demand drops

+* 考虑一个托管服务，比如AWS **自动扩展**
+    * 为每个 **Web 服务器** 创建一个组，并为每个 **应用服务器** 类型创建一个组，将每个组放置在多个可用区域中
+    * 设置一个最小值和最大数目的实例


设置最小和最大实例数

0x4ec7 · 2017-06-06T09:24:13Z

solutions/system_design/scaling_aws/README.md

+    * 设置一个最小值和最大数目的实例
+    * 通过 CloudWatch 来扩展或收缩
+        * 可预测负载的简单时间度量
+        * 指标超过一段时间：


时间段内的指标???

0x4ec7 · 2017-06-06T09:25:19Z

solutions/system_design/scaling_aws/README.md

 ![Imgur](http://i.imgur.com/jj3A5N8.png)

 **Note:** **Autoscaling** groups not shown to reduce clutter

+**注释：** **自动伸缩** 组不需要显示以减少混乱


注释： 自动伸缩 组不显示以减少混乱

0x4ec7 · 2017-06-06T09:30:28Z

solutions/system_design/scaling_aws/README.md

 * If our **MySQL Database** starts to grow too large, we might considering only storing a limited time period of data in the database, while storing the rest in a data warehouse such as Redshift
    * A data warehouse such as Redshift can comfortably handle the constraint of 1 TB of new content per month
 * With 40,000 average read requests per second, read traffic for popular content can be addressed by scaling the **Memory Cache**, which is also useful for handling the unevenly distributed traffic and traffic spikes
    * The **SQL Read Replicas** might have trouble handling the cache misses, we'll probably need to employ additional SQL scaling patterns
 * 400 average writes per second (with presumably significantly higher peaks) might be tough for a single **SQL Write Master-Slave**, also pointing to a need for additional scaling techniques

+* 如果我们的 **MySQL 数据库** 开始变得过于庞大, 我们可能只考虑把数据在数据库中存储一段有限的时间, 同时在例如 Redshift 这样的数据仓库中存储其余的数据
+    * 像 Redshift 这样的数据仓库能够轻松处理每月 1TB 的新内容
+* 平均每秒 40,0000 次的读取请求, 可以通过扩展 **内存缓存** 来处理流行内容的读取流量，这对于处理不均匀分布的流量和流量峰值也很有用


平均每秒 40,000 次的读取请求
流行内容 > 热点内容

0x4ec7 · 2017-06-06T09:31:42Z

solutions/system_design/scaling_aws/README.md

+* 如果我们的 **MySQL 数据库** 开始变得过于庞大, 我们可能只考虑把数据在数据库中存储一段有限的时间, 同时在例如 Redshift 这样的数据仓库中存储其余的数据
+    * 像 Redshift 这样的数据仓库能够轻松处理每月 1TB 的新内容
+* 平均每秒 40,0000 次的读取请求, 可以通过扩展 **内存缓存** 来处理流行内容的读取流量，这对于处理不均匀分布的流量和流量峰值也很有用
+    * **SQL读取副本** 可能会遇到处理缓存泄露的问题, 我们可能需要使用额外的SQL扩展模式


cache misses > 缓存未命中

0x4ec7 · 2017-06-06T09:36:40Z

solutions/system_design/scaling_aws/README.md

 * [Federation](https://github.com/donnemartin/system-design-primer#federation)
 * [Sharding](https://github.com/donnemartin/system-design-primer#sharding)
 * [Denormalization](https://github.com/donnemartin/system-design-primer#denormalization)
 * [SQL Tuning](https://github.com/donnemartin/system-design-primer#sql-tuning)

+* [集合](https://github.com/donnemartin/system-design-primer#federation)
+* [分片](https://github.com/donnemartin/system-design-primer#sharding)
+* [反规范化](https://github.com/donnemartin/system-design-primer#denormalization)


0x4ec7 · 2017-06-06T09:42:27Z

solutions/system_design/scaling_aws/README.md

 We can further separate out our [**Application Servers**](https://github.com/donnemartin/system-design-primer#application-layer) to allow for independent scaling.  Batch processes or computations that do not need to be done in real-time can be done [**Asynchronously**](https://github.com/donnemartin/system-design-primer#asynchronism) with **Queues** and **Workers**:

+我们可以进一步分离我们的 [**应用服务器**](https://github.com/donnemartin/system-design-primer#application-layer) 允许独立扩展。不需要实时完成的批处理或计算可以通过队列和人员异步完成：


以允许独立扩展. 不需要实时完成的批处理任务和计算可以通过 Queues和Workers异步完成

queues, workers 可不翻译

0x4ec7 · 2017-06-06T09:45:55Z

solutions/system_design/scaling_aws/README.md

@@ -358,8 +700,16 @@ We can further separate out our [**Application Servers**](https://github.com/don
 * [Graph database](https://github.com/donnemartin/system-design-primer#graph-database)
 * [SQL vs NoSQL](https://github.com/donnemartin/system-design-primer#sql-or-nosql)

+* [健值存储](https://github.com/donnemartin/system-design-primer#key-value-store)


0x4ec7 · 2017-06-06T09:46:50Z

solutions/system_design/scaling_aws/README.md

+* 缓存到哪里
+    * [客户端缓存](https://github.com/donnemartin/system-design-primer#client-caching)
+    * [CDN 缓存](https://github.com/donnemartin/system-design-primer#cdn-caching)
+    * [网络服务缓存](https://github.com/donnemartin/system-design-primer#web-server-caching)


前后翻译不一致

0x4ec7 · 2017-06-06T09:49:35Z

solutions/system_design/scaling_aws/README.md

 * Discuss tradeoffs:
    * External communication with clients - [HTTP APIs following REST](https://github.com/donnemartin/system-design-primer#representational-state-transfer-rest)
    * Internal communications - [RPC](https://github.com/donnemartin/system-design-primer#remote-procedure-call-rpc)
 * [Service discovery](https://github.com/donnemartin/system-design-primer#service-discovery)

+* 关于折中方案的讨论:
+    * 客户端的外部通讯 - [HTTP APIs 后的空闲](https://github.com/donnemartin/system-design-primer#representational-state-transfer-rest)


遵循REST的HTTP APIs

竟然没看出来... 我一定是做梦在翻译得...

0x4ec7 · 2017-06-06T09:50:52Z

solutions/system_design/scaling_aws/README.md

 ### Latency numbers

+### 延迟数字


延迟数字指标

0x4ec7 · 2017-06-06T09:52:09Z

校对完毕

AceLeeWinnie

辛苦 @0x4ec7 校对啦，有些问题需要再对一下。另外不知道标题有没有更好的选择，现在看着就无聊😝。最后以后有校对建议能不能麻烦给个完整版，一个字的建议不造咋整呐。最后的最后，再次谢谢大佬！

AceLeeWinnie · 2017-06-07T13:45:21Z

solutions/system_design/scaling_aws/README.md

 Solving this problem takes an iterative approach of: 1) **Benchmark/Load Test**, 2) **Profile** for bottlenecks 3) address bottlenecks while evaluating alternatives and trade-offs, and 4) repeat, which is good pattern for evolving basic designs to scalable designs.

+解决这个问题是一个循序渐进的过程：1) **基准/负载 测试**， 2) 瓶颈 **概述**， 3) 当评估可选和折中方案时定位瓶颈，4) 重复，这是向可扩展的设计发展基础设计的好模式。


个人觉得后面的 which 从句修饰的是 an iterative approach 即这四个步骤组成的一系列过程。

AceLeeWinnie · 2017-06-07T14:04:05Z

solutions/system_design/scaling_aws/README.md

+* 额外添加和扩展 **内存缓存**，**MySQL 读取副本**也能够帮助释放在 **MySQL 写线程** 的负载。
+* 添加逻辑到 **网络服务器** 来区分读和写操作
+* 在 **MySQL 读取副本** 之前添加 **负载均衡** （不是为了减少混乱）
+* 大多数服务都是读取负载大于写入负载


这里没看懂...

AceLeeWinnie · 2017-06-07T14:09:09Z

solutions/system_design/scaling_aws/README.md

 * Discuss tradeoffs:
    * External communication with clients - [HTTP APIs following REST](https://github.com/donnemartin/system-design-primer#representational-state-transfer-rest)
    * Internal communications - [RPC](https://github.com/donnemartin/system-design-primer#remote-procedure-call-rpc)
 * [Service discovery](https://github.com/donnemartin/system-design-primer#service-discovery)

+* 关于折中方案的讨论:
+    * 客户端的外部通讯 - [HTTP APIs 后的空闲](https://github.com/donnemartin/system-design-primer#representational-state-transfer-rest)


竟然没看出来... 我一定是做梦在翻译得...

AceLeeWinnie · 2017-06-07T14:15:13Z

@sqrthree 这个校对是一个还是俩呢

linhe0x0 · 2017-06-07T14:19:27Z

@AceLeeWinnie 一个就可以了，如果有争议的地方可以在群里讨论下。

AceLeeWinnie · 2017-06-08T04:24:40Z

@sqrthree 经过群里各位大佬指点，决定维持原翻译，可以合啦

0x4ec7 · 2017-06-08T04:32:45Z

@AceLeeWinnie @sqrthree 👍

linhe0x0

英文原文要删除

AceLeeWinnie · 2017-06-09T04:51:48Z

@sqrthree 忘了... 已删

linhe0x0

文中还有一些用了斜体，麻烦也调整为粗体吧。

linhe0x0 · 2017-06-09T07:08:46Z

solutions/system_design/scaling_aws/README.md


-*Note: This document links directly to relevant areas found in the [system design topics](https://github.com/donnemartin/system-design-primer#index-of-system-design-topics) to avoid duplication.  Refer to the linked content for general talking points, tradeoffs, and alternatives.*
+*** 注释：为了避免重复，这篇文章的链接直接关联到 [系统设计主题](https://github.com/donnemartin/system-design-primer#index-of-system-design-topics) 的相关章节。为一讨论要点、折中方案和可选方案做参考。***


AceLeeWinnie · 2017-06-09T07:13:40Z

@sqrthree 现在呢

linhe0x0 · 2017-06-09T07:15:51Z

@AceLeeWinnie ** 那个还不行，有 view 视图你可以看下，另外斜体好像还没改完。

AceLeeWinnie · 2017-06-09T07:27:12Z

@sqrthree 改完了Ｏ(≧口≦)Ｏ，你看下

translate:初稿

9c45f66

AceLeeWinnie mentioned this pull request May 26, 2017

在 AWS 上设计支持百万级到千万级用户的系统 #18

Closed

AceLeeWinnie changed the title ~~translate:初稿~~ 在 AWS 上设计支持百万级到千万级用户的系统 May 26, 2017

linhe0x0 added the 等待校对 label May 26, 2017

linhe0x0 added 正在校对 and removed 等待校对 labels Jun 6, 2017

0x4ec7 reviewed Jun 6, 2017

View reviewed changes

solutions/system_design/scaling_aws/README.md Outdated

### Latency numbers

### 延迟数字

Copy link

0x4ec7 Jun 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

延迟数字指标

update: 根据一校意见修改

f29e2b3

AceLeeWinnie commented Jun 7, 2017

View reviewed changes

linhe0x0 suggested changes Jun 8, 2017

View reviewed changes

clean: 中文

b715264

linhe0x0 suggested changes Jun 9, 2017

View reviewed changes

update:斜变粗

1bcc35c

update: 修改斜体和链接

7064512

linhe0x0 approved these changes Jun 9, 2017

View reviewed changes

linhe0x0 merged commit 140f4ee into xitu:translation Jun 9, 2017

linhe0x0 removed the 正在校对 label Jun 9, 2017

AceLeeWinnie deleted the translate branch July 2, 2017 08:46

		@@ -1,33 +1,62 @@
		# Design a system that scales to millions of users on AWS
		# 在 AWS 上设计支持百万级到千万级用户的系统

		Solving this problem takes an iterative approach of: 1) Benchmark/Load Test, 2) Profile for bottlenecks 3) address bottlenecks while evaluating alternatives and trade-offs, and 4) repeat, which is good pattern for evolving basic designs to scalable designs.

		解决这个问题是一个循序渐进的过程：1) 基准/负载测试， 2) 瓶颈概述， 3) 当评估可选和折中方案时定位瓶颈，4) 重复，这是向可扩展的设计发展基础设计的好模式。

		Clarify with your interviewer if you should run back-of-the-envelope usage calculations.

		如果你应该做一个粗略的使用计算，需要和你的访谈人员明确这一点

		Add a DNS such as Route 53 to map the domain to the instance's public IP.

		添加 DNS 服务，比如 53 号路由，将域映射到实例的公共 IP 中。

		Our Benchmarks/Load Tests and Profiling show that we are read-heavy (100:1 with writes) and our database is suffering from poor performance from the high read requests.

		我们的性能/负载测试和性能测试显示我们读操作频繁（100:1 的读写比率），并且数据库在高读请求时表现很糟糕。

		We can further separate out our [Application Servers](https://github.com/donnemartin/system-design-primer#application-layer) to allow for independent scaling. Batch processes or computations that do not need to be done in real-time can be done [Asynchronously](https://github.com/donnemartin/system-design-primer#asynchronism) with Queues and Workers:

		我们可以进一步分离我们的 [应用服务器](https://github.com/donnemartin/system-design-primer#application-layer) 允许独立扩展。不需要实时完成的批处理或计算可以通过队列和人员异步完成：


		Note: This document links directly to relevant areas found in the [system design topics](https://github.com/donnemartin/system-design-primer#index-of-system-design-topics) to avoid duplication. Refer to the linked content for general talking points, tradeoffs, and alternatives.
		* 注释：为了避免重复，这篇文章的链接直接关联到 [系统设计主题](https://github.com/donnemartin/system-design-primer#index-of-system-design-topics) 的相关章节。为一讨论要点、折中方案和可选方案做参考。*

在 AWS 上设计支持百万级到千万级用户的系统 #31

在 AWS 上设计支持百万级到千万级用户的系统 #31

Conversation

AceLeeWinnie commented May 26, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0x4ec7 Jun 6, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0x4ec7 commented Jun 6, 2017

AceLeeWinnie left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AceLeeWinnie commented Jun 7, 2017

linhe0x0 commented Jun 7, 2017

AceLeeWinnie commented Jun 8, 2017

0x4ec7 commented Jun 8, 2017

linhe0x0 left a comment

Choose a reason for hiding this comment

AceLeeWinnie commented Jun 9, 2017

linhe0x0 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AceLeeWinnie commented Jun 9, 2017

linhe0x0 commented Jun 9, 2017

AceLeeWinnie commented Jun 9, 2017

0x4ec7 Jun 6, 2017 •

edited

Loading