Editorial and zh updates

Author: Meggielqk

en_US/design/durable-storage.md

@@ -111,12 +111,12 @@ Transactions rely on **Optimistic Concurrency Control (OCC)**, assuming that cli
 **Transaction Flow:**
 
 1. **Initiation:** A client process (Tx) requests the Leader node to create a transaction context (containing the Leader's term and last committed serial number).
-2. **Operations:** Durable storage transaction is represented by an Erlang function. In the body of the function the client can read data (information about accessed topics and time ranges is added to the transaction context), schedule writes and deletes. The client can also set commit preconditions (checks for the existence/non-existence of specific TTVs). Reads are executed immediately, while scheduled writes/deletes only materialize upon full commitment and replication.
+2. **Operations:** Durable storage transaction is represented by an Erlang function. Inside this function, the client can read data (which adds the information about accessed topics and time ranges to the transaction context) and schedule writes or deletes. The client can also set commit preconditions (checks for the existence/non-existence of specific TTVs). Reads are executed immediately, while scheduled writes/deletes only materialize upon full commitment and replication.
 3. **Submission & Verification:** The client sends the list of operations to the Leader.
    - The Leader checks the preconditions against the latest data snapshot.
    - It verifies that the reads do not conflict with recent writes.
 4. **"Cooking (preparing)" and Logging:** If successful, the Leader "cooks" the transaction:
-   - It assigns each written TTVs to on of the streams, creating new streams if necessary.
+   - It assigns each written TTV to one of the streams, creating new streams if necessary.
    - It creates a list of low-level storage mutations that can be applied to all replicas in a deterministic manner.
 5. **Commit:** A batch of "cooked" transactions is added to the Raft log (`builtin_raft`) or the RocksDB write-ahead log (WAL).
 6. **Outcome:** Upon successful completion, the transaction process is notified. Conflicts result in the transaction being aborted and retried.
@@ -160,10 +160,6 @@ Both pools group subscribers by stream and topic, reusing resources to serve mul
 
 <img src="./assets/real-time_subscriptions.png" alt="real-time_subscriptions" style="zoom:67%;" />
 
-## Conclusion: The Foundation of High-Reliability MQTT
-
-The Optimized Durable Storage in EMQX 6.0 is the resilient foundation for high-reliability MQTT messaging. By re-engineering RocksDB and embedding concepts like TTVs and Streams, DS provides a purpose-built, highly available, and persistent internal database. This architecture, coupled with sophisticated features like the LTS algorithm and Raft replication, ensures lossless message delivery and optimal retrieval for complex wildcard and shared subscriptions, solidifying EMQX's position as a leading solution for demanding IoT infrastructure.
-
 ## More Information
 
 Durable Storage serves as the core data foundation for several high-reliability and persistence-related features in EMQX, providing unified storage, replay, and consistency guarantees for upper-layer functionality, including:

zh_CN/design/durable-storage.md

@@ -108,13 +108,13 @@ flowchart TB
 **事务流程：**
 
 1. **初始化：** 客户端进程（Tx）请求 Leader 节点创建一个事务上下文（包含 Leader 的任期号和最近一次提交的序列号）。
-2. **操作阶段：** 客户端在上下文中调度读取（会加入上下文）、写入和删除操作，并可设置提交前提条件（如检查特定 TTV 是否存在/不存在）。这些操作仅在事务成功提交并完成复制后才会真正生效。
+2. **操作阶段：** 持久存储事务以一个 Erlang 函数的形式表示。客户端可以在此函数内部执行读取操作（会将访问的主题及时间范围信息添加到事务上下文中），并安排写入或删除操作。客户端还可以设置提交前置条件（例如检查特定 TTV 是否存在或不存在）。读取操作会立即执行，而安排的写入/删除操作只有在事务成功提交并完成复制后才会真正生效。
 3. **提交与验证：** 客户端将操作列表发送至 Leader。
    - Leader 根据最新数据快照检查前提条件。
    - 验证读取内容是否与最近写入发生冲突。
 4. **“烹制（准备）”与日志记录：** 如果验证通过，Leader 对事务进行“烹制”（即准备阶段）：
-   - 将写入的 TTV 分配到对应的流（Stream）。
-   - 生成一组确定性的底层存储变更操作，可在所有副本上复现。
+   - 为每个待写入的 TTV 分配所属的流（如有需要会创建新的流）。
+   - 生成一组可确定性地应用到所有副本上的低层存储变更操作列表。
 5. **提交：** 经过“烹制”的事务批次被写入 Raft 日志（`builtin_raft`）或 RocksDB 的预写日志（Write-Ahead Log, WAL）。
 6. **结果：** 成功完成后，客户端进程收到提交通知。若检测到冲突，则事务会被中止并重新尝试。
 
@@ -171,12 +171,6 @@ DS 维护两个订阅者池：
 
 <img src="./assets/real-time_subscriptions.png" alt="real-time_subscriptions" style="zoom:67%;" />
 
-## 结论：高可靠 MQTT 的基石
-
-EMQX 6.0 中的优化的持久存储（DS）为高可靠 MQTT 消息传递提供了坚实的基础。通过重新设计 RocksDB 并引入 TTV 与 Stream 等概念，DS 构建了一个专用的、高可用且持久的内部数据库系统。
-
-结合 LTS 算法 与 Raft 复制机制，该架构实现了无损消息传递与复杂通配符/共享订阅场景下的最优数据读取性能，进一步巩固了 EMQX 作为高要求 IoT 基础设施领先方案的地位。
-
 ## 更多信息
 
 持久存储是 EMQX 多项高可靠性与消息持久化特性的核心数据基础组件，为上层功能提供统一的存储、重放与一致性保障。包括：

zh_CN/durability/durability_introduction.md

@@ -4,12 +4,6 @@ EMQX 内置了 MQTT 会话持久化（Durable Session）功能，可以将会话
 
 本页面介绍了 EMQX 中会话持久化的概念、原理和使用方法。
 
-::: warning 重要提示
-
-该功能自 EMQX v5.7.0 版本起可用。然而，尚不支持共享订阅会话的持久化，计划在后续版本中实现。
-
-:::
-
 ## 基本概念
 
 在学习 EMQX 的持久会话功能之前，了解一些 EMQX 的基本概念是非常重要的。
@@ -33,8 +27,8 @@ EMQX 内置了 MQTT 会话持久化（Durable Session）功能，可以将会话
 
 EMQX 提供了两种不同的客户端会话实现，每种实现都针对特定的使用场景进行了优化：
 
-- **临时会话**：会话状态保存在正在运行的 EMQX 节点的内存中。当 EMQX 节点重启时，其状态会丢失。
-- **持久会话**：会话状态和接收的消息备份在持久存储中。EMQX 节点重启后可以恢复这些会话。
+- **临时会话（regular session）**：会话状态保存在正在运行的 EMQX 节点的内存中。当 EMQX 节点重启时，其状态会丢失。
+- **持久会话（durable session）**：会话状态和接收的消息备份在持久存储中。EMQX 节点重启后可以恢复这些会话。
 
 会话实现的选择取决于会话过期间隔和 `durable_sessions.enable` 配置参数，该参数可以全局设置或按 [zone](../configuration/configuration.md#zone-override) 设置。基于以下标准可以选择实现方式：
 
@@ -178,11 +172,11 @@ mqttx sub -t t/1 -i emqx_c --no-clean -q 1
 
 ### 持久会话
 
-持久会话构建于 DS 数据库引擎之上。当客户端以**非零会话过期间隔**连接时，EMQX 会将该会话的状态以及路由到此会话的消息保存到 DS 中。
+持久会话构建于 DS 数据库引擎之上。当客户端以**非零会话过期间隔**连接时，EMQX 会将该会话的状态保存到 DS 中。
 
 - **消息持久化：**
 
-  当持久会话订阅某个主题时，匹配的消息除了正常投递外，还会写入到 DS 中。这确保客户端离线期间的消息能够在其重连后继续投递。
+  当持久会话以 QoS > 0 订阅某个主题过滤器时，EMQX 会在其路由表中将该主题过滤器标记为“可持久化”（durable）。任何发布到被标记为可持久化的主题上的消息，都会在正常转发给临时会话客户端的同时，被写入 DS 进行持久化存储。
 
 - **消费进度跟踪：**