Fix some typos

baidu · Mar 23, 2018 · 72efd3a · 72efd3a
1 parent a15f5a4
commit 72efd3a
Show file tree

Hide file tree

Showing 4 changed files with 8 additions and 8 deletions.
diff --git a/docs/cn/benchmark.md b/docs/cn/benchmark.md
@@ -9,10 +9,9 @@
 
 这些设计虽然能跑出不错的benchmark数据，但是完全偏离了实际的应用场景。以batch为例， batch的问题在于本质上并没有去指导如何提升系统的QPS。在性能测试中，并发度通常很高，会有源源不断的请求进来，所以每个请求并不需要等待多长时间就能满足batch size的条件, 然而在真实场景中，并发度并没有这么高，这样会导致每个请求都必须要『等待』一个设定的值， latency无法达到最优解。而这时候工程师往往会沉浸在优化超时、batch size等调参工作，从而忽略了分析系统瓶颈这类真正有意义的事情。另外硬件性能的逐渐提升，网络和磁盘本身的延迟越来越短， 这套机制无法兼顾低负载下的延迟和高负载的吞吐。
 
-在braft中，我们主要采用了一下几点方法来提高的性能:
-
-* 数据流是全并发的， leader写本地磁盘和向follower复制数据是完全同步的。
+在braft中，我们主要采用了以下几点方法来提高的性能:
 
+- 数据流是全并发的， leader写本地磁盘和向follower复制数据是完全并发的。
 - 尽可能的提高局部性，充分发挥不同层面的cache的作用
 - 尽可能隔离不同硬件的访问，通过流水线的形式提高吞吐
 - 尽可能的降低锁临界区大小， 关键路径上采用lock-free/wait-free算法. 

diff --git a/docs/cn/cli.md b/docs/cn/cli.md
@@ -37,6 +37,7 @@ Command:
   add_peer --group=$group_id --peer=$adding_peer --conf=$current_conf
   remove_peer --group=$group_id --peer=$removing_peer --conf=$current_conf
   change_peers --group=$group_id --conf=$current_conf --new_peers=$new_peers
-  reset_peer --group=$group_id --peer==$target_peer --conf=$target_conf
+  reset_peer --group=$group_id --peer==$target_peer --new_peers=$new_peers
   snapshot --group=$group_id --peer=$target_peer
+  transfer_leader --group=$group_id --peer=$target_leader --conf=$current_conf
 ```
diff --git a/docs/cn/raft_protocol.md b/docs/cn/raft_protocol.md
@@ -158,8 +158,8 @@ RAFT采用协同一致性的方式来解决节点的变更，先提交一个包
 
 1. 首先对新节点进行CaughtUp追数据
 2. 全部新节点完成CaughtUp之后，向新老集合发送Cold+new命令
-3. 如果新老节点集合多数都应答了Cold+new，就向新老节点集合发送Cnew命令
-4. 如果新老节点集合都应答了Cnew，完成节点切换
+3. 如果新节点集合多数和老节点集合多数都应答了Cold+new，就向新老节点集合发送Cnew命令
+4. 如果新节点集合多数应答了Cnew，完成节点切换
 
 配置改变示意图如下：
 
@@ -290,4 +290,4 @@ RAFT中Client的读写都通过Leader完成，一旦Leader出现IO慢节点，
 
 - 本地IO Batch写入
 
-传统的元信息复制需求，需要对每一条更新都进行fsync，保证刷到磁盘上。如果针对每一条Log Entry都进行fsync将会比较费，可以采用类似网络Batch发送的的方式进行本地磁盘IO Batch写入，来提高吞吐。
+传统的元信息复制需求，需要对每一条更新都进行fsync，保证刷到磁盘上。如果针对每一条Log Entry都进行fsync将会比较费，可以采用类似网络Batch发送的的方式进行本地磁盘IO Batch写入，来提高吞吐。
diff --git a/docs/cn/server.md b/docs/cn/server.md
@@ -445,7 +445,7 @@ void change_peers(const Configuration& new_peers, Closure* done);
 
 节点变更分为几个阶段:
 
-- **追赶阶段: ** 如果新的节点配置相对于当前有新增的一个或者多个节点，leader对应的Replicator, 向把最新的snapshot再这个这些中安装，然后开始同步之后的日志。等到所有的新节点数据都追的差不多，就开始进入一下一阶段。
+- **追赶阶段**: 如果新的节点配置相对于当前有新增的一个或者多个节点，leader对应的Replicator, 向把最新的snapshot再这个这些中安装，然后开始同步之后的日志。等到所有的新节点数据都追的差不多，就开始进入一下一阶段。
   - 追赶是为了避免新加入的节点数据和集群相差过远而影响集群的可用性. 并不会影响数据安全性.
   - 在追赶阶段完成前， **只有**leader知道这些新节点的存在，这个节点都不会被记入到集群的决策集合中，包括选主和日志提交的判定。追赶阶段任意节点失败，则这次节点变更就会被标记为失败。
 - **联合选举阶段**: leader会将旧节点配置和新节点配置写入Log, 在这个阶段之后直道下一个阶段之前，所有的选举和日志同步都需要在**新老节点之间达到多数**。 这里和标准算法有一点不同， 考虑到和之前实现的兼容性，如果这次只变更了一个节点,  则直接进入下一阶段。