Merge ec6ad34466 into a07e261677
This commit is contained in:
Alpha
GitHub
commit
3f3b5a2e37
|
|
@ -559,7 +559,7 @@ DNS 和 email 等系统使用的是此种方式。最终一致性在高可用性
|
|||
* 基于延迟路由
|
||||
* 基于地理位置路由
|
||||
|
||||
### 缺陷:DNS
|
||||
### 缺陷：DNS
|
||||
|
||||
* 虽说缓存可以减轻 DNS 延迟，但连接 DNS 服务器还是带来了轻微的延迟。
|
||||
* 虽然它们通常由[政府，网络服务提供商和大公司](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729)管理，但 DNS 服务管理仍可能是复杂的。
|
||||
|
|
@ -588,7 +588,9 @@ DNS 和 email 等系统使用的是此种方式。最终一致性在高可用性
|
|||
|
||||
### CDN 推送（push）
|
||||
|
||||
当你服务器上内容发生变动时，推送 CDN 接受新内容。直接推送给 CDN 并重写 URL 地址以指向你的内容的 CDN 地址。你可以配置内容到期时间及何时更新。内容只有在更改或新增是才推送，流量最小化，但储存最大化。
|
||||
当你服务器上内容发生变动时，推送 CDN 接受新内容。直接推送给 CDN 并重写 URL 地址以指向你的内容的 CDN 地址。你可以配置内容到期时间及何时更新。内容只有在更改或新增时才推送，流量最小化，但储存最大化。
|
||||
|
||||
低流量站点或者内容不经常更新的站点使用 CDN 推送效果不错。内容被放置在 CDN 上一次，而不是定期重新拉取。
|
||||
|
||||
### CDN 拉取（pull）
|
||||
|
||||
|
|
@ -620,12 +622,12 @@ CDN 拉取是当第一个用户请求该资源时，从服务器上拉取资源
|
|||
|
||||
负载均衡器将传入的请求分发到应用服务器和数据库等计算资源。无论哪种情况，负载均衡器将从计算资源来的响应返回给恰当的客户端。负载均衡器的效用在于:
|
||||
|
||||
* 防止请求进入不好的服务器
|
||||
* 防止请求进入不健康的服务器
|
||||
* 防止资源过载
|
||||
* 帮助消除单一的故障点
|
||||
* 帮助消除单点故障
|
||||
|
||||
负载均衡器可以通过硬件（昂贵）或 HAProxy 等软件来实现。
|
||||
增加的好处包括:
|
||||
负载均衡器可以通过（昂贵的）硬件或 HAProxy 等软件来实现。
|
||||
额外的好处包括:
|
||||
|
||||
* **SSL 终结** ─ 解密传入的请求并加密服务器响应，这样的话后端服务器就不必再执行这些潜在高消耗运算了。
|
||||
* 不需要再每台服务器上安装 [X.509 证书](https://en.wikipedia.org/wiki/X.509)。
|
||||
|
|
@ -659,8 +661,8 @@ CDN 拉取是当第一个用户请求该资源时，从服务器上拉取资源
|
|||
#### 缺陷：水平扩展
|
||||
|
||||
* 水平扩展引入了复杂度并涉及服务器复制
|
||||
* 服务器应该是无状态的:它们也不该包含像 session 或资料图片等与用户关联的数据。
|
||||
* session 可以集中存储在数据库或持久化[缓存](#缓存)（Redis、Memcached）的数据存储区中。
|
||||
* 服务器应该是无状态的：它们也不该包含像 session 或资料图片等与用户关联的数据。
|
||||
* Session 可以集中存储在数据库或持久化[缓存](#缓存)（Redis、Memcached）的数据存储区中。
|
||||
* 缓存和数据库等下游服务器需要随着上游服务器进行扩展，以处理更多的并发连接。
|
||||
|
||||
### 缺陷：负载均衡器
|
||||
|
|
@ -1119,7 +1121,7 @@ Google 发布了第一个列型存储数据库 [Bigtable](http://www.read.seas.h
|
|||
|
||||
### 应用缓存
|
||||
|
||||
基于内存的缓存比如 Memcached 和 Redis 是应用程序和数据存储之间的一种键值存储。由于数据保存在 RAM 中，它比存储在磁盘上的典型数据库要快多了。RAM 比磁盘限制更多，所以例如 [least recently used (LRU)](https://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used) 的[缓存无效算法](https://en.wikipedia.org/wiki/Cache_algorithms)可以将「热门数据」放在 RAM 中，而对一些比较「冷门」的数据不做处理。
|
||||
基于内存的缓存比如 Memcached 和 Redis 是应用程序和数据存储之间的一种键值存储。由于数据保存在 RAM 中，它比存储在磁盘上的典型数据库要快多了。RAM 比磁盘限制更多，所以例如 [least recently used (LRU)](https://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used) 的[缓存失效算法](https://en.wikipedia.org/wiki/Cache_algorithms)可以将「热门数据」放在 RAM 中，而对一些比较「冷门」的数据不做处理。
|
||||
|
||||
Redis 有下列附加功能：
|
||||
|
||||
|
|
@ -1267,9 +1269,9 @@ def set_user(user_id, values):
|
|||
|
||||
### 缓存的缺点：
|
||||
|
||||
- 需要保持缓存和真实数据源之间的一致性，比如数据库根据[缓存无效](https://en.wikipedia.org/wiki/Cache_algorithms)。
|
||||
- 需要保持缓存和真实数据源之间的一致性，比如数据库根据[缓存失效](https://en.wikipedia.org/wiki/Cache_algorithms)。
|
||||
- 需要改变应用程序比如增加 Redis 或者 memcached。
|
||||
- 无效缓存是个难题，什么时候更新缓存是与之相关的复杂问题。
|
||||
- 缓存失效是个难题，什么时候更新缓存是与之相关的复杂问题。
|
||||
|
||||
### 相关资源和延伸阅读
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue