Auto-sync: Update Chinese docs from English PR

Synced from: pingcap/docs#22708
Target PR: pingcap#21649
AI Provider: azure

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

Author: github-actions[bot]

br/br-log-architecture.md

@@ -17,7 +17,35 @@ summary: 了解 TiDB 的日志备份与 PITR 的架构设计。
 
 日志备份的流程如下：
 
-![BR log backup process design](/media/br/br-log-backup-ts.png)
+```mermaid
+sequenceDiagram
+    actor User
+    participant BR
+    participant PD
+    participant TiKV
+    participant TiDB
+    participant Storage
+
+    User->>BR: 运行 `br log start`
+    BR->>PD: 注册日志备份任务
+    TiKV->>PD: 获取日志备份任务
+    par TiKV 处理本地日志备份任务
+        loop
+            TiKV->>TiKV: 读取 KV 变更数据
+            TiKV->>PD: 获取全局 checkpoint ts
+            TiKV->>TiKV: 生成本地元信息
+            TiKV->>Storage: 上传日志数据和元信息
+            TiKV->>PD: 配置 GC
+        end
+    and
+        loop
+            TiDB->>TiKV: 监控备份进度
+            TiDB->>PD: 上报全局 checkpoint ts
+        end
+    end
+    User->>BR: 运行 `br log status`
+    BR->>PD: 获取日志备份任务状态
+```
 
 系统组件和关键概念：
 
@@ -53,7 +81,29 @@ summary: 了解 TiDB 的日志备份与 PITR 的架构设计。
 
 PITR 的流程如下：
 
-![Point-in-time recovery process design](/media/br/pitr-ts.png)
+```mermaid
+sequenceDiagram
+    actor User
+    participant BR
+    participant TiKV
+    participant PD
+    participant Storage
+
+    User->>BR: 运行 `br restore point`
+    BR->>TiKV: 恢复全量数据
+    loop 恢复日志数据
+        BR->>Storage: 读取备份数据
+        BR->>PD: 获取 Region 信息
+        BR->>TiKV: 请求 TiKV 恢复数据
+        loop TiKV 处理恢复请求
+            TiKV->>Storage: 下载 KV
+            TiKV->>TiKV: 重写 KV
+            TiKV->>TiKV: 应用 KV
+        end
+        TiKV->>BR: 上报恢复结果
+        BR->>BR: 处理所有恢复结果
+    end
+```
 
 完整的 PITR 交互流程描述如下：
 

br/br-snapshot-architecture.md

@@ -17,7 +17,28 @@ summary: 了解 TiDB 快照备份与恢复功能的架构设计。
 
 集群快照数据备份的流程如下：
 
-![snapshot backup process design](/media/br/br-snapshot-backup-ts.png)
+```mermaid
+sequenceDiagram
+    actor User
+    participant BR
+    participant PD
+    participant TiKV
+    participant Storage
+
+    User->>BR: 运行 `br backup full`
+    BR->>PD: 暂停 GC
+    BR->>PD: 获取 TiKV 和 Region 信息
+    BR->>TiKV: 请求 TiKV 备份数据
+    loop TiKV 处理本地快照备份任务
+        TiKV->>TiKV: 扫描 KV
+        TiKV->>TiKV: 生成 SST
+        TiKV->>Storage: 上传 SST
+    end
+    TiKV->>BR: 报告备份结果
+    BR->>BR: 处理所有备份结果
+    BR->>TiKV: 备份 schema
+    BR->>Storage: 上传备份元信息
+```
 
 完整的备份交互流程描述如下：
 
@@ -49,7 +70,27 @@ summary: 了解 TiDB 快照备份与恢复功能的架构设计。
 
 恢复集群快照备份数据的流程如下：
 
-![snapshot restore process design](/media/br/br-snapshot-restore-ts.png)
+```mermaid
+sequenceDiagram
+    actor User
+    participant BR
+    participant PD
+    participant TiKV
+    participant Storage
+
+    User->>BR: 运行 `br restore`
+    BR->>PD: 暂停 Region 调度
+    BR->>TiKV: 恢复 schema
+    BR->>PD: 切分并打散 Region
+    BR->>TiKV: 请求 TiKV 恢复数据
+    loop TiKV 处理恢复请求
+        TiKV->>Storage: 下载 SST
+        TiKV->>TiKV: 重写 KV
+        TiKV->>TiKV: 导入 SST
+    end
+    TiKV->>BR: 报告恢复结果
+    BR->>BR: 处理所有恢复结果
+```
 
 完整的恢复交互流程描述如下：
 

dm/feature-shard-merge-pessimistic.md

@@ -79,7 +79,35 @@ DM 在悲观模式下进行分表 DDL 的迁移有以下几点使用限制：
 
 基于上述例子，本部分介绍了 DM 在默认的悲观模式下合库合表过程中进行 DDL 迁移的实现原理。
 
-![shard-ddl-flow](/media/dm/shard-ddl-flow.png)
+```mermaid
+---
+config:
+    themeCSS: |
+        /* hide the ugly borders */
+        rect.rect {
+            stroke: none;
+        }
+---
+sequenceDiagram
+    autonumber
+    box rgba(0,255,0,0.08)
+        participant Worker1 as DM-worker 1
+    end
+    box rgba(255,255,0,0.08)
+        participant Master as DM-master
+    end
+    box rgba(0,255,0,0.08)
+        participant Worker2 as DM-worker 2
+    end
+
+    Worker1->>Master: 1. DDL info
+    Master->>Worker1: 2. DDL lock info
+    Worker2->>Master: 3. DDL info
+    Master->>Worker2: 4. DDL lock info
+    Master->>Worker1: 5. DDL execute request
+    Worker1->>Master: 6. DDL executed
+    Master-->>Worker2: 7. DDL ignore request
+```
 
 在这个例子中，DM-worker-1 负责迁移来自 MySQL 实例 1 的数据，DM-worker-2 负责迁移来自 MySQL 实例 2 的数据，DM-master 负责协调多个 DM-worker 间的 DDL 迁移。
 

pessimistic-transaction.md

@@ -141,31 +141,128 @@ TiDB 在悲观事务模式下支持了 2 种隔离级别：
 
 ## 悲观事务提交流程
 
-TiDB 悲观锁复用了乐观锁的两阶段提交逻辑，重点在 DML 执行时做了改造。
+在事务提交流程中，悲观事务和乐观事务的逻辑相同。两者都采用两阶段提交（2PC）模式。悲观事务的重要适配点在于 DML 执行。
 
-![TiDB 悲观事务的提交流程](/media/pessimistic-transaction-commit.png)
-
-在两阶段提交之前增加了 Acquire Pessimistic Lock 阶段，简要步骤如下。
+```mermaid
+---
+config:
+  themeCSS: |
+    /* workaround for https://github.com/mermaid-js/mermaid/issues/523 */
+    /* mark the two "Lock" arrows as red, by restyling the dashed arrows */
+    line.messageLine1 {
+        stroke: #d32f2f;
+        stroke-dasharray: none !important;
+    }
+    /* make sure the arrow heads inherit the stroke color (another bug in mermaid) */
+    #arrowhead path {
+        fill: context-stroke;
+        stroke: context-stroke;
+    }
+---
+sequenceDiagram
+    participant Client
+    participant TiDB
+    participant TiKV
+
+    Client->>TiDB: BEGIN
+    rect rgba(255, 0, 0, 0.08)
+        Client->>TiDB: DML
+        TiDB-->>TiKV: Lock
+        TiDB-->>TiKV: Lock
+    end
+    rect rgba(0, 0, 0, 0.04)
+        Client->>TiDB: COMMIT
+        TiDB->>TiKV: Prewrite
+        TiDB->>TiKV: Commit
+    end
+```
 
-1. （同乐观锁）TiDB 收到来自客户端的 begin 请求，获取当前时间戳作为本事务的 StartTS。
-2. TiDB 收到来自客户端的更新数据的请求：TiDB 向 TiKV 发起加悲观锁请求，该锁持久化到 TiKV。
-3. （同乐观锁）客户端发起 commit，TiDB 开始执行与乐观锁一样的两阶段提交。
+悲观事务在 2PC 之前增加了 `Acquire Pessimistic Lock` 阶段。该阶段包括以下步骤：
 
-![TiDB 中的悲观事务](/media/pessimistic-transaction-in-tidb.png)
+1. （同乐观事务模式）TiDB 收到来自客户端的 `begin` 请求，当前时间戳即为该事务的 start_ts。
+2. 当 TiDB 服务器收到来自客户端的写请求时，TiDB 服务器会向 TiKV 服务器发起悲观锁请求，并将该锁持久化到 TiKV 服务器。
+3. （同乐观事务模式）当客户端发送 commit 请求时，TiDB 开始执行与乐观事务模式类似的两阶段提交。
 
-相关细节本节不再赘述，详情可阅读 [TiDB 悲观锁实现原理](https://pingkai.cn/tidbcommunity/blog/7730ed79)。
+```mermaid
+---
+title: Pessimistic Transaction in TiDB
+---
+sequenceDiagram
+    participant client
+    participant TiDB
+    participant PD
+    participant TiKV
+
+    client->>TiDB: begin
+    TiDB->>PD: get ts as start_ts
+    loop execute SQL
+        rect rgba(0, 0, 0, 0.04)
+            alt do read
+                TiDB->>TiKV: get data from TiKV with start_ts
+                TiDB->>client: return read result
+            else do write
+                rect rgba(255, 0, 0, 0.08)
+                    loop if has write conflict
+                        TiDB->>PD: get ts as for_update_ts
+                        TiDB->>TiDB: write in cache
+                        TiDB->>TiKV: acquire pessimistic locks parallelly
+                    end
+                end
+                TiDB->>client: return write result
+            end
+        end
+    end
+    client->>TiDB: commit
+    opt start 2PC
+        rect rgba(0, 0, 0, 0.04)
+            par prewrite
+                TiDB->>TiKV: prewrite each key in cache with start_ts parallelly
+            end
+        end
+        rect rgba(0, 0, 0, 0.04)
+            par commit
+                TiDB->>PD: get ts as commit_ts
+                TiDB->>TiKV: commit primary_key with commit_ts first
+                TiDB->>client: success
+                TiDB->>TiKV: commit each secondary_key with commit_ts parallelly
+            end
+        end
+    end
+```
 
 ## Pipelined 加锁流程
 
-加悲观锁需要向 TiKV 写入数据，要经过 Raft 提交并 apply 后才能返回，相比于乐观事务，不可避免的会增加部分延迟。为了降低加锁的开销，TiKV 实现了 pipelined 加锁流程：当数据满足加锁要求时，TiKV 立刻通知 TiDB 执行后面的请求，并异步写入悲观锁，从而降低大部分延迟，显著提升悲观事务的性能。但当 TiKV 出现网络隔离或者节点宕机时，悲观锁异步写入有可能失败，从而产生以下影响：
+加悲观锁需要向 TiKV 写入数据。只有在经过 Raft 提交并 apply 后，TiKV 才能向 TiDB 返回加锁成功的响应。因此，相比乐观事务，悲观事务模式不可避免地具有更高的延迟。
+
+为了降低加锁的开销，TiKV 实现了 pipelined 加锁流程：当数据满足加锁要求时，TiKV 立刻通知 TiDB 执行后续请求，并异步写入悲观锁。该流程降低了大部分延迟，显著提升了悲观事务的性能。但是，当 TiKV 发生网络隔离或者 TiKV 节点宕机时，悲观锁的异步写入可能失败，并产生以下影响：
 
-* 无法阻塞修改相同数据的其他事务。如果业务逻辑依赖加锁或等锁机制，业务逻辑的正确性将受到影响。
+* 无法阻塞修改相同数据的其他事务。如果应用逻辑依赖加锁或等锁机制，应用逻辑的正确性将受到影响。
 
-* 有较低概率导致事务提交失败，但不会影响事务正确性。
+* 有较低概率导致事务提交失败，但不会影响事务的正确性。
 
-如果业务逻辑依赖加锁或等锁机制，或者即使在集群异常情况下也要尽可能保证事务提交的成功率，应关闭 pipelined 加锁功能。
+<CustomContent platform="tidb">
 
-![Pipelined pessimistic lock](/media/pessimistic-transaction-pipelining.png)
+如果应用逻辑依赖加锁或等锁机制，或者你希望即使在 TiKV 集群异常的情况下也尽可能保证事务提交的成功率，则应关闭 pipelined 加锁功能。
+
+```mermaid
+---
+title: pipelined pessimistic lock
+---
+sequenceDiagram
+    participant Client
+    participant TiDB
+    participant TiKV1
+    participant TiKV2
+    participant TiKV3
+
+    loop
+        Client->>TiDB: DML
+        TiDB->>TiKV1: Acquire pessimistic locks
+        TiKV1->>TiDB: OK
+        TiKV1--)TiKV2: Log replication
+        TiKV1--)TiKV3: Log replication
+    end
+```
 
 该功能默认开启，可修改 TiKV 配置关闭：
 
@@ -174,14 +271,22 @@ TiDB 悲观锁复用了乐观锁的两阶段提交逻辑，重点在 DML 执行
 pipelined = false
 ```
 
-若集群是 v4.0.9 及以上版本，也可通过[在线修改 TiKV 配置](/dynamic-config.md#在线修改-tikv-配置)功能动态关闭该功能：
+若 TiKV 集群为 v4.0.9 及以上版本，也可通过[在线修改 TiKV 配置](/dynamic-config.md#在线修改-tikv-配置)功能动态关闭该功能：
 
 {{< copyable "sql" >}}
 
 ```sql
 set config tikv pessimistic-txn.pipelined='false';
 ```
 
+</CustomContent>
+
+<CustomContent platform="tidb-cloud">
+
+如果应用逻辑依赖加锁或等锁机制，或者你希望即使在 TiKV 集群异常的情况下也尽可能保证事务提交的成功率，可以[联系 TiDB Cloud 支持](/tidb-cloud/tidb-cloud-support.md)关闭 pipelined 加锁功能。
+
+</CustomContent>
+
 ## 内存悲观锁
 
 TiKV 在 v6.0.0 中引入了内存悲观锁功能。开启内存悲观锁功能后，悲观锁通常只会被存储在 Region leader 的内存中，而不会将锁持久化到磁盘，也不会通过 Raft 协议将锁同步到其他副本，因此可以大大降低悲观事务加锁的开销，提升悲观事务的吞吐并降低延迟。