Change translation details

README-zh-Hant.md

@@ -1047,7 +1047,7 @@ Graphs databases offer high performance for data models with complex relationshi
 - 关系型数据
 - 需要复杂的 joins
 - 事务
-- 清除缩放模式
+- 清晰的缩放模式
 - 更成熟的开发人员，社区，代码，工具等等
 - 通过索引查找非常快
 
@@ -1082,7 +1082,7 @@ Graphs databases offer high performance for data models with complex relationshi
   <i><a href=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Source: Scalable system design patterns</a></i>
 </p>
 
-缓存可以提高页面加载时间，并可以减少服务器和数据库的负载。在这个模式中，分发器会先去查看这个请求之前是否处理过，如果可以找到之前的结果那么就返回至客户端，否则，就将请求分发至处理池，以便将实际的处理结果存储至缓存中。
+缓存可以提高页面加载速度，并可以减少服务器和数据库的负载。在这个模型中，分发器先查看请求之前是否被响应过，如果有则将之前的结果直接返回，来省掉真正的处理。
 
 数据库分片均匀分布的读取是最好的。但是热门数据会让读取分布不均匀，这样就会造成瓶颈，如果在数据库前加个缓存，就会抹平不均匀的负载和突发流量对数据库的影响。
 
@@ -1092,7 +1092,7 @@ Graphs databases offer high performance for data models with complex relationshi
 
 ### CDN 缓存
 
-[CDNs](#content-delivery-network) 也是一种缓存。
+[CDNs](#content-delivery-network) 也被视为一种缓存。
 
 ### Web 服务器缓存
 
@@ -1100,11 +1100,11 @@ Graphs databases offer high performance for data models with complex relationshi
 
 ### 数据库缓存
 
-数据库的默认配置中通常包含缓存级别，针对一般用例进行了优化。调整配置中在不同情况下使用不同的模式可以进一步提高性能。
+数据库的默认配置中通常包含缓存级别，针对一般用例进行了优化。调整配置，在不同情况下使用不同的模式可以进一步提高性能。
 
 ### 应用缓存
 
-基于内存的缓存比如 Memcached 和 Redis 是应用程序和数据存储之间的一种键值存储。由于数据保存在 RAM 中，它比存储在磁盘上的典型数据库要快多了。RAM 比磁盘限制更多，所以[缓存无效算法](https://en.wikipedia.org/wiki/Cache_algorithms)比如 [least recently used (LRU)](https://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used) 可以将「热门数据」放在 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 有下列附加功能：
 
@@ -1122,7 +1122,7 @@ Redis 有下列附加功能：
 
 ### 数据库查询级别的缓存
 
-当你查询数据库的时候，将查询结果作为关键字同时将结果存储到缓存中。这种方法会遇到以下问题：
+当你查询数据库的时候，将查询语句的哈希值与查询结果存储到缓存中。这种方法会遇到以下问题：
 
 - 很难用复杂的查询删除已缓存结果。
 - 如果一条数据比如表中某条数据的一项被改变，则需要删除所有可能包含已更改项的缓存结果。
@@ -1177,7 +1177,7 @@ def get_user(self, user_id):
 
 ##### 缓存的缺点：
 
-- 每一次所需数据不在缓存中都需要经历三个过程，这会导致明显的延迟。
+- 请求的数据如果不在缓存中就需要经过三个步骤来获取数据，这会导致明显的延迟。
 - 如果数据库中的数据更新了会导致缓存中的数据过时。这个问题需要通过设置 TTL 强制更新缓存或者直写模式来缓解这种情况。
 - 当一个节点出现故障的时候，它将会被一个新的节点替代，这增加了延迟的时间。
 
@@ -1192,7 +1192,7 @@ def get_user(self, user_id):
 应用使用缓存作为主要的数据存储，将数据读写到缓存中，而缓存负责从数据库中读写数据。
 
 - 应用向缓存中添加/更新数据
-- 缓存将所需内容写入数据存储
+- 缓存同步地写入数据存储
 - 返回所需内容
 
 应用代码：
@@ -1209,7 +1209,7 @@ def set_user(user_id, values):
     cache.set(user_id, user)
 ```
 
-由于读写操作所以直写模式整体是一种很慢的操作，但是读取刚写入的数据很快。相比读取数据，用户通常比较能接受更新数据时速度较慢。缓存中的数据不会过时。
+由于存写操作所以直写模式整体是一种很慢的操作，但是读取刚写入的数据很快。相比读取数据，用户通常比较能接受更新数据时速度较慢。缓存中的数据不会过时。
 
 ##### 直写模式的缺点：
 
@@ -1254,7 +1254,7 @@ def set_user(user_id, values):
 
 - 需要保持缓存和真实数据源之间的一致性，比如数据库根据[缓存无效](https://en.wikipedia.org/wiki/Cache_algorithms)。
 - 需要改变应用程序比如增加 Redis 或者 memcached。
-- 无效缓存是个难题，什么时候更新缓存是额外复杂的问题。
+- 无效缓存是个难题，什么时候更新缓存是与之相关的复杂问题。
 
 ### 相关资源和延伸阅读
 
@@ -1274,7 +1274,7 @@ def set_user(user_id, values):
   <i><a href=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Source: Intro to architecting systems for scale</a></i>
 </p>
 
-异步工作流有助于减少操作的请求时间否则它们就会按顺序执行。它们可以通过提前进行一些耗时的工作来帮助减少请求时间，比如定期汇总数据。
+异步工作流有助于减少那些原本顺序执行的请求时间。它们可以通过提前进行一些耗时的工作来帮助减少请求时间，比如定期汇总数据。
 
 ### 消息队列
 
@@ -1283,7 +1283,7 @@ def set_user(user_id, values):
 - 应用程序将作业发布到队列，然后通知用户作业状态
 - 一个 worker 从队列中取出该作业，对其进行处理，然后显示该作业完成
 
-用户未被阻止，作业在后台处理。在此期间，客户端可能会进行一些处理使得看上去像是任务已经完成了。例如，如果要发送一条推文，推文可能会马上出现在你的时间线上，但是可能需要一些时间才能将你的推文推送到你的所有关注者那里去。
+不去阻塞用户操作，作业在后台处理。在此期间，客户端可能会进行一些处理使得看上去像是任务已经完成了。例如，如果要发送一条推文，推文可能会马上出现在你的时间线上，但是可能需要一些时间才能将你的推文推送到你的所有关注者那里去。
 
 **Redis** 是一个令人满意的简单的消息代理，但是消息有可能会丢失。
 
@@ -1303,7 +1303,7 @@ def set_user(user_id, values):
 
 ### 异步的缺点：
 
-- 廉价计算和实时工作流等用例可能更适用于同步操作，因为引入队列可能会增加延迟和复杂性。
+- 简单的计算和实时工作流等用例可能更适用于同步操作，因为引入队列可能会增加延迟和复杂性。
 
 ### 相关资源和延伸阅读
 
@@ -1324,14 +1324,14 @@ def set_user(user_id, values):
 
 HTTP 是一种在客户端和服务器之间编码和传输数据的方法。它是一个请求/响应协议：客户端和服务端针对相关内容和完成状态信息的请求和响应。HTTP 是独立的，允许请求和响应流经许多执行负载均衡，缓存，加密和压缩的中间路由器和服务器。
 
-一个基本的 HTTP 请求由一个动词（方法）和一个资源（endpoint）组成。 以下是常见的 HTTP 动词：
+一个基本的 HTTP 请求由一个动词（方法）和一个资源（端点）组成。 以下是常见的 HTTP 动词：
 
 | 动词     | 描述             | *幂等  | 安全性  | 可缓存            |
-| ------ | -------------- | ---- | ---- | ------------- |
+| ------ | -------------- | ---- | ---- | -------------- |
 | GET    | 读取资源           | Yes  | Yes  | Yes            |
-| POST   | 创建资源或触发处理数据的进程 | No   | No   | 可以，如果回应包含刷新信息 |
+| POST   | 创建资源或触发处理数据的进程 | No   | No   | Yes，如果回应包含刷新信息 |
 | PUT    | 创建或替换资源        | Yes  | No   | No             |
-| PATCH  | 部分更新资源         | No   | No   | 可以，如果回应包含刷新信息 |
+| PATCH  | 部分更新资源         | No   | No   | Yes，如果回应包含刷新信息 |
 | DELETE | 删除资源           | Yes  | No   | No             |
 
 *多次执行不会产生不同的结果。