修改校对者发现的问题
AidenLiudm
parent
f19dae323b
commit
69f57b9952
|
|
@ -409,20 +409,20 @@
|
|||
|
||||
### 来源及延伸阅读
|
||||
|
||||
* [A word on scalability](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
|
||||
* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
|
||||
* [简单谈谈可扩展性](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
|
||||
* [可扩展性，可用性，稳定性和](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
|
||||
|
||||
## 延迟与吞吐量
|
||||
|
||||
**延迟**是执行操作或运算结果所花费的时间。
|
||||
|
||||
**吞吐量**是单位时间内(执行)此类操作或运算的数量。
|
||||
**吞吐量**是单位时间内（执行）此类操作或运算的数量。
|
||||
|
||||
通常，你应该以**可接受级延迟**下**最大化吞吐量**为目标。
|
||||
|
||||
### 来源及延伸阅读
|
||||
|
||||
* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput)
|
||||
* [理解延迟与吞吐量](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput)
|
||||
|
||||
## 可用性与一致性
|
||||
|
||||
|
|
@ -436,42 +436,42 @@
|
|||
|
||||
在一个分布式计算系统中，只能同时满足下列的两点:
|
||||
|
||||
* **一致性** - 每次访问都能获得最新数据但可能会收到错误响应
|
||||
* **可用性** - 每次访问都能收到非错响应，但不保证获取到最新数据
|
||||
* **分区容错性** - 在任意分区网络故障的情况下系统仍能继续运行
|
||||
* **一致性** ─ 每次访问都能获得最新数据但可能会收到错误响应
|
||||
* **可用性** ─ 每次访问都能收到非错响应，但不保证获取到最新数据
|
||||
* **分区容错性** ─ 在任意分区网络故障的情况下系统仍能继续运行
|
||||
|
||||
*网络并不可靠，所以你应要支持分区容错性，并需要在软件可用性和一致性间做出取舍。*
|
||||
|
||||
#### CP - 一致性和分区容错性
|
||||
#### CP ─ 一致性和分区容错性
|
||||
|
||||
等待分区节点的响应可能会导致延时错误。如果你的业务需求需要原子读写，CP 是一个不错的选择。
|
||||
|
||||
#### AP - 可用性与分区容错性
|
||||
#### AP ─ 可用性与分区容错性
|
||||
|
||||
响应返回的最近版本数据可能并不是最新的。当分区解析完后，写入(操作)可能要花一些时间来传播。
|
||||
响应返回的最近版本数据可能并不是最新的。当分区解析完后，写入（操作）可能需要一些时间来传播。
|
||||
|
||||
如果业务需求允许[最终一致性](#eventual-consistency)，或当有外部故障时要求系统继续运行，AP 是一个不错的选择。
|
||||
|
||||
### 来源及延伸阅读
|
||||
|
||||
* [CAP theorem revisited](http://robertgreiner.com/2014/08/cap-theorem-revisited/)
|
||||
* [A plain english introduction to CAP theorem](http://ksat.me/a-plain-english-introduction-to-cap-theorem/)
|
||||
* [再看 CAP 理论](http://robertgreiner.com/2014/08/cap-theorem-revisited/)
|
||||
* [通俗易懂地介绍 CAP 理论](http://ksat.me/a-plain-english-introduction-to-cap-theorem/)
|
||||
* [CAP FAQ](https://github.com/henryr/cap-faq)
|
||||
|
||||
## 一致性模式
|
||||
|
||||
有同一份数据的多份副本，我们面临着怎样同步它们的选择，以便让客户端有一致的显示数据。回想 [CAP 定理](#cap-theorem)中的一致性定义 - 每次访问都能获得最新数据但可能会收到错误响应
|
||||
有同一份数据的多份副本，我们面临着怎样同步它们的选择，以便让客户端有一致的显示数据。回想 [CAP 定理](#cap-theorem)中的一致性定义 ─ 每次访问都能获得最新数据但可能会收到错误响应
|
||||
|
||||
|
||||
### 弱一致性
|
||||
|
||||
在写入之后，访问可能看到，也可能看不到(写入数据)。尽力优化之让其可见。
|
||||
在写入之后，访问可能看到，也可能看不到（写入数据）。尽力优化之让其能访问最新数据。
|
||||
|
||||
这种方式可以 memcached 等系统中看到。弱一致性在 VoIP，视频聊天和实时多人游戏等真实用例中表现不错。打个比方，如果你在通话中丢失信号几秒钟时间，当重新连接时你是听不到这几秒钟所说的话的。
|
||||
|
||||
### 最终一致性
|
||||
|
||||
在写入后，访问最终能看到写入数据(通常在数毫秒内)。数据被异步复制。
|
||||
在写入后，访问最终能看到写入数据（通常在数毫秒内）。数据被异步复制。
|
||||
|
||||
DNS 和 email 等系统使用的是此种方式。最终一致性在高可用性系统中效果不错。
|
||||
|
||||
|
|
@ -479,7 +479,7 @@ DNS 和 email 等系统使用的是此种方式。最终一致性在高可用性
|
|||
|
||||
在写入后，访问立即可见。数据被同步复制。
|
||||
|
||||
文件系统和关系型数据库(RDBMS)中使用的是此种方式。强一致性在需要记录的系统中运作良好。
|
||||
文件系统和关系型数据库（RDBMS）中使用的是此种方式。强一致性在需要记录的系统中运作良好。
|
||||
|
||||
### 来源及延伸阅读
|
||||
|
||||
|
|
@ -487,19 +487,19 @@ DNS 和 email 等系统使用的是此种方式。最终一致性在高可用性
|
|||
|
||||
## 可用性模式
|
||||
|
||||
有两种支持高可用性的模式: **故障切换(fail-over)**和**复制(replication)**。
|
||||
有两种支持高可用性的模式: **故障切换（fail-over）**和**复制（replication）**。
|
||||
|
||||
### 故障切换
|
||||
|
||||
#### 工作到备用切换(Active-passive)
|
||||
#### 工作到备用切换（Active-passive）
|
||||
|
||||
关于工作到备用的故障切换，工作服务器发送周期信号给等待中的备用服务器。如果周期信号中断，备用服务器切换成工作服务器的 IP 地址并恢复服务。
|
||||
关于工作到备用的故障切换流程是，工作服务器发送周期信号给待机中的备用服务器。如果周期信号中断，备用服务器切换成工作服务器的 IP 地址并恢复服务。
|
||||
|
||||
宕机时间取决于备用服务器处于‘热‘等待状态还是需要从‘冷‘等待状态进行启动。只有工作服务器处理流量。
|
||||
宕机时间取决于备用服务器处于“热”待机状态还是需要从“冷”待机状态进行启动。只有工作服务器处理流量。
|
||||
|
||||
工作到备用的故障切换也被称为主从切换。
|
||||
|
||||
#### 双工作切换(Active-active)
|
||||
#### 双工作切换（Active-active）
|
||||
|
||||
在双工作切换中，双方都在管控流量，在它们之间分散负载。
|
||||
|
||||
|
|
@ -514,12 +514,12 @@ DNS 和 email 等系统使用的是此种方式。最终一致性在高可用性
|
|||
|
||||
### 复制
|
||||
|
||||
#### 主-从复制和主-主复制
|
||||
#### 主─从复制和主─主复制
|
||||
|
||||
这个主题进一步探讨了[数据库](#database)部分:
|
||||
|
||||
* [主-从复制](#master-slave-replication)
|
||||
* [主-主复制](#master-master-replication)
|
||||
* [主─从复制](#master-slave-replication)
|
||||
* [主─主复制](#master-master-replication)
|
||||
|
||||
## 域名系统
|
||||
|
||||
|
|
@ -531,12 +531,12 @@ DNS 和 email 等系统使用的是此种方式。最终一致性在高可用性
|
|||
|
||||
域名系统是把 www.example.com 等域名转换成 IP 地址。
|
||||
|
||||
域名系统是分层次的，一些 DNS 服务器位于顶层。当查询(域名) IP 时，路由或 ISP 提供连接 DNS 服务器的信息。较低层 DNS 服务器缓存映射，它可能会因为 DNS 传播延时而失效。DNS 结果可以缓存在浏览器或操作系统中一段时间，时间长短取决于[存活时间 TTL](https://en.wikipedia.org/wiki/Time_to_live)。
|
||||
域名系统是分层次的，一些 DNS 服务器位于顶层。当查询（域名） IP 时，路由或 ISP 提供连接 DNS 服务器的信息。较底层的 DNS 服务器缓存映射，它可能会因为 DNS 传播延时而失效。DNS 结果可以缓存在浏览器或操作系统中一段时间，时间长短取决于[存活时间 TTL](https://en.wikipedia.org/wiki/Time_to_live)。
|
||||
|
||||
* **NS 记录(域名服务)** - 指定解析域名或子域名的 DNS 服务器。
|
||||
* **MX 记录(邮件交换)** - 指定接收信息的邮件服务器。
|
||||
* **A 记录(地址)** - 指定域名对应的 IP 地址记录。
|
||||
* **CNAME(规范)** - 一个域名映射到另一个域名或 `CNAME` 记录(example.com 指向 www.example.com)或映射到一个 `A` 记录。
|
||||
* **NS 记录（域名服务）** ─ 指定解析域名或子域名的 DNS 服务器。
|
||||
* **MX 记录（邮件交换）** ─ 指定接收信息的邮件服务器。
|
||||
* **A 记录（地址）** ─ 指定域名对应的 IP 地址记录。
|
||||
* **CNAME（规范）** ─ 一个域名映射到另一个域名或 `CNAME` 记录（example.com 指向 www.example.com）或映射到一个 `A` 记录。
|
||||
|
||||
[CloudFlare](https://www.cloudflare.com/dns/) 和 [Route 53](https://aws.amazon.com/route53/) 等平台提供管理 DNS 的功能。某些 DNS 服务通过集中方式来路由流量:
|
||||
|
||||
|
|
@ -549,15 +549,15 @@ DNS 和 email 等系统使用的是此种方式。最终一致性在高可用性
|
|||
|
||||
### 缺陷:DNS
|
||||
|
||||
* 虽说缓存可以来减轻 DNS 延迟，但连接 DNS 服务器还是带来了轻微的延迟。
|
||||
* 虽说缓存可以减轻 DNS 延迟，但连接 DNS 服务器还是带来了轻微的延迟。
|
||||
* 虽然它们通常由[政府，网络服务提供商和大公司](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729)管理，但 DNS 服务管理仍可能是复杂的。
|
||||
* DNS 服务最近遭受 [DDoS 攻击](http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/)，防止不知道 Twtter IP 地址的用户访问 Twiiter。
|
||||
* DNS 服务最近遭受 [DDoS 攻击](http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/)，阻止不知道 Twtter IP 地址的用户访问 Twiiter。
|
||||
|
||||
### 来源及延伸阅读
|
||||
|
||||
* [DNS architecture](https://technet.microsoft.com/en-us/library/dd197427(v=ws.10).aspx)
|
||||
* [DNS 架构](https://technet.microsoft.com/en-us/library/dd197427(v=ws.10).aspx)
|
||||
* [Wikipedia](https://en.wikipedia.org/wiki/Domain_Name_System)
|
||||
* [DNS articles](https://support.dnsimple.com/categories/dns/)
|
||||
* [关于 DNS 的文章](https://support.dnsimple.com/categories/dns/)
|
||||
|
||||
## 内容分发网络
|
||||
|
||||
|
|
@ -574,22 +574,22 @@ DNS 和 email 等系统使用的是此种方式。最终一致性在高可用性
|
|||
* 从靠近用户的数据中心提供资源
|
||||
* 通过 CDN 你的服务器不必真的处理请求
|
||||
|
||||
### CDN 推送(push)
|
||||
### CDN 推送（push）
|
||||
|
||||
当你服务器上内容发生变动时，推送给 CDN 接受新的内容。你负责提供内容，直接推送给 CDN 并重写 URL 地址以指向 CDN 地址。你可以配置内容到期时间及何时更新。内容只有在更改或新增是才推送，最小化流量，但最大化存储空间。
|
||||
当你服务器上内容发生变动时，推送 CDN 接受新内容。你负责提供内容，直接推送给 CDN 并重写 URL 地址以指向 CDN 地址。你可以配置内容到期时间及何时更新。内容只有在更改或新增是才推送，最小化流量，但最大化存储空间。
|
||||
|
||||
|
||||
|
||||
|
||||
### CDN 拉取(pull)
|
||||
### CDN 拉取（pull）
|
||||
|
||||
CDN 拉取是当第一个用户请求该资源时，从服务器上拉取资源。你将内容留在自己的服务器上并重写 URL 指向 CDN 地址。这样请求会更慢，直到内容被缓存在 CDN 上，。
|
||||
CDN 拉取是当第一个用户请求该资源时，从服务器上拉取资源。你将内容留在自己的服务器上并重写 URL 指向 CDN 地址。这样请求会更慢，直到内容被缓存在 CDN 上。
|
||||
|
||||
[存活时间(TTL)](https://en.wikipedia.org/wiki/Time_to_live)决定缓存多久时间。CDN 拉取方式最小化 CDN 上的储存空间，但如果过期文件并在实际更改之前被拉取，则会导致冗余的流量。
|
||||
[存活时间（TTL）](https://en.wikipedia.org/wiki/Time_to_live)决定缓存多久时间。CDN 拉取方式最小化 CDN 上的储存空间，但如果过期文件并在实际更改之前被拉取，则会导致冗余的流量。
|
||||
|
||||
高流量站点使用 CDN 拉取效果不错，因为只有最近请求的内容保存在 CDN 中，流量才能更平衡地分散。
|
||||
|
||||
### 缺陷:CDN
|
||||
### 缺陷：CDN
|
||||
|
||||
* CDN 成本可能因流量而异，可能在权衡之后你将不会使用 CDN。
|
||||
* 如果在 TTL 过期之前更新内容，CDN 缓存内容可能会过时。
|
||||
|
|
@ -597,8 +597,8 @@ CDN 拉取是当第一个用户请求该资源时，从服务器上拉取资源
|
|||
|
||||
### 来源及延伸阅读
|
||||
|
||||
* [Globally distributed content delivery](http://repository.cmu.edu/cgi/viewcontent.cgi?article=2112&context=compsci)
|
||||
* [The differences between push and pull CDNs](http://www.travelblogadvice.com/technical/the-differences-between-push-and-pull-cdns/)
|
||||
* [全球性内容分发网络](http://repository.cmu.edu/cgi/viewcontent.cgi?article=2112&context=compsci)
|
||||
* [CDN 拉取和 CDN 推送的区别](http://www.travelblogadvice.com/technical/the-differences-between-push-and-pull-cdns/)
|
||||
* [Wikipedia](https://en.wikipedia.org/wiki/Content_delivery_network)
|
||||
|
||||
## 负载均衡器
|
||||
|
|
@ -615,46 +615,46 @@ CDN 拉取是当第一个用户请求该资源时，从服务器上拉取资源
|
|||
* 防止资源过载
|
||||
* 帮助消除单一的故障点
|
||||
|
||||
负载均衡器可以通过硬件(昂贵)或 HAProxy 等软件来实现。
|
||||
增加的益处包括:
|
||||
负载均衡器可以通过硬件（昂贵）或 HAProxy 等软件来实现。
|
||||
增加的好处包括:
|
||||
|
||||
* **SSL 终结** - 解密传入的请求并加密服务器响应，这样的话后端服务器就不必再执行这些潜在高消耗运算了。
|
||||
* **SSL 终结** ─ 解密传入的请求并加密服务器响应，这样的话后端服务器就不必再执行这些潜在高消耗运算了。
|
||||
* 不需要再每台服务器上安装 [X.509 证书](https://en.wikipedia.org/wiki/X.509)。
|
||||
* **Session 留存** - 如果 Web 应用程序不追踪会话，发出 cookie 并将特定客户端的请求路由到同一实例。
|
||||
* **Session 留存** ─ 如果 Web 应用程序不追踪会话，发出 cookie 并将特定客户端的请求路由到同一实例。
|
||||
|
||||
通常会设置采用[工作-备用](#active-passive) 或 [双工作](#active-active) 模式的多个负载均衡器，以免发生故障。
|
||||
通常会设置采用[工作─备用](#active-passive) 或 [双工作](#active-active) 模式的多个负载均衡器，以免发生故障。
|
||||
|
||||
负载均衡器能基于多种方式来路由流量:
|
||||
|
||||
* 随机
|
||||
* 最少负载
|
||||
* Session/cookies
|
||||
* Session/cookie
|
||||
* [轮询调度或加权轮询调度算法](http://g33kinfo.com/info/archives/2657)
|
||||
* [四层负载均衡](#layer-4-load-balancing)
|
||||
* [七层负载均衡](#layer-7-load-balancing)
|
||||
|
||||
### 四层负载均衡
|
||||
|
||||
四层负载均衡根据监看[传输层](#communication)的信息来决定如何分发请求。通常，这会涉及来源，目标 IP 地址和请求头中的端口，但不包括数据包(报文)内容。四层负载均衡执行[网络地址转换(NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/)来向上游服务器转发网络数据包。
|
||||
四层负载均衡根据监看[传输层](#communication)的信息来决定如何分发请求。通常，这会涉及来源，目标 IP 地址和请求头中的端口，但不包括数据包（报文）内容。四层负载均衡执行[网络地址转换（NAT）](https://www.nginx.com/resources/glossary/layer-4-load-balancing/)来向上游服务器转发网络数据包。
|
||||
|
||||
### 七层负载均衡器
|
||||
|
||||
七层负载均衡器根据监看[应用层](#communication)来决定怎样分发请求。这会涉及请求头的内容，消息和 cookie。七层负载均衡器终结网络流量，读取消息，做出负载均衡判定，然后传送给特定服务器。比如，一个七层负载均衡器能直接将视频流量连接到托管视频的服务器，同时将更敏感的用户账单流量引导到安全性更强的服务器。
|
||||
七层负载均衡器根据监控[应用层](#communication)来决定怎样分发请求。这会涉及请求头的内容，消息和 cookie。七层负载均衡器终结网络流量，读取消息，做出负载均衡判定，然后传送给特定服务器。比如，一个七层负载均衡器能直接将视频流量连接到托管视频的服务器，同时将更敏感的用户账单流量引导到安全性更强的服务器。
|
||||
|
||||
以损失灵活性为代价，四层负载均衡比七层负载均衡只需更少时间和计算资源，虽然这在现代商用硬件上的性能影响甚微。
|
||||
以损失灵活性为代价，四层负载均衡比七层负载均衡花费更少时间和计算资源，虽然这对现代商用硬件的性能影响甚微。
|
||||
|
||||
### 水平扩展
|
||||
|
||||
负载均衡器还能帮助水平扩展，提高性能和可用性。使用商业硬件的性价比更高，并且比在单台硬件上**纵向扩展**更贵的硬件具有更高的可用性。招聘商业硬件的人才比特定企业系统的人才更容易。
|
||||
负载均衡器还能帮助水平扩展，提高性能和可用性。使用商业硬件的性价比更高，并且比在单台硬件上**垂直扩展**更贵的硬件具有更高的可用性。相比招聘特定企业系统人才，招聘商业硬件方面的人才更加容易。
|
||||
|
||||
#### 缺陷:水平扩展
|
||||
#### 缺陷：水平扩展
|
||||
|
||||
* 水平扩展引入了复杂度并设计服务器复制
|
||||
* 服务器应该是无状态的:它们也不该包含任何与用户关联的数据，像 session 或资料图片。
|
||||
* session 可以集中存储在数据库或持久化[缓存](#cache)(Redis, Memcached)的数据存储区中。
|
||||
* 水平扩展引入了复杂度并涉及服务器复制
|
||||
* 服务器应该是无状态的:它们也不该包含像 session 或资料图片等与用户关联的数据。
|
||||
* session 可以集中存储在数据库或持久化[缓存](#cache)（Redis, Memcached）的数据存储区中。
|
||||
* 缓存和数据库等下游服务器需要随着上游服务器进行扩展，以处理更多的并发连接。
|
||||
|
||||
### 缺陷:负载均衡器
|
||||
### 缺陷：负载均衡器
|
||||
|
||||
* 如果没有足够的资源配置或配置错误，负载均衡器会变成一个性能瓶颈。
|
||||
* 引入负载均衡器以帮助消除单点故障但导致了额外的复杂性。
|
||||
|
|
@ -662,13 +662,13 @@ CDN 拉取是当第一个用户请求该资源时，从服务器上拉取资源
|
|||
|
||||
### 来源及延伸阅读
|
||||
|
||||
* [NGINX architecture](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)
|
||||
* [HAProxy architecture guide](http://www.haproxy.org/download/1.2/doc/architecture.txt)
|
||||
* [Scalability](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
|
||||
* [NGINX 架构](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)
|
||||
* [HAProxy 架构指南](http://www.haproxy.org/download/1.2/doc/architecture.txt)
|
||||
* [可扩展性](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
|
||||
* [Wikipedia](https://en.wikipedia.org/wiki/Load_balancing_(computing))
|
||||
* [Layer 4 load balancing](https://www.nginx.com/resources/glossary/layer-4-load-balancing/)
|
||||
* [Layer 7 load balancing](https://www.nginx.com/resources/glossary/layer-7-load-balancing/)
|
||||
* [ELB listener config](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html)
|
||||
* [四层负载平衡](https://www.nginx.com/resources/glossary/layer-4-load-balancing/)
|
||||
* [七层负载平衡](https://www.nginx.com/resources/glossary/layer-7-load-balancing/)
|
||||
* [ELB 监听器配置](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html)
|
||||
|
||||
## Reverse proxy (web server)
|
||||
|
||||
|
|
@ -1261,7 +1261,7 @@ def set_user(user_id, values):
|
|||
- [从缓存到内存数据](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast)
|
||||
- [可扩展系统设计模式](http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html)
|
||||
- [大型系统架构介绍](http://lethain.com/introduction-to-architecting-systems-for-scale/)
|
||||
- [可扩展性，可用性，稳定性，模式](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
|
||||
- [可扩展性，可用性，稳定性和模式](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
|
||||
- [可扩展性](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
|
||||
- [AWS ElastiCache 策略](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Strategies.html)
|
||||
- [维基百科](https://en.wikipedia.org/wiki/Cache_(computing))
|
||||
|
|
|
|||
Loading…
Reference in New Issue