fix style mistake and make small optimization (#574)

zhengyangyong · medcl · commit 17edb66fc56d · 2019-02-19T10:08:30.000+08:00
diff --git a/070_Index_Mgmt/50_Reindexing.asciidoc b/070_Index_Mgmt/50_Reindexing.asciidoc
@@ -38,7 +38,7 @@ GET /old_index/_search?scroll=1m
 --------------------------------------------------
 
 
-如果旧的索引持续会有变化，你希望新的索引中也包括那些新加的文档。那就可以对新加的文档做重新索引，
+如果旧的索引会持续变化，你希望新的索引中也包括那些新加的文档。那就可以对新加的文档做重新索引，
 但还是要用日期类字段过滤来匹配那些新加的文档。
 
 ****
diff --git a/070_Index_Mgmt/55_Aliases.asciidoc b/070_Index_Mgmt/55_Aliases.asciidoc
@@ -3,7 +3,7 @@
 
 在前面提到的，重建索引的问题是必须更新应用中的索引名称。 ((("index aliases")))  索引别名就是用来解决这个问题的！
 
-索引 _别名_ 就像一个快捷方式或软连接，可以指向一个或多个索引，也可以给任何一个需要索引名的API来使用。别名 ((("aliases, index"))) 带给我们极大的灵活性，允许我们做下面这些：
+索引 _别名_ 就像一个快捷方式或软连接，可以指向一个或多个索引，也可以给任何一个需要索引名的API来使用。_别名_ ((("aliases, index"))) 带给我们极大的灵活性，允许我们做下面这些：
 
  * 在运行的集群中可以无缝的从一个索引切换到另一个索引
  * 给多个索引分组 (例如， `last_three_months`)
diff --git a/075_Inside_a_shard/10_Intro.asciidoc b/075_Inside_a_shard/10_Intro.asciidoc
@@ -1,7 +1,7 @@
 [[inside-a-shard]]
 == 分片内部原理
 
-在 <<distributed-cluster>>, 我们介绍了 _分片_, 并将它((("shards"))) 描述成最小的 _工作单元_。但是究竟什么 _是_ 一个分片，它是如何工作的？
+在 <<distributed-cluster>>, 我们介绍了 _分片_, 并将它((("shards"))) 描述成最小的 _工作单元_ 。但是究竟什么 _是_ 一个分片，它是如何工作的？
 在这个章节，我们回答以下问题:
 
 * 为什么搜索是 _近_ 实时的？
diff --git a/075_Inside_a_shard/50_Persistent_changes.asciidoc b/075_Inside_a_shard/50_Persistent_changes.asciidoc
@@ -76,7 +76,7 @@ POST /_flush?wait_for_ongoing <2>
 <1> 刷新（flush） `blogs` 索引。
 <2> 刷新（flush）所有的索引并且并且等待所有刷新在返回前完成。
 
-你很少需要自己手动执行一个的 `flush` 操作；通常情况下，自动刷新就足够了。
+你很少需要自己手动执行 `flush` 操作；通常情况下，自动刷新就足够了。
 
 这就是说，在重启节点或关闭索引之前执行 <<flush-api,flush>> 有益于你的索引。当 Elasticsearch 尝试恢复或重新打开一个索引，
 它需要重放 translog 中所有的操作，所以如果日志越短，恢复越快。
diff --git a/075_Inside_a_shard/60_Segment_merging.asciidoc b/075_Inside_a_shard/60_Segment_merging.asciidoc
@@ -42,7 +42,7 @@ TIP: 查看 <<segments-and-merging>> 来为你的实例获取关于合并调整
 `optimize` API大可看做是 _强制合并_ API((("merging segments", "optimize API and")))((("optimize API")))((("segments", "merging", "optimize API")))。它会将一个分片强制合并到 `max_num_segments` 参数指定大小的段数目。
 这样做的意图是减少段的数量（通常减少到一个），来提升搜索性能。
 
-WARNING: `optimize` API _不应该_ 被用在一个动态索引————一个正在被活跃更新的索引。后台合并流程已经可以很好地完成工作。
+WARNING: `optimize` API _不应该_ 被用在一个活跃的索引————一个正积极更新的索引。后台合并流程已经可以很好地完成工作。
 optimizing 会阻碍这个进程。不要干扰它！
 
 在特定情况下，使用 `optimize` API 颇有益处。例如在日志这种用例下，每天、每周、每月的日志被存储在一个索引中。
@@ -59,6 +59,6 @@ POST /logstash-2014-10/_optimize?max_num_segments=1 <1>
 
 [WARNING]
 ====
-请注意，使用 `optimize` API 触发段合并的操作一点也不会受到任何资源上的限制。这可能会消耗掉你节点上全部的I/O资源, 使其没有余裕来处理搜索请求，从而有可能使集群失去响应。
+请注意，使用 `optimize` API 触发段合并的操作不会受到任何资源上的限制。这可能会消耗掉你节点上全部的I/O资源, 使其没有余裕来处理搜索请求，从而有可能使集群失去响应。
 如果你想要对索引执行 `optimize`，你需要先使用分片分配（查看 <<migrate-indices>>）把索引移到一个安全的节点，再执行。
 ====
