revert non relative

Signed-off-by: nolouch <nolouch@gmail.com>

develop/dev-guide-use-follower-read.md

@@ -1,29 +1,27 @@
 ---
-title: Replicas Read - Follower/Leader Read
-summary: TiDB 提供多种使用 Follower Read 在特定情况下加速查询, 选择特定副本进行读(Replicas Read).
+title: Follower Read
+summary: 使用 Follower Read 在特定情况下加速查询。
 aliases: ['/zh/tidb/dev/use-follower-read']
 ---
 
-# Replicas Read
+# Follower Read
 
-本章将介绍 TiDB 读取数据的方式，并且介绍如何切换 Leader/ Follower Read, 在特定情况下加速查询的方法。
+本章将介绍使用 Follower Read 在特定情况下加速查询的方法。
 
 ## 简介
 
 在 TiDB 当中，数据是以 [Region](/tidb-storage.md#region) 为单位，分散在集群中所有的节点上进行存储的。一个 Region 可以存在多个副本，副本又分为一个 leader 和多个 follower。当 leader 上的数据发生变化时，TiDB 会将数据同步更新到 follower。
 
 默认情况下，TiDB 只会在同一个 Region 的 leader 上读写数据。当系统中存在读取热点 Region 导致 leader 资源紧张成为整个系统读取瓶颈时，启用 Follower Read 功能可明显降低 leader 的负担，并且通过在多个 follower 之间均衡负载，显著地提升整体系统的吞吐能力。
 
-## 何时使用 Follower Read
+## 何时使用
 
 你可以在 [TiDB Dashboard 流量可视化页面](/dashboard/dashboard-key-visualizer.md)当中通过可视化的方法分析你的应用程序是否存在热点 Region。你可以通过将「指标选择框」选择到 `Read (bytes)` 或 `Read (keys)` 查看是否存在读取热点 Region。
 
 如果发现确实存在热点问题，你可以通过阅读 [TiDB 热点问题处理](/troubleshoot-hot-spot-issues.md)章节进行逐一排查，以便从应用程序层面上避免热点的产生。
 
 如果读取热点的确无法避免或者改动的成本很大，你可以尝试通过 Follower Read 功能将读取请求更好的负载均衡到 follower region。
 
-Follower Read 默认情况下是保证强一致性的，因此默认情况下其实是 Follower Strong Read, Follower Storng Read 会产生 Follower 和 Leader 之间的通信校验开销，为了减少与 Leader 的通信，Follower Strong Read 更适合大查询的场景, 即查询读取数据的耗时远远大于 rpc 通信时间。 
-
 ## 开启 Follower Read
 
 <SimpleTab>

pd-control.md

@@ -1278,7 +1278,7 @@ store 1
 ......
 ```
 
-### store 下线
+#### store 下线
 
 下线 store id 为 1 的 store：
 
@@ -1352,12 +1352,11 @@ store weight 1 5 10
 
 {{< copyable "" >}}
 
-### store limit 命令
+#### store limit 命令
 
 详细解释：[store limit](/configure-store-limit.md)
 
 ```bash
-
 >> store limit                         // 显示所有 store 添加和删除 peer 的速度上限
 >> store limit add-peer                // 显示所有 store 添加 peer 的速度上限
 >> store limit remove-peer             // 显示所有 store 删除 peer 的速度上限