Merge pull request #384 from PanggNOTlovebean/main

docs: 优化中文文档的措辞和表达

content/zh/ch6.md

@@ -229,7 +229,7 @@ breadcrumbs: false
 
 许多应用程序让用户提交一些数据，然后查看他们提交的内容。这可能是客户数据库中的记录，或讨论线程上的评论，或其他类似的东西。提交新数据时，必须将其发送到主节点，但当用户查看数据时，可以从从节点读取。如果数据经常被查看但只是偶尔被写入，这尤其合适。
 
-使用异步复制，存在一个问题，如 [图 6-3](/ch6#fig_replication_read_your_writes) 所示：如果用户在写入后不久查看数据，新数据可能尚未到达副本。对用户来说，看起来他们提交的数据丢失了，所以他们会理解地不高兴。
+使用异步复制，存在一个问题，如 [图 6-3](/ch6#fig_replication_read_your_writes) 所示：如果用户在写入后不久查看数据，新数据可能尚未到达副本。对用户来说，看起来他们提交的数据丢失了，所以他们自然会不高兴。
 
 {{< figure src="/fig/ddia_0603.png" id="fig_replication_read_your_writes" caption="图 6-3. 用户进行写入，然后从陈旧副本读取。为了防止这种异常，我们需要写后读一致性。" class="w-full my-4" >}}
 
@@ -303,7 +303,7 @@ Poons 先生
 
 ### 复制延迟的解决方案 {#id131}
 
-在使用最终一致系统时，值得思考如果复制延迟增加到几分钟甚至几小时，应用程序的行为如何。如果答案是"没问题"，那很好。然而，如果结果对用户来说是糟糕的体验，那么设计系统以提供更强的保证（如写后读）很重要。假装复制是同步的，而实际上它是异步的，是以后出现问题的秘诀。
+在使用最终一致系统时，值得思考如果复制延迟增加到几分钟甚至几小时，应用程序的行为如何。如果答案是"没问题"，那很好。然而，如果结果对用户来说是糟糕的体验，那么设计系统以提供更强的保证（如写后读）很重要。明明是异步复制，却假装它是同步的，这为日后出问题埋下了隐患。
 
 如前所述，应用程序可以提供比底层数据库更强的保证——例如，通过在主节点或同步更新的从节点上执行某些类型的读取。然而，在应用程序代码中处理这些问题很复杂且容易出错。