Update high-concurrency.md

v3.0/reference/best-practices/high-concurrency.md

@@ -32,7 +32,7 @@ category: reference
 
 TiDB 以 Region 为单位对数据进行切分，每个 Region 有大小限制（默认 96M）。 Region 的切分方式是范围切分。每个 Region 会有多副本，每一组副本，称为一个 Raft-Group。每个 Raft-Group 中由 Leader 负责执行这块数据的读 & 写（TiDB 即将支持 [Follower-Read](https://zhuanlan.zhihu.com/p/78164196)）。Leader 会自动地被 PD 组件均匀调度在不同的物理节点上，用以均分读写压力。
 
-![图1. TiDB 数据概览](/media/high-concurrency-best-practice/tidb-data-overview.png)
+![TiDB 数据概览](/media/high-concurrency-best-practice/tidb-data-overview.png)
 
 只要业务的写入没有 AUTO_INCREMENT 的主键，或没有单调递增的索引（即没有业务上的写入热点，更多细节可参阅 [TiDB 正确使用方式](https://zhuanlan.zhihu.com/p/25574778)），从原理上来说，TiDB 依靠这个架构可具备线性扩展的读写能力，并且可以充分利用分布式资源。从这一点看，TiDB 尤其适合高并发批量写入场景的业务。
 
@@ -87,7 +87,7 @@ INSERT INTO TEST_HOTSPOT(id, age, user_name, email) values(%v, %v, '%v', '%v');
 
 短时间内大量数据会持续写入到同一个 Region上。
 
-![图2. TiKV Region 分裂流程](/media/high-concurrency-best-practice/tikv-Region-split.png)
+![TiKV Region 分裂流程](/media/high-concurrency-best-practice/tikv-Region-split.png)
 
 上图简单描述了这个过程，随着数据持续写入，TiKV 会将一个 Region 切分为多个。但因为首先发起选举的是原 Leader 所在的 Store，所以新切分好的两个 Region 的 Leader 很可能还会在原 Store 上。新切分好的 Region 2，3 上，也会重复之前发生在 Region 1 上的过程。也就是压力会密集地集中在 TiKV-Node 1 上。
 
@@ -113,7 +113,7 @@ SPLIT TABLE table_name [INDEX index_name] BY (value_list) [, (value_list)]
 
 但是 TiDB 并不自动将这个切分动作提前完成。原因如下：
 
-![图3. Table Region Range](/media/high-concurrency-best-practice/table-Region-range.png)
+![Table Region Range](/media/high-concurrency-best-practice/table-Region-range.png)
 
 从图 3 可知，Table 行数据 key 的编码中，行数据唯一可变的是行 ID （rowID）。在 TiDB 中 rowID 是一个 Int64 整形。但是用户不一定能将 Int64 整形范围均匀切分成需要的份数，然后均匀分布在不同的节点上，还需要结合实际情况。