diff --git a/consensus/raft-log-replication.md b/consensus/raft-log-replication.md
index 49ee0d4e..35aee0f4 100644
--- a/consensus/raft-log-replication.md
+++ b/consensus/raft-log-replication.md
@@ -44,14 +44,14 @@ Raft 算法中，领导者通过广播消息（AppendEntries RPC）将日志条
 
 领导者向客户端返回结果，并不意味着日志复制过程已完全结束，跟随者尚不清楚日志条目是否已被大多数节点确认。Raft 的设计通过心跳或后续日志复制请求中携带更新的提交索引（leaderCommit），通知跟随者提交日志。此机制将“达成共识的过程”优化为一个阶段，减少了客户端约一半的等待时间。
 
-:::tip 如何选择节点的数量
+:::tip 如何选择节点的数量？
 
 Raft 日志复制过程需要等待多数节点确认。节点越多，等待的延迟也相应增加。所以说，以 Raft 构建的分布式系统并不是节点越多越好。如 etcd，推荐使用 3 个节点，对高可用性要求较高，且能容忍稍高的性能开销，可增加至 5 个节点，如果超出 5 个节点，可能得不偿失。
 :::
 
 我们来看日志复制的另一种情况。在上述例子中，只有 follower-1 成功追加日志，follower-2 因为日志不连续，追加失败。日志的连续性至关重要，如果日志条目没有按正确顺序应用到状态机，各个 follower 节点的状态肯定不一致。
 
-当 follower-2 收到日志复制请求后，它会通过 prevLogIndex 和 prevLogTerm 检查本地日志的连续性。如果日志缺失或存在冲突，follower-2 会返回失败响应，指明与领导者日志不一致的部分。
+日志不连续的问题是这样解决的：follower-2 收到日志复制请求后，它会通过 prevLogIndex 和 prevLogTerm 检查本地日志的连续性。如果日志缺失或存在冲突，follower-2 返回失败响应，指明与领导者日志不一致的部分。
 
 ```json
 {
@@ -61,4 +61,4 @@ Raft 日志复制过程需要等待多数节点确认。节点越多，等待的
   "conflictTerm": 3//缺失日志的“上一个有效日志条目”的任期号
 }
 ```
-当领导者收到失败响应，根据 conflictIndex 和 conflictTerm 找到与跟随者日志的最大匹配索引（例如，6）。随后，领导者从该索引开始重新向跟随者（如 follower-1）发送日志条目，逐步修复日志的不一致性，直至同步完成。
\ No newline at end of file
+当领导者收到失败响应，根据 conflictIndex 和 conflictTerm 找到与跟随者日志的最大匹配索引（例如，6）。随后，领导者从该索引开始重新向跟随者（如 follower-2）发送日志条目，逐步修复日志的不一致性，直至同步完成。
\ No newline at end of file