You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by di...@apache.org on 2022/09/14 01:53:03 UTC
[rocketmq-site] branch new-official-website updated: merge new official website develop (#235)
This is an automated email from the ASF dual-hosted git repository.
dinglei pushed a commit to branch new-official-website
in repository https://gitbox.apache.org/repos/asf/rocketmq-site.git
The following commit(s) were added to refs/heads/new-official-website by this push:
new 1b7dc363 merge new official website develop (#235)
1b7dc363 is described below
commit 1b7dc363ef5091509cbb56e711a700d4a40faa48
Author: zhoubo <87...@qq.com>
AuthorDate: Wed Sep 14 09:52:59 2022 +0800
merge new official website develop (#235)
* [ISSUE #221]Optimize RocketMQ 5.0 16dledger.md file (#222)
* remove log&server doc
* #232 init rocketmq 5.0 doc, contains concepts,models,features (#234)
* add server docs (#225)
* add log docs (#226)
* [ISSUE #230] Polish up cn document command formate for RocketMQ5.0 (#231)
Co-authored-by: mxsm <lj...@gmail.com>
Co-authored-by: Zhongliang.Chen <ch...@gmail.com>
Co-authored-by: windWheel <18...@qq.com>
---
"docs/01-\344\273\213\347\273\215/02quickstart.md" | 12 +-
.../15deploy.md" | 53 ++--
docusaurus.config.js | 2 +-
.../01-\344\273\213\347\273\215/02quickstart.md" | 104 --------
.../5.0/01-\344\273\213\347\273\215/03whatis.md" | 155 -----------
.../01whychoose.md" | 0
.../02concepts.md" | 79 ++++++
.../03limits.md" | 24 ++
.../02quickstart.md" | 224 ++++++++++++++++
.../04concept1.md" | 87 -------
.../05message1.md" | 178 -------------
.../06message2.md" | 76 ------
.../07message3.md" | 45 ----
.../08message4.md" | 29 ---
.../09message5.md" | 149 -----------
.../11concept2.md" | 60 -----
.../12push.md" | 233 -----------------
.../13pull.md" | 120 ---------
.../01main.md" | 120 +++++++++
.../02topic.md" | 131 ++++++++++
.../03messagequeue.md" | 107 ++++++++
.../04message.md" | 231 +++++++++++++++++
.../04producer.md" | 137 ++++++++++
.../07consumergroup.md" | 121 +++++++++
.../08consumer.md" | 154 +++++++++++
.../09subscription.md" | 100 +++++++
.../01normalmessage.md" | 98 +++++++
.../02delaymessage.md" | 145 +++++++++++
.../03fifomessage.md" | 192 ++++++++++++++
.../04transactionmessage.md" | 220 ++++++++++++++++
.../05sendretrypolicy.md" | 134 ++++++++++
.../06consumertype.md" | 210 +++++++++++++++
.../07messagefilter.md" | 287 +++++++++++++++++++++
.../08consumerloadbalance.md" | 169 ++++++++++++
.../09consumerprogress.md" | 101 ++++++++
.../10consumerretrypolicy.md" | 205 +++++++++++++++
.../11messagestorepolicy.md" | 66 +++++
.../15bestpractice.md" | 228 ----------------
.../17messagetra.md" | 117 ---------
.../20log.md" | 190 --------------
.../21subscribe.md" | 215 ---------------
.../15deploy.md" | 75 +++---
.../16admintool.md" | 0
.../17Dashboard.md" | 2 -
.../18Exporter.md" | 0
.../23local.md" | 147 -----------
.../24server.md" | 99 -------
.../15bestpractice.md" | 104 ++++++++
.../16dledger.md" | 4 +-
.../18access.md" | 10 +-
.../19JVMOS.md" | 5 +-
.../21subscribe.md" | 100 +++++++
.../22FAQ.md" | 25 +-
.../5.0/picture/v5/archiforconsumer.png | Bin 0 -> 148858 bytes
.../5.0/picture/v5/archiforconsumergroup.png | Bin 0 -> 147277 bytes
.../5.0/picture/v5/archiforproducer.png | Bin 0 -> 145985 bytes
.../5.0/picture/v5/archiforqueue.png | Bin 0 -> 147979 bytes
.../5.0/picture/v5/archiforsubsciption.png | Bin 0 -> 147298 bytes
.../5.0/picture/v5/archifortopic.png | Bin 0 -> 154100 bytes
.../5.0/picture/v5/asyncarchi.png | Bin 0 -> 134753 bytes
.../5.0/picture/v5/changeInvisibletime.png | Bin 0 -> 35179 bytes
.../5.0/picture/v5/cleanpolicy.png | Bin 0 -> 49206 bytes
.../5.0/picture/v5/clustermode.png | Bin 0 -> 45888 bytes
.../5.0/picture/v5/clusterqueuemode.png | Bin 0 -> 87461 bytes
.../5.0/picture/v5/consumemode.png | Bin 0 -> 171868 bytes
.../5.0/picture/v5/consumerflow.png | Bin 0 -> 51028 bytes
.../5.0/picture/v5/consumerprogress.png | Bin 0 -> 39051 bytes
.../5.0/picture/v5/consumerprogress1.png | Bin 0 -> 30458 bytes
.../5.0/picture/v5/delaywork.png | Bin 0 -> 121608 bytes
.../5.0/picture/v5/fifo_trade.png | Bin 0 -> 191635 bytes
.../5.0/picture/v5/fifoinclustermode.png | Bin 0 -> 77930 bytes
.../5.0/picture/v5/fifomessagegroup.png | Bin 0 -> 103052 bytes
.../5.0/picture/v5/lifecyclefordelay.png | Bin 0 -> 11735 bytes
.../5.0/picture/v5/lifecyclefornormal.png | Bin 0 -> 11596 bytes
.../5.0/picture/v5/lifecyclefortrans.png | Bin 0 -> 20575 bytes
.../5.0/picture/v5/mainarchi.png | Bin 0 -> 217008 bytes
.../5.0/picture/v5/maxoffset.png | Bin 0 -> 61307 bytes
.../5.0/picture/v5/messagefilter.png | Bin 0 -> 197371 bytes
.../5.0/picture/v5/messagefilter0.png | Bin 0 -> 81657 bytes
.../5.0/picture/v5/messagefilter2.png | Bin 0 -> 227418 bytes
.../5.0/picture/v5/offlineprocess.png | Bin 0 -> 131816 bytes
.../5.0/picture/v5/onlineprocess.png | Bin 0 -> 138684 bytes
.../5.0/picture/v5/p2pmode.png | Bin 0 -> 64008 bytes
.../5.0/picture/v5/producer_topic.png | Bin 0 -> 35076 bytes
.../5.0/picture/v5/pubsub.png | Bin 0 -> 81608 bytes
.../5.0/picture/v5/pushconsumer.png | Bin 0 -> 83105 bytes
.../5.0/picture/v5/retrymachinestatus.png | Bin 0 -> 59915 bytes
.../5.0/picture/v5/retrytimeline.png | Bin 0 -> 33100 bytes
.../5.0/picture/v5/scheduletask.png | Bin 0 -> 46032 bytes
.../5.0/picture/v5/simplemachinestatus.png | Bin 0 -> 48360 bytes
.../5.0/picture/v5/simpletimeline.png | Bin 0 -> 27620 bytes
.../5.0/picture/v5/subscription_diff_group.png | Bin 0 -> 125638 bytes
.../5.0/picture/v5/subscription_one_group.png | Bin 0 -> 12705 bytes
.../5.0/picture/v5/syncarchi.png | Bin 0 -> 171060 bytes
.../5.0/picture/v5/tradetrans01.png | Bin 0 -> 134035 bytes
.../5.0/picture/v5/tradewithfifo.png | Bin 0 -> 59917 bytes
.../5.0/picture/v5/tradewithnormal.png | Bin 0 -> 56955 bytes
.../5.0/picture/v5/tradewithrmqtrans.png | Bin 0 -> 190210 bytes
.../5.0/picture/v5/tradewithtrans.png | Bin 0 -> 91597 bytes
.../5.0/picture/v5/transflow.png | Bin 0 -> 43363 bytes
.../5.0/picture/v5/transwithnormal.png | Bin 0 -> 84607 bytes
.../5.0/picture/v5/updateprogress.png | Bin 0 -> 61307 bytes
.../20log.md" | 190 --------------
.../24server.md" | 99 -------
.../version-5.0.json | 22 +-
i18n/en/docusaurus-theme-classic/footer.json | 60 +++++
i18n/en/docusaurus-theme-classic/navbar.json | 16 ++
src/pages/origin.md | 4 +-
.../01-\344\273\213\347\273\215/02quickstart.md" | 104 --------
.../01-\344\273\213\347\273\215/03whatis.md" | 153 -----------
.../01whychoose.md" | 0
.../02concepts.md" | 79 ++++++
.../03limits.md" | 24 ++
.../02quickstart.md" | 224 ++++++++++++++++
.../04concept1.md" | 87 -------
.../05message1.md" | 178 -------------
.../06message2.md" | 76 ------
.../07message3.md" | 45 ----
.../08message4.md" | 29 ---
.../09message5.md" | 149 -----------
.../11concept2.md" | 60 -----
.../12push.md" | 233 -----------------
.../13pull.md" | 120 ---------
.../01main.md" | 120 +++++++++
.../02topic.md" | 131 ++++++++++
.../03messagequeue.md" | 107 ++++++++
.../04message.md" | 231 +++++++++++++++++
.../04producer.md" | 133 ++++++++++
.../07consumergroup.md" | 121 +++++++++
.../08consumer.md" | 150 +++++++++++
.../09subscription.md" | 100 +++++++
.../01normalmessage.md" | 98 +++++++
.../02delaymessage.md" | 145 +++++++++++
.../03fifomessage.md" | 192 ++++++++++++++
.../04transactionmessage.md" | 220 ++++++++++++++++
.../05sendretrypolicy.md" | 134 ++++++++++
.../06consumertype.md" | 210 +++++++++++++++
.../07messagefilter.md" | 284 ++++++++++++++++++++
.../08consumerloadbalance.md" | 169 ++++++++++++
.../09consumerprogress.md" | 101 ++++++++
.../10consumerretrypolicy.md" | 205 +++++++++++++++
.../11messagestorepolicy.md" | 66 +++++
.../15bestpractice.md" | 228 ----------------
.../17messagetra.md" | 117 ---------
.../20log.md" | 190 --------------
.../21subscribe.md" | 215 ---------------
.../15deploy.md" | 75 +++---
.../16admintool.md" | 0
.../17Dashboard.md" | 10 +-
.../18Exporter.md" | 0
.../23local.md" | 147 -----------
.../24server.md" | 99 -------
.../15bestpractice.md" | 104 ++++++++
.../16dledger.md" | 47 ++--
.../18access.md" | 33 ++-
.../19JVMOS.md" | 5 +-
.../21subscribe.md" | 100 +++++++
.../22FAQ.md" | 25 +-
.../31pull-request.md" | 41 ++-
.../version-5.0/picture/v5/archiforconsumer.png | Bin 0 -> 148858 bytes
.../picture/v5/archiforconsumergroup.png | Bin 0 -> 147277 bytes
.../version-5.0/picture/v5/archiforproducer.png | Bin 0 -> 145985 bytes
.../version-5.0/picture/v5/archiforqueue.png | Bin 0 -> 147979 bytes
.../version-5.0/picture/v5/archiforsubsciption.png | Bin 0 -> 147298 bytes
.../version-5.0/picture/v5/archifortopic.png | Bin 0 -> 154100 bytes
.../version-5.0/picture/v5/asyncarchi.png | Bin 0 -> 134753 bytes
.../version-5.0/picture/v5/changeInvisibletime.png | Bin 0 -> 35179 bytes
.../version-5.0/picture/v5/cleanpolicy.png | Bin 0 -> 49206 bytes
.../version-5.0/picture/v5/clustermode.png | Bin 0 -> 45888 bytes
.../version-5.0/picture/v5/clusterqueuemode.png | Bin 0 -> 87461 bytes
.../version-5.0/picture/v5/consumemode.png | Bin 0 -> 171868 bytes
.../version-5.0/picture/v5/consumerflow.png | Bin 0 -> 51028 bytes
.../version-5.0/picture/v5/consumerprogress.png | Bin 0 -> 39051 bytes
.../version-5.0/picture/v5/consumerprogress1.png | Bin 0 -> 30458 bytes
.../version-5.0/picture/v5/delaywork.png | Bin 0 -> 121608 bytes
.../version-5.0/picture/v5/fifo_trade.png | Bin 0 -> 191635 bytes
.../version-5.0/picture/v5/fifoinclustermode.png | Bin 0 -> 77930 bytes
.../version-5.0/picture/v5/fifomessagegroup.png | Bin 0 -> 103052 bytes
.../version-5.0/picture/v5/lifecyclefordelay.png | Bin 0 -> 11735 bytes
.../version-5.0/picture/v5/lifecyclefornormal.png | Bin 0 -> 11596 bytes
.../version-5.0/picture/v5/lifecyclefortrans.png | Bin 0 -> 20575 bytes
.../version-5.0/picture/v5/mainarchi.png | Bin 0 -> 217008 bytes
.../version-5.0/picture/v5/maxoffset.png | Bin 0 -> 61307 bytes
.../version-5.0/picture/v5/messagefilter.png | Bin 0 -> 197371 bytes
.../version-5.0/picture/v5/messagefilter0.png | Bin 0 -> 81657 bytes
.../version-5.0/picture/v5/messagefilter2.png | Bin 0 -> 227418 bytes
.../version-5.0/picture/v5/offlineprocess.png | Bin 0 -> 131816 bytes
.../version-5.0/picture/v5/onlineprocess.png | Bin 0 -> 138684 bytes
versioned_docs/version-5.0/picture/v5/p2pmode.png | Bin 0 -> 64008 bytes
.../version-5.0/picture/v5/producer_topic.png | Bin 0 -> 35076 bytes
versioned_docs/version-5.0/picture/v5/pubsub.png | Bin 0 -> 81608 bytes
.../version-5.0/picture/v5/pushconsumer.png | Bin 0 -> 83105 bytes
.../version-5.0/picture/v5/retrymachinestatus.png | Bin 0 -> 59915 bytes
.../version-5.0/picture/v5/retrytimeline.png | Bin 0 -> 33100 bytes
.../version-5.0/picture/v5/scheduletask.png | Bin 0 -> 46032 bytes
.../version-5.0/picture/v5/simplemachinestatus.png | Bin 0 -> 48360 bytes
.../version-5.0/picture/v5/simpletimeline.png | Bin 0 -> 27620 bytes
.../picture/v5/subscription_diff_group.png | Bin 0 -> 125638 bytes
.../picture/v5/subscription_one_group.png | Bin 0 -> 12705 bytes
.../version-5.0/picture/v5/syncarchi.png | Bin 0 -> 171060 bytes
.../version-5.0/picture/v5/tradetrans01.png | Bin 0 -> 134035 bytes
.../version-5.0/picture/v5/tradewithfifo.png | Bin 0 -> 59917 bytes
.../version-5.0/picture/v5/tradewithnormal.png | Bin 0 -> 56955 bytes
.../version-5.0/picture/v5/tradewithrmqtrans.png | Bin 0 -> 190210 bytes
.../version-5.0/picture/v5/tradewithtrans.png | Bin 0 -> 91597 bytes
.../version-5.0/picture/v5/transflow.png | Bin 0 -> 43363 bytes
.../version-5.0/picture/v5/transwithnormal.png | Bin 0 -> 84607 bytes
.../version-5.0/picture/v5/updateprogress.png | Bin 0 -> 61307 bytes
208 files changed, 7237 insertions(+), 4947 deletions(-)
diff --git "a/docs/01-\344\273\213\347\273\215/02quickstart.md" "b/docs/01-\344\273\213\347\273\215/02quickstart.md"
index 9876b0d9..c0cd3570 100644
--- "a/docs/01-\344\273\213\347\273\215/02quickstart.md"
+++ "b/docs/01-\344\273\213\347\273\215/02quickstart.md"
@@ -13,19 +13,19 @@
:::tip RocketMQ下载
-RocketMQ 的安装包分为两种，二进制包和源码包。点击[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-source-release.zip) 下载 Apache RocketMQ 4.9.4的源码包。你也可以从[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-bin-release.zip) 下载到二进制包。二进制包是已经编译完成后可以直接运行的，源码包是需要编译后运行的，
+RocketMQ 的安装包分为两种，二进制包和源码包。当前 5.0 版本即将Release，可以先使用Develop分支下载源码编译。
+
+点击[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-source-release.zip) 下载 Apache RocketMQ 4.9.4的源码包。你也可以从[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-bin-release.zip) 下载到二进制包。二进制包是已经编译完成后可以直接运行的，源码包是需要编译后运行的，
:::
-这里以在Linux环境下利用社区4.9.4的源码包为例，介绍RocketMQ安装过程。
+这里以在Linux环境下利用 develop 分支源码包为例，介绍RocketMQ安装过程。
-解压4.9.4的源码包并编译构建二进制可执行文件
+解压 develop 分支的源码包并编译构建二进制可执行文件
```shell
-$ unzip rocketmq-all-4.9.4-source-release.zip
-$ cd rocketmq-all-4.9.4-source-release/
$ mvn -Prelease-all -DskipTests clean install -U
-$ cd distribution/target/rocketmq-4.9.4/rocketmq-4.9.4
+$ cd distribution/target/rocketmq-5.0.0-SNAPSHOT/rocketmq-5.0.0-SNAPSHOT
```
## 2. 启动NameServer
diff --git "a/docs/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/15deploy.md" "b/docs/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/15deploy.md"
index cdd5984c..9e56d4b2 100644
--- "a/docs/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/15deploy.md"
+++ "b/docs/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/15deploy.md"
@@ -1,14 +1,23 @@
# 部署方式
-<!-- ## 集群搭建 -->
+Apache RocketMQ 5.0 版本完成基本消息收发，包括 NameServer、Broker、Proxy 组件。 在 5.0 版本中 Proxy 和 Broker 根据实际诉求可以分为 Local 模式和 Cluster 模式，一般情况下如果没有特殊需求，或者遵循从早期版本平滑升级的思路，可以选用Local模式。
-## 单Master模式
+- 在 Local 模式下，Broker 和 Proxy 是同进程部署，只是在原有 Broker 的配置基础上新增 Proxy 的简易配置就可以运行。
+- 在 Cluster 模式下，Broker 和 Proxy 分别部署，即在原有的集群基础上，额外再部署 Proxy 即可。
+
+## 部署方案和使用约束
+
+## Local模式部署
+
+由于 Local 模式下 Proxy 和 Broker 是同进程部署，Proxy本身无状态，因此主要的集群配置仍然以 Broker 为基础进行即可。
+
+### 单组节点单副本模式
:::caution
-这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用, 可以用于本地测试。
+这种方式风险较大，因为 Broker 只有一个节点，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用, 可以用于本地测试。
:::
-### 启动 NameServer
+#### 启动 NameServer
```bash
### 首先启动Name Server
@@ -19,31 +28,31 @@ $ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
```
-### 启动 Broker
+#### 启动 Broker+Proxy
```bash
-### 启动Broker
-$ nohup sh bin/mqbroker -n localhost:9876 &
+
+$ nohup sh bin/mqproxy -n localhost:9876 &
### 验证Name Server 是否启动成功，例如Broker的IP为：192.168.1.2，且名称为broker-a
$ tail -f ~/logs/rocketmqlogs/Broker.log
-The broker[broker-a, 192.169.1.2:10911] boot success...
+The broker[xxx, 192.169.1.2:10911] boot success...
```
-## 多Master模式
+### 多组节点（集群）单副本模式
-一个集群无Slave，全是Master，例如2个Master或者3个Master，这种模式的优缺点如下：
+一个集群内全部部署 Master 角色，不部署Slave 副本，例如2个Master或者3个Master，这种模式的优缺点如下：
- 优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；
- 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。
-### 启动NameServer
+#### 启动NameServer
NameServer需要先于Broker启动，且如果在生产环境使用，为了保证高可用，建议一般规模的集群启动3个NameServer，各节点的启动命令相同，如下：
```bash
-### 首先启动Name Server
+# 首先启动Name Server
$ nohup sh mqnamesrv &
### 验证Name Server 是否启动成功
@@ -51,14 +60,14 @@ $ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
```
-### 启动Broker集群
+#### 启动Broker+Proxy集群
```bash
### 在机器A，启动第一个Master，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties &
### 在机器B，启动第二个Master，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties &
...
```
@@ -69,15 +78,15 @@ $ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker
:::
-## 多Master多Slave模式-异步复制
+## 多节点（集群）多副本模式-异步复制
-每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：
+每个Master配置一个Slave，有多组 Master-Slave，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：
- 优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样；
- 缺点：Master宕机，磁盘损坏情况下会丢失少量消息。
-### 启动NameServer
+#### 启动NameServer
```bash
### 首先启动Name Server
@@ -88,7 +97,7 @@ $ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
```
-### 启动Broker集群
+#### 启动Broker+Proxy集群
```bash
### 在机器A，启动第一个Master，例如NameServer的IP为：192.168.1.1
@@ -104,7 +113,7 @@ $ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broke
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties &
```
-## 多Master多Slave模式-同步双写
+### 多节点（集群）多副本模式-同步双写
每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：
@@ -112,7 +121,7 @@ $ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broke
- 缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。
-### 启动NameServer
+#### 启动NameServer
```bash
### 首先启动Name Server
@@ -123,7 +132,7 @@ $ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
```
-### 启动Broker集群
+#### 启动 Broker+Proxy 集群
```bash
### 在机器A，启动第一个Master，例如NameServer的IP为：192.168.1.1
diff --git a/docusaurus.config.js b/docusaurus.config.js
index 360e94b5..7ba6e745 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -279,7 +279,7 @@ const darkCodeTheme = require("prism-react-renderer/themes/dracula");
items: [
// { to: "/info", label: "项目信息" },
{ to: "/contact", label: "参与社区" },
- { to: "/origin", label: "创始团队" },
+ { to: "/origin", label: "项目起源" },
{ to: "/team", label: "贡献团队" },
{ to: "/docs/贡献指南/29how-to-contribute", label: "贡献说明" },
// ... more items
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/01-\344\273\213\347\273\215/02quickstart.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/01-\344\273\213\347\273\215/02quickstart.md"
deleted file mode 100644
index f02b6670..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/01-\344\273\213\347\273\215/02quickstart.md"
+++ /dev/null
@@ -1,104 +0,0 @@
-# 快速开始
-
-这一节介绍如何快速部署一个单 Master RocketMQ 集群，并完成简单的消息收发。
-
-:::tip 系统要求
-
-1. 64位操作系统，推荐 Linux/Unix/macOS
-2. 64位 JDK 1.8+
-
-:::
-
-## 1.下载安装Apache RocketMQ
-
-:::tip RocketMQ下载
-
-RocketMQ 的安装包分为两种，二进制包和源码包。点击[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-source-release.zip) 下载 Apache RocketMQ 4.9.4的源码包。你也可以从[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-bin-release.zip) 下载到二进制包。二进制包是已经编译完成后可以直接运行的，源码包是需要编译后运行的，
-
-:::
-
-这里以在Linux环境下利用社区4.9.4的源码包为例，介绍RocketMQ安装过程。
-
-解压4.9.4的源码包并编译构建二进制可执行文件
-
-```shell
- > unzip rocketmq-all-4.9.4-source-release.zip
- > cd rocketmq-all-4.9.4-source-release/
- > mvn -Prelease-all -DskipTests clean install -U
- > cd distribution/target/rocketmq-4.9.4/rocketmq-4.9.4
-```
-## 2. 启动NameServer
-
-安装完RocketMQ包后，我们启动NameServer
-
-```shell
-### 启动namesrv
-$ nohup sh bin/mqnamesrv &
-
-### 验证namesrv是否启动成功
-$ tail -f ~/logs/rocketmqlogs/namesrv.log
-The Name Server boot success...
-```
-
-:::info
-
-我们可以在namesrv.log 中看到 **'The Name Server boot success..'，** 表示NameServer 已成功启动。
-
-:::
-
-
-
-## 3. 启动Broker
-
-NameServer成功启动后，我们启动Broker
-
-```shell
-### 先启动broker
-$ nohup sh bin/mqbroker -n localhost:9876 &
-
-### 验证broker是否启动成功, 比如, broker的ip是192.168.1.2 然后名字是broker-a
-$ tail -f ~/logs/rocketmqlogs/Broker.log
-The broker[broker-a,192.169.1.2:10911] boot success...
-```
-
-:::info
-
-我们可以在 Broker.log 中看到“The broker[brokerName,ip:port] boot success..”，这表明 broker 已成功启动。
-
-:::
-
-:::note
-
-至此，一个单Master的RocketMQ集群已经部署起来了，我们可以利用脚本进行简单的消息收发。
-
-:::
-
-## 4. 消息收发
-
-在进行消息收发之前，我们需要告诉客户端NameServer的地址，RocketMQ有多种方式在客户端中设置NameServer地址，这里我们利用环境变量`NAMESRV_ADDR`
-
-``` shell
- > export NAMESRV_ADDR=localhost:9876
- > sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer
- SendResult [sendStatus=SEND_OK, msgId= ...
-
- > sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer
- ConsumeMessageThread_%d Receive New Messages: [MessageExt...
-```
-
-
-
-## 5. 关闭服务器
-
-完成实验后，我们可以通过以下方式关闭服务
-
-```shell
-> sh bin/mqshutdown broker
-The mqbroker(36695) is running...
-Send shutdown request to mqbroker(36695) OK
-
-> sh bin/mqshutdown namesrv
-The mqnamesrv(36664) is running...
-Send shutdown request to mqnamesrv(36664) OK
-```
-
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/01-\344\273\213\347\273\215/03whatis.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/01-\344\273\213\347\273\215/03whatis.md"
deleted file mode 100644
index b604d59a..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/01-\344\273\213\347\273\215/03whatis.md"
+++ /dev/null
@@ -1,155 +0,0 @@
-# What is RocketMQ
-
-People subscribe to some of their favorites by applications.
-When an author publishes an article to the relevant section, we can receive relevant news feeds.
-
-
-Pub/Sub is a messaging paradigm where message senders(called publishers, producers) send messages directly to specific recipients (called subscribers, consumers). The basic message model of RocketMQ is a simple Pub/Sub model.
-
-import Tabs from '@theme/Tabs';
-
-import TabItem from '@theme/TabItem';
-
-:::tip 相关概念
-
-<Tabs>
- <TabItem value="生产者" label="生产者" default>
- 负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。
-
-更多详见 ➡️ [生产者](/docs/生产者/04concept1)
- </TabItem>
- <TabItem value="消费者" label="消费者">
- 负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。
-
-更多详见 ➡️ [消费者](/docs/消费者/11concept2)
-
- </TabItem>
- <TabItem value="消息主题" label="主题">
- 表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。
-
-更多详见 ➡️ [基本概念](/docs/生产者/04concept1)
-
- </TabItem>
-</Tabs>
-
-:::
-
-
-## RocketMQ的基础消息模型，一个简单的Pub/Sub模型
-
-
-
-
-
-
-
-:::note 基本消息系统模型
-
-上图就是是一个基本的消息系统模型，包括**生产者 (Producer)**，**消费者 (Consumer)**，中间进行基于**消息主题（Topic）**的消息传送。
-
-:::
-
-在**基于主题**的系统中，消息被发布到主题或命名通道上。消费者将收到其订阅的主题上的所有消息，生产者负责定义订阅者所订阅的消息类别。这是一个基础的概念模型，而在实际的应用中，结构会更复杂。例如为了支持高并发和水平扩展，中间的消息主题需要进行分区，同一个Topic会有多个生产者，同一个信息会有多个消费者，消费者之间要进行负载均衡等。
-
-
-
-
-
-## RocketMQ 扩展后的消息模型
-
-
-
-
-
-
-
-:::note 扩展的消息系统模型
-
-上图就是一个扩展后的消息模型，包括**两个生产者**，**两个消息Topic**，以及**两组消费者 Comsumer**。
-
-存储消息Topic的 **代理服务器**( **Broker** )，是实际部署过程的对应的代理服务器。
-
-:::
-
-- 为了**水平扩展**，RocketMQ 对 Topic进行了分区，这种操作被称为**队列**（MessageQueue）。
-
-- 为了**并发消费**，Consumer Group的概念应运而生。
-
-:::info
-
-- Consumer主要有两种消费方式，即**广播模式**，和**集群模式**（图中是最常用的集群模式）。
-- 同一个 Consumer Group 中的 Consumer 实例是负载均衡消费，如图中 ConsumerGroupA 订阅 TopicA，TopicA 对应 3个队列，则 GroupA 中的 Consumer1 消费的是 MessageQueue 0和 MessageQueue 1的消息，Consumer2是消费的是MessageQueue2的消息。
-
-:::
-
-## RocketMQ的部署模型
-
-Producer、Consumer又是如何找到Topic和Broker的地址呢？消息的具体发送和接收又是怎么进行的呢？
-
-
-
-Apache RocketMQ 部署架构上主要分为四部分:
-
-### 生产者 Producer
-
-发布消息的角色。Producer通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败和重试。
-
-### **消费者 Consumer**
-
-消息消费的角色。
-
-- 支持以推（push），拉（pull）两种模式对消息进行消费。
-- 同时也支持**集群方式**和广播方式的消费
-- 提供实时消息订阅机制，可以满足大多数用户的需求。
-
-## 名字服务器 **NameServer**
-
-NameServer是 一个简单的 Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现。
-
-主要包括两个功能：
-
-- **Broker管理**，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
-- **路由信息管理**，每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。
-
-NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息。
-
-## 代理服务器 Broker
-
-Broker主要负责消息的存储、投递和查询以及服务高可用保证。
-
-NameServer几乎无状态节点，因此可集群部署，节点之间无任何信息同步。Broker部署相对复杂。
-
-在 Master-Slave 架构中，Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。
-
-
-
-:::note 部署模型小结
-
-- 每个 **Broker** 与 **NameServer** 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。
-
-- **Producer** 与 **NameServer** 集群中的其中一个节点建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。
-- **Consumer** 与 **NameServer** 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave发送心跳。Consumer 既可以从 Master 订阅消息，也可以从Slave订阅消息。
-
-:::
-
-## RocketMQ集群工作流程
-
-### 1. 启动NameServer
-
-启动NameServer。NameServer启动后监听端口，等待Broker、Producer、Consumer连接，相当于一个路由控制中心。
-
-### 2. 启动 Broker
-
-启动 Broker。与所有 NameServer 保持长连接，定时发送心跳包。心跳包中包含当前 Broker 信息以及存储所有 Topic 信息。注册成功后，NameServer 集群中就有 Topic跟Broker 的映射关系。
-
-### 3. 创建 Topic
-
-创建 Topic 时需要指定该 Topic 要存储在哪些 Broker 上，也可以在发送消息时自动创建Topic。
-
-### 4. 生产者发送消息
-
-生产者发送消息。启动时先跟 NameServer 集群中的其中一台建立长连接，并从 NameServer 中获取当前发送的 Topic存在于哪些 Broker 上，轮询从队列列表中选择一个队列，然后与队列所在的 Broker建立长连接从而向 Broker发消息。
-
-### 5. 消费者接受消息
-
-消费者接受消息。跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，然后开始消费消息。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/01-\344\273\213\347\273\215/01whychoose.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/01whychoose.md"
similarity index 100%
rename from "i18n/en/docusaurus-plugin-content-docs/5.0/01-\344\273\213\347\273\215/01whychoose.md"
rename to "i18n/en/docusaurus-plugin-content-docs/5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/01whychoose.md"
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/02concepts.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/02concepts.md"
new file mode 100644
index 00000000..33d28a3c
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/02concepts.md"
@@ -0,0 +1,79 @@
+# 基本概念
+
+本文介绍 Apache RocketMQ 的基本概念，以便您更好地理解和使用 Apache RocketMQ 。
+
+## 主题（Topic）
+Apache RocketMQ 中消息传输和存储的顶层容器，用于标识同一类业务逻辑的消息。主题通过TopicName来做唯一标识和区分。更多信息，请参见[主题（Topic）](../03-领域模型/02topic.md)。
+
+## 消息类型（MessageType）
+Apache RocketMQ 中按照消息传输特性的不同而定义的分类，用于类型管理和安全校验。 Apache RocketMQ 支持的消息类型有普通消息、顺序消息、事务消息和定时/延时消息。
+
+## 消息队列（MessageQueue）
+队列是 Apache RocketMQ 中消息存储和传输的实际容器，也是消息的最小存储单元。 Apache RocketMQ 的所有主题都是由多个队列组成，以此实现队列数量的水平拆分和队列内部的流式存储。队列通过QueueId来做唯一标识和区分。更多信息，请参见[队列（MessageQueue）](../03-领域模型/03messagequeue.md)。
+
+## 消息（Message）
+消息是 Apache RocketMQ 中的最小数据传输单元。生产者将业务数据的负载和拓展属性包装成消息发送到服务端，服务端按照相关语义将消息投递到消费端进行消费。更多信息，请参见[消息（Message）](../03-领域模型/04message.md)。
+
+## 消息视图（MessageView）
+消息视图是 Apache RocketMQ 面向开发视角提供的一种消息只读接口。通过消息视图可以读取消息内部的多个属性和负载信息，但是不能对消息本身做任何修改。
+
+## 消息标签（MessageTag）
+消息标签是Apache RocketMQ 提供的细粒度消息分类属性，可以在主题层级之下做消息类型的细分。消费者通过订阅特定的标签来实现细粒度过滤。更多信息，请参见[消息过滤](../04-功能行为/07messagefilter.md)。
+
+## 消息位点（MessageQueueOffset）
+消息是按到达Apache RocketMQ 服务端的先后顺序存储在指定主题的多个队列中，每条消息在队列中都有一个唯一的Long类型坐标，这个坐标被定义为消息位点。更多信息，请参见[消费进度管理](../04-功能行为/09consumerprogress.md)。
+
+## 消费位点（ConsumerOffset）
+一条消息被某个消费者消费完成后不会立即从队列中删除，Apache RocketMQ 会基于每个消费者分组记录消费过的最新一条消息的位点，即消费位点。更多信息，请参见[消费进度管理](../04-功能行为/09consumerprogress.md)。
+
+## 消息索引（MessageKey）
+消息索引是Apache RocketMQ 提供的面向消息的索引属性。通过设置的消息索引可以快速查找到对应的消息内容。
+
+## 生产者（Producer）
+生产者是Apache RocketMQ 系统中用来构建并传输消息到服务端的运行实体。生产者通常被集成在业务系统中，将业务消息按照要求封装成消息并发送至服务端。更多信息，请参见[生产者（Producer）](../03-领域模型/04producer.md)。
+
+## 事务检查器（TransactionChecker）
+Apache RocketMQ 中生产者用来执行本地事务检查和异常事务恢复的监听器。事务检查器应该通过业务侧数据的状态来检查和判断事务消息的状态。更多信息，请参见[事务消息](../04-功能行为/04transactionmessage.md)。
+
+## 事务状态（TransactionResolution）
+Apache RocketMQ 中事务消息发送过程中，事务提交的状态标识，服务端通过事务状态控制事务消息是否应该提交和投递。事务状态包括事务提交、事务回滚和事务未决。更多信息，请参见[事务消息](../04-功能行为/04transactionmessage.md)。
+
+## 消费者分组（ConsumerGroup）
+消费者分组是Apache RocketMQ 系统中承载多个消费行为一致的消费者的负载均衡分组。和消费者不同，消费者分组并不是运行实体，而是一个逻辑资源。在 Apache RocketMQ 中，通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾。更多信息，请参见[消费者分组（ConsumerGroup）](../03-领域模型/07consumergroup.md)。
+
+## 消费者（Consumer）
+消费者是Apache RocketMQ 中用来接收并处理消息的运行实体。消费者通常被集成在业务系统中，从服务端获取消息，并将消息转化成业务可理解的信息，供业务逻辑处理。更多信息，请参见[消费者（Consumer）](../03-领域模型/08consumer.md)。
+
+## 消费结果（ConsumeResult）
+Apache RocketMQ 中PushConsumer消费监听器处理消息完成后返回的处理结果，用来标识本次消息是否正确处理。消费结果包含消费成功和消费失败。
+
+## 订阅关系（Subscription）
+订阅关系是Apache RocketMQ 系统中消费者获取消息、处理消息的规则和状态配置。订阅关系由消费者分组动态注册到服务端系统，并在后续的消息传输中按照订阅关系定义的过滤规则进行消息匹配和消费进度维护。更多信息，请参见[订阅关系（Subscription）](../03-领域模型/09subscription.md)。
+
+## 消息过滤
+消费者可以通过订阅指定消息标签（Tag）对消息进行过滤，确保最终只接收被过滤后的消息合集。过滤规则的计算和匹配在Apache RocketMQ
+的服务端完成。更多信息，请参见[消息过滤](../04-功能行为/07messagefilter.md)。
+
+## 重置消费位点
+以时间轴为坐标，在消息持久化存储的时间范围内，重新设置消费者分组对已订阅主题的消费进度，设置完成后消费者将接收设定时间点之后，由生产者发送到Apache RocketMQ 服务端的消息。更多信息，请参见[重置消费位点](../04-功能行为/09consumerprogress.md)。
+
+## 消息轨迹
+在一条消息从生产者发出到消费者接收并处理过程中，由各个相关节点的时间、地点等数据汇聚而成的完整链路信息。通过消息轨迹，您能清晰定位消息从生产者发出，经由Apache RocketMQ 服务端，投递给消费者的完整链路，方便定位排查问题。
+
+## 消息堆积
+生产者已经将消息发送到Apache RocketMQ 的服务端，但由于消费者的消费能力有限，未能在短时间内将所有消息正确消费掉，此时在服务端保存着未被消费的消息，该状态即消息堆积。
+
+
+
+## 事务消息
+事务消息是Apache RocketMQ 提供的一种高级消息类型，支持在分布式场景下保障消息生产和本地事务的最终一致性。
+
+
+
+## 定时/延时消息
+定时/延时消息是Apache RocketMQ 提供的一种高级消息类型，消息被发送至服务端后，在指定时间后才能被消费者消费。通过设置一定的定时时间可以实现分布式场景的延时调度触发效果。
+
+
+## 顺序消息
+顺序消息是Apache RocketMQ 提供的一种高级消息类型，支持消费者按照发送消息的先后顺序获取消息，从而实现业务场景中的顺序处理。
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/03limits.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/03limits.md"
new file mode 100644
index 00000000..05b1f03e
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/03limits.md"
@@ -0,0 +1,24 @@
+# 参数约束和建议
+
+Apache RocketMQ 系统中存在很多自定义参数和资源命名，您在使用 Apache RocketMQ 时建议参考如下说明规范系统设置，避对某些具体参数设置不合理导致应用出现异常。
+
+
+| 参数 | [...]
+|-----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [...]
+| Topic名称 | 字符建议：字母a\~z或A\~Z、数字0\~9以及下划线（_）、短划线（-）和百分号（%）。 <br></br> 长度建议：1\~64个字符。 <br></br> 系统保留字符：Topic名称不允许使用以下保留字符或含有特殊前缀的字符命名。 <br></br> 保留字符: TBW102 * BenchmarkTest * SELF_TEST_TOPIC * OFFSET_MOVED_EVENT * SCHEDULE_TOPIC_XXXX * RMQ_SYS_TRANS_HALF_TOPIC * RMQ_SYS_TRACE_TOPIC * RMQ_SYS_TRANS_OP_HALF_TOPIC <br></br> 特殊前缀: * rmq_sys_ %RETRY%_ %DLQ%_ rocketmq-broker- [...]
+| ConsumerGroup名称 | 字符建议：支持字母a\~z或A\~Z、数字0\~9以及下划线（_）、短划线（-）和百分号（%）。 <br></br> 长度建议：1\~64个字符。 <br></br> 系统保留字符：ConsumerGroup不允许使用以下保留字符或含有特殊前缀的字符命名。 <br></br> 保留字符: * DEFAULT_CONSUMER * DEFAULT_PRODUCER * TOOLS_CONSUMER * FILTERSRV_CONSUMER * __MONITOR_CONSUMER * CLIENT_INNER_PRODUCER * SELF_TEST_P_GROUP * SELF_TEST_C_GROUP * CID_ONS-HTTP-PROXY * CID_ONSAPI_PERMISSION * CID_ONSAPI_OWNER * CID_ONSAPI_PULL * CID_RMQ_SYS_TRANS * 特殊字符 * CID_RMQ_SYS_ * CID_HOUSEKEEPIN [...]
+| ACL Credentials | 字符建议：AK（AccessKey ID）、SK（AccessKey Secret）和Token仅支持字母a\~z或A\~Z、数字0\~9。 <br></br> 长度建议：不超过1024个字符。 [...]
+| 请求超时时间 | 默认值：3000毫秒。 <br></br> 取值范围：该参数为客户端本地行为，取值范围建议不要超过30000毫秒。 [...]
+| 消息大小 | 默认值：不超过4 MB。不涉及消息压缩，仅计算消息体body的大小。 <br></br>取值范围：建议不超过4 MB。 [...]
+| 消息自定义属性 | 字符限制：所有可见字符。 <br></br>长度建议：属性的Key和Value总长度不超过16 KB。 <br></br>系统保留属性：不允许使用以下保留属性作为自定义属性的Key。 保留属性Key [...]
+| MessageGroup | 字符限制：所有可见字符。 <br></br>长度建议：1\~64字节。 [...]
+| 消息发送重试次数 | 默认值：3次。 <br></br>取值范围：无限制。 [...]
+| 消息消费重试次数 | 默认值：16次。 [...]
+| 事务异常检查间隔 | 默认值：60秒。 [...]
+| 半事务消息第一次回查时间 | 默认值：取值等于\[事务异常检查间隔\] * 最大限制：不超过1小时。 [...]
+| 半事务消息最大超时时长 | 默认值：4小时。 * 取值范围：不支持自定义修改。 [...]
+| PushConsumer本地缓存 |默认值： <br></br> * 最大缓存数量：1024条。 <br></br>* 最大缓存大小：64 M。 <br></br>取值范围：支持用户自定义设置，无限制。 [...]
+| PushConsumer重试间隔时长 | 默认值： <br></br>* 非顺序性投递：间隔时间阶梯变化，具体取值，请参见PushConsumer消费重试策略。 <br></br>* 顺序性投递：3000毫秒。 [...]
+| PushConsumer消费并发度 | 默认值：20个线程。 [...]
+| 获取消息最大批次 | 默认值：32条。 [...]
+| SimpleConsumer最大不可见时间 | 默认值：用户必填参数，无默认值。 <br></br> 取值范围建议：最小10秒；最大12小时。 [...]
\ No newline at end of file
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\345\277\253\351\200\237\345\205\245\351\227\250/02quickstart.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/02-\345\277\253\351\200\237\345\205\245\351\227\250/02quickstart.md"
new file mode 100644
index 00000000..aec64d19
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/02-\345\277\253\351\200\237\345\205\245\351\227\250/02quickstart.md"
@@ -0,0 +1,224 @@
+# 快速开始
+
+这一节介绍如何快速部署一个单节点单副本 RocketMQ 服务，并完成简单的消息收发。
+
+:::tip 系统要求
+
+1. 64位操作系统，推荐 Linux/Unix/macOS
+2. 64位 JDK 1.8+
+
+:::
+
+## 1.下载安装Apache RocketMQ
+
+:::tip RocketMQ下载
+
+RocketMQ 的安装包分为两种，二进制包和源码包。 点击[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-source-release.zip) 下载 Apache RocketMQ 4.9.4的源码包。你也可以从[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-bin-release.zip) 下载到二进制包。二进制包是已经编译完成后可以直接运行的，源码包是需要编译后运行的，
+
+:::
+
+这里以在Linux环境下利用社区5.0.0的源码包为例，介绍RocketMQ安装过程。
+
+解压4.9.4的源码包并编译构建二进制可执行文件
+
+```shell
+ > unzip rocketmq-all-5.0.0-source-release.zip
+ > cd rocketmq-all-5.0.0-source-release/
+ > mvn -Prelease-all -DskipTests clean install -U
+ > cd distribution/target/rocketmq-5.0.0/rocketmq-5.0.0
+```
+## 2. 启动NameServer
+
+安装完RocketMQ包后，我们启动NameServer
+
+```shell
+### 启动namesrv
+$ nohup sh bin/mqnamesrv &
+
+### 验证namesrv是否启动成功
+$ tail -f ~/logs/rocketmqlogs/namesrv.log
+The Name Server boot success...
+```
+
+:::info
+
+我们可以在namesrv.log 中看到 **'The Name Server boot success..'，** 表示NameServer 已成功启动。
+
+:::
+
+
+
+## 3. 启动Broker+Proxy
+
+NameServer成功启动后，我们启动Broker和Proxy，5.x 版本下我们建议使用 Local 模式部署，即 Broker 和 Proxy 同进程部署。5.x 版本也支持 Broker 和 Proxy 分离部署以实现更灵活的集群能力。详情参考[部署教程](../05-部署运维/15deploy.md)。
+
+```shell
+### 先启动broker
+$ nohup sh bin/mqbroker -n localhost:9876 &
+
+### 验证broker是否启动成功, 比如, broker的ip是192.168.1.2 然后名字是broker-a
+$ tail -f ~/logs/rocketmqlogs/Broker.log
+The broker[broker-a,192.169.1.2:10911] boot success...
+```
+
+:::info
+
+我们可以在 Broker.log 中看到“The broker[brokerName,ip:port] boot success..”，这表明 broker 已成功启动。
+
+:::
+
+:::note
+
+至此，一个单节点副本的 RocketMQ 集群已经部署起来了，我们可以利用脚本进行简单的消息收发。
+
+:::
+
+## 4. 工具测试消息收发
+
+在进行工具测试消息收发之前，我们需要告诉客户端NameServer的地址，RocketMQ有多种方式在客户端中设置NameServer地址，这里我们利用环境变量`NAMESRV_ADDR`
+
+``` shell
+ > export NAMESRV_ADDR=localhost:9876
+ > sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer
+ SendResult [sendStatus=SEND_OK, msgId= ...
+
+ > sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer
+ ConsumeMessageThread_%d Receive New Messages: [MessageExt...
+```
+
+## 5. SDK测试消息收发
+
+工具测试完成后，我们可以尝试使用 SDK 收发消息。这里以 Java SDK 为例介绍一下消息收发过程。
+
+1. 在IDEA中创建一个Java工程。
+
+2. 在 *pom.xml* 文件中添加以下依赖引入Java依赖库。
+
+ ```xml
+ <dependency>
+ <groupId>org.apache.rocketmq</groupId>
+ <artifactId>rocketmq-client-java</artifactId>
+ <version>5.0.0</version>
+ </dependency>
+ ```
+
+3. 在已创建的Java工程中，创建发送普通消息程序并运行，示例代码如下：
+
+```java
+import org.apache.rocketmq.client.apis.*;
+import org.apache.rocketmq.client.apis.consumer.ConsumeResult;
+import org.apache.rocketmq.client.apis.consumer.MessageListener;
+import org.apache.rocketmq.client.apis.consumer.SimpleConsumer;
+import org.apache.rocketmq.client.apis.message.Message;
+import org.apache.rocketmq.client.apis.message.MessageBuilder;
+import org.apache.rocketmq.client.apis.message.MessageView;
+import org.apache.rocketmq.client.apis.producer.Producer;
+import org.apache.rocketmq.client.apis.producer.SendReceipt;
+import java.time.Duration;
+import java.util.List;
+public class ProducerExample {
+ public static void main(String[] args) throws ClientException {
+ //接入点地址，需要设置成Proxy的地址和端口列表，一般是xxx:8081;xxx:8081。
+ String endpoint = "localhost:8081";
+ //消息发送的目标Topic名称，需要提前创建。
+ String topic = "Your Topic";
+ ClientServiceProvider provider = ClientServiceProvider.loadService();
+ ClientConfigurationBuilder builder = ClientConfiguration.newBuilder().setEndpoints(endpoint);
+ ClientConfiguration configuration = builder.build();
+ //初始化Producer时需要设置通信配置以及预绑定的Topic。
+ Producer producer = provider.newProducerBuilder()
+ .setTopics(topic)
+ .setClientConfiguration(configuration)
+ .build();
+ //普通消息发送。
+ Message message = provider.newMessageBuilder()
+ .setTopic(topic)
+ //设置消息索引键，可根据关键字精确查找某条消息。
+ .setKeys("messageKey")
+ //设置消息Tag，用于消费端根据指定Tag过滤消息。
+ .setTag("messageTag")
+ //消息体。
+ .setBody("messageBody".getBytes())
+ .build();
+ try {
+ //发送消息，需要关注发送结果，并捕获失败等异常。
+ SendReceipt sendReceipt = producer.send(message);
+ System.out.println(sendReceipt.getMessageId());
+ } catch (ClientException e) {
+ e.printStackTrace();
+ }
+ }
+}
+```
+
+
+4. 在已创建的Java工程中，创建订阅普通消息程序并运行。Apache RocketMQ 支持[SimpleConsumer](../04-功能行为/06consumertype.md)和[PushConsumer](../04-功能行为/06consumertype.md)两种消费者类型，您可以选择以下任意一种方式订阅消息。
+
+```java
+import org.apache.rocketmq.client.apis.*;
+import org.apache.rocketmq.client.apis.consumer.ConsumeResult;
+import org.apache.rocketmq.client.apis.consumer.FilterExpression;
+import org.apache.rocketmq.client.apis.consumer.FilterExpressionType;
+import org.apache.rocketmq.client.apis.consumer.PushConsumer;
+
+import java.io.IOException;
+import java.util.Collections;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+public class PushConsumerExample {
+ private static final Logger LOGGER = LoggerFactory.getLogger(PushConsumerExample.class);
+
+ private PushConsumerExample() {
+ }
+
+ public static void main(String[] args) throws ClientException, IOException, InterruptedException {
+ final ClientServiceProvider provider = ClientServiceProvider.loadService();
+ //接入点地址，需要设置成Proxy的地址和端口列表，一般是xxx:8081;xxx:8081。
+ String endpoints = "localhost:8081";
+ ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
+ .setEndpoints(endpoints)
+ .build();
+ //订阅消息的过滤规则，表示订阅所有Tag的消息。
+ String tag = "*";
+ FilterExpression filterExpression = new FilterExpression(tag, FilterExpressionType.TAG);
+ //为消费者指定所属的消费者分组，Group需要提前创建。
+ String consumerGroup = "Your ConsumerGroup";
+ //指定需要订阅哪个目标Topic，Topic需要提前创建。
+ String topic = "Your Topic";
+ //初始化PushConsumer，需要绑定消费者分组ConsumerGroup、通信参数以及订阅关系。
+ PushConsumer pushConsumer = provider.newPushConsumerBuilder()
+ .setClientConfiguration(clientConfiguration)
+ //设置消费者分组。
+ .setConsumerGroup(consumerGroup)
+ //设置预绑定的订阅关系。
+ .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
+ //设置消费监听器。
+ .setMessageListener(messageView -> {
+ //处理消息并返回消费结果。
+ // LOGGER.info("Consume message={}", messageView);
+ System.out.println("Consume message!!");
+ return ConsumeResult.SUCCESS;
+ })
+ .build();
+ Thread.sleep(Long.MAX_VALUE);
+ //如果不需要再使用PushConsumer，可关闭该进程。
+ //pushConsumer.close();
+ }
+}
+```
+
+## 6. 关闭服务器
+
+完成实验后，我们可以通过以下方式关闭服务
+
+```shell
+> sh bin/mqshutdown broker
+The mqbroker(36695) is running...
+Send shutdown request to mqbroker(36695) OK
+
+> sh bin/mqshutdown namesrv
+The mqnamesrv(36664) is running...
+Send shutdown request to mqnamesrv(36664) OK
+```
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/04concept1.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/04concept1.md"
deleted file mode 100644
index 1bb5f75c..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/04concept1.md"
+++ /dev/null
@@ -1,87 +0,0 @@
-# 基本概念
-
-在生产者一章的基本概念包括**消息，Tag，Keys，队列和生产者**的介绍。
-
-## 消息
-
-RocketMQ 消息构成非常简单，如下图所示。
-
-- **topic**，表示要发送的消息的主题。
-- **body** 表示消息的存储内容
-- **properties** 表示消息属性
-- **transactionId** 会在事务消息中使用。
-
-:::tip
-- Tag: 不管是 RocketMQ 的 Tag 过滤还是延迟消息等都会利用 Properties 消息属性的能力
-
-- Keys: 服务器会根据 keys 创建哈希索引，设置后，可以在 Console 系统根据 Topic、Keys 来查询消息，由于是哈希索引，请尽可能保证 key 唯一，例如订单号，商品 Id 等。
-:::
-
-<center>
-<img src="../picture/Message.png" width="500"></img>
-</center>
-
-Message 可以设置的属性值包括：
-
-
-| 字段名 | 默认值 | 必要性 | 说明 |
-| :------------: | -------- | ------------- | ------------- |
-| Topic | null | 必填 | 消息所属 topic 的名称 |
-| Body | null | 必填 | 消息体 |
-| Tags | null | 选填 | 消息标签，方便服务器过滤使用。目前只支持每个消息设置一个 |
-| Keys | null | 选填 | 代表这条消息的业务关键词 |
-| Flag | 0 | 选填 | 完全由应用来设置，RocketMQ 不做干预 |
-| DelayTimeLevel | 0 | 选填 | 消息延时级别，0 表示不延时，大于 0 会延时特定的时间才会被消费 |
-| WaitStoreMsgOK | true | 选填 | 表示消息是否在服务器落盘后才返回应答。 |
-
-## Tag
-
-Topic 与 Tag 都是业务上用来归类的标识，区别在于 Topic 是一级分类，而 Tag 可以理解为是二级分类。使用 Tag 可以实现对 Topic 中的消息进行过滤。
-
-:::tip
-- Topic：消息主题，通过 Topic 对不同的业务消息进行分类。
-- Tag：消息标签，用来进一步区分某个 Topic 下的消息分类，消息从生产者发出即带上的属性。
-:::
-
-
-
-
-Topic 和 Tag 的关系如下图所示。
-
-
-
-### 什么时候该用 Topic，什么时候该用 Tag？
-
-可以从以下几个方面进行判断：
-
-- 消息类型是否一致：如普通消息、事务消息、定时（延时）消息、顺序消息，不同的消息类型使用不同的 Topic，无法通过 Tag 进行区分。
-
-- 业务是否相关联：没有直接关联的消息，如淘宝交易消息，京东物流消息使用不同的 Topic 进行区分；而同样是天猫交易消息，电器类订单、女装类订单、化妆品类订单的消息可以用 Tag 进行区分。
-
-- 消息优先级是否一致：如同样是物流消息，盒马必须小时内送达，天猫超市 24 小时内送达，淘宝物流则相对会慢一些，不同优先级的消息用不同的 Topic 进行区分。
-
-- 消息量级是否相当：有些业务消息虽然量小但是实时性要求高，如果跟某些万亿量级的消息使用同一个 Topic，则有可能会因为过长的等待时间而“饿死”，此时需要将不同量级的消息进行拆分，使用不同的 Topic。
-
-总的来说，针对消息分类，您可以选择创建多个 Topic，或者在同一个 Topic 下创建多个 Tag。但通常情况下，不同的 Topic 之间的消息没有必然的联系，而 Tag 则用来区分同一个 Topic 下相互关联的消息，例如全集和子集的关系、流程先后的关系。
-
-## Keys
-
-Apache RocketMQ 每个消息可以在业务层面的设置唯一标识码 keys 字段，方便将来定位消息丢失问题。 Broker 端会为每个消息创建索引（哈希索引），应用可以通过 topic、key 来查询这条消息内容，以及消息被谁消费。由于是哈希索引，请务必保证 key 尽可能唯一，这样可以避免潜在的哈希冲突。
-
-```java
- // 订单Id
- String orderId = "20034568923546";
- message.setKeys(orderId);
-```
-
-## 队列
-
-为了支持高并发和水平扩展，需要对 Topic 进行分区，在 RocketMQ 中这被称为队列，一个 Topic 可能有多个队列，并且可能分布在不同的 Broker 上。
-
-
-
-一般来说一条消息，如果没有重复发送（比如因为服务端没有响应而进行重试），则只会存在在 Topic 的其中一个队列中，消息在队列中按照先进先出的原则存储，每条消息会有自己的位点，每个队列会统计当前消息的总条数，这个称为最大位点 MaxOffset；队列的起始位置对应的位置叫做起始位点 MinOffset。队列可以提升消息发送和消费的并发度。
-
-## 生产者
-
-生产者（Producer）就是消息的发送者，Apache RocketMQ 拥有丰富的消息类型，可以支持不用的应用场景，在不同的场景中，需要使用不同的消息进行发送。比如在电商交易中超时未支付关闭订单的场景，在订单创建时会发送一条延时消息。这条消息将会在 30 分钟以后投递给消费者，消费者收到此消息后需要判断对应的订单是否已完成支付。如支付未完成，则关闭订单。如已完成支付则忽略，此时就需要用到延迟消息；电商场景中，业务上要求同一订单的消息保持严格顺序，此时就要用到顺序消息。在日志处理场景中，可以接受的比较大的发送延迟，但对吞吐量的要求很高，希望每秒能处理百万条日志，此时可以使用批量消息。在银行扣款的场景中，要保持上游的扣款操作和下游的短信通知保持一致，此时就要使用事务消息，下一节将会介绍各种类型
消息的发送。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/05message1.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/05message1.md"
deleted file mode 100644
index 336e1010..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/05message1.md"
+++ /dev/null
@@ -1,178 +0,0 @@
-# 普通消息发送
-
-## 1.向集群中创建 Topic
-
-RocketMQ集群是默认开启了 **autoCreateTopicEnable** 配置，会自动为发送的消息创建 Topic，如果 autoCreateTopicEnable 没有开启，也可以利用 RocketMQ Admin 工具创建目标 Topic 。
-
-```shell
-> sh bin/mqadmin updateTopic -c DefaultCluster -t TopicTest -n 127.0.0.1:9876
-create topic to 127.0.0.1:10911 success.
-TopicConfig [topicName=TopicTest, readQueueNums=8, writeQueueNums=8, perm=RW-, topicFilterType=SINGLE_TAG, topicSysFlag=0, order=false, attributes=null]
-```
-
-可以看到在执行完命令后，在该台Broker机器上创建了8个队列，名为TopicTest的Topic。
-
-## 2.添加客户端依赖
-
-首先需要在 JAVA 程序中添加 RocketMQ 的客户端依赖。
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-<Tabs>
-<TabItem value="Maven" label="Maven" default >
-
-```java
-<dependency>
- <groupId>org.apache.rocketmq</groupId>
- <artifactId>rocketmq-client</artifactId>
- <version>4.9.4</version>
-</dependency>
-```
-</TabItem>
-<TabItem value="Gradle" label="Gradle">
-
-```java
-compile 'org.apache.rocketmq:rocketmq-client:4.9.4'
-```
-
-</TabItem>
-
-</Tabs>
-
-
-## 3.消息发送
-
-Apache RocketMQ可用于以三种方式发送消息：**同步、异步和单向传输**。前两种消息类型是可靠的，因为无论它们是否成功发送都有响应。
-
-### 3.1 同步发送
-
-同步发送是指消息发送方发出一条消息后，会在收到服务端同步响应之后才发下一条消息的通讯方式，可靠的同步传输被广泛应用于各种场景，如重要的通知消息、短消息通知等。
-
-
-<center>
-<img src="../picture/同步发送.png" width="500"></img>
-</center>
-
-同步发送的整个代码流程如下：
-1. **首先会创建一个producer**。普通消息可以创建 DefaultMQProducer，创建时需要填写生产组的名称，生产者组是指同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。
-2. **设置 NameServer 的地址**。Apache RocketMQ很多方式设置NameServer地址(客户端配置中有介绍)，这里是在代码中调用producer的API setNamesrvAddr进行设置，如果有多个NameServer，中间以分号隔开，比如"127.0.0.2:9876;127.0.0.3:9876"。
-3. **第三步是构建消息**。指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤。
-4. **最后调用send接口将消息发送出去**。同步发送等待结果最后返回SendResult，SendResut包含实际发送状态还包括SEND_OK（发送成功）, FLUSH_DISK_TIMEOUT（刷盘超时）, FLUSH_SLAVE_TIMEOUT（同步到备超时）, SLAVE_NOT_AVAILABLE（备不可用），如果发送失败会抛出异常。
-``` javascript {16,15}
-public class SyncProducer {
- public static void main(String[] args) throws Exception {
- // 初始化一个producer并设置Producer group name
- DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name"); //（1）
- // 设置NameServer地址
- producer.setNamesrvAddr("localhost:9876"); //（2）
- // 启动producer
- producer.start();
- for (int i = 0; i < 100; i++) {
- // 创建一条消息，并指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤
- Message msg = new Message("TopicTest" /* Topic */,
- "TagA" /* Tag */,
- ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
- ); //（3）
- // 利用producer进行发送，并同步等待发送结果
- SendResult sendResult = producer.send(msg); //（4）
- System.out.printf("%s%n", sendResult);
- }
- // 一旦producer不再使用，关闭producer
- producer.shutdown();
- }
-}
-```
-
-
-
-### 3.2 异步发送
-
-<center>
-<img src="../picture/异步发送.png" width="500"></img>
-</center>
-
-
-异步发送是指发送方发出一条消息后，不等服务端返回响应，接着发送下一条消息的通讯方式。异步发送需要实现**异步发送回调接口**（SendCallback）。
-:::note
-异步发送需要实现**异步发送回调接口**（SendCallback）。
-:::
-消息发送方在发送了一条消息后，不需要等待服务端响应即可发送第二条消息，发送方通过回调接口接收服务端响应，并处理响应结果。异步发送一般用于链路耗时较长，对响应时间较为敏感的业务场景。例如，视频上传后通知启动转码服务，转码完成后通知推送转码结果等。
-
-如下是示例代码。
-
-``` javascript {16,17}
-public class AsyncProducer {
- public static void main(String[] args) throws Exception {
- // 初始化一个producer并设置Producer group name
- DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
- // 设置NameServer地址
- producer.setNamesrvAddr("localhost:9876");
- // 启动producer
- producer.start();
- producer.setRetryTimesWhenSendAsyncFailed(0);
- for (int i = 0; i < 100; i++) {
- final int index = i;
- // 创建一条消息，并指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤
- Message msg = new Message("TopicTest",
- "TagA",
- "Hello world".getBytes(RemotingHelper.DEFAULT_CHARSET));
- // 异步发送消息, 发送结果通过callback返回给客户端
- producer.send(msg, new SendCallback() {
- @Override
- public void onSuccess(SendResult sendResult) {
- System.out.printf("%-10d OK %s %n", index,
- sendResult.getMsgId());
- }
- @Override
- public void onException(Throwable e) {
- System.out.printf("%-10d Exception %s %n", index, e);
- e.printStackTrace();
- }
- });
- }
- // 一旦producer不再使用，关闭producer
- producer.shutdown();
- }
-}
-```
-
-:::note
-异步发送与同步发送代码唯一区别在于调用send接口的参数不同，异步发送不会等待发送返回，取而代之的是send方法需要传入 SendCallback 的实现，SendCallback 接口主要有onSuccess 和 onException 两个方法，表示消息发送成功和消息发送失败。
-:::
-
-### 3.3 单向模式发送
-
-<center>
-<img src="../picture/Oneway发送.png" width="500"></img>
-</center>
-
-
-
-发送方只负责发送消息，不等待服务端返回响应且没有回调函数触发，即只发送请求不等待应答。此方式发送消息的过程耗时非常短，一般在微秒级别。适用于某些耗时非常短，但对可靠性要求并不高的场景，例如日志收集。
-
-``` javascript {16}
-public class OnewayProducer {
- public static void main(String[] args) throws Exception{
- // 初始化一个producer并设置Producer group name
- DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
- // 设置NameServer地址
- producer.setNamesrvAddr("localhost:9876");
- // 启动producer
- producer.start();
- for (int i = 0; i < 100; i++) {
- // 创建一条消息，并指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤
- Message msg = new Message("TopicTest" /* Topic */,
- "TagA" /* Tag */,
- ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
- );
- // 由于在oneway方式发送消息时没有请求应答处理，如果出现消息发送失败，则会因为没有重试而导致数据丢失。若数据不可丢，建议选用可靠同步或可靠异步发送方式。
- producer.sendOneway(msg);
- }
- // 一旦producer不再使用，关闭producer
- producer.shutdown();
- }
-}
-```
-
-单向模式调用sendOneway，不会对返回结果有任何等待和处理。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/06message2.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/06message2.md"
deleted file mode 100644
index a89b26bc..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/06message2.md"
+++ /dev/null
@@ -1,76 +0,0 @@
-# 顺序消息发送
-
-## 顺序消息介绍
-顺序消息是一种对消息发送和消费顺序有严格要求的消息。
-
-对于一个指定的Topic，消息严格按照先进先出（FIFO）的原则进行消息发布和消费，即先发布的消息先消费，后发布的消息后消费。在 Apache RocketMQ 中支持分区顺序消息，如下图所示。我们可以按照某一个标准对消息进行分区（比如图中的ShardingKey），同一个ShardingKey的消息会被分配到同一个队列中，并按照顺序被消费。
-
-
-
-顺序消息的应用场景也非常广泛，比如在创建订单的例子中，需要保证同一个订单的生成、付款和发货，这三个操作被顺序执行。如果是普通消息，订单A的消息可能会被轮询发送到不同的队列中，不同队列的消息将无法保持顺序，而顺序消息发送时将ShardingKey相同（同一订单号）的消息序路由到一个逻辑队列中。
-
-## 顺序消息示例代码
-
-顺序消息的代码如下所示：
-
-```jsx {13}
-public class Producer {
- public static void main(String[] args) throws UnsupportedEncodingException {
- try {
- DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
- producer.start();
-
- String[] tags = new String[] {"TagA", "TagB", "TagC", "TagD", "TagE"};
- for (int i = 0; i < 100; i++) {
- int orderId = i % 10;
- Message msg =
- new Message("TopicTest", tags[i % tags.length], "KEY" + i,
- ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET));
- SendResult sendResult = producer.send(msg, new MessageQueueSelector() {
- @Override
- public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
- Integer id = (Integer) arg;
- int index = id % mqs.size();
- return mqs.get(index);
- }
- }, orderId);
-
- System.out.printf("%s%n", sendResult);
- }
-
- producer.shutdown();
- } catch (MQClientException | RemotingException | MQBrokerException | InterruptedException e) {
- e.printStackTrace();
- }
- }
-}
-```
-
-这里的区别主要是调用了```SendResult send(Message msg, MessageQueueSelector selector, Object arg)```方法，MessageQueueSelector 是队列选择器，arg 是一个 Java Object 对象，可以传入作为消息发送分区的分类标准。
-
-:::tip
-MessageQueueSelector的接口如下：
-
-```jsx
-public interface MessageQueueSelector {
- MessageQueue select(final List<MessageQueue> mqs, final Message msg, final Object arg);
-}
-```
-
-其中 mqs 是可以发送的队列，msg是消息，arg是上述send接口中传入的Object对象，返回的是该消息需要发送到的队列。上述例子里，是以orderId作为分区分类标准，对所有队列个数取余，来对将相同orderId的消息发送到同一个队列中。
-:::
-
-
-## 顺序消息的一致性
-
-如果一个Broker掉线，那么此时队列总数是否会发化？
-
-如果发生变化，那么同一个 ShardingKey 的消息就会发送到不同的队列上，造成乱序。如果不发生变化，那消息将会发送到掉线Broker的队列上，必然是失败的。因此 Apache RocketMQ 提供了两种模式，如果要保证严格顺序而不是可用性，创建 Topic 是要指定 ```-o``` 参数（--order）为true，表示顺序消息:
-
-```shell {1}
-> sh bin/mqadmin updateTopic -c DefaultCluster -t TopicTest -o true -n 127.0.0.1:9876
-create topic to 127.0.0.1:10911 success.
-TopicConfig [topicName=TopicTest, readQueueNums=8, writeQueueNums=8, perm=RW-, topicFilterType=SINGLE_TAG, topicSysFlag=0, order=true, attributes=null]
-```
-
-其次要保证NameServer中的配置 ```orderMessageEnable``` 和 ```returnOrderTopicConfigToBroker``` 必须是 true。如果上述任意一个条件不满足，则是保证可用性而不是严格顺序。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/07message3.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/07message3.md"
deleted file mode 100644
index 0daf28dd..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/07message3.md"
+++ /dev/null
@@ -1,45 +0,0 @@
-# 延迟消息发送
-
-延时消息是指消息发送到Apache RocketMQ后，并不期望立马投递这条消息，而是延迟一定时间后才投递到Consumer进行消费。
-
-Apache RocketMQ 一共支持18个等级的延迟投递，具体时间如下：
-
-| 投递等级（delay level） | 延迟时间 | 投递等级（delay level） | 延迟时间 |
-|-------------------|------|-------------------|-------|
-| 1 | 1s | 10 | 6min |
-| 2 | 5s | 11 | 7min |
-| 3 | 10s | 12 | 8min |
-| 4 | 30s | 13 | 9min |
-| 5 | 1min | 14 | 10min |
-| 6 | 2min | 15 | 20min |
-| 7 | 3min | 16 | 30min |
-| 8 | 4min | 17 | 1h |
-| 9 | 5min | 18 | 2h |
-
-延迟消息的示例代码如下：
-
-```javascript {10,11}
-public class ScheduledMessageProducer {
- public static void main(String[] args) throws Exception {
- // Instantiate a producer to send scheduled messages
- DefaultMQProducer producer = new DefaultMQProducer("ExampleProducerGroup");
- // Launch producer
- producer.start();
- int totalMessagesToSend = 100;
- for (int i = 0; i < totalMessagesToSend; i++) {
- Message message = new Message("TestTopic", ("Hello scheduled message " + i).getBytes());
- // This message will be delivered to consumer 10 seconds later.
- message.setDelayTimeLevel(3);
- // Send the message
- producer.send(message);
- }
-
- // Shutdown producer after use.
- producer.shutdown();
- }
-
-}
-```
-:::tip
-这里最重要的是message中设置延迟等级，例子中设置的等级是3，也就是发送者发送后，10s后消费者才能收到消息。
-:::
\ No newline at end of file
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/08message4.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/08message4.md"
deleted file mode 100644
index 04892f74..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/08message4.md"
+++ /dev/null
@@ -1,29 +0,0 @@
-# 批量消息发送
-
-在对吞吐率有一定要求的情况下，Apache RocketMQ可以将一些消息聚成一批以后进行发送，可以增加吞吐率，并减少API和网络调用次数。
-
-
-
-```javascript {10,11,12,13}
-public class SimpleBatchProducer {
-
- public static void main(String[] args) throws Exception {
- DefaultMQProducer producer = new DefaultMQProducer("BatchProducerGroupName");
- producer.start();
-
- //If you just send messages of no more than 1MiB at a time, it is easy to use batch
- //Messages of the same batch should have: same topic, same waitStoreMsgOK and no schedule support
- String topic = "BatchTest";
- List<Message> messages = new ArrayList<>();
- messages.add(new Message(topic, "Tag", "OrderID001", "Hello world 0".getBytes()));
- messages.add(new Message(topic, "Tag", "OrderID002", "Hello world 1".getBytes()));
- messages.add(new Message(topic, "Tag", "OrderID003", "Hello world 2".getBytes()));
-
- producer.send(messages);
- }
-}
-```
-
-:::note
-这里调用非常简单，将消息打包成 Collection`<Message>` msgs传入方法中即可，需要注意的是批量消息的大小不能超过 1MiB（否则需要自行分割），其次同一批 batch 中 topic 必须相同。
-:::
\ No newline at end of file
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/09message5.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/09message5.md"
deleted file mode 100644
index e85ce461..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/02-\347\224\237\344\272\247\350\200\205/09message5.md"
+++ /dev/null
@@ -1,149 +0,0 @@
-# 事务消息发送
-
-## 事务消息介绍
-
-在一些对数据一致性有强需求的场景，可以用 Apache RocketMQ 事务消息来解决，从而保证上下游数据的一致性。
-
-
-
-事务消息发送分为两个阶段。第一阶段会发送一个**半事务消息**，半事务消息是指暂不能投递的消息，生产者已经成功地将消息发送到了 Broker，但是Broker 未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，如果发送成功则执行本地事务，并根据本地事务执行成功与否，向 Broker 半事务消息状态（commit或者rollback），半事务消息只有 commit 状态才会真正向下游投递。如果由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，Broker 端会通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit或是Rollback）。这样最终保证了本地事务执行成功，下游就能收到消息，本地事务执行失败，下游就收不到消息。总而保证了上下游数据的一致性。
-
-整个事务消息的详细交互流程如下图所示：
-
-
-
-## 事务消息步骤
-
-事务消息**发送**步骤如下：
-
-1. 生产者将半事务消息发送至 `RocketMQ Broker`。
-2. `RocketMQ Broker` 将消息持久化成功之后，向生产者返回 Ack 确认消息已经发送成功，此时消息为半事务消息。
-3. 生产者开始执行本地事务逻辑。
-4. 生产者根据本地事务执行结果向服务端提交二次确认结果（Commit或是Rollback），服务端收到确认结果后处理逻辑如下：
-- 二次确认结果为Commit：服务端将半事务消息标记为可投递，并投递给消费者。
-- 二次确认结果为Rollback：服务端将回滚事务，不会将半事务消息投递给消费者。
-5. 在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为Unknown未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。
-
-事务消息**回查**步骤如下：
-1. 生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
-2. 生产者根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行处理。
-
-## 示例代码
-
-示例代码如下：
-
-```javascript {39}
-public class TransactionProducer {
- public static void main(String[] args) throws MQClientException, InterruptedException {
- TransactionListener transactionListener = new TransactionListenerImpl();
- TransactionMQProducer producer = new TransactionMQProducer("please_rename_unique_group_name");
- ExecutorService executorService = new ThreadPoolExecutor(2, 5, 100, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(2000), new ThreadFactory() {
- @Override
- public Thread newThread(Runnable r) {
- Thread thread = new Thread(r);
- thread.setName("client-transaction-msg-check-thread");
- return thread;
- }
- });
-
- producer.setExecutorService(executorService);
- producer.setTransactionListener(transactionListener);
- producer.start();
-
- String[] tags = new String[] {"TagA", "TagB", "TagC", "TagD", "TagE"};
- for (int i = 0; i < 10; i++) {
- try {
- Message msg =
- new Message("TopicTest", tags[i % tags.length], "KEY" + i,
- ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET));
- SendResult sendResult = producer.sendMessageInTransaction(msg, null);
- System.out.printf("%s%n", sendResult);
-
- Thread.sleep(10);
- } catch (MQClientException | UnsupportedEncodingException e) {
- e.printStackTrace();
- }
- }
-
- for (int i = 0; i < 100000; i++) {
- Thread.sleep(1000);
- }
- producer.shutdown();
- }
-
- static class TransactionListenerImpl implements TransactionListener {
- private AtomicInteger transactionIndex = new AtomicInteger(0);
-
- private ConcurrentHashMap<String, Integer> localTrans = new ConcurrentHashMap<>();
-
- @Override
- public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
- int value = transactionIndex.getAndIncrement();
- int status = value % 3;
- localTrans.put(msg.getTransactionId(), status);
- return LocalTransactionState.UNKNOW;
- }
-
- @Override
- public LocalTransactionState checkLocalTransaction(MessageExt msg) {
- Integer status = localTrans.get(msg.getTransactionId());
- if (null != status) {
- switch (status) {
- case 0:
- return LocalTransactionState.UNKNOW;
- case 1:
- return LocalTransactionState.COMMIT_MESSAGE;
- case 2:
- return LocalTransactionState.ROLLBACK_MESSAGE;
- default:
- return LocalTransactionState.COMMIT_MESSAGE;
- }
- }
- return LocalTransactionState.COMMIT_MESSAGE;
- }
- }
-}
-```
-
-事务消息的发送不再使用 DefaultMQProducer，而是使用 `TransactionMQProducer` 进行发送，上述的例子中设置了事务回查的线程池，如果不设置也会默认生成一个，最重要的是需要实现 `TransactionListener` 接口，并传入 `TransactionMQProducer`。
-
-:::note
-
-TransactionListener接口的定义如下：
-
-````javascript {9,18}
-public interface TransactionListener {
- /**
- * When send transactional prepare(half) message succeed, this method will be invoked to execute local transaction.
- *
- * @param msg Half(prepare) message
- * @param arg Custom business parameter
- * @return Transaction state
- */
- LocalTransactionState executeLocalTransaction(final Message msg, final Object arg);
-
- /**
- * When no response to prepare(half) message. broker will send check message to check the transaction status, and this
- * method will be invoked to get local transaction status.
- *
- * @param msg Check message
- * @return Transaction state
- */
- LocalTransactionState checkLocalTransaction(final MessageExt msg);
-}
-````
-:::
-
-`executeLocalTransaction` 是半事务消息发送成功后，执行本地事务的方法，具体执行完本地事务后，可以在该方法中返回以下三种状态：
-
-- `LocalTransactionState.COMMIT_MESSAGE`：提交事务，允许消费者消费该消息
-- `LocalTransactionState.ROLLBACK_MESSAGE`：回滚事务，消息将被丢弃不允许消费。
-- `LocalTransactionState.UNKNOW`：暂时无法判断状态，等待固定时间以后Broker端根据回查规则向生产者进行消息回查。
-
-`checkLocalTransaction`是由于二次确认消息没有收到，Broker端回查事务状态的方法。回查规则：本地事务执行完成后，若Broker端收到的本地事务返回状态为LocalTransactionState.UNKNOW，或生产者应用退出导致本地事务未提交任何状态。则Broker端会向消息生产者发起事务回查，第一次回查后仍未获取到事务状态，则之后每隔一段时间会再次回查。
-
-:::caution
-
-此外，需要注意的是事务消息的生产组名称 ProducerGroupName不能随意设置。事务消息有回查机制，回查时Broker端如果发现原始生产者已经崩溃崩溃，则会联系同一生产者组的其他生产者实例回查本地事务执行情况以Commit或Rollback半事务消息。
-
-:::
\ No newline at end of file
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\346\266\210\350\264\271\350\200\205/11concept2.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\346\266\210\350\264\271\350\200\205/11concept2.md"
deleted file mode 100644
index 8c47747f..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\346\266\210\350\264\271\350\200\205/11concept2.md"
+++ /dev/null
@@ -1,60 +0,0 @@
-# 基础概念
-
-消息通过生产者发送到某一个Topic，如果需要订阅该Topic并消费里面的消息的话，就要创建对应的消费者进行消费。在介绍消费者的使用方法之前，我们先介绍**消费组**、**消费位点**、**推和拉**等概念。
-
-## 消费者与消费组
-
-消息系统的重要作用之一是削峰填谷，但比如在电商大促的场景中，如果下游的消费者消费能力不足的话，大量的瞬时流量进入会后堆积在服务端。此时，消息的端到端延迟（从发送到被消费的时间）就会增加，对服务端而言，一直消费历史数据也会产生冷读。因此需要增加消费能力来解决这个问题，除了去优化消息消费的时间，最简单的方式就是扩容消费者。
-
-但是否随意增加消费者就能提升消费能力？ 首先需要了解消费组的概念。在消费者中消费组的有非常重要的作用，如果多个消费者设置了相同的Consumer Group，我们认为这些消费者在同一个消费组内。
-
-在 Apache RocketMQ 有两种消费模式，分别是：
-
-- 集群消费模式：当使用集群消费模式时，RocketMQ 认为任意一条消息只需要被消费组内的任意一个消费者处理即可。
-- 广播消费模式：当使用广播消费模式时，RocketMQ 会将每条消息推送给消费组所有的消费者，保证消息至少被每个消费者消费一次。
-
-集群消费模式适用于每条消息只需要被处理一次的场景，也就是说整个消费组会Topic收到全量的消息，而消费组内的消费分担消费这些消息，因此可以通过扩缩消费者数量，来提升或降低消费能力，具体示例如下图所示，是最常见的消费方式。
-
-
-
-广播消费模式适用于每条消息需要被消费组的每个消费者处理的场景，也就是说消费组内的每个消费者都会收到订阅Topic的全量消息，因此即使扩缩消费者数量也无法提升或降低消费能力，具体示例如下图所示。
-
-
-
-## 负载均衡
-
-集群模式下，同一个消费组内的消费者会分担收到的全量消息，这里的分配策略是怎样的？如果扩容消费者是否一定能提升消费能力？
-
-Apache RocketMQ 提供了多种集群模式下的分配策略，包括平均分配策略、机房优先分配策略、一致性hash分配策略等，可以通过如下代码进行设置相应负载均衡策略
-
-```java
- consumer.setAllocateMessageQueueStrategy(new AllocateMessageQueueAveragely());
-```
-
-默认的分配策略是平均分配，这也是最常见的策略。平均分配策略下消费组内的消费者会按照类似分页的策略均摊消费。
-
-在平均分配的算法下，可以通过增加消费者的数量来提高消费的并行度。比如下图中，通过增加消费者来提高消费能力。
-
-
-
-
-
-但也不是一味地增加消费者就能提升消费能力的，比如下图中Topic的总队列数小于消费者的数量时，消费者将分配不到队列，即使消费者再多也无法提升消费能力。
-
-
-
-## 消费位点
-
-
-
-如上图所示，在Apache RocketMQ中每个队列都会记录自己的最小位点、最大位点。针对于消费组，还有消费位点的概念，在集群模式下，消费位点是由客户端提给交服务端保存的，在广播模式下，消费位点是由客户端自己保存的。一般情况下消费位点正常更新，不会出现消息重复，但如果消费者发生崩溃或有新的消费者加入群组，就会触发重平衡，重平衡完成后，每个消费者可能会分配到新的队列，而不是之前处理的队列。为了能继续之前的工作，消费者需要读取每个队列最后一次的提交的消费位点，然后从消费位点处继续拉取消息。但在实际执行过程中，由于客户端提交给服务端的消费位点并不是实时的，所以重平衡就可能会导致消息少量重复。
-
-## 推、拉和长轮询
-
-MQ的消费模式可以大致分为两种，一种是推Push，一种是拉Pull。
-
-- Push是服务端主动推送消息给客户端，优点是及时性较好，但如果客户端没有做好流控，一旦服务端推送大量消息到客户端时，就会导致客户端消息堆积甚至崩溃。
-
-- Pull是客户端需要主动到服务端取数据，优点是客户端可以依据自己的消费能力进行消费，但拉取的频率也需要用户自己控制，拉取频繁容易造成服务端和客户端的压力，拉取间隔长又容易造成消费不及时。
-
-Apache RocketMQ既提供了Push模式也提供了Pull模式。
\ No newline at end of file
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\346\266\210\350\264\271\350\200\205/12push.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\346\266\210\350\264\271\350\200\205/12push.md"
deleted file mode 100644
index 0e54cc7b..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\346\266\210\350\264\271\350\200\205/12push.md"
+++ /dev/null
@@ -1,233 +0,0 @@
-# Push消费
-
-RocketMQ Push消费的示例代码如下
-
-```javascript
-public class Consumer {
- public static void main(String[] args) throws InterruptedException, MQClientException {
- // 初始化consumer，并设置consumer group name
- DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name");
-
- // 设置NameServer地址
- consumer.setNamesrvAddr("localhost:9876");
- //订阅一个或多个topic，并指定tag过滤条件，这里指定*表示接收所有tag的消息
- consumer.subscribe("TopicTest", "*");
- //注册回调接口来处理从Broker中收到的消息
- consumer.registerMessageListener(new MessageListenerConcurrently() {
- @Override
- public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
- System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
- // 返回消息消费状态，ConsumeConcurrentlyStatus.CONSUME_SUCCESS为消费成功
- return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
- }
- });
- // 启动Consumer
- consumer.start();
- System.out.printf("Consumer Started.%n");
- }
-}
-```
-
-首先需要初始化消费者，初始化消费者时，必须填写ConsumerGroupName，同一个消费组的ConsumerGroupName是相同的，这是判断消费者是否属于同一个消费组的重要属性。然后是设置NameServer地址，这里与Producer一样不再介绍。然后是调用subscribe方法订阅Topic，subscribe方法需要指定需要订阅的Topic名，也可以增加消息过滤的条件，比如TagA等，上述代码中指定*表示接收所有tag的消息。除了订阅之外，还需要注册回调接口编写消费逻辑来处理从Broker中收到的消息，调用registerMessageListener方法，需要传入MessageListener的实现，上述代码中是并发消费，因此是MessageListenerConcurrently的实现，其接口如下
-
-:::note MessageListenerConcurrently 接口
-```javascript
-/**
- * A MessageListenerConcurrently object is used to receive asynchronously delivered messages concurrently
- */
-public interface MessageListenerConcurrently extends MessageListener {
- /**
- * It is not recommend to throw exception,rather than returning ConsumeConcurrentlyStatus.RECONSUME_LATER if
- * consumption failure
- *
- * @param msgs msgs.size() >= 1<br> DefaultMQPushConsumer.consumeMessageBatchMaxSize=1,you can modify here
- * @return The consume status
- */
- ConsumeConcurrentlyStatus consumeMessage(final List<MessageExt> msgs,
- final ConsumeConcurrentlyContext context);
-}
-```
-:::
-
-其中，msgs是从Broker端获取的需要被消费消息列表，用户实现该接口，并把自己对消息的消费逻辑写在consumeMessage方法中，然后返回消费状态，ConsumeConcurrentlyStatus.CONSUME_SUCCESS表示消费成功，或者表示RECONSUME_LATER表示消费失败，一段时间后再重新消费。
-
-可以看到RocketMQ提供的消费者API却非常简单，用户并不需要关注重平衡或者拉取的逻辑，只需要写好自己的消费逻辑即可。
-
-## 集群模式和广播模式
-
-我们可以通过以下代码来设置采用集群模式，RocketMQ Push Consumer默认为集群模式，同一个消费组内的消费者分担消费。
-
-```java
-consumer.setMessageModel(MessageModel.CLUSTERING);
-```
-
-通过以下代码来设置采用广播模式，广播模式下，消费组内的每一个消费者都会消费全量消息。
-
-```java
-consumer.setMessageModel(MessageModel.BROADCASTING);
-```
-
-## 并发消费和顺序消费
-
-上面已经介绍设置Push Consumer并发消费的方法，通过在注册消费回调接口时传入MessageListenerConcurrently接口的实现来完成。在并发消费中，可能会有多个线程同时消费一个队列的消息，因此即使发送端通过发送顺序消息保证消息在同一个队列中按照FIFO的顺序，也无法保证消息实际被顺序消费。
-
-因此RocketMQ提供了顺序消费的方式， 顺序消费设置与并发消费API层面只有一处不同，在注册消费回调接口时传入MessageListenerOrderly接口的实现。
-
-```javascript
-consumer.registerMessageListener(new MessageListenerOrderly() {
- AtomicLong consumeTimes = new AtomicLong(0);
- @Override
- public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, ConsumeOrderlyContext context) {
- System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
- this.consumeTimes.incrementAndGet();
- if ((this.consumeTimes.get() % 2) == 0) {
- return ConsumeOrderlyStatus.SUCCESS;
- } else if ((this.consumeTimes.get() % 5) == 0) {
- context.setSuspendCurrentQueueTimeMillis(3000);
- return ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT;
- }
- return ConsumeOrderlyStatus.SUCCESS;
- }
- });
-```
-
-顺序消费也有两种返回结果，ConsumeOrderlyStatus.SUCCESS表示消费成功，ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT表示消费失败。
-
-## 消息过滤
-
-消息过滤是指消息生产者向Topic中发送消息时，设置消息属性对消息进行分类，消费者订阅Topic时，根据消息属性设置过滤条件对消息进行过滤，只有符合过滤条件的消息才会被投递到消费端进行消费。
-
-消费者订阅Topic时若未设置过滤条件，无论消息发送时是否有设置过滤属性，Topic中的所有消息都将被投递到消费端进行消费。
-
-RocketMQ支持的消息过滤方式有两种，Tag过滤和SQL92过滤。
-
-| 过滤方式 | 说明 | 场景 |
-|---------|------------------------------------------------|---------------------|
-| Tag过滤 | 消费者订阅的Tag和发送者设置的消息Tag相互匹配，则消息被投递给消费端进行消费。 | 简单过滤场景。一条消息支持设置一个Tag，仅需要对Topic中的消息进行一级分类并过滤时可以使用此方式。 |
-| SQL92过滤 | 发送者设置Tag或消息属性，消费者订阅满足SQL92过滤表达式的消息被投递给消费端进行消费。 | 复杂过滤场景。一条消息支持设置多个属性，可根据SQL语法自定义组合多种类型的表达式对消息进行多级分类并实现多维度的过滤。 |
-
-### Tag过滤
-
-Tag在生产者章节已经介绍过，用于对某个Topic下的消息进行分类。生产者在发送消息时，指定消息的Tag，消费者需根据已经指定的Tag来进行订阅。
-
-以下图电商交易场景为例，从客户下单到收到商品这一过程会生产一系列消息，以如下消息为例：
-- 订单消息
-- 支付消息
-- 物流消息
-
-这些消息会发送到名称为Trade_Topic的Topic中，被各个不同的系统所订阅，以如下系统为例：
-- 支付系统：只需订阅支付消息。
-- 物流系统：只需订阅物流消息。
-- 实时计算系统：需要订阅所有和交易相关的消息。
-- 交易成功率分析系统：需订阅订单和支付消息。
-
-过滤示意图如下所示
-
-
-
-对于物流系统和支付系统来说，它们都只订阅但个Tag，此时只需要在调用subcribe接口时明确标明Tag即可。
-
-```java
-consumer.subscribe("TagFilterTest", "TagA");
-```
-
-对于实时计算系统来说，它订阅交易Topic下所有的消息，Tag用星号（*）表示即可。
-
-```java
-consumer.subscribe("TagFilterTest", "*");
-```
-
-对于交易成功率分析系统来说，它订阅了订单和支付两个Tag的消息，在多个Tag之间用两个竖线（||）分隔即可。
-
-```java
-consumer.subscribe("TagFilterTest", "TagA||TagB");
-```
-
-这里需要注意的是，如果同一个消费者多次订阅某个Topic下的Tag，以最后一次订阅为准。
-
-```java
-//如下错误代码中，Consumer只能订阅到TagFilterTest下TagB的消息，而不能订阅TagA的消息。
-consumer.subscribe("TagFilterTest", "TagA");
-consumer.subscribe("TagFilterTest", "TagB");
-```
-
-### SQL92过滤
-
-SQL92过滤是在消息发送时设置消息的Tag或自定义属性，消费者订阅时使用SQL语法设置过滤表达式，根据自定义属性或Tag过滤消息。
->Tag属于一种特殊的消息属性，在SQL语法中，Tag的属性值为TAGS。
-开启属性过滤首先要在Broker端设置配置enablePropertyFilter=true，该值默认为false。
-
-以下图电商交易场景为例，从客户下单到收到商品这一过程会生产一系列消息，按照类型将消息分为订单消息和物流消息，其中给物流消息定义地域属性，按照地域分为杭州和上海：
-- 订单消息
-- 物流消息
- - 物流消息且地域为杭州
- - 物流消息且地域为上海
-
-这些消息会发送到名称为Trade_Topic的Topic中，被各个不同的系统所订阅，以如下系统为例：
-- 物流系统1：只需订阅物流消息且消息地域为杭州。
-- 物流系统2：只需订阅物流消息且消息地域为杭州或上海。
-- 订单跟踪系统：只需订阅订单消息。
-
-SQL92过滤示意图如下所示：
-
-
-
-地域将作为自定义属性设置在消息中。
-
-- 消息发送端：
- 设置消息的自定义属性。
-
-```java
-Message msg = new Message("topic", "tagA", "Hello MQ".getBytes());
-// 设置自定义属性A，属性值为1。
-msg.putUserProperties("a", "1");
-```
-
-- 消息消费端：
- 使用SQL语法设置过滤表达式，并根据自定义属性过滤消息。
-```java
-consumer.subscribe("SqlFilterTest",
- MessageSelector.bySql("(TAGS is not null and TAGS in ('TagA', 'TagB'))" +
- "and (a is not null and a between 0 and 3)"));
-```
-
-## 消息重试和死信队列
-
-### 消息重试
-
-若Consumer消费某条消息失败，则RockettMQ会在重试间隔时间后，将消息重新投递给Consumer消费，若达到最大重试次数后消息还没有成功被消费，则消息将被投递至死信队列
->消息重试只针对集群消费模式生效；广播消费模式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息
-- 最大重试次数：消息消费失败后，可被重复投递的最大次数。
-```java
-consumer.setMaxReconsumeTimes(10);
-```
-- 重试间隔：消息消费失败后再次被投递给Consumer消费的间隔时间，只在顺序消费中起作用。
-```java
-consumer.setSuspendCurrentQueueTimeMillis(5000);
-```
-
-顺序消费和并发消费的重试机制并不相同，顺序消费消费失败后是先在客户端本地重试，并且为了保证顺序性消费失败的消息不会被跳过先去消费下一条而是一直重试到最大重试次数，而并发消费消费失败后会将消费失败的消息重新投递回服务端，再等待服务端重新投递回来，在这期间会正常消费队列后面的消息。
->并发消费失败后并不是投递回原Topic，而是投递到一个特殊Topic，其命名为%RETRY%ConsumerGroupName，集群模式下并发消费每一个ConsumerGroup会对应一个特殊Topic，并会订阅该Topic。
-两者参数差别如下
-
-| 消费类型 | 重试间隔 | 最大重试次数 |
-|------|--------------------------------------------|--------------------------------------------------------------|
-| 顺序消费 | 间隔时间可通过自定义设置，SuspendCurrentQueueTimeMillis | 最大重试次数可通过自定义参数MaxReconsumeTimes取值进行配置。该参数取值无最大限制。若未设置参数值，默认最大重试次数为Integer.MAX |
-| 并发消费 | 间隔时间根据重试次数阶梯变化，取值范围：1秒～2小时。不支持自定义配置 | 最大重试次数可通过自定义参数MaxReconsumeTimes取值进行配置。默认值为16次，该参数取值无最大限制，建议使用默认值 |
-
-并发消费重试间隔如下，可以看到与延迟消息第三个等级开始的时间完全一致。
-
-| 第几次重试 | 与上次重试的间隔时间 | 第几次重试 | 与上次重试的间隔时间 |
-|-------|------------|-------|------------|
-| 1 | 10s | 9 | 7min |
-| 2 | 30s | 10 | 8min |
-| 3 | 1min | 11 | 9min |
-| 4 | 2min | 12 | 10min |
-| 5 | 3min | 13 | 20min |
-| 6 | 4min | 14 | 30min |
-| 7 | 5min | 15 | 1h |
-| 8 | 6min | 16 | 2h |
-
-### 死信队列
-
-当一条消息初次消费失败，RocketMQ会自动进行消息重试，达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息。此时，该消息不会立刻被丢弃，而是将其发送到该消费者对应的特殊队列中，这类消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列（Dead-Letter Queue），死信队列是死信Topic下分区数为一的单独队列。如果产生了死信消息，那对应的ConsumerGroup的死信Topic名称为%DLQ%ConsumerGroupName，死信队列的消息将不会再被消费。可以利用RocketMQ Admin工具或者RocketMQ Dashboard上查询到对应死信消息的信息。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\346\266\210\350\264\271\350\200\205/13pull.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\346\266\210\350\264\271\350\200\205/13pull.md"
deleted file mode 100644
index 1c0e53cd..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\346\266\210\350\264\271\350\200\205/13pull.md"
+++ /dev/null
@@ -1,120 +0,0 @@
-# Pull消费
-
-在RocketMQ中有两种Pull方式，一种是比较原始`Pull Consumer`，它不提供相关的订阅方法，需要调用pull方法时指定队列进行拉取，并需要自己更新位点。另一种是`Lite Pull Consumer`，它提供了Subscribe和Assign两种方式，使用起来更加方便。
-
-## Pull Consumer
-
-Pull Consumer示例如下
-
-```javascript
-public class PullConsumerTest {
- public static void main(String[] args) throws MQClientException {
- DefaultMQPullConsumer consumer = new DefaultMQPullConsumer("please_rename_unique_group_name_5");
- consumer.setNamesrvAddr("127.0.0.1:9876");
- consumer.start();
- try {
- MessageQueue mq = new MessageQueue();
- mq.setQueueId(0);
- mq.setTopic("TopicTest");
- mq.setBrokerName("jinrongtong-MacBook-Pro.local");
- long offset = 26;
- PullResult pullResult = consumer.pull(mq, "*", offset, 32);
- if (pullResult.getPullStatus().equals(PullStatus.FOUND)) {
- System.out.printf("%s%n", pullResult.getMsgFoundList());
- consumer.updateConsumeOffset(mq, pullResult.getNextBeginOffset());
- }
- } catch (Exception e) {
- e.printStackTrace();
- }
- consumer.shutdown();
- }
-}
-```
-
-首先需要初始化`DefaultMQPullConsumer`并启动，然后构造需要拉取的队列`MessageQueue`，除了构造外也可以如下所示调用`fetchSubscribeMessageQueues`方法获取某个Topic的所有队列，然后挑选队列进行拉取。
-
-```java
-Set<MessageQueue> queueSet = consumer.fetchSubscribeMessageQueues("TopicTest");
-```
-
-找到或者构造完队列之后，调用pull方法就可以进行拉取，需要传入拉取的队列，过滤表达式，拉取的位点，最大拉取消息条数等参数。拉取完成后会返回拉取结果`PullResult`，PullResult中的PullStatus表示结果状态，如下所示
-
-```javascript
-public enum PullStatus {
- /**
- * Founded
- */
- FOUND,
- /**
- * No new message can be pull
- */
- NO_NEW_MSG,
- /**
- * Filtering results can not match
- */
- NO_MATCHED_MSG,
- /**
- * Illegal offset,may be too big or too small
- */
- OFFSET_ILLEGAL
-}
-```
-
-FOUND表示拉取到消息，NO_NEW_MSG表示没有发现新消息，NO_MATCHED_MSG表示没有匹配的消息，OFFSET_ILLEGAL表示传入的拉取位点是非法的，有可能偏大或偏小。如果拉取状态是FOUND，我们可以通过`pullResult`的`getMsgFoundList`方法获取拉取到的消息列表。最后，如果消费完成，通过`updateConsumeOffset`方法更新消费位点。
-
-## Lite Pull Consumer
-
-Lite Pull Consumer是RocketMQ 4.6.0推出的Pull Consumer，相比于原始的Pull Consumer更加简单易用，它提供了Subscribe和Assign两种模式，Subscribe模式示例如下
-
-```javascript
-public class LitePullConsumerSubscribe {
- public static volatile boolean running = true;
- public static void main(String[] args) throws Exception {
- DefaultLitePullConsumer litePullConsumer = new DefaultLitePullConsumer("lite_pull_consumer_test");
- litePullConsumer.subscribe("TopicTest", "*");
- litePullConsumer.setPullBatchSize(20);
- litePullConsumer.start();
- try {
- while (running) {
- List<MessageExt> messageExts = litePullConsumer.poll();
- System.out.printf("%s%n", messageExts);
- }
- } finally {
- litePullConsumer.shutdown();
- }
- }
-}
-```
-
-首先还是初始化`DefaultLitePullConsumer`并设置`ConsumerGroupName`，调用subscribe方法订阅topic并启动。与Push Consumer不同的是，`LitePullConsumer`拉取消息调用的是轮询poll接口，如果能拉取到消息则返回对应的消息列表，否则返回null。通过`setPullBatchSize`可以设置每一次拉取的最大消息数量，此外如果不额外设置，`LitePullConsumer`默认是自动提交位点。在subscribe模式下，同一个消费组下的多个`LitePullConsumer`会负载均衡消费，与PushConsumer一致。
-
-如下是Assign模式的示例
-```javascript
-public class LitePullConsumerAssign {
- public static volatile boolean running = true;
- public static void main(String[] args) throws Exception {
- DefaultLitePullConsumer litePullConsumer = new DefaultLitePullConsumer("please_rename_unique_group_name");
- litePullConsumer.setAutoCommit(false);
- litePullConsumer.start();
- Collection<MessageQueue> mqSet = litePullConsumer.fetchMessageQueues("TopicTest");
- List<MessageQueue> list = new ArrayList<>(mqSet);
- List<MessageQueue> assignList = new ArrayList<>();
- for (int i = 0; i < list.size() / 2; i++) {
- assignList.add(list.get(i));
- }
- litePullConsumer.assign(assignList);
- litePullConsumer.seek(assignList.get(0), 10);
- try {
- while (running) {
- List<MessageExt> messageExts = litePullConsumer.poll();
- System.out.printf("%s %n", messageExts);
- litePullConsumer.commitSync();
- }
- } finally {
- litePullConsumer.shutdown();
- }
- }
-}
-```
-
-Assign模式一开始仍然是初始化`DefaultLitePullConsumer`，这里我们采用手动提交位点的方式，因此设置AutoCommit为false，然后启动consumer。与Subscribe模式不同的是，Assign模式下没有自动的负载均衡机制，需要用户自行指定需要拉取的队列，因此在例子中，先用fetchMessageQueues获取了Topic下的队列，再取前面的一半队列进行拉取，示例中还调用了seek方法，将第一个队列拉取的位点设置从10开始。紧接着进入循环不停地调用poll方法拉取消息，拉取到消息后调用commitSync方法手动提交位点。
\ No newline at end of file
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/01main.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/01main.md"
new file mode 100644
index 00000000..b2813ffc
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/01main.md"
@@ -0,0 +1,120 @@
+# 领域模型概述
+
+本文为您介绍 Apache RocketMQ 的领域模型。
+
+Apache RocketMQ 是一款典型的分布式架构下的中间件产品，使用异步通信方式和发布订阅的消息传输模型。通信方式和传输模型的具体说明，请参见下文**通信方式介绍**和**消息传输模型**介绍。
+Apache RocketMQ 产品具备异步通信的优势，系统拓扑简单、上下游耦合较弱，主要应用于异步解耦，流量削峰填谷等场景。
+
+## Apache RocketMQ领域模型
+
+
+
+如上图所示，Apache RocketMQ 中消息的生命周期主要分为消息生产、消息存储、消息消费这三部分。
+
+生产者生产消息并发送至 Apache RocketMQ 服务端，消息被存储在服务端的主题中，消费者通过订阅主题消费消息。
+
+**消息生产**
+
+[生产者（Producer）](../03-领域模型/04producer.md)：
+
+Apache RocketMQ 中用于产生消息的运行实体，一般集成于业务调用链路的上游。生产者是轻量级匿名无身份的。
+
+**消息存储**
+
+* [主题（Topic）](../03-领域模型/02topic.md)：
+
+ Apache RocketMQ 消息传输和存储的分组容器，主题内部由多个队列组成，消息的存储和水平扩展实际是通过主题内的队列实现的。
+
+* [队列（MessageQueue）](../03-领域模型/03messagequeue.md)：
+
+ Apache RocketMQ 消息传输和存储的实际单元容器，类比于其他消息队列中的分区。 Apache RocketMQ 通过流式特性的无限队列结构来存储消息，消息在队列内具备顺序性存储特征。
+
+* [消息（Message）](../03-领域模型/04message.md)：
+
+ Apache RocketMQ 的最小传输单元。消息具备不可变性，在初始化发送和完成存储后即不可变。
+
+
+
+
+**消息消费**
+
+* [消费者分组（ConsumerGroup）](../03-领域模型/07consumergroup.md)：
+
+ Apache RocketMQ 发布订阅模型中定义的独立的消费身份分组，用于统一管理底层运行的多个消费者（Consumer）。同一个消费组的多个消费者必须保持消费逻辑和配置一致，共同分担该消费组订阅的消息，实现消费能力的水平扩展。
+
+* [消费者（Consumer）](../03-领域模型/08consumer.md)：
+
+ Apache RocketMQ 消费消息的运行实体，一般集成在业务调用链路的下游。消费者必须被指定到某一个消费组中。
+
+* [订阅关系（Subscription）](../03-领域模型/09subscription.md)：
+
+ Apache RocketMQ 发布订阅模型中消息过滤、重试、消费进度的规则配置。订阅关系以消费组粒度进行管理，消费组通过定义订阅关系控制指定消费组下的消费者如何实现消息过滤、消费重试及消费进度恢复等。
+
+ Apache RocketMQ 的订阅关系除过滤表达式之外都是持久化的，即服务端重启或请求断开，订阅关系依然保留。
+
+
+
+
+
+
+## 通信方式介绍
+
+分布式系统架构思想下，将复杂系统拆分为多个独立的子模块，例如微服务模块。此时就需要考虑子模块间的远程通信，典型的通信模式分为以下两种，一种是同步的RPC远程调用；一种是基于中间件代理的异步通信方式。
+
+同步RPC调用模型
+
+
+同步RPC调用模型下，不同系统之间直接进行调用通信，每个请求直接从调用方发送到被调用方，然后要求被调用方立即返回响应结果给调用方，以确定本次调用结果是否成功。
+**注意** 此处的同步并不代表RPC的编程接口方式，RPC也可以有异步非阻塞调用的编程方式，但本质上仍然是需要在指定时间内得到目标端的直接响应。
+
+异步通信模型
+
+
+异步消息通信模式下，各子系统之间无需强耦合直接连接，调用方只需要将请求转化成异步事件（消息）发送给中间代理，发送成功即可认为该异步链路调用完成，剩下的工作中间代理会负责将事件可靠通知到下游的调用系统，确保任务执行完成。该中间代理一般就是消息中间件。
+
+异步通信的优势如下：
+
+* 系统拓扑简单由于调用方和被调用方统一和中间代理通信，系统是星型结构，易于维护和管理。
+
+
+
+* 上下游耦合性弱上下游系统之间弱耦合，结构更灵活，由中间代理负责缓冲和异步恢复。 上下游系统间可以独立升级和变更，不会互相影响。
+
+
+
+* 容量削峰填谷基于消息的中间代理往往具备很强的流量缓冲和整形能力，业务流量高峰到来时不会击垮下游。
+
+
+
+## 消息传输模型介绍
+
+主流的消息中间件的传输模型主要为点对点模型和发布订阅模型。
+
+点对点模型
+
+
+点对点模型也叫队列模型，具有如下特点：
+
+* 消费匿名：消息上下游沟通的唯一的身份就是队列，下游消费者从队列获取消息无法申明独立身份。
+
+* 一对一通信：基于消费匿名特点，下游消费者即使有多个，但都没有自己独立的身份，因此共享队列中的消息，每一条消息都只会被唯一一个消费者处理。因此点对点模型只能实现一对一通信。
+
+
+
+
+发布订阅模型
+
+
+发布订阅模型具有如下特点：
+
+* 消费独立：相比队列模型的匿名消费方式，发布订阅模型中消费方都会具备的身份，一般叫做订阅组（订阅关系），不同订阅组之间相互独立不会相互影响。
+
+* 一对多通信：基于独立身份的设计，同一个主题内的消息可以被多个订阅组处理，每个订阅组都可以拿到全量消息。因此发布订阅模型可以实现一对多通信。
+
+
+
+
+传输模型对比
+
+点对点模型和发布订阅模型各有优势，点对点模型更为简单，而发布订阅模型的扩展性更高。 Apache RocketMQ 使用的传输模型为发布订阅模型，因此也具有发布订阅模型的特点。
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/02topic.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/02topic.md"
new file mode 100644
index 00000000..54fe601f
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/02topic.md"
@@ -0,0 +1,131 @@
+# 主题（Topic）
+
+本文介绍 Apache RocketMQ 中主题（Topic）的定义、模型关系、内部属性、行为约束、版本兼容性及使用建议。
+
+## 定义
+
+主题是 Apache RocketMQ 中消息传输和存储的顶层容器，用于标识同一类业务逻辑的消息。 主题的作用主要如下：
+
+* **定义数据的分类隔离：** 在 Apache RocketMQ 的方案设计中，建议将不同业务类型的数据拆分到不同的主题中管理，通过主题实现存储的隔离性和订阅隔离性。
+
+* **定义数据的身份和权限：** Apache RocketMQ 的消息本身是匿名无身份的，同一分类的消息使用相同的主题来做身份识别和权限管理。
+
+
+## 模型关系
+
+
+在整个 Apache RocketMQ 的领域模型中，主题所处的流程和位置如下：
+
+
+
+主题是 Apache RocketMQ 的顶层存储，所有消息资源的定义都在主题内部完成，但主题是一个逻辑概念，并不是实际的消息容器。
+
+主题内部由多个队列组成，消息的存储和水平扩展能力最终是由队列实现的；并且针对主题的所有约束和属性设置，最终也是通过主题内部的队列来实现。
+
+## 内部属性
+
+**主题名称**
+
+* 定义：主题的名称，用于标识主题，主题名称集群内全局唯一。
+
+* 取值：由用户创建主题时定义。
+
+* 约束：请参见[参数限制](../01-基础介绍/03limits.md)。
+
+
+
+
+**队列列表**
+
+* 定义：队列作为主题的组成单元，是消息存储的实际容器，一个主题内包含一个或多个队列，消息实际存储在主题的各队列内。更多信息，请参见[队列（MessageQueue）](../03-领域模型/03messagequeue.md)。
+
+* 取值：系统根据队列数量给主题分配队列，队列数量创建主题时定义。
+
+* 约束：一个主题内至少包含一个队列。
+
+
+
+
+**消息类型**
+
+* 定义：主题所支持的消息类型。
+
+* 取值：创建主题时选择消息类型。Apache RocketMQ 支持的主题类型如下：
+ * Normal：[普通消息](../04-功能行为/01normalmessage.md)，消息本身无特殊语义，消息之间也没有任何关联。
+
+ * FIFO：[顺序消息](../04-功能行为/03fifomessage.md)，Apache RocketMQ 通过消息分组MessageGroup标记一组特定消息的先后顺序，可以保证消息的投递顺序严格按照消息发送时的顺序。
+
+ * Delay：[定时/延时消息](../04-功能行为/02delaymessage.md)，通过指定延时时间控制消息生产后不要立即投递，而是在延时间隔后才对消费者可见。
+
+ * Transaction：[事务消息](../04-功能行为/04transactionmessage.md)，Apache RocketMQ 支持分布式事务消息，支持应用数据库更新和消息调用的事务一致性保障。
+
+* 约束：每个主题只支持一种消息类型。
+
+
+
+
+## 行为约束
+
+**消息类型强制校验**
+
+Apache RocketMQ 5.x版本将消息类型拆分到主题中进行独立运维和处理，因此系统会对发送的消息类型和主题定的消息类型进行强制校验，若校验不通过，则消息发送请求会被拒绝，并返回类型不匹配异常。校验原则如下：
+
+* 消息类型必须一致发送的消息的类型，必须和目标主题定义的消息类型一致。
+
+* 主题类型必须单一每个主题只支持一种消息类型，不允许将多种类型的消息发送到同一个主题中。
+
+**常见错误使用场景**
+
+* 发送的消息类型不匹配例如，创建主题时消息类型定义为顺序消息，发送消息时发送事务消息到该主题中，此时消息发送请求会被拒绝，并返回类型不匹配异常。
+
+* 单一消息主题混用例如，创建主题时消息类型定义为普通消息，发送消息时同时发送普通消息和顺序消息到该主题中，则顺序消息的发送请求会被拒绝，并返回类型不匹配异常。
+
+
+## 版本兼容性
+
+
+消息类型的强制校验，仅针对 Apache RocketMQ 服务端5.x版本生效。 Apache RocketMQ 服务端4.x和3.x历史版本的SDK不支持强制校验，您需要自己保证消息类型一致。 如果您使用的服务端版本为历史版本，建议您升级到
+Apache RocketMQ 服务端5.x版本。
+
+## 使用建议
+
+**按照业务分类合理拆分主题**
+
+
+
+Apache RocketMQ 的主题拆分设计应遵循大类统一原则，即将相同业务域内同一功能属性的消息划分为同一主题。拆分主题时，您可以从以下角度考虑拆分粒度：
+
+* 消息类型是否一致：不同类型的消息，如顺序消息和普通消息需要使用不同的主题。
+
+* 消息业务是否关联：如果业务没有直接关联，比如，淘宝交易消息和盒马物流消息没有业务交集，需要使用不同的消息主题；同样是淘宝交易消息，女装类订单和男装类订单可以使用同一个订单。当然，如果业务量较大或其他子模块应用处理业务时需要进一步拆分订单类型，您也可以将男装订单和女装订单的消息拆分到两个主题中。
+
+* 消息量级是否一样：数量级不同或时效性不同的业务消息建议使用不同的主题，例如某些业务消息量很小但是时效性要求很强，如果跟某些万亿级消息量的业务使用同一个主题，会增加消息的等待时长。
+
+
+
+
+**正确拆分示例：** 线上商品购买场景下，订单交易如订单创建、支付、取消等流程消息使用一个主题，物流相关消息使用一个主题，积分管理相关消息使用一个主题。
+
+**错误拆分示例：**
+
+* 拆分粒度过粗：会导致业务隔离性差，不利于独立运维和故障处理。例如，所有交易消息和物流消息都共用一个主题。
+
+* 拆分粒度过细：会消耗大量主题资源，造成系统负载过重。例如，按照用户ID区分，每个用户ID使用一个主题。
+
+
+
+
+**单一主题只收发一种类型消息，避免混用**
+
+
+
+Apache RocketMQ 主题的设计原则为通过主题隔离业务，不同业务逻辑的消息建议使用不同的主题。同一业务逻辑消息的类型都相同，因此，对于指定主题，应该只收发同一种类型的消息。
+
+**主题管理尽量避免自动化机制**
+
+在 Apache RocketMQ 架构中，主题属于顶层资源和容器，拥有独立的权限管理、可观测性指标采集和监控等能力，创建和管理主题会占用一定的系统资源。因此，生产环境需要严格管理主题资源，请勿随意进行增、删、改、查操作。
+
+
+
+Apache RocketMQ 虽然提供了自动创建主题的功能，但是建议仅在测试环境使用，生产环境请勿打开，避免产生大量垃圾主题，无法管理和回收并浪费系统资源。
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/03messagequeue.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/03messagequeue.md"
new file mode 100644
index 00000000..a40e7a08
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/03messagequeue.md"
@@ -0,0 +1,107 @@
+# 队列（MessageQueue）
+
+
+本文介绍 Apache RocketMQ 中队列（MessageQueue）的定义、模型关系、内部属性、版本兼容性及使用建议。
+
+## 定义
+
+
+队列是 Apache RocketMQ 中消息存储和传输的实际容器，也是 Apache RocketMQ 消息的最小存储单元。 Apache RocketMQ 的所有主题都是由多个队列组成，以此实现队列数量的水平拆分和队列内部的流式存储。
+
+队列的主要作用如下：
+
+* 存储顺序性
+
+ 队列天然具备顺序性，即消息按照进入队列的顺序写入存储，同一队列间的消息天然存在顺序关系，队列头部为最早写入的消息，队列尾部为最新写入的消息。消息在队列中的位置和消息之间的顺序通过位点（Offset）进行标记管理。
+
+* 流式操作语义
+
+ Apache RocketMQ 基于队列的存储模型可确保消息从任意位点读取任意数量的消息，以此实现类似聚合读取、回溯读取等特性，这些特性是RabbitMQ、ActiveMQ等非队列存储模型不具备的。
+
+
+
+
+
+
+## 模型关系
+
+在整个 Apache RocketMQ 的领域模型中，队列所处的流程和位置如下：
+
+
+
+Apache RocketMQ 默认提供消息可靠存储机制，所有发送成功的消息都被持久化存储到队列中，配合生产者和消费者客户端的调用可实现至少投递一次的可靠性语义。
+
+Apache RocketMQ 队列模型和Kafka的分区（Partition）模型类似。在 Apache RocketMQ 消息收发模型中，队列属于主题的一部分，虽然所有的消息资源以主题粒度管理，但实际的操作实现是面向队列。例如，生产者指定某个主题，向主题内发送消息，但实际消息发送到该主题下的某个队列中。
+
+Apache RocketMQ 中通过修改队列数量，以此实现横向的水平扩容和缩容。
+
+## 内部属性
+
+读写权限
+
+* 定义：当前队列是否可以读写数据。
+
+* 取值：由服务端定义，枚举值如下
+ * 6：读写状态，当前队列同时允许写入消息和读取消息操作。
+
+ * 4：只读状态，当前队列只允许读取历史消息，不允许向队列写入新的消息。
+
+ * 2：只写状态，当前队列只允许写入新消息，不允许读取消息。
+
+ * 0：不可读写状态，当前队列不允许任何读写操作。
+
+
+
+
+* 约束：队列的读写权限属于运维侧操作，不建议频繁修改。
+
+
+
+
+## 行为约束
+
+每个主题下会由一到多个队列来存储消息，每个主题对应的队列数与消息类型以及实例所处地域（Region）相关，队列数暂不支持修改。
+
+## 版本兼容性
+
+队列的名称属性在 Apache RocketMQ 服务端的不同版本中有如下差异：
+
+* 服务端3.x/4.x版本：队列名称由{主题名称}+{BrokerID}+{QueueID}三元组组成，和物理节点绑定。
+
+* 服务端5.x版本：队列名称为一个集群分配的全局唯一的字符串组成，和物理节点解耦。
+
+
+
+
+因此，在开发过程中，建议不要对队列名称做任何假设和绑定。如果您在代码中自定义拼接队列名称并和其他操作进行绑定，一旦服务端版本升级，可能会出现队列名称无法解析的兼容性问题。
+
+## 使用建议
+
+**按照实际业务消耗设置队列数**
+
+Apache RocketMQ 的队列数可在创建主题或变更主题时设置修改，队列数量的设置应遵循少用够用原则，避免随意增加队列数量。
+
+主题内队列数过多可能对导致如下问题：
+
+* 集群元数据膨胀
+
+ Apache RocketMQ 会以队列粒度采集指标和监控数据，队列过多容易造成管控元数据膨胀。
+
+* 客户端压力过大
+
+ Apache RocketMQ 的消息读写都是针对队列进行操作，队列过多容易产生空轮询请求，增加系统负荷。
+
+**常见队列增加场景**
+
+* 需要增加队列实现物理节点负载均衡
+
+ Apache RocketMQ 每个主题的多个队列可以分布在不同的服务节点上，在集群水平扩容增加节点后，为了保证集群流量的负载均衡，建议在新的服务节点上新增队列，或将旧的队列迁移到新的服务节点上。
+
+* 需要增加队列实现顺序消息性能扩展
+
+ 在 Apache RocketMQ 服务端4.x版本中，顺序消息的顺序性在队列内生效的，因此顺序消息的并发度会在一定程度上受队列数量的影响，因此建议仅在系统性能瓶颈时再增加队列。
+
+
+
+
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04message.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04message.md"
new file mode 100644
index 00000000..6cbe1f75
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04message.md"
@@ -0,0 +1,231 @@
+# 消息（Message）
+
+本文介绍 Apache RocketMQ 中消息（Message）的定义、模型关系、内部属性、行为约束及使用建议。
+
+## 定义
+
+
+消息是 Apache RocketMQ 中的最小数据传输单元。生产者将业务数据的负载和拓展属性包装成消息发送到 Apache RocketMQ 服务端，服务端按照相关语义将消息投递到消费端进行消费。
+
+
+
+Apache RocketMQ 的消息模型具备如下特点：
+
+* **消息不可变性**
+
+ 消息本质上是已经产生并确定的事件，一旦产生后，消息的内容不会发生改变。即使经过传输链路的控制也不会发生变化，消费端获取的消息都是只读消息视图。
+
+
+
+* **消息持久化**
+
+ Apache RocketMQ 会默认对消息进行持久化，即将接收到的消息存储到 Apache RocketMQ 服务端的存储文件中，保证消息的可回溯性和系统故障场景下的可恢复性。
+
+
+
+## 模型关系
+
+在整个 Apache RocketMQ 的领域模型中，消息所处的流程和位置如下：
+
+1. 消息由生产者初始化并发送到Apache RocketMQ 服务端。
+
+2. 消息按照到达Apache RocketMQ 服务端的顺序存储到队列中。
+
+3. 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
+
+
+
+
+## 消息内部属性
+
+**系统保留属性**
+
+**主题名称**
+
+* 定义：当前消息所属的主题的名称。集群内全局唯一。更多信息，请参见[主题（Topic）](./02topic.md)。
+
+* 取值：从客户端SDK接口获取。
+
+
+
+
+**消息类型**
+
+* 定义：当前消息的类型。
+
+* 取值：从客户端SDK接口获取。Apache RocketMQ 支持的消息类型如下：
+ * Normal：[普通消息](../04-功能行为/01normalmessage.md)，消息本身无特殊语义，消息之间也没有任何关联。
+
+ * FIFO：[顺序消息](../04-功能行为/03fifomessage.md)，Apache RocketMQ 通过消息分组MessageGroup标记一组特定消息的先后顺序，可以保证消息的投递顺序严格按照消息发送时的顺序。
+
+ * Delay：[定时/延时消息](../04-功能行为/02delaymessage.md)，通过指定延时时间控制消息生产后不要立即投递，而是在延时间隔后才对消费者可见。
+
+ * Transaction：[事务消息](../04-功能行为/04transactionmessage.md)，Apache RocketMQ 支持分布式事务消息，支持应用数据库更新和消息调用的事务一致性保障。
+
+
+
+
+
+
+
+**消息队列**
+
+* 定义：实际存储当前消息的队列。更多信息，请参见[队列（MessageQueue）](./03messagequeue.md)。
+
+* 取值：由服务端指定并填充。
+
+
+
+
+**消息位点**
+
+* 定义：当前消息存储在队列中的位置。更多信息，请参见[消费进度原理](../04-功能行为/09consumerprogress.md)。
+
+* 取值：由服务端指定并填充。取值范围：0\~long.Max。
+
+
+
+
+**消息ID**
+
+* 定义：消息的唯一标识，集群内每条消息的ID全局唯一。
+
+* 取值：生产者客户端系统自动生成。固定为数字和大写字母组成的32位字符串。
+
+
+
+
+**索引Key列表（可选）**
+
+* 定义：消息的索引键，可通过设置不同的Key区分消息和快速查找消息。
+
+* 取值：由生产者客户端定义。
+
+
+
+
+**过滤标签Tag（可选）**
+
+* 定义：消息的过滤标签。消费者可通过Tag对消息进行过滤，仅接收指定标签的消息。
+
+* 取值：由生产者客户端定义。
+
+* 约束：一条消息仅支持设置一个标签。
+
+
+
+
+**定时时间（可选）**
+
+* 定义：定时场景下，消息触发延时投递的毫秒级时间戳。更多信息，请参见[定时/延时消息](../04-功能行为/02delaymessage.md)。
+
+* 取值：由消息生产者定义。
+
+* 约束：最大可设置定时时长为40天。
+
+
+
+
+**消息发送时间**
+
+* 定义：消息发送时，生产者客户端系统的本地毫秒级时间戳。
+
+* 取值：由生产者客户端系统填充。
+
+* 说明：客户端系统时钟和服务端系统时钟可能存在偏差，消息发送时间是以客户端系统时钟为准。
+
+
+
+
+**消息保存时间戳**
+
+* 定义：消息在Apache RocketMQ 服务端完成存储时，服务端系统的本地毫秒级时间戳。 对于定时消息和事务消息，消息保存时间指的是消息生效对消费方可见的服务端系统时间。
+
+
+* 取值：由服务端系统填充。
+
+* 说明：客户端系统时钟和服务端系统时钟可能存在偏差，消息保留时间是以服务端系统时钟为准。
+
+
+
+
+**消费重试次数**
+
+* 定义：消息消费失败后，Apache RocketMQ 服务端重新投递的次数。每次重试后，重试次数加1。更多信息，请参见[消费重试](../04-功能行为/10consumerretrypolicy.md)。
+
+* 取值：由服务端系统标记。首次消费，重试次数为0；消费失败首次重试时，重试次数为1。
+
+
+
+
+**业务自定义属性**
+
+
+* 定义：生产者可以自定义设置的扩展信息。
+
+* 取值：由消息生产者自定义，按照字符串键值对设置。
+
+
+
+
+**消息负载**
+
+* 定义：业务消息的实际报文数据。
+
+* 取值：由生产者负责序列化编码，按照二进制字节传输。
+
+* 约束：请参见[参数限制](../01-基础介绍/03limits.md)。
+
+
+
+
+## 行为约束
+
+
+消息大小不得超过其类型所对应的限制，否则消息会发送失败。
+
+系统默认的消息最大限制如下：
+
+* 普通和顺序消息：4 MB
+
+* 事务和定时或延时消息：64 KB
+
+
+
+
+## 使用建议
+
+
+**单条消息不建议传输超大负载**
+
+作为一款消息中间件产品，Apache RocketMQ 一般传输的是都是业务事件数据。单个原子消息事件的数据大小需要严格控制，如果单条消息过大容易造成网络传输层压力，不利于异常重试和流量控制。
+
+生产环境中如果需要传输超大负载，建议按照固定大小做报文拆分，或者结合文件存储等方法进行传输。
+
+**消息中转时做好不可变设计**
+
+Apache RocketMQ 服务端5.x版本中，消息本身不可编辑，消费端获取的消息都是只读消息视图。
+但在历史版本3.x和4.x版本中消息不可变性没有强约束，因此如果您需要在使用过程中对消息进行中转操作，务必将消息重新初始化。
+
+* 正确使用示例如下：
+
+ ```java
+ Message m = Consumer.receive();
+ Message m2= MessageBuilder.buildFrom(m);
+ Producer.send(m2);
+ ```
+
+
+
+* 错误使用示例如下：
+
+ ```java
+ Message m = Consumer.receive();
+ m.update()；
+ Producer.send(m);
+ ```
+
+
+
+
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04producer.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04producer.md"
new file mode 100644
index 00000000..beb36d85
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04producer.md"
@@ -0,0 +1,137 @@
+# 生产者（Producer）
+
+本文介绍 Apache RocketMQ 中生产者（Producer）的定义、模型关系、内部属性、版本兼容性及使用建议。
+
+## 定义
+
+生产者是 Apache RocketMQ 系统中用来构建并传输消息到服务端的运行实体。
+
+生产者通常被集成在业务系统中，将业务消息按照要求封装成 Apache RocketMQ 的[消息（Message）](./04message.md)并发送至服务端。
+
+在消息生产者中，可以定义如下传输行为：
+
+* 发送方式：生产者可通过API接口设置消息发送的方式。Apache RocketMQ 支持同步传输和异步传输。
+
+* 批量发送：生产者可通过API接口设置消息批量传输的方式。例如，批量发送的消息条数或消息大小。
+
+* 事务行为：Apache RocketMQ 支持事务消息，对于事务消息需要生产者配合进行事务检查等行为保障事务的最终一致性。具体信息，请参见[事务消息](../04-功能行为/04transactionmessage.md)。
+
+
+
+
+生产者和主题的关系为多对多关系，即同一个生产者可以向多个主题发送消息，对于平台类场景如果需要发送消息到多个主题，并不需要创建多个生产者；同一个主题也可以接收多个生产者的消息，以此可以实现生产者性能的水平扩展和容灾。
+
+
+## 模型关系
+
+在 Apache RocketMQ 的领域模型中，生产者的位置和流程如下：
+
+1. 消息由生产者初始化并发送到Apache RocketMQ 服务端。
+
+2. 消息按照到达Apache RocketMQ 服务端的顺序存储到主题的指定队列中。
+
+3. 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
+
+
+
+
+## 内部属性
+
+
+**客户端ID**
+
+* 定义：生产者客户端的标识，用于区分不同的生产者。集群内全局唯一。
+
+* 取值：客户端ID由Apache RocketMQ 的SDK自动生成，主要用于日志查看、问题定位等运维场景，不支持修改。
+
+
+
+
+**通信参数**
+
+* 接入点信息 **（必选）** ：连接服务端的接入地址，用于识别服务端集群。 接入点必须按格式配置，建议使用域名，避免使用IP地址，防止节点变更无法进行热点迁移。
+
+
+* 身份认证信息 **（可选）** ：客户端用于身份验证的凭证信息。 仅在服务端开启身份识别和认证时需要传输。
+
+
+* 请求超时时间 **（可选）** ：客户端网络请求调用的超时时间。取值范围和默认值，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+
+
+
+**预绑定主题列表**
+
+* 定义：Apache RocketMQ 的生产者需要将消息发送到的目标主题列表，主要作用如下：
+ * 事务消息 **（必须设置）** ：事务消息场景下，生产者在故障、重启恢复时，需要检查事务消息的主题中是否有未提交的事务消息。避免生产者发送新消息后，主题中的旧事务消息一直处于未提交状态，造成业务延迟。
+
+ * 非事务消息 **（建议设置）** ：服务端会在生产者初始化时根据预绑定主题列表，检查目标主题的访问权限和合法性，而不需要等到应用启动后再检查。
+
+ 若未设置，或后续消息发送的目标主题动态变更， Apache RocketMQ 会对目标主题进行动态补充检验。
+
+* 约束：对于事务消息，预绑定列表必须设置，且需要和事务检查器一起配合使用。
+
+
+
+
+**事务检查器**
+
+* 定义：Apache RocketMQ 的事务消息机制中，为保证异常场景下事务的最终一致性，生产者需要主动实现事务检查器的接口。具体信息，请参见[事务消息](../04-功能行为/04transactionmessage.md)。
+
+* 发送事务消息时，事务检查器必须设置，且需要和预绑定主题列表一起配合使用。
+
+
+
+
+**发送重试策略**：
+
+* 定义: 生产者在消息发送失败时的重试策略。具体信息，请参见[消息发送重试机制](../04-功能行为/05sendretrypolicy.md)。
+
+## 版本兼容性
+
+Apache RocketMQ 服务端5.x版本开始，生产者是匿名的，无需管理生产者分组（ProducerGroup）；对于历史版本服务端3.x和4.x版本，已经使用的生产者分组可以废弃无需再设置，且不会对当前业务产生影响。
+
+## 使用建议
+
+**不建议单一进程创建大量生产者**
+
+
+
+Apache RocketMQ 的生产者和主题是多对多的关系，支持同一个生产者向多个主题发送消息。对于生产者的创建和初始化，建议遵循够用即可、最大化复用原则，如果有需要发送消息到多个主题的场景，无需为每个主题都创建一个生产者。
+
+**不建议频繁创建和销毁生产者**
+
+
+
+Apache RocketMQ 的生产者是可以重复利用的底层资源，类似数据库的连接池。因此不需要在每次发送消息时动态创建生产者，且在发送结束后销毁生产者。这样频繁的创建销毁会在服务端产生大量短连接请求，严重影响系统性能。
+
+* 正确示例
+
+ ```java
+ Producer p = ProducerBuilder.build();
+ for (int i =0;i<n;i++)
+ {
+ Message m= MessageBuilder.build();
+ p.send(m);
+ }
+ p.shutdown();
+ ```
+
+
+
+* 典型错误示例
+
+ ```java
+ for (int i =0;i<n;i++)
+ {
+ Producer p = ProducerBuilder.build();
+ Message m= MessageBuilder.build();
+ p.send(m);
+ p.shutdown();
+ }
+ ```
+
+
+
+
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/07consumergroup.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/07consumergroup.md"
new file mode 100644
index 00000000..9e3e79bb
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/07consumergroup.md"
@@ -0,0 +1,121 @@
+# 消费者分组（ConsumerGroup）
+
+本文介绍 Apache RocketMQ 中消费者分组（ConsumerGroup）的定义、模型关系、内部属性、行为约束、版本兼容性及使用建议。
+
+## 定义
+
+
+消费者分组是 Apache RocketMQ 系统中承载多个消费行为一致的消费者的负载均衡分组。
+
+和消费者不同，消费者分组并不是运行实体，而是一个逻辑资源。在 Apache RocketMQ 中，通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾。
+
+在消费者分组中，统一定义以下消费行为，同一分组下的多个消费者将按照分组内统一的消费行为和负载均衡策略消费消息。
+
+* 订阅关系：Apache RocketMQ 以消费者分组的粒度管理订阅关系，实现订阅关系的管理和追溯。具体信息，请参见[订阅关系（Subscription）](./09subscription.md)。
+
+* 投递顺序性：Apache RocketMQ 的服务端将消息投递给消费者消费时，支持顺序投递和并发投递，投递方式在消费者分组中统一配置。具体信息，请参见[顺序消息](../04-功能行为/03fifomessage.md)。
+
+* 消费重试策略： 消费者消费消息失败时的重试策略，包括重试次数、死信队列设置等。具体信息，请参见[消费重试](../04-功能行为/10consumerretrypolicy.md)。
+
+
+
+
+## 模型关系
+
+
+在 Apache RocketMQ 的领域模型中，消费者分组的位置和流程如下：
+
+1. 消息由生产者初始化并发送到Apache RocketMQ 服务端。
+
+2. 消息按照到达Apache RocketMQ 服务端的顺序存储到主题的指定队列中。
+
+3. 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
+
+
+
+
+## 内部属性
+
+
+**消费者分组名称**
+
+* 定义：消费者分组的名称，用于区分不同的消费者分组。集群内全局唯一。
+
+* 取值：消费者分组由用户设置并创建。具体命名规范，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+
+
+
+**投递顺序性**
+
+* 定义：消费者消费消息时，Apache RocketMQ 向消费者客户端投递消息的顺序。
+
+ 根据不同的消费场景，Apache RocketMQ 提供顺序投递和并发投递两种方式。具体信息，请参见[顺序消息](../04-功能行为/03fifomessage.md)。
+
+* 取值：默认投递方式为并发投递。
+
+
+
+
+**消费重试策略**
+
+* 定义：消费者消费消息失败时，系统的重试策略。消费者消费消息失败时，系统会按照重试策略，将指定消息投递给消费者重新消费。具体信息，请参见[消费重试](../04-功能行为/10consumerretrypolicy.md)。
+
+* 取值：重试策略包括：
+
+ * 最大重试次数：表示消息可以重新被投递的最大次数，超过最大重试次数还没被成功消费，消息将被投递至死信队列或丢弃。
+
+ * 重试间隔：Apache RocketMQ 服务端重新投递消息的间隔时间。 最大重试次数和重试间隔的取值范围及默认值，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+* 约束：重试间隔仅在PushConsumer消费类型下有效。
+
+
+**订阅关系**
+
+* 定义：当前消费者分组关联的订阅关系集合。包括消费者订阅的主题，以及消息的过滤规则等。订阅关系由消费者动态注册到消费者分组中，Apache RocketMQ 服务端会持久化订阅关系并匹配消息的消费进度。更多信息，请参见[订阅关系（Subscription）](./09subscription.md)。
+
+## 行为约束
+
+在 Apache RocketMQ 领域模型中，消费者的管理通过消费者分组实现，同一分组内的消费者共同分摊消息进行消费。因此，为了保证分组内消息的正常负载和消费，
+
+Apache RocketMQ 要求同一分组下的所有消费者以下消费行为保持一致：
+
+* **投递顺序**
+
+* **消费重试策略**
+
+
+
+
+## 版本兼容性
+
+如行为约束中所述，同一分组内所有消费者的投递顺序和消费重试策略需要保持一致。
+
+* Apache RocketMQ 服务端5.x版本：上述消费者的消费行为从关联的消费者分组中统一获取，因此，同一分组内所有消费者的消费行为必然是一致的，客户端无需关注。
+
+* Apache RocketMQ 服务端3.x/4.x历史版本：上述消费逻辑由消费者客户端接口定义，因此，您需要自己在消费者客户端设置时保证同一分组下的消费者的消费行为一致。
+
+
+
+
+若您使用 Apache RocketMQ 服务端5.x版本，客户端使用历史版本SDK，则消费者的消费逻辑以消费者客户端接口的设置为准。
+
+## 使用建议
+
+**按照业务合理拆分分组**
+
+Apache RocketMQ 的消费者和主题是多对多的关系，对于消费者分组的拆分设计，建议遵循以下原则：
+
+* 消费者的投递顺序一致：同一消费者分组下所有消费者的消费投递顺序是相同的，统一都是顺序投递或并发投递，不同业务场景不能混用消费者分组。
+
+* 消费者业务类型一致：一般消费者分组和主题对应，不同业务域对消息消费的要求不同，例如消息过滤属性、消费重试策略不同。因此，不同业务域主题的消费建议使用不同的消费者分组，避免一个消费者分组消费超过10个主题。
+
+
+
+
+**消费者分组管理尽量避免自动化机制**
+
+在 Apache RocketMQ 架构中，消费分组属于状态管理类的逻辑资源，每个消费分组都会涉及关联的消费状态、堆积信息、可观测指标和监控采集数据。因此，生产环境需要严格管理消费者分组资源，请勿随意进行增、删、改、查操作。
+
+Apache RocketMQ 虽然提供了自动创建消费者分组的功能，但是建议仅在测试环境使用，生产环境请勿打开，避免产生大量消费者分组，无法管理和回收，且浪费系统资源。
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/08consumer.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/08consumer.md"
new file mode 100644
index 00000000..02b7a89e
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/08consumer.md"
@@ -0,0 +1,154 @@
+# 消费者（Consumer）
+
+本文介绍 Apache RocketMQ 中消费者（Consumer）的定义、模型关系、内部属性、行为约束、版本兼容性及使用建议。
+
+## 定义
+
+
+消费者是 Apache RocketMQ 中用来接收并处理消息的运行实体。 消费者通常被集成在业务系统中，从 Apache RocketMQ 服务端获取消息，并将消息转化成业务可理解的信息，供业务逻辑处理。
+
+在消息消费端，可以定义如下传输行为：
+
+* 消费者身份：消费者必须关联一个指定的消费者分组，以获取分组内统一定义的行为配置和消费状态。
+
+* 消费者类型：Apache RocketMQ 面向不同的开发场景提供了多样的消费者类型，包括PushConsumer类型、SimpleConsumer类型、PullConsumer类型（仅推荐流处理场景使用）等。具体信息，请参见[消费者分类](../04-功能行为/06consumertype.md)。
+
+* 消费者本地运行配置：消费者根据不同的消费者类型，控制消费者客户端本地的运行配置。例如消费者客户端的线程数，消费并发度等，实现不同的传输效果。
+
+
+
+
+## 模型关系
+
+
+在 Apache RocketMQ 的领域模型中，消费者的位置和流程如下：
+
+1. 消息由生产者初始化并发送到Apache RocketMQ 服务端。
+
+2. 消息按照到达Apache RocketMQ 服务端的顺序存储到主题的指定队列中。
+
+3. 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
+
+
+
+
+## 内部属性
+
+**消费者分组名称**
+
+* 定义：当前消费者关联的消费者分组名称，消费者必须关联到指定的消费者分组，通过消费者分组获取消费行为。更多信息，请参见[消费者分组（ConsumerGroup）](./07consumergroup.md)。
+
+* 取值：消费者分组为Apache RocketMQ 的逻辑资源，需要您提前通过控制台或OpenAPI创建。具体命名格式，请参见[使用限制](../01-基础介绍/03limits.md)。
+
+
+
+
+**客户端ID**
+
+* 定义：消费者客户端的标识，用于区分不同的消费者。集群内全局唯一。
+
+* 取值：客户端ID由Apache RocketMQ 的SDK自动生成，主要用于日志查看、问题定位等运维场景，不支持修改。
+
+
+
+
+**通信参数**
+
+* 接入点信息 **（必选）** ：连接服务端的接入地址，用于识别服务端集群。 接入点必须按格式配置，建议使用域名，避免使用IP地址，防止节点变更无法进行热点迁移。
+
+
+* 身份认证信息 **（可选）** ：客户端用于身份验证的凭证信息。 仅在服务端开启身份识别和认证时需要传输。
+
+
+* 请求超时时间 **（可选）** ：客户端网络请求调用的超时时间。取值范围和默认值，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+
+
+
+**预绑定订阅关系列表**
+
+* 定义：指定消费者的订阅关系列表。 Apache RocketMQ 服务端可在消费者初始化阶段，根据预绑定的订阅关系列表对目标主题进行权限及合法性校验，无需等到应用启动后才能校验。
+
+
+* 取值：建议在消费者初始化阶段明确订阅关系即要订阅的主题列表，若未设置，或订阅的主题动态变更，Apache RocketMQ 会对目标主题进行动态补充校验。
+
+
+
+
+**消费监听器**
+
+* 定义：Apache RocketMQ 服务端将消息推送给消费者后，消费者调用消息消费逻辑的监听器。
+
+* 取值：由消费者客户端本地配置。
+
+* 约束：使用PushConsumer类型的消费者消费消息时，消费者客户端必须设置消费监听器。消费者类型的具体信息，请参见[消费者分类](../04-功能行为/06consumertype.md)。
+
+
+
+
+## 行为约束
+
+
+在 Apache RocketMQ 领域模型中，消费者的管理通过消费者分组实现，同一分组内的消费者共同分摊消息进行消费。因此，为了保证分组内消息的正常负载和消费，
+
+Apache RocketMQ 要求同一分组下的所有消费者以下消费行为保持一致：
+
+* **投递顺序**
+
+* **消费重试策略**
+
+
+
+
+## 版本兼容性
+
+
+如行为约束中所述，同一分组内所有消费者的投递顺序和消费重试策略需要保持一致。
+
+* Apache RocketMQ 服务端5.x版本：上述消费者的消费行为从关联的消费者分组中统一获取，因此，同一分组内所有消费者的消费行为必然是一致的，客户端无需关注。
+
+* Apache RocketMQ 服务端3.x/4.x历史版本：上述消费逻辑由消费者客户端接口定义，因此，您需要自己在消费者客户端设置时保证同一分组下的消费者的消费行为一致。
+
+若您使用 Apache RocketMQ 服务端5.x版本，客户端使用历史版本SDK，则消费者的消费逻辑以消费者客户端接口的设置为准。
+
+## 使用建议
+
+
+**不建议在单一进程内创建大量消费者**
+
+Apache RocketMQ 的消费者在通信协议层面支持非阻塞传输模式，网络通信效率较高，并且支持多线程并发访问。因此，大部分场景下，单一进程内同一个消费分组只需要初始化唯一的一个消费者即可，开发过程中应避免以相同的配置初始化多个消费者。
+
+**不建议频繁创建和销毁消费者**
+
+Apache RocketMQ 的消费者是可以重复利用的底层资源，类似数据库的连接池。因此不需要在每次接收消息时动态创建消费者，且在消费完成后销毁消费者。这样频繁地创建销毁会在服务端产生大量短连接请求，严重影响系统性能。
+
+* 正确示例
+
+ ```java
+ Consumer c = ConsumerBuilder.build();
+ for (int i =0;i<n;i++)
+ {
+ Message m= c.receive();
+ //process message
+ }
+ c.shutdown();
+ ```
+
+
+
+* 典型错误示例
+
+ ```java
+ for (int i =0;i<n;i++)
+ {
+ Consumer c = ConsumerBuilder.build();
+ Message m= c.receive();
+ //process message
+ c.shutdown();
+ }
+ ```
+
+
+
+
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/09subscription.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/09subscription.md"
new file mode 100644
index 00000000..035d8da6
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/09subscription.md"
@@ -0,0 +1,100 @@
+# 订阅关系（Subscription）
+
+本文介绍 Apache RocketMQ 中订阅关系（Subscription）的定义、模型关系、内部属性及使用建议。
+
+## 定义
+
+
+订阅关系是 Apache RocketMQ 系统中消费者获取消息、处理消息的规则和状态配置。
+
+订阅关系由消费者分组动态注册到服务端系统，并在后续的消息传输中按照订阅关系定义的过滤规则进行消息匹配和消费进度维护。
+
+通过配置订阅关系，可控制如下传输行为：
+
+* 消息过滤规则：用于控制消费者在消费消息时，选择主题内的哪些消息进行消费，设置消费过滤规则可以高效地过滤消费者需要的消息集合，灵活根据不同的业务场景设置不同的消息接收范围。具体信息，请参见[消息过滤](../04-功能行为/07messagefilter.md)。
+
+* 消费状态：Apache RocketMQ 服务端默认提供订阅关系持久化的能力，即消费者分组在服务端注册订阅关系后，当消费者离线并再次上线后，可以获取离线前的消费进度并继续消费。
+
+## 订阅关系判断原则
+
+Apache RocketMQ 的订阅关系按照消费者分组和主题粒度设计，因此，一个订阅关系指的是指定某个消费者分组对于某个主题的订阅，判断原则如下：
+
+* 不同消费者分组对于同一个主题的订阅相互独立如下图所示，消费者分组Group A和消费者分组Group B分别以不同的订阅关系订阅了同一个主题Topic A，这两个订阅关系互相独立，可以各自定义，不受影响。
+
+ 
+
+* 同一个消费者分组对于不同主题的订阅也相互独立如下图所示，消费者分组Group A订阅了两个主题Topic A和Topic B，对于Group A中的消费者来说，订阅的Topic A为一个订阅关系，订阅的Topic B为另外一个订阅关系，且这两个订阅关系互相独立，可以各自定义，不受影响。
+
+ 
+
+
+
+
+## 模型关系
+
+
+在 Apache RocketMQ 的领域模型中，订阅关系的位置和流程如下：
+
+1. 消息由生产者初始化并发送到Apache RocketMQ 服务端。
+
+2. 消息按照到达Apache RocketMQ 服务端的顺序存储到主题的指定队列中。
+
+3. 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
+
+## 内部属性
+
+**过滤类型**
+
+* 定义：消息过滤规则的类型。订阅关系中设置消息过滤规则后，系统将按照过滤规则匹配主题中的消息，只将符合条件的消息投递给消费者消费，实现消息的再次分类。
+
+* 取值：
+ * TAG过滤：按照Tag字符串进行全文过滤匹配。
+
+ * SQL92过滤：按照SQL语法对消息属性进行过滤匹配。
+
+
+**过滤表达式**
+
+* 定义：自定义的过滤规则表达式。
+
+* 取值：具体取值规范，请参见[过滤表达式语法规范](../04-功能行为/07messagefilter.md)。
+
+
+
+
+## 行为约束
+
+**订阅关系一致**
+
+Apache RocketMQ 是按照消费者分组粒度管理订阅关系，因此，同一消费者分组内的消费者在消费逻辑上必须保持一致，否则会出现消费冲突，导致部分消息消费异常。
+
+* 正确示例
+
+ ```java
+ //Consumer c1
+ Consumer c1 = ConsumerBuilder.build(groupA);
+ c1.subscribe(topicA,"TagA");
+ //Consumer c2
+ Consumer c2 = ConsumerBuilder.build(groupA);
+ c1.subscribe(topicA,"TagA");
+ ```
+
+
+
+* 错误示例
+
+ ```java
+ //Consumer c1
+ Consumer c1 = ConsumerBuilder.build(groupA);
+ c1.subscribe(topicA,"TagA");
+ //Consumer c2Consumer
+ c2 = ConsumerBuilder.build(groupA);
+ c1.subscribe(topicA,"TagB");
+ ```
+
+## 使用建议
+
+**建议不要频繁修改订阅关系**
+
+在 Apache RocketMQ 领域模型中，订阅关系关联了过滤规则、消费进度等元数据和相关配置，同时系统需要保证消费者分组下的所有消费者的消费行为、消费逻辑、负载策略等一致，整体运算逻辑比较复杂。因此，不建议在生产环境中通过频繁修改订阅关系来实现业务逻辑的变更，这样可能会导致客户端一直处于负载均衡调整和变更的过程，从而影响消息接收。
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/01normalmessage.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/01normalmessage.md"
new file mode 100644
index 00000000..7ef444ce
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/01normalmessage.md"
@@ -0,0 +1,98 @@
+# 普通消息
+
+普通消息为 Apache RocketMQ 中最基础的消息，区别于有特性的顺序消息、定时/延时消息和事务消息。本文为您介绍普通消息的应用场景、功能原理、使用方法和使用建议。
+
+## 应用场景
+
+普通消息一般应用于微服务解耦、事件驱动、数据集成等场景，这些场景大多数要求数据传输通道具有可靠传输的能力，且对消息的处理时机、处理顺序没有特别要求。
+
+**典型场景一：微服务异步解耦**
+
+
+如上图所示，以在线的电商交易场景为例，上游订单系统将用户下单支付这一业务事件封装成独立的普通消息并发送至Apache RocketMQ服务端，下游按需从服务端订阅消息并按照本地消费逻辑处理下游任务。每个消息之间都是相互独立的，且不需要产生关联。
+
+**典型场景二：数据集成传输**
+
+
+如上图所示，以离线的日志收集场景为例，通过埋点组件收集前端应用的相关操作日志，并转发到 Apache RocketMQ 。每条消息都是一段日志数据，Apache RocketMQ 不做任何处理，只需要将日志数据可靠投递到下游的存储系统和分析系统即可，后续功能由后端应用完成。
+
+## 功能原理
+
+**什么是普通消息**
+
+定义：普通消息是Apache RocketMQ基本消息功能，支持生产者和消费者的异步解耦通信。
+
+
+**普通消息生命周期**
+
+* 初始化：消息被生产者构建并完成初始化，待发送到服务端的状态。
+
+* 待消费：消息被发送到服务端，对消费者可见，等待消费者消费的状态。
+
+* 消费中：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程。 此时服务端会等待消费者完成消费并提交消费结果，如果一定时间后没有收到消费者的响应，Apache RocketMQ会对消息进行重试处理。具体信息，请参见[消费重试](./10consumerretrypolicy.md)。
+
+* 消费提交：消费者完成消费处理，并向服务端提交消费结果，服务端标记当前消息已经被处理（包括消费成功和失败）。 Apache RocketMQ默认支持保留所有消息，此时消息数据并不会立即被删除，只是逻辑标记已消费。消息在保存时间到期或存储空间不足被删除前，消费者仍然可以回溯消息重新消费。
+
+* 消息删除：Apache RocketMQ按照消息保存机制滚动清理最早的消息数据，将消息从物理文件中删除。更多信息，请参见[消息存储和清理机制](./11messagestorepolicy.md)。
+
+## 使用限制
+
+普通消息仅支持使用MessageType为Normal主题，即普通消息只能发送至类型为普通消息的主题中，发送的消息的类型必须和主题的类型一致。
+
+## 使用示例
+
+普通消息支持设置消息索引键、消息过滤标签等信息，用于消息过滤和搜索查找。以Java语言为例，收发普通消息的示例代码如下：
+
+```java
+//普通消息发送。
+MessageBuilder messageBuilder = new MessageBuilder();
+Message message = messageBuilder.setTopic("topic")
+ //设置消息索引键，可根据关键字精确查找某条消息。
+ .setKeys("messageKey")
+ //设置消息Tag，用于消费端根据指定Tag过滤消息。
+ .setTag("messageTag")
+ //消息体。
+ .setBody("messageBody".getBytes())
+ .build();
+try {
+ //发送消息，需要关注发送结果，并捕获失败等异常。
+ SendReceipt sendReceipt = producer.send(message);
+ System.out.println(sendReceipt.getMessageId());
+} catch (ClientException e) {
+ e.printStackTrace();
+}
+//消费示例一：使用PushConsumer消费普通消息，只需要在消费监听器中处理即可。
+MessageListener messageListener = new MessageListener() {
+ @Override
+ public ConsumeResult consume(MessageView messageView) {
+ System.out.println(messageView);
+ //根据消费结果返回状态。
+ return ConsumeResult.SUCCESS;
+ }
+};
+//消费示例二：使用SimpleConsumer消费普通消息，主动获取消息进行消费处理并提交消费结果。
+List<MessageView> messageViewList = null;
+try {
+ messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
+ messageViewList.forEach(messageView -> {
+ System.out.println(messageView);
+ //消费处理完成后，需要主动调用ACK提交消费结果。
+ try {
+ simpleConsumer.ack(messageView);
+ } catch (ClientException e) {
+ e.printStackTrace();
+ }
+ });
+} catch (ClientException e) {
+ //如果遇到系统流控等原因造成拉取失败，需要重新发起获取消息请求。
+ e.printStackTrace();
+}
+```
+
+## 使用建议
+
+**设置全局唯一业务索引键，方便问题追踪**
+
+Apache RocketMQ支持自定义索引键（消息的Key），在消息查询和轨迹查询时，可以通过索引键高效精确地查询到消息。
+
+因此，发送消息时，建议设置业务上唯一的信息作为索引，方便后续快速定位消息。例如，订单ID，用户ID等。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/02delaymessage.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/02delaymessage.md"
new file mode 100644
index 00000000..f4bac752
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/02delaymessage.md"
@@ -0,0 +1,145 @@
+# 定时/延时消息
+
+定时/延时消息为 Apache RocketMQ 中的高级特性消息，本文为您介绍定时/延时消息的应用场景、功能原理、使用限制、使用方法和使用建议。
+:::note
+
+定时消息和延时消息本质相同，都是服务端根据消息设置的定时时间在某一固定时刻将消息投递给消费者消费。因此，下文统一用定时消息描述。
+
+:::
+## 应用场景
+
+在分布式定时调度触发、任务超时处理等场景，需要实现精准、可靠的定时事件触发。使用 Apache RocketMQ 的定时消息可以简化定时调度任务的开发逻辑，实现高性能、可扩展、高可靠的定时触发能力。
+
+**典型场景一：分布式定时调度**
+
+
+在分布式定时调度场景下，需要实现各类精度的定时任务，例如每天5点执行文件清理，每隔2分钟触发一次消息推送等需求。传统基于数据库的定时调度方案在分布式场景下，性能不高，实现复杂。基于 Apache RocketMQ 的定时消息可以封装出多种类型的定时触发器。
+
+**典型场景二：任务超时处理**
+
+
+以电商交易场景为例，订单下单后暂未支付，此时不可以直接关闭订单，而是需要等待一段时间后才能关闭订单。使用 Apache RocketMQ 定时消息可以实现超时任务的检查触发。
+
+基于定时消息的超时任务处理具备如下优势：
+
+* 精度高、开发门槛低：基于消息通知方式不存在定时阶梯间隔。可以轻松实现任意精度事件触发，无需业务去重。
+
+* 高性能可扩展：传统的数据库扫描方式较为复杂，需要频繁调用接口扫描，容易产生性能瓶颈。 Apache RocketMQ 的定时消息具有高并发和水平扩展的能力。
+
+
+## 功能原理
+
+**什么是定时消息**
+
+定时消息是 Apache RocketMQ 提供的一种高级消息类型，消息被发送至服务端后，在指定时间后才能被消费者消费。通过设置一定的定时时间可以实现分布式场景的延时调度触发效果。
+
+**定时时间设置原则**
+
+* Apache RocketMQ 定时消息设置的定时时间是一个预期触发的系统时间戳，延时时间也需要转换成当前系统时间后的某一个时间戳，而不是一段延时时长。
+
+* 定时时间的格式为毫秒级的Unix时间戳，您需要将要设置的时刻转换成时间戳形式。具体方式，请参见[Unix时间戳转换工具](https://www.unixtimestamp.com/)。
+
+* 定时时间必须设置在定时时长范围内，超过范围则定时不生效，服务端会立即投递消息。
+
+* 定时时长最大值默认为24小时，不支持自定义修改，更多信息，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+* 定时时间必须设置为当前时间之后，若设置到当前时间之前，则定时不生效，服务端会立即投递消息。
+
+
+**示例如下：**
+
+* 定时消息：例如，当前系统时间为2022-06-09 17:30:00，您希望消息在下午19:20:00定时投递，则定时时间为2022-06-09 19:20:00，转换成时间戳格式为1654773600000。
+
+* 延时消息：例如，当前系统时间为2022-06-09 17:30:00，您希望延时1个小时后投递消息，则您需要根据当前时间和延时时长换算成定时时刻，即消息投递时间为2022-06-09 18:30:00，转换为时间戳格式为1654770600000。
+
+**定时消息生命周期**
+
+
+
+* 初始化：消息被生产者构建并完成初始化，待发送到服务端的状态。
+
+* 定时中：消息被发送到服务端，和普通消息不同的是，服务端不会直接构建消息索引，而是会将定时消息单独存储在定时存储系统中，等待定时时刻到达。
+
+* 待消费：定时时刻到达后，服务端将消息重新写入普通存储引擎，对下游消费者可见，等待消费者消费的状态。
+
+* 消费中：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程。 此时服务端会等待消费者完成消费并提交消费结果，如果一定时间后没有收到消费者的响应，Apache RocketMQ会对消息进行重试处理。具体信息，请参见[消费重试](./10consumerretrypolicy.md)。
+
+* 消费提交：消费者完成消费处理，并向服务端提交消费结果，服务端标记当前消息已经被处理（包括消费成功和失败）。 Apache RocketMQ 默认支持保留所有消息，此时消息数据并不会立即被删除，只是逻辑标记已消费。消息在保存时间到期或存储空间不足被删除前，消费者仍然可以回溯消息重新消费。
+
+* 消息删除：Apache RocketMQ按照消息保存机制滚动清理最早的消息数据，将消息从物理文件中删除。更多信息，请参见[消息存储和清理机制](./11messagestorepolicy.md)。
+
+
+## 使用限制
+
+**消息类型一致性**
+
+定时消息仅支持在 MessageType为Delay 的主题内使用，即定时消息只能发送至类型为定时消息的主题中，发送的消息的类型必须和主题的类型一致。
+
+**定时精度约束**
+
+Apache RocketMQ 定时消息的定时时长参数精确到毫秒级，但是默认精度为1000ms，即定时消息为秒级精度。
+
+Apache RocketMQ 定时消息的状态支持持久化存储，系统由于故障重启后，仍支持按照原来设置的定时时间触发消息投递。若存储系统异常重启，可能会导致定时消息投递出现一定延迟。
+
+## 使用示例
+
+和普通消息相比，定时消费发送时，必须设置定时触发的目标时间戳。
+
+以Java语言为例，使用定时消息示例参考如下：
+
+```java
+ //定时/延时消息发送
+ MessageBuilder messageBuilder = null;
+ //以下示例表示：延迟时间为10分钟之后的Unix时间戳。
+ Long deliverTimeStamp = System.currentTimeMillis() + 10L * 60 * 1000;
+ Message message = messageBuilder.setTopic("topic")
+ //设置消息索引键，可根据关键字精确查找某条消息。
+ .setKeys("messageKey")
+ //设置消息Tag，用于消费端根据指定Tag过滤消息。
+ .setTag("messageTag")
+ .setDeliveryTimestamp(deliverTimeStamp)
+ //消息体
+ .setBody("messageBody".getBytes())
+ .build();
+ try {
+ //发送消息，需要关注发送结果，并捕获失败等异常。
+ SendReceipt sendReceipt = producer.send(message);
+ System.out.println(sendReceipt.getMessageId());
+ } catch (ClientException e) {
+ e.printStackTrace();
+ }
+ //消费示例一：使用PushConsumer消费定时消息，只需要在消费监听器处理即可。
+ MessageListener messageListener = new MessageListener() {
+ @Override
+ public ConsumeResult consume(MessageView messageView) {
+ System.out.println(messageView.getDeliveryTimestamp());
+ //根据消费结果返回状态。
+ return ConsumeResult.SUCCESS;
+ }
+ };
+ //消费示例二：使用SimpleConsumer消费定时消息，主动获取消息进行消费处理并提交消费结果。
+ List<MessageView> messageViewList = null;
+ try {
+ messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
+ messageViewList.forEach(messageView -> {
+ System.out.println(messageView);
+ //消费处理完成后，需要主动调用ACK提交消费结果。
+ try {
+ simpleConsumer.ack(messageView);
+ } catch (ClientException e) {
+ e.printStackTrace();
+ }
+ });
+ } catch (ClientException e) {
+ //如果遇到系统流控等原因造成拉取失败，需要重新发起获取消息请求。
+ e.printStackTrace();
+ }
+```
+
+
+
+## 使用建议
+
+**避免大量相同定时时刻的消息**
+
+定时消息的实现逻辑需要先经过定时存储等待触发，定时时间到达后才会被投递给消费者。因此，如果将大量定时消息的定时时间设置为同一时刻，则到达该时刻后会有大量消息同时需要被处理，会造成系统压力过大，导致消息分发延迟，影响定时精度。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/03fifomessage.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/03fifomessage.md"
new file mode 100644
index 00000000..24413bd3
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/03fifomessage.md"
@@ -0,0 +1,192 @@
+# 顺序消息
+
+顺序消息为 Apache RocketMQ 中的高级特性消息，本文为您介绍顺序消息的应用场景、功能原理、使用限制、使用方法和使用建议。
+
+## 应用场景
+
+在有序事件处理、撮合交易、数据实时增量同步等场景下，异构系统间需要维持强一致的状态同步，上游的事件变更需要按照顺序传递到下游进行处理。在这类场景下使用 Apache RocketMQ 的顺序消息可以有效保证数据传输的顺序性。
+
+**典型场景一：撮合交易**
+
+
+以证券、股票交易撮合场景为例，对于出价相同的交易单，坚持按照先出价先交易的原则，下游处理订单的系统需要严格按照出价顺序来处理订单。
+
+**典型场景二：数据实时增量同步**
+
+普通消息
+顺序消息
+
+以数据库变更增量同步场景为例，上游源端数据库按需执行增删改操作，将二进制操作日志作为消息，通过 Apache RocketMQ 传输到下游搜索系统，下游系统按顺序还原消息数据，实现状态数据按序刷新。如果是普通消息则可能会导致状态混乱，和预期操作结果不符，基于顺序消息可以实现下游状态和上游操作结果一致。
+
+## 功能原理
+
+**什么是顺序消息**
+
+顺序消息是 Apache RocketMQ 提供的一种高级消息类型，支持消费者按照发送消息的先后顺序获取消息，从而实现业务场景中的顺序处理。 相比其他类型消息，顺序消息在发送、存储和投递的处理过程中，更多强调多条消息间的先后顺序关系。
+
+
+
+Apache RocketMQ 顺序消息的顺序关系通过消息组（MessageGroup）判定和识别，发送顺序消息时需要为每条消息设置归属的消息组，相同消息组的多条消息之间遵循先进先出的顺序关系，不同消息组、无消息组的消息之间不涉及顺序性。
+
+基于消息组的顺序判定逻辑，支持按照业务逻辑做细粒度拆分，可以在满足业务局部顺序的前提下提高系统的并行度和吞吐能力。
+
+**如何保证消息的顺序性**
+
+Apache RocketMQ 的消息的顺序性分为两部分，生产顺序性和消费顺序性。
+
+* **生产顺序性** ：
+
+ Apache RocketMQ 通过生产者和服务端的协议保障单个生产者串行地发送消息，并按序存储和持久化。
+
+ 如需保证消息生产的顺序性，则必须满足以下条件：
+ * 单一生产者：消息生产的顺序性仅支持单一生产者，不同生产者分布在不同的系统，即使设置相同的消息组，不同生产者之间产生的消息也无法判定其先后顺序。
+
+ * 串行发送：Apache RocketMQ 生产者客户端支持多线程安全访问，但如果生产者使用多线程并行发送，则不同线程间产生的消息将无法判定其先后顺序。
+
+ 满足以上条件的生产者，将顺序消息发送至 Apache RocketMQ 后，会保证设置了同一消息组的消息，按照发送顺序存储在同一队列中。服务端顺序存储逻辑如下：
+ * 相同消息组的消息按照先后顺序被存储在同一个队列。
+
+ * 不同消息组的消息可以混合在同一个队列中，且不保证连续。
+
+
+
+
+ 如上图所示，消息组1和消息组4的消息混合存储在队列1中， Apache RocketMQ 保证消息组1中的消息G1-M1、G1-M2、G1-M3是按发送顺序存储，且消息组4的消息G4-M1、G4-M2也是按顺序存储，但消息组1和消息组4中的消息不涉及顺序关系。
+
+
+
+* **消费顺序性** ：
+
+ Apache RocketMQ
+ 通过消费者和服务端的协议保障消息消费严格按照存储的先后顺序来处理。
+
+ 如需保证消息消费的顺序性，则必须满足以下条件：
+ * 投递顺序
+
+ Apache RocketMQ 通过客户端SDK和服务端通信协议保障消息按照服务端存储顺序投递，但业务方消费消息时需要严格按照接收---处理---应答的语义处理消息，避免因异步处理导致消息乱序。
+
+ :::note
+ 消费者类型为PushConsumer时， Apache RocketMQ 保证消息按照存储顺序一条一条投递给消费者，若消费者类型为SimpleConsumer，则消费者有可能一次拉取多条消息。此时，消息消费的顺序性需要由业务方自行保证。消费者类型的具体信息，请参见[消费者分类](./06consumertype.md)。
+ :::
+
+ * 有限重试
+
+ Apache RocketMQ 顺序消息投递仅在重试次数限定范围内，即一条消息如果一直重试失败，超过最大重试次数后将不再重试，跳过这条消息消费，不会一直阻塞后续消息处理。
+
+ 对于需要严格保证消费顺序的场景，请务设置合理的重试次数，避免参数不合理导致消息乱序。
+
+
+
+**生产顺序性和消费顺序性组合**
+
+如果消息需要严格按照先进先出（FIFO）的原则处理，即先发送的先消费、后发送的后消费，则必须要同时满足生产顺序性和消费顺序性。
+
+一般业务场景下，同一个生产者可能对接多个下游消费者，不一定所有的消费者业务都需要顺序消费，您可以将生产顺序性和消费顺序性进行差异化组合，应用于不同的业务场景。例如发送顺序消息，但使用非顺序的并发消费方式来提高吞吐能力。更多组合方式如下表所示：
+
+
+| 生产顺序 | 消费顺序 | 顺序性效果 |
+|-----------------|------|---------------------------------------------------------------------------------------------------|
+| 设置消息组，保证消息顺序发送。 | 顺序消费 | 按照消息组粒度，严格保证消息顺序。 同一消息组内的消息的消费顺序和发送顺序完全一致。 |
+| 设置消息组，保证消息顺序发送。 | 并发消费 | 并发消费，尽可能按时间顺序处理。 |
+| 未设置消息组，消息乱序发送。 | 顺序消费 | 按队列存储粒度，严格顺序。 基于 Apache RocketMQ 本身队列的属性，消费顺序和队列存储的顺序一致，但不保证和发送顺序一致。 |
+| 未设置消息组，消息乱序发送。 | 并发消费 | 并发消费，尽可能按照时间顺序处理。 |
+
+
+
+**顺序消息生命周期**
+
+
+* 初始化：消息被生产者构建并完成初始化，待发送到服务端的状态。
+
+* 待消费：消息被发送到服务端，对消费者可见，等待消费者消费的状态。
+
+* 消费中：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程。 此时服务端会等待消费者完成消费并提交消费结果，如果一定时间后没有收到消费者的响应，Apache RocketMQ会对消息进行重试处理。具体信息，请参见[消费重试](./10consumerretrypolicy.md)。
+
+* 消费提交：消费者完成消费处理，并向服务端提交消费结果，服务端标记当前消息已经被处理（包括消费成功和失败）。 Apache RocketMQ 默认支持保留所有消息，此时消息数据并不会立即被删除，只是逻辑标记已消费。消息在保存时间到期或存储空间不足被删除前，消费者仍然可以回溯消息重新消费。
+
+* 消息删除：Apache RocketMQ按照消息保存机制滚动清理最早的消息数据，将消息从物理文件中删除。更多信息，请参见[消息存储和清理机制](./11messagestorepolicy.md)。
+
+:::note
+
+* 消息消费失败或消费超时，会触发服务端重试逻辑，重试消息属于新的消息，原消息的生命周期已结束。
+
+* 顺序消息消费失败进行消费重试时，为保障消息的顺序性，后续消息不可被消费，必须等待前面的消息消费完成后才能被处理。
+
+:::
+
+
+## 使用限制
+
+顺序消息仅支持使用MessageType为FIFO的主题，即顺序消息只能发送至类型为顺序消息的主题中，发送的消息的类型必须和主题的类型一致。
+
+## 使用示例
+
+和普通消息发送相比，顺序消息发送必须要设置消息组。消息组的粒度建议按照业务场景，尽可能细粒度设计，以便实现业务拆分和并发扩展。
+
+以Java语言为例，收发顺序消息的示例代码如下：
+
+```java
+ //顺序消息发送。
+ MessageBuilder messageBuilder = null;
+ Message message = messageBuilder.setTopic("topic")
+ //设置消息索引键，可根据关键字精确查找某条消息。
+ .setKeys("messageKey")
+ //设置消息Tag，用于消费端根据指定Tag过滤消息。
+ .setTag("messageTag")
+ //设置顺序消息的排序分组，该分组尽量保持离散，避免热点排序分组。
+ .setMessageGroup("fifoGroup001")
+ //消息体。
+ .setBody("messageBody".getBytes())
+ .build();
+ try {
+ //发送消息，需要关注发送结果，并捕获失败等异常
+ SendReceipt sendReceipt = producer.send(message);
+ System.out.println(sendReceipt.getMessageId());
+ } catch (ClientException e) {
+ e.printStackTrace();
+ }
+ //消费顺序消息时，需要确保当前消费者分组是顺序投递模式，否则仍然按并发乱序投递。
+ //消费示例一：使用PushConsumer消费顺序消息，只需要在消费监听器处理即可。
+ MessageListener messageListener = new MessageListener() {
+ @Override
+ public ConsumeResult consume(MessageView messageView) {
+ System.out.println(messageView);
+ //根据消费结果返回状态。
+ return ConsumeResult.SUCCESS;
+ }
+ };
+ //消费示例二：使用SimpleConsumer消费顺序消息，主动获取消息进行消费处理并提交消费结果。
+ //需要注意的是，同一个MessageGroup的消息，如果前序消息没有消费完成，再次调用Receive是获取不到后续消息的。
+ List<MessageView> messageViewList = null;
+ try {
+ messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
+ messageViewList.forEach(messageView -> {
+ System.out.println(messageView);
+ //消费处理完成后，需要主动调用ACK提交消费结果。
+ try {
+ simpleConsumer.ack(messageView);
+ } catch (ClientException e) {
+ e.printStackTrace();
+ }
+ });
+ } catch (ClientException e) {
+ //如果遇到系统流控等原因造成拉取失败，需要重新发起获取消息请求。
+ e.printStackTrace();
+ }
+```
+
+
+
+## 使用建议
+
+**串行消费，避免批量消费导致乱序**
+
+消息消费建议串行处理，避免一次消费多条消费，否则可能出现乱序情况。
+
+例如：发送顺序为1-\>2-\>3-\>4，消费时批量消费，消费顺序为1-\>23（批量处理，失败）-\>23（重试处理）-\>4，此时可能由于消息3的失败导致消息2被重复处理，最后导致消息消费乱序。
+
+**消息组尽可能打散，避免集中导致热点**
+
+Apache RocketMQ 保证相同消息组的消息存储在同一个队列中，如果不同业务场景的消息都集中在少量或一个消息组中，则这些消息存储压力都会集中到服务端的少量队列或一个队列中。容易导致性能热点，且不利于扩展。一般建议的消息组设计会采用订单ID、用户ID作为顺序参考，即同一个终端用户的消息保证顺序，不同用户的消息无需保证顺序。
+
+因此建议将业务以消息组粒度进行拆分，例如，将订单ID、用户ID作为消息组关键字，可实现同一终端用户的消息按照顺序处理，不同用户的消息无需保证顺序。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/04transactionmessage.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/04transactionmessage.md"
new file mode 100644
index 00000000..c84be92b
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/04transactionmessage.md"
@@ -0,0 +1,220 @@
+# 事务消息
+
+事务消息为 Apache RocketMQ 中的高级特性消息，本文为您介绍事务消息的应用场景、功能原理、使用限制、使用方法和使用建议。
+
+## 应用场景
+
+**分布式事务的诉求**
+
+分布式系统调用的特点为一个核心业务逻辑的执行，同时需要调用多个下游业务进行处理。因此，如何保证核心业务和多个下游业务的执行结果完全一致，是分布式事务需要解决的主要问题。
+
+
+以电商交易场景为例，用户支付订单这一核心操作的同时会涉及到下游物流发货、积分变更、购物车状态清空等多个子系统的变更。当前业务的处理分支包括：
+
+* 主分支订单系统状态更新：由未支付变更为支付成功。
+
+* 物流系统状态新增：新增待发货物流记录，创建订单物流记录。
+
+* 积分系统状态变更：变更用户积分，更新用户积分表。
+
+* 购物车系统状态变更：清空购物车，更新用户购物车记录。
+
+**传统XA事务方案：性能不足**
+
+为了保证上述四个分支的执行结果一致性，典型方案是基于XA协议的分布式事务系统来实现。将四个调用分支封装成包含四个独立事务分支的大事务。基于XA分布式事务的方案可以满足业务处理结果的正确性，但最大的缺点是多分支环境下资源锁定范围大，并发度低，随着下游分支的增加，系统性能会越来越差。
+
+**基于普通消息方案：一致性保障困难**
+
+将上述基于XA事务的方案进行简化，将订单系统变更作为本地事务，剩下的系统变更作为普通消息的下游来执行，事务分支简化成普通消息+订单表事务，充分利用消息异步化的能力缩短链路，提高并发度。
+
+
+该方案中消息下游分支和订单系统变更的主分支很容易出现不一致的现象，例如：
+
+* 消息发送成功，订单没有执行成功，需要回滚整个事务。
+
+* 订单执行成功，消息没有发送成功，需要额外补偿才能发现不一致。
+
+* 消息发送超时未知，此时无法判断需要回滚订单还是提交订单变更。
+
+**基于Apache RocketMQ分布式事务消息：支持最终一致性**
+
+上述普通消息方案中，普通消息和订单事务无法保证一致的原因，本质上是由于普通消息无法像单机数据库事务一样，具备提交、回滚和统一协调的能力。
+
+而基于Apache RocketMQ实现的分布式事务消息功能，在普通消息基础上，支持二阶段的提交能力。将二阶段提交和本地事务绑定，实现全局提交结果的一致性。
+
+
+Apache RocketMQ事务消息的方案，具备高性能、可扩展、业务开发简单的优势。具体事务消息的原理和流程，请参见下文的功能原理。
+
+## 功能原理
+
+**什么是事务消息**
+
+事务消息是 Apache RocketMQ 提供的一种高级消息类型，支持在分布式场景下保障消息生产和本地事务的最终一致性。
+
+**事务消息处理流程**
+
+事务消息交互流程如下图所示。
+
+1. 生产者将消息发送至Apache RocketMQ服务端。
+
+2. Apache RocketMQ服务端将消息持久化成功之后，向生产者返回Ack确认消息已经发送成功，此时消息被标记为"暂不能投递"，这种状态下的消息即为半事务消息。
+
+3. 生产者开始执行本地事务逻辑。
+
+4. 生产者根据本地事务执行结果向服务端提交二次确认结果（Commit或是Rollback），服务端收到确认结果后处理逻辑如下：
+ * 二次确认结果为Commit：服务端将半事务消息标记为可投递，并投递给消费者。
+
+ * 二次确认结果为Rollback：服务端将回滚事务，不会将半事务消息投递给消费者。
+
+5. 在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为Unknown未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。
+ **说明** 服务端回查的间隔时间和最大回查次数，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+6. 生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
+
+7. 生产者根据检查到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行处理。
+
+
+**事务消息生命周期**
+
+
+* 初始化：半事务消息被生产者构建并完成初始化，待发送到服务端的状态。
+
+* 事务待提交：半事务消息被发送到服务端，和普通消息不同，并不会直接被服务端持久化，而是会被单独存储到事务存储系统中，等待第二阶段本地事务返回执行结果后再提交。此时消息对下游消费者不可见。
+
+* 消息回滚：第二阶段如果事务执行结果明确为回滚，服务端会将半事务消息回滚，该事务消息流程终止。
+
+* 提交待消费：第二阶段如果事务执行结果明确为提交，服务端会将半事务消息重新存储到普通存储系统中，此时消息对下游消费者可见，等待被消费者获取并消费。
+
+* 消费中：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程。 此时服务端会等待消费者完成消费并提交消费结果，如果一定时间后没有收到消费者的响应，Apache RocketMQ会对消息进行重试处理。具体信息，请参见[消费重试](./10consumerretrypolicy.md)。
+
+* 消费提交：消费者完成消费处理，并向服务端提交消费结果，服务端标记当前消息已经被处理（包括消费成功和失败）。 Apache RocketMQ默认支持保留所有消息，此时消息数据并不会立即被删除，只是逻辑标记已消费。消息在保存时间到期或存储空间不足被删除前，消费者仍然可以回溯消息重新消费。
+
+* 消息删除：Apache RocketMQ按照消息保存机制滚动清理最早的消息数据，将消息从物理文件中删除。更多信息，请参见[消息存储和清理机制](./11messagestorepolicy.md)。
+
+
+## 使用限制
+
+**消息类型一致性**
+
+事务消息仅支持在 MessageType 为 Transaction 的主题内使用，即事务消息只能发送至类型为事务消息的主题中，发送的消息的类型必须和主题的类型一致。
+
+**消费事务性**
+
+Apache RocketMQ 事务消息保证本地主分支事务和下游消息发送事务的一致性，但不保证消息消费结果和上游事务的一致性。因此需要下游业务分支自行保证消息正确处理，建议消费端做好[消费重试](./10consumerretrypolicy.md)，如果有短暂失败可以利用重试机制保证最终处理成功。
+
+**中间状态可见性**
+
+Apache RocketMQ 事务消息为最终一致性，即在消息提交到下游消费端处理完成之前，下游分支和上游事务之间的状态会不一致。因此，事务消息仅适合接受异步执行的事务场景。
+
+**事务超时机制**
+
+Apache RocketMQ 事务消息的命周期存在超时机制，即半事务消息被生产者发送服务端后，如果在指定时间内服务端无法确认提交或者回滚状态，则消息默认会被回滚。事务超时时间，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+## 使用示例
+
+事务消息相比普通消息发送时需要修改以下几点：
+
+* 发送事务消息前，需要开启事务并关联本地的事务执行。
+
+* 为保证事务一致性，在构建生产者时，必须设置事务检查器和预绑定事务消息发送的主题列表，客户端内置的事务检查器会对绑定的事务主题做异常状态恢复。
+
+
+以Java语言为例，使用事务消息示例参考如下：
+
+```java
+ //演示demo，模拟订单表查询服务，用来确认订单事务是否提交成功。
+ private static boolean checkOrderById(String orderId) {
+ return true;
+ }
+ //演示demo，模拟本地事务的执行结果。
+ private static boolean doLocalTransaction() {
+ return true;
+ }
+ public static void main(String[] args) throws ClientException {
+ ClientServiceProvider provider = new ClientServiceProvider();
+ MessageBuilder messageBuilder = new MessageBuilder();
+ //构造事务生产者：事务消息需要生产者构建一个事务检查器，用于检查确认异常半事务的中间状态。
+ Producer producer = provider.newProducerBuilder()
+ .setTransactionChecker(messageView -> {
+ /**
+ * 事务检查器一般是根据业务的ID去检查本地事务是否正确提交还是回滚，此处以订单ID属性为例。
+ * 在订单表找到了这个订单，说明本地事务插入订单的操作已经正确提交；如果订单表没有订单，说明本地事务已经回滚。
+ */
+ final String orderId = messageView.getProperties().get("OrderId");
+ if (Strings.isNullOrEmpty(orderId)) {
+ // 错误的消息，直接返回Rollback。
+ return TransactionResolution.ROLLBACK;
+ }
+ return checkOrderById(orderId) ? TransactionResolution.COMMIT : TransactionResolution.ROLLBACK;
+ })
+ .build();
+ //开启事务分支。
+ final Transaction transaction;
+ try {
+ transaction = producer.beginTransaction();
+ } catch (ClientException e) {
+ e.printStackTrace();
+ //事务分支开启失败，直接退出。
+ return;
+ }
+ Message message = messageBuilder.setTopic("topic")
+ //设置消息索引键，可根据关键字精确查找某条消息。
+ .setKeys("messageKey")
+ //设置消息Tag，用于消费端根据指定Tag过滤消息。
+ .setTag("messageTag")
+ //一般事务消息都会设置一个本地事务关联的唯一ID，用来做本地事务回查的校验。
+ .addProperty("OrderId", "xxx")
+ //消息体。
+ .setBody("messageBody".getBytes())
+ .build();
+ //发送半事务消息
+ final SendReceipt sendReceipt;
+ try {
+ sendReceipt = producer.send(message, transaction);
+ } catch (ClientException e) {
+ //半事务消息发送失败，事务可以直接退出并回滚。
+ return;
+ }
+ /**
+ * 执行本地事务，并确定本地事务结果。
+ * 1. 如果本地事务提交成功，则提交消息事务。
+ * 2. 如果本地事务提交失败，则回滚消息事务。
+ * 3. 如果本地事务未知异常，则不处理，等待事务消息回查。
+ *
+ */
+ boolean localTransactionOk = doLocalTransaction();
+ if (localTransactionOk) {
+ try {
+ transaction.commit();
+ } catch (ClientException e) {
+ // 业务可以自身对实时性的要求选择是否重试，如果放弃重试，可以依赖事务消息回查机制进行事务状态的提交。
+ e.printStackTrace();
+ }
+ } else {
+ try {
+ transaction.rollback();
+ } catch (ClientException e) {
+ // 建议记录异常信息，回滚异常时可以无需重试，依赖事务消息回查机制进行事务状态的提交。
+ e.printStackTrace();
+ }
+ }
+ }
+```
+
+## 使用建议
+
+**避免大量未决事务导致超时**
+
+Apache RocketMQ支持在事务提交阶段异常的情况下发起事务回查，保证事务一致性。但生产者应该尽量避免本地事务返回未知结果。大量的事务检查会导致系统性能受损，容易导致事务处理延迟。
+
+**正确处理"进行中"的事务**
+
+消息回查时，对于正在进行中的事务不要返回Rollback或Commit结果，应继续保持Unknown的状态。 一般出现消息回查时事务正在处理的原因为：事务执行较慢，消息回查太快。解决方案如下：
+
+* 将第一次事务回查时间设置较大一些，但可能导致依赖回查的事务提交延迟较大。
+
+* 程序能正确识别正在进行中的事务。
+
+
+
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/05sendretrypolicy.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/05sendretrypolicy.md"
new file mode 100644
index 00000000..4a6070b9
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/05sendretrypolicy.md"
@@ -0,0 +1,134 @@
+# 消息发送重试和流控机制
+
+本文为您介绍 Apache RocketMQ 的消息发送重试机制和消息流控机制。
+
+## 背景信息
+
+**消息发送重试**
+
+Apache RocketM Q的消息发送重试机制主要为您解答如下问题：
+
+* 部分节点异常是否影响消息发送？
+
+* 请求重试是否会阻塞业务调用？
+
+* 请求重试会带来什么不足？
+
+**消息流控**
+
+Apache RocketMQ 的流控机制主要为您解答如下问题：
+
+* 系统在什么情况下会触发流控？
+
+* 触发流控时客户端行为是什么？
+
+* 应该如何避免触发流控，以及如何应对突发流控？
+
+## 消息发送重试机制
+
+### 重试基本概念
+
+Apache RocketMQ 客户端连接服务端发起消息发送请求时，可能会因为网络故障、服务异常等原因导致调用失败。为保证消息的可靠性， Apache RocketMQ 在客户端SDK中内置请求重试逻辑，尝试通过重试发送达到最终调用成功的效果。
+
+同步发送和异步发送模式均支持消息发送重试。
+
+**重试触发条件**
+
+触发消息发送重试机制的条件如下：
+
+* 客户端消息发送请求调用失败或请求超时
+
+* 网络异常造成连接失败或请求超时。
+
+* 服务端节点处于重启或下线等状态造成连接失败。
+
+* 服务端运行慢造成请求超时。
+
+* 服务端返回失败错误码
+ * 系统逻辑错误：因运行逻辑不正确造成的错误。
+
+ * 系统流控错误：因容量超限造成的流控错误。
+
+:::note
+对于事务消息，只会进行[透明重试（transparent retries）](https://github.com/grpc/proposal/blob/master/A6-client-retries.md#transparent-retries)，网络超时或异常等场景不会进行重试。
+:::
+
+### 重试流程
+
+生产者在初始化时设置消息发送最大重试次数，当出现上述触发条件的场景时，生产者客户端会按照设置的重试次数一直重试发送消息，直到消息发送成功或达到最大重试次数重试结束，并在最后一次重试失败后返回调用错误响应。
+
+* 同步发送：调用线程会一直阻塞，直到某次重试成功或最终重试失败，抛出错误码和异常。
+
+* 异步发送：调用线程不会阻塞，但调用结果会通过异常事件或者成功事件返回。
+
+### 重试间隔
+
+* 除服务端返回系统流控错误场景，其他触发条件触发重试后，均会立即进行重试，无等待间隔。
+
+* 若由于服务端返回流控错误触发重试，系统会按照指数退避策略进行延迟重试。指数退避算法通过以下参数控制重试行为：
+
+ * INITIAL_BACKOFF： 第一次失败重试前后需等待多久，默认值：1秒。
+
+ * MULTIPLIER ：指数退避因子，即退避倍率，默认值：1.6。
+
+ * JITTER ：随机抖动因子，默认值：0.2。
+
+ * MAX_BACKOFF ：等待间隔时间上限，默认值：120秒
+
+ * MIN_CONNECT_TIMEOUT ：最短重试间隔，默认值：20秒。
+
+
+**建议算法如下：**
+
+ ```unknow
+ ConnectWithBackoff()
+ current_backoff = INITIAL_BACKOFF
+ current_deadline = now() + INITIAL_BACKOFF
+ while (TryConnect(Max(current_deadline, now() + MIN_CONNECT_TIMEOUT))!= SUCCESS)
+ SleepUntil(current_deadline)
+ current_backoff = Min(current_backoff * MULTIPLIER, MAX_BACKOFF)
+ current_deadline = now() + current_backoff + UniformRandom(-JITTER * current_backoff, JITTER * current_backoff)
+ ```
+ 更多信息，请参见[connection-backoff 策略](https://github.com/grpc/grpc/blob/master/doc/connection-backoff.md)。
+
+### 功能约束
+
+* 链路耗时阻塞评估：从上述重试机制可以看出，在重试流程中生产者仅能控制最大重试次数。若由于系统异常触发了SDK内置的重试逻辑，则服务端需要等待最终重试结果，可能会导致消息发送请求链路被阻塞。对于某些实时调用类场景，您需要合理评估每次调用请求的超时时间以及最大重试次数，避免影响全链路的耗时。
+
+* 最终异常兜底： Apache RocketMQ 客户端内置的发送请求重试机制并不能保证消息发送一定成功。当最终重试仍然失败时，业务方调用需要捕获异常，并做好冗余保护处理，避免消息发送结果不一致。
+
+* 消息重复问题：因远程调用的不确定性，当Apache RocketMQ客户端因请求超时触发消息发送重试流程，此时客户端无法感知服务端的处理结果，客户端进行的消息发送重试可能会产生消息重复问题，业务逻辑需要自行处理消息重复问题。
+
+
+## 消息流控机制
+
+### 消息流控基本概念
+
+消息流控指的是系统容量或水位过高， Apache RocketMQ 服务端会通过快速失败返回流控错误来避免底层资源承受过高压力。
+
+### 触发条件
+
+Apache RocketMQ 的消息流控触发条件如下：
+
+* 存储压力大：参考[消费进度管理](./09consumerprogress.md)的原理机制，消费者分组的初始消费位点为当前队列的最大消费位点。若某些场景例如业务上新等需要回溯到指定时刻前开始消费，此时队列的存储压力会瞬间飙升，触发消息流控。
+
+* 服务端请求任务排队溢出：若消费者消费能力不足，导致队列中有大量堆积消息，当堆积消息超过一定数量后会触发消息流控，减少下游消费系统压力。
+
+### 流控行为
+
+当系统触发消息发送流控时，客户端会收到系统限流错误和异常，错误码信息如下：
+
+* reply-code：530
+
+* reply-text：TOO_MANY_REQUESTS
+
+客户端收到系统流控错误码后，会根据指数退避策略进行消息发送重试。
+
+### 处理建议
+
+* 如何避免触发消息流控：触发限流的根本原因是系统容量或水位过高，您可以利用可观测性功能监控系统水位容量等，保证底层资源充足，避免触发流控机制。
+
+* 突发消息流控处理：如果因为突发原因触发消息流控，且客户端内置的重试流程执行失败，则建议业务方将请求调用临时替换到其他系统进行应急处理。
+
+
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/06consumertype.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/06consumertype.md"
new file mode 100644
index 00000000..9fe5055c
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/06consumertype.md"
@@ -0,0 +1,210 @@
+# 消费者分类
+
+Apache RocketMQ 支持 PushConsumer 、 SimpleConsumer 以及 PullConsumer 这三种类型的消费者，本文分别从使用方式、实现原理、可靠性重试和适用场景等方面为您介绍这两种类型的消费者。
+
+## 背景信息
+
+Apache RocketMQ 面向不同的业务场景提供了不同消费者类型，每种消费者类型的集成方式和控制方式都不一样。了解如下问题，可以帮助您选择更匹配业务场景的消费者类型。
+
+* 如何实现并发消费：消费者如何使用并发的多线程机制处理消息，以此提高消息处理效率？
+
+* 如何实现同步、异步消息处理：对于不同的集成场景，消费者获取消息后可能会将消息异步分发到业务逻辑中处理，此时，消息异步化处理如何实现？
+
+* 如何实现消息可靠处理：消费者处理消息时如何返回响应结果？如何在消息异常情况进行重试，保证消息的可靠处理？
+
+以上问题的具体答案，请参考下文。
+
+## 功能概述
+
+
+
+如上图所示， Apache RocketMQ 的消费者处理消息时主要经过以下阶段：消息获取---\>消息处理---\>消费状态提交。
+
+针对以上几个阶段，Apache RocketMQ 提供了不同的消费者类型： PushConsumer 、SimpleConsumer 和 PullConsumer。这几种类型的消费者通过不同的实现方式和接口可满足您在不同业务场景下的消费需求。具体差异如下：
+
+:::info
+
+在实际使用场景中，PullConsumer 仅推荐在流处理框架中集成使用，大多数消息收发场景使用 PushConsumer 和 SimpleConsumer 就可以满足需求。
+
+若您的业务场景发生变更，或您当前使用的消费者类型不适合当前业务，您可以选择在 PushConsumer 和SimpleConsumer 之间变更消费者类型。变更消费者类型不影响当前Apache RocketMQ 资源的使用和业务处理。
+
+:::
+
+:::danger
+生产环境中相同的 ConsumerGroup 下严禁混用 PullConsumer 和其他两种消费者，否则会导致消息消费异常。
+:::
+
+| 对比项 | PushConsumer | SimpleConsumer | PullConsumer |
+|---------|--------------------------------------|----------------------------|-------------------------|
+| 接口方式 | 使用监听器回调接口返回消费结果，消费者仅允许在监听器范围内处理消费逻辑。 | 业务方自行实现消息处理，并主动调用接口返回消费结果。 |业务方自行按队列拉取消息，并可选择性地提交消费结果|
+| 消费并发度管理 | 由SDK管理消费并发度。 | 由业务方消费逻辑自行管理消费线程。 |由业务方消费逻辑自行管理消费线程。|
+|负载均衡粒度| 5.0 SDK是消息粒度，更均衡，早期版本是队列维度| 消息粒度，更均衡| 队列粒度，吞吐攒批性能更好，但容易不均衡|
+| 接口灵活度 | 高度封装，不够灵活。 | 原子接口，可灵活自定义。 |原子接口，可灵活自定义。|
+| 适用场景 | 适用于无自定义流程的业务消息开发场景。 | 适用于需要高度自定义业务流程的业务开发场景。 |仅推荐在流处理框架场景下集成使用|
+
+
+
+## PushConsumer
+
+
+PushConsumers是一种高度封装的消费者类型，消费消息仅通过消费监听器处理业务并返回消费结果。消息的获取、消费状态提交以及消费重试都通过 Apache RocketMQ 的客户端SDK完成。
+
+**使用方式**
+
+PushConsumer的使用方式比较固定，在消费者初始化时注册一个消费监听器，并在消费监听器内部实现消息处理逻辑。由 Apache RocketMQ 的SDK在后台完成消息获取、触发监听器调用以及进行消息重试处理。
+
+示例代码如下：
+
+```java
+//消费示例：使用PushConsumer消费普通消息。
+ClientServiceProvider provider = ClientServiceProvider.loadService();
+ String topic = "Your Topic";
+ FilterExpression filterExpression = new FilterExpression("Your Filter Tag", FilterExpressionType.TAG);
+ PushConsumer pushConsumer = provider.newPushConsumerBuilder()
+ //设置消费者分组。
+ .setConsumerGroup("Your ConsumerGroup")
+ //设置接入点。
+ .setClientConfiguration(ClientConfiguration.newBuilder().setEndpoints("Your Endpoint").build())
+ //设置预绑定的订阅关系。
+ .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
+ //设置消费监听器。
+ .setMessageListener(new MessageListener() {
+ @Override
+ public ConsumeResult consume(MessageView messageView) {
+ //消费消息并返回处理结果。
+ return ConsumeResult.SUCCESS;
+ }
+ })
+ .build();
+
+```
+
+PushConsumer的消费监听器执行结果分为以下三种情况：
+
+* 返回消费成功：以Java SDK为例，返回`ConsumeResult.SUCCESS`，表示该消息处理成功，服务端按照消费结果更新消费进度。
+
+* 返回消费失败：以Java SDK为例，返回`ConsumeResult.FAILURE`，表示该消息处理失败，需要根据消费重试逻辑判断是否进行重试消费。
+
+* 出现非预期失败：例如抛异常等行为，该结果按照消费失败处理，需要根据消费重试逻辑判断是否进行重试消费。
+
+
+PushConsumer 消费消息时，若消息处理逻辑出现预期之外的阻塞导致消息处理一直无法执行成功，SDK会按照消费超时处理强制提交消费失败结果，并按照消费重试逻辑进行处理。消息超时，请参见[PushConsumer消费重试策略](./10consumerretrypolicy.md)。
+
+:::info
+出现消费超时情况时，SDK虽然提交消费失败结果，但是当前消费线程可能仍然无法响应中断，还会继续处理消息。
+:::
+
+**内部原理**
+
+在PushConsumer类型中，消息的实时处理能力是基于SDK内部的典型Reactor线程模型实现的。如下图所示，SDK内置了一个长轮询线程，先将消息异步拉取到SDK内置的缓存队列中，再分别提交到消费线程中，触发监听器执行本地消费逻辑。
+
+
+可靠性重试
+
+PushConsumer 消费者类型中，客户端SDK和消费逻辑的唯一边界是消费监听器接口。客户端SDK严格按照监听器的返回结果判断消息是否消费成功，并做可靠性重试。所有消息必须以同步方式进行消费处理，并在监听器接口结束时返回调用结果，不允许再做异步化分发。消息重试具体信息，请参见[PushConsumer消费重试策略](./10consumerretrypolicy.md)。
+
+使用PushConsumer消费者消费时，不允许使用以下方式处理消息，否则 Apache RocketMQ 无法保证消息的可靠性。
+
+* 错误方式一：消息还未处理完成，就提前返回消费成功结果。此时如果消息消费失败，Apache RocketMQ 服务端是无法感知的，因此不会进行消费重试。
+
+* 错误方式二：在消费监听器内将消息再次分发到自定义的其他线程，消费监听器提前返回消费结果。此时如果消息消费失败，Apache RocketMQ 服务端同样无法感知，因此也不会进行消费重试。
+
+顺序性保障
+
+基于 Apache RocketMQ
+[顺序消息](./03fifomessage.md)的定义，如果消费者分组设置了顺序消费模式，则PushConsumer在触发消费监听器时，严格遵循消息的先后顺序。业务处理逻辑无感知即可保证消息的消费顺序。
+
+:::info
+消息消费按照顺序处理的前提是遵循同步提交原则，如果业务逻辑自定义实现了异步分发，则Apache RocketMQ 无法保证消息的顺序性。
+:::
+
+适用场景
+
+PushConsumer严格限制了消息同步处理及每条消息的处理超时时间，适用于以下场景：
+
+* 消息处理时间可预估：如果不确定消息处理耗时，经常有预期之外的长时间耗时的消息，PushConsumer的可靠性保证会频繁触发消息重试机制造成大量重复消息。
+
+* 无异步化、高级定制场景：PushConsumer限制了消费逻辑的线程模型，由客户端SDK内部按最大吞吐量触发消息处理。该模型开发逻辑简单，但是不允许使用异步化和自定义处理流程。
+
+
+
+
+## SimpleConsumer
+
+SimpleConsumer 是一种接口原子型的消费者类型，消息的获取、消费状态提交以及消费重试都是通过消费者业务逻辑主动发起调用完成。
+
+**使用方式**
+
+SimpleConsumer 的使用涉及多个接口调用，由业务逻辑按需调用接口获取消息，然后分发给业务线程处理消息，最后按照处理的结果调用提交接口，返回服务端当前消息的处理结果。示例如下：
+
+```java
+ //消费示例：使用SimpleConsumer消费普通消息，主动获取消息处理并提交。
+ ClientServiceProvider provider1 = ClientServiceProvider.loadService();
+ String topic1 = "Your Topic";
+ FilterExpression filterExpression1 = new FilterExpression("Your Filter Tag", FilterExpressionType.TAG);
+ SimpleConsumer simpleConsumer = provider1.newSimpleConsumerBuilder()
+ //设置消费者分组。
+ .setConsumerGroup("Your ConsumerGroup")
+ //设置接入点。
+ .setClientConfiguration(ClientConfiguration.newBuilder().setEndpoints("Your Endpoint").build())
+ //设置预绑定的订阅关系。
+ .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
+ .build();
+ List<MessageView> messageViewList = null;
+ try {
+ //SimpleConsumer需要主动获取消息，并处理。
+ messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
+ messageViewList.forEach(messageView -> {
+ System.out.println(messageView);
+ //消费处理完成后，需要主动调用ACK提交消费结果。
+ try {
+ simpleConsumer.ack(messageView);
+ } catch (ClientException e) {
+ e.printStackTrace();
+ }
+ });
+ } catch (ClientException e) {
+ //如果遇到系统流控等原因造成拉取失败，需要重新发起获取消息请求。
+ e.printStackTrace();
+ }
+```
+
+SimpleConsumer主要涉及以下几个接口行为：
+
+
+| 接口名称 | 主要作用 | 可修改参数 [...]
+|---------------------------|-----------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [...]
+| `ReceiveMessage` | 消费者主动调用该接口从服务端获取消息。 **说明** 由于服务端存储为分布式，可能会出现服务端实际有消息，但是返回为空的现象。 一般可通过重新发起ReceiveMessage调用或提高ReceiveMessage的并发度解决。 | * 批量拉取消息数：SimpleConsumer可以一次性批量获取多条消息实现批量消费，该接口可修改批量获取的消息数量。 * 消费不可见时间：消息的最长处理耗时，该参数用于控制消费失败时的消息重试间隔。具体信息，请参见[SimpleConsumer消费重试策略](./10consumerretrypolicy.md)。消费者调用`ReceiveMessage`接口时需要指定消费不可见时间。 |
+| `AckMessage` | 消费者成功消费消息后，主动调用该接口向服务端返回消费成功响应。 | 无 [...]
+| `ChangeInvisibleDuration` | 消费重试场景下，消费者可通过该接口修改消息处理时长，即控制消息的重试间隔。 | 消费不可见时间：调用本接口可修改`ReceiveMessage`接口预设的消费不可见时间的参数值。一般用于需要延长消息处理时长的场景。 |
+
+
+
+**可靠性重试**
+
+SimpleConsumer消费者类型中，客户端SDK和服务端通过`ReceiveMessage`和`AckMessage`接口通信。客户端SDK如果处理消息成功则调用`AckMessage`接口；如果处理失败只需要不回复ACK响应，即可在定义的消费不可见时间到达后触发消费重试流程。更多信息，请参见[SimpleConsumer消费重试策略](./10consumerretrypolicy.md)。
+
+**顺序性保障**
+
+基于 Apache RocketMQ [顺序消息](./03fifomessage.md)的定义，SimpleConsumer在处理顺序消息时，会按照消息存储的先后顺序获取消息。即需要保持顺序的一组消息中，如果前面的消息未处理完成，则无法获取到后面的消息。
+
+适用场景
+
+SimpleConsumer提供原子接口，用于消息获取和提交消费结果，相对于PushConsumer方式更加灵活。SimpleConsumer适用于以下场景：
+
+* 消息处理时长不可控：如果消息处理时长无法预估，经常有长时间耗时的消息处理情况。建议使用SimpleConsumer消费类型，可以在消费时自定义消息的预估处理时长，若实际业务中预估的消息处理时长不符合预期，也可以通过接口提前修改。
+
+* 需要异步化、批量消费等高级定制场景：SimpleConsumer在SDK内部没有复杂的线程封装，完全由业务逻辑自由定制，可以实现异步分发、批量消费等高级定制场景。
+
+* 需要自定义消费速率：SimpleConsumer是由业务逻辑主动调用接口获取消息，因此可以自由调整获取消息的频率，自定义控制消费速率。
+
+## PullConsumer
+
+待补充。。
+
+
+## 使用建议
+
+**PushConsumer合理控制消费耗时，避免无限阻塞**
+
+对于PushConsumer消费类型，需要严格控制消息的消费耗时，尽量避免出现消息处理超时导致消息重复。如果业务经常会出现一些预期外的长时间耗时的消息，建议使用SimpleConsumer，并设置好消费不可见时间。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/07messagefilter.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/07messagefilter.md"
new file mode 100644
index 00000000..8d8e87e0
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/07messagefilter.md"
@@ -0,0 +1,287 @@
+# 消息过滤
+
+消费者订阅了某个主题后，Apache RocketMQ 会将该主题中的所有消息投递给消费者。若消费者只需要关注部分消息，可通过设置过滤条件在 Apache RocketMQ 服务端进行过滤，只获取到需要关注的消息子集，避免接收到大量无效的消息。本文介绍消息过滤的定义、原理、分类及不同过滤方式的使用方法、配置示例等。
+
+## 应用场景
+
+Apache RocketMQ 作为发布订阅模型的消息中间件广泛应用于上下游业务集成场景。在实际业务场景中，同一个主题下的消息往往会被多个不同的下游业务方处理，各下游的处理逻辑不同，只关注自身逻辑需要的消息子集。
+
+使用 Apache RocketMQ 的消息过滤功能，可以帮助消费者更高效地过滤自己需要的消息集合，避免大量无效消息投递给消费者，降低下游系统处理压力。
+
+Apache RocketMQ 主要解决的单个业务域即同一个主题内不同消息子集的过滤问题，一般是基于同一业务下更具体的分类进行过滤匹配。如果是需要对不同业务域的消息进行拆分，建议使用不同主题处理不同业务域的消息。
+
+## 功能概述
+
+**消息过滤定义**
+
+过滤的含义指的是将符合条件的消息投递给消费者，而不是将匹配到的消息过滤掉。
+
+
+Apache RocketMQ 的消息过滤功能通过生产者和消费者对消息的属性、标签进行定义，并在 Apache RocketMQ 服务端根据过滤条件进行筛选匹配，将符合条件的消息投递给消费者进行消费。
+
+**消息过滤原理**
+
+
+消息过滤主要通过以下几个关键流程实现：
+
+* 生产者：生产者在初始化消息时预先为消息设置一些属性和标签，用于后续消费时指定过滤目标。
+
+* 消费者：消费者在初始化及后续消费流程中通过调用订阅关系注册接口，向服务端上报需要订阅指定主题的哪些消息，即过滤条件。
+
+* 服务端：消费者获取消息时会触发服务端的动态过滤计算，Apache RocketMQ 服务端根据消费者上报的过滤条件的表达式进行匹配，并将符合条件的消息投递给消费者。
+
+**消息过滤分类**
+
+Apache RocketMQ 支持Tag标签过滤和SQL属性过滤，这两种过滤方式对比如下：
+
+
+
+| 对比项 | Tag标签过滤 | SQL属性过滤 |
+|------|------------------|------------------------------------|
+| 过滤目标 | 消息的Tag标签。 | 消息的属性，包括用户自定义属性以及系统属性（Tag是一种系统属性）。 |
+| 过滤能力 | 精准匹配。 | SQL语法匹配。 |
+| 适用场景 | 简单过滤场景、计算逻辑简单轻量。 | 复杂过滤场景、计算逻辑较复杂。 |
+
+
+具体的使用方式及示例，请参见下文的Tag标签过滤和SQL属性过滤。
+
+## 订阅关系一致性
+
+过滤表达式属于订阅关系的一部分，Apache RocketMQ 的领域模型规定，同一消费者分组内的多个消费者的订阅关系包括过滤表达式，必须保持一致，否则可能会导致部分消息消费不到。更多信息，请参见[订阅关系（Subscription）](../03-领域模型/09subscription.md)。
+
+## Tag标签过滤
+
+Tag标签过滤方式是 Apache RocketMQ 提供的基础消息过滤能力，基于生产者为消息设置的Tag标签进行匹配。生产者在发送消息时，设置消息的Tag标签，消费者需指定已有的Tag标签来进行匹配订阅。
+
+**场景示例**
+
+以下图电商交易场景为例，从客户下单到收到商品这一过程会生产一系列消息：
+
+* 订单消息
+
+* 支付消息
+
+* 物流消息
+
+这些消息会发送到名称为Trade_Topic的Topic中，被各个不同的下游系统所订阅：
+
+* 支付系统：只需订阅支付消息。
+
+* 物流系统：只需订阅物流消息。
+
+* 交易成功率分析系统：需订阅订单和支付消息。
+
+* 实时计算系统：需要订阅所有和交易相关的消息。
+
+过滤效果如下图所示：
+
+**Tag标签设置**
+
+* Tag由生产者发送消息时设置，每条消息允许设置一个Tag标签。
+
+* Tag使用可见字符，建议长度不超过128字符。
+
+
+**Tag标签过滤规则**
+
+Tag标签过滤为精准字符串匹配，过滤规则设置格式如下：
+
+* 单Tag匹配：过滤表达式为目标Tag。表示只有消息标签为指定目标Tag的消息符合匹配条件，会被发送给消费者。
+
+* 多Tag匹配：多个Tag之间为或的关系，不同Tag间使用两个竖线（\|\|）隔开。例如，Tag1\|\|Tag2\|\|Tag3，表示标签为Tag1或Tag2或Tag3的消息都满足匹配条件，都会被发送给消费者进行消费。
+
+* 全部匹配：使用星号（\*）作为全匹配表达式。表示主题下的所有消息都将被发送给消费者进行消费。
+
+
+
+
+**使用示例**
+
+* 发送消息，设置Tag标签。
+
+ ```java
+ Message message = messageBuilder.setTopic("topic")
+ //设置消息索引键，可根据关键字精确查找某条消息。
+ .setKeys("messageKey")
+ //设置消息Tag，用于消费端根据指定Tag过滤消息。
+ //该示例表示消息的Tag设置为"TagA"。
+ .setTag("TagA")
+ //消息体。
+ .setBody("messageBody".getBytes())
+ .build();
+ ```
+
+
+
+* 订阅消息，匹配单个Tag标签。
+
+ ```java
+ String topic = "Your Topic";
+ //只订阅消息标签为"TagA"的消息。
+ FilterExpression filterExpression = new FilterExpression("TagA", FilterExpressionType.TAG);
+ pushConsumer.subscribe(topic, filterExpression);
+ ```
+
+
+
+* 订阅消息，匹配多个Tag标签。
+
+ ```java
+ String topic = "Your Topic";
+ //只订阅消息标签为"TagA"、"TagB"或"TagC"的消息。
+ FilterExpression filterExpression = new FilterExpression("TagA||TagB||TagC", FilterExpressionType.TAG);
+ pushConsumer.subscribe(topic, filterExpression);
+ ```
+
+
+
+* 订阅消息，匹配Topic中的所有消息，不进行过滤。
+
+ ```java
+ String topic = "Your Topic";
+ //使用Tag标签过滤消息，订阅所有消息。
+ FilterExpression filterExpression = new FilterExpression("*", FilterExpressionType.TAG);
+ pushConsumer.subscribe(topic, filterExpression);
+ ```
+
+
+
+
+
+
+## SQL属性过滤
+
+SQL属性过滤是 Apache RocketMQ 提供的高级消息过滤方式，通过生产者为消息设置的属性（Key）及属性值（Value）进行匹配。生产者在发送消息时可设置多个属性，消费者订阅时可设置SQL语法的过滤表达式过滤多个属性。
+
+:::info
+Tag是一种系统属性，所以SQL过滤方式也兼容Tag标签过滤。在SQL语法中，Tag的属性名称为TAGS。
+:::
+
+**场景示例**
+
+以下图电商交易场景为例，从客户下单到收到商品这一过程会生产一系列消息，按照类型将消息分为订单消息和物流消息，其中给物流消息定义地域属性，按照地域分为杭州和上海：
+
+* 订单消息
+
+* 物流消息
+ * 物流消息且地域为杭州
+
+ * 物流消息且地域为上海
+
+这些消息会发送到名称为Trade_Topic的Topic中，被各个不同的系统所订阅：
+
+* 物流系统1：只需订阅物流消息且消息地域为杭州。
+
+* 物流系统2：只需订阅物流消息且消息地域为杭州或上海。
+
+* 订单跟踪系统：只需订阅订单消息。
+
+* 实时计算系统：需要订阅所有和交易相关的消息。
+
+
+
+
+过滤效果如下图所示：
+
+**消息属性设置**
+
+生产者发送消息时可以自定义消息属性，每个属性都是一个自定义的键值对（Key-Value）。
+
+每条消息支持设置多个属性。
+
+**SQL属性过滤规则**
+
+SQL属性过滤使用SQL92语法作为过滤规则表达式，语法规范如下：
+
+
+| 语法 | 说明 | 示例 |
+|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| IS NULL | 判断属性不存在。 | `a IS NULL` ：属性a不存在。 |
+| IS NOT NULL | 判断属性存在。 | `a IS NOT NULL`：属性a存在。 |
+| * \> * \>= * \< * \<= | 用于比较数字，不能用于比较字符串，否则消费者客户端启动时会报错。 **说明** 可转化为数字的字符串也被认为是数字。 | * `a IS NOT NULL AND a > 100`：属性a存在且属性a的值大于100。 * `a IS NOT NULL AND a > 'abc'`：错误示例，abc为字符串，不能用于比较大小。 |
+| BETWEEN xxx AND xxx | 用于比较数字，不能用于比较字符串，否则消费者客户端启动时会报错。等价于\>= xxx AND \<= xxx。表示属性值在两个数字之间。 | `a IS NOT NULL AND (a BETWEEN 10 AND 100)`：属性a存在且属性a的值大于等于10且小于等于100。 |
+| NOT BETWEEN xxx AND xxx | 用于比较数字，不能用于比较字符串，否则消费者客户端启动会报错。等价于\< xxx OR \> xxx，表示属性值在两个值的区间之外。 | `a IS NOT NULL AND (a NOT BETWEEN 10 AND 100)`：属性a存在且属性a的值小于10或大于100。 |
+| IN (xxx, xxx) | 表示属性的值在某个集合内。集合的元素只能是字符串。 | `a IS NOT NULL AND (a IN ('abc', 'def'))`：属性a存在且属性a的值为abc或def。 |
+| * = * \<\> | 等于和不等于。可用于比较数字和字符串。 | `a IS NOT NULL AND (a = 'abc' OR a<>'def')`：属性a存在且属性a的值为abc或a的值不为def。 |
+| * AND * OR | 逻辑与、逻辑或。可用于组合任意简单的逻辑判断，需要将每个逻辑判断内容放入括号内。 | `a IS NOT NULL AND (a > 100) OR (b IS NULL)`：属性a存在且属性a的值大于100或属性b不存在。 |
+
+
+
+由于SQL属性过滤是生产者定义消息属性，消费者设置SQL过滤条件，因此过滤条件的计算结果具有不确定性，服务端的处理方式如下：
+
+* 异常情况处理：如果过滤条件的表达式计算抛异常，消息默认被过滤，不会被投递给消费者。例如比较数字和非数字类型的值。
+
+* 空值情况处理：如果过滤条件的表达式计算值为null或不是布尔类型（true和false），则消息默认被过滤，不会被投递给消费者。例如发送消息时未定义某个属性，在订阅时过滤条件中直接使用该属性，则过滤条件的表达式计算结果为null。
+
+* 数值类型不符处理：如果消息自定义属性为浮点型，但过滤条件中使用整数进行判断，则消息默认被过滤，不会被投递给消费者。
+
+
+
+
+**使用示例**
+
+* 发送消息，同时设置消息Tag标签和自定义属性。
+
+ ```java
+ Message message = messageBuilder.setTopic("topic")
+ //设置消息索引键，可根据关键字精确查找某条消息。
+ .setKeys("messageKey")
+ //设置消息Tag，用于消费端根据指定Tag过滤消息。
+ //该示例表示消息的Tag设置为"messageTag"。
+ .setTag("messageTag")
+ //消息也可以设置自定义的分类属性，例如环境标签、地域、逻辑分支。
+ //该示例表示为消息自定义一个属性，该属性为地域，属性值为杭州。
+ .addProperty("Region", "Hangzhou")
+ //消息体。
+ .setBody("messageBody".getBytes())
+ .build();
+ ```
+
+
+
+* 订阅消息，根据单个自定义属性匹配消息。
+
+ ```java
+ String topic = "topic";
+ //只订阅地域属性为杭州的消息。
+ FilterExpression filterExpression = new FilterExpression("Region IS NOT NULL AND Region='Hangzhou'", FilterExpressionType.SQL92);
+ simpleConsumer.subscribe(topic, filterExpression);
+ ```
+
+
+
+* 订阅消息，同时根据多个自定义属性匹配消息。
+
+ ```java
+ String topic = "topic";
+ //只订阅地域属性为杭州且价格属性大于30的消息。
+ FilterExpression filterExpression = new FilterExpression("Region IS NOT NULL AND price IS NOT NULL AND Region = 'Hangzhou' AND price > 30", FilterExpressionType.SQL92);
+ simpleConsumer.subscribe(topic, filterExpression);
+ ```
+
+
+
+* 订阅消息，匹配Topic中的所有消息，不进行过滤。
+
+ ```java
+ String topic = "topic";
+ //订阅所有消息。
+ FilterExpression filterExpression = new FilterExpression("True", FilterExpressionType.SQL92);
+ simpleConsumer.subscribe(topic, filterExpression);
+ ```
+
+## 使用建议
+
+**合理划分主题和Tag标签**
+
+从消息的过滤机制和主题的原理机制可以看出，业务消息的拆分可以基于主题进行筛选，也可以基于主题内消息的Tag标签及属性进行筛选。关于拆分方式的选择，应遵循以下原则：
+
+* 消息类型是否一致：不同类型的消息，如顺序消息和普通消息需要使用不同的主题进行拆分，无法通过Tag标签进行分类。
+
+* 业务域是否相同：不同业务域和部门的消息应该拆分不同的主题。例如物流消息和支付消息应该使用两个不同的主题；同样是一个主题内的物流消息，普通物流消息和加急物流消息则可以通过不同的Tag进行区分。
+
+* 消息量级和重要性是否一致：如果消息的量级规模存在巨大差异，或者说消息的链路重要程度存在差异，则应该使用不同的主题进行隔离拆分。
+
+
+
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/08consumerloadbalance.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/08consumerloadbalance.md"
new file mode 100644
index 00000000..6281bf01
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/08consumerloadbalance.md"
@@ -0,0 +1,169 @@
+# 消费者负载均衡
+
+消费者从 Apache RocketMQ 获取消息消费时，通过消费者负载均衡策略，可将主题内的消息分配给指定消费者分组中的多个消费者共同分担，提高消费并发能力和消费者的水平扩展能力。本文介绍 Apache RocketMQ 消费者的负载均衡策略。
+
+## 背景信息
+
+了解消费者负载均衡策略，可以帮助您解决以下问题：
+
+* 消息消费处理的容灾策略：您可以根据消费者负载均衡策略，明确当局部节点出现故障时，消息如何进行消费重试和容灾切换。
+
+* 消息消费的顺序性机制：通过消费者负载均衡策略，您可以进一步了解消息消费时，如何保证同一消息组内消息的先后顺序。
+
+* 消息分配的水平拆分策略：了解消费者负载均衡策略，您可以明确消息消费压力如何被分配到不同节点，有针对性地进行流量迁移和水平扩缩容。
+
+
+
+
+## 广播消费和共享消费
+
+在 Apache RocketMQ 领域模型中，同一条消息支持被多个消费者分组订阅，同时，对于每个消费者分组可以初始化多个消费者。您可以根据消费者分组和消费者的不同组合，实现以下两种不同的消费效果：
+
+* **消费组间广播消费** ：如上图所示，每个消费者分组只初始化唯一一个消费者，每个消费者可消费到消费者分组内所有的消息，各消费者分组都订阅相同的消息，以此实现单客户端级别的广播一对多推送效果。
+
+ 该方式一般可用于网关推送、配置推送等场景。
+
+
+* **消费组内共享消费** ：如上图所示，每个消费者分组下初始化了多个消费者，这些消费者共同分担消费者分组内的所有消息，实现消费者分组内流量的水平拆分和均衡负载。
+
+ 该方式一般可用于微服务解耦场景。
+
+
+## 什么是消费者负载均衡
+
+如上文所述，消费组间广播消费场景下，每个消费者分组内只有一个消费者，因此不涉及消费者的负载均衡。
+
+消费组内共享消费场景下，消费者分组内多个消费者共同分担消息，消息按照哪种逻辑分配给哪个消费者，就是由消费者负载均衡策略所决定的。
+
+根据消费者类型的不同，消费者负载均衡策略分为以下两种模式：
+
+* [消息粒度负载均衡](#section-x2b-2cu-gpf)：PushConsumer和SimpleConsumer默认负载策略
+
+* [队列粒度负载均衡](#section-n9m-6xy-y77)：PullConsumer默认负载策略
+
+
+
+
+## 消息粒度负载均衡
+
+**使用范围**
+
+对于PushConsumer和SimpleConsumer类型的消费者，默认且仅使用消息粒度负载均衡策略。
+
+:::note
+上述说明是指5.0 SDK下，PushConsumer默认使用消息粒度负载均衡，对于3.x/4.x等Remoting协议SDK 仍然使用了队列粒度负载均衡。业务集成如无特殊需求，建议使用新版本机制。
+:::
+
+**策略原理**
+
+消息粒度负载均衡策略中，同一消费者分组内的多个消费者将按照消息粒度平均分摊主题中的所有消息，即同一个队列中的消息，可被平均分配给多个消费者共同消费。
+
+
+如上图所示，消费者分组Group A中有三个消费者A1、A2和A3，这三个消费者将共同消费主题中同一队列Queue1中的多条消息。
+**注意** 消息粒度负载均衡策略保证同一个队列的消息可以被多个消费者共同处理，但是该策略使用的消息分配算法结果是随机的，并不能指定消息被哪一个特定的消费者处理。
+
+消息粒度的负载均衡机制，是基于内部的单条消息确认语义实现的。消费者获取某条消息后，服务端会将该消息加锁，保证这条消息对其他消费者不可见，直到该消息消费成功或消费超时。因此，即使多个消费者同时消费同一队列的消息，服务端也可保证消息不会被多个消费者重复消费。
+
+**顺序消息负载机制**
+
+在顺序消息中，消息的顺序性指的是同一消息组内的多个消息之间的先后顺序。因此，顺序消息场景下，消息粒度负载均衡策略还需要保证同一消息组内的消息，按照服务端存储的先后顺序进行消费。不同消费者处理同一个消息组内的消息时，会严格按照先后顺序锁定消息状态，确保同一消息组的消息串行消费。
+
+
+如上图所述，队列Queue1中有4条顺序消息，这4条消息属于同一消息组G1，存储顺序由M1到M4。在消费过程中，前面的消息M1、M2被消费者Consumer A1处理时，只要消费状态没有提交，消费者A2是无法并行消费后续的M3、M4消息的，必须等前面的消息提交消费状态后才能消费后面的消息。
+
+**策略特点**
+
+相对于队列粒度负载均衡策略，消息粒度负载均衡策略有以下特点：
+
+* 消费分摊更均衡传统队列级的负载均衡策略中，如果队列数量和消费者数量不均衡，则可能会出现部分消费者空闲，或部分消费者处理过多消息的情况。消息粒度负载均衡策略无需关注消费者和队列的相对数量，能够更均匀地分摊消息。
+
+* 对非对等消费者更友好对于线上生产环境，由于网络机房分区延迟、消费者物理资源规格不一致等原因，消费者的处理能力可能会不一致，如果按照队列分配消息，则可能出现部分消费者消息堆积、部分消费者空闲的情况。消息粒度负载均衡策略按需分配，消费者处理任务更均衡。
+
+* 队列分配运维更方便传统基于绑定队列的负载均衡策略，必须保证队列数量大于等于消费者数量，以免产生部分消费者获取不到队列出现空转的情况，而消息粒度负载均衡策略则无需关注队列数。
+
+
+**适用场景**
+
+消息粒度消费负载均衡策略下，同一队列内的消息离散地分布于多个消费者，适用于绝大多数在线事件处理的场景。只需要基本的消息处理能力，对消息之间没有批量聚合的诉求。而对于流式处理、聚合计算场景，需要明确地对消息进行聚合、批处理时，更适合使用队列粒度的负载均衡策略。
+
+**使用示例**
+
+消息粒度负载均衡策略不需要额外设置，对于PushConsumer和SimpleConsumer消费者类型默认启用。
+
+```java
+SimpleConsumer simpleConsumer = null;
+ //消费示例一：使用PushConsumer消费普通消息，只需要在消费监听器处理即可，无需关注消息负载均衡。
+ MessageListener messageListener = new MessageListener() {
+ @Override
+ public ConsumeResult consume(MessageView messageView) {
+ System.out.println(messageView);
+ //根据消费结果返回状态。
+ return ConsumeResult.SUCCESS;
+ }
+ };
+ //消费示例二：使用SimpleConsumer消费普通消息，主动获取消息处理并提交。会按照订阅的主题自动获取，无需关注消息负载均衡。
+ List<MessageView> messageViewList = null;
+ try {
+ messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
+ messageViewList.forEach(messageView -> {
+ System.out.println(messageView);
+ //消费处理完成后，需要主动调用ACK提交消费结果。
+ try {
+ simpleConsumer.ack(messageView);
+ } catch (ClientException e) {
+ e.printStackTrace();
+ }
+ });
+ } catch (ClientException e) {
+ //如果遇到系统流控等原因造成拉取失败，需要重新发起获取消息请求。
+ e.printStackTrace();
+ }
+
+```
+
+
+
+## 队列粒度负载均衡
+
+**使用范围**
+
+对于历史版本（服务端4.x/3.x版本）的消费者，包括PullConsumer、DefaultPushConsumer、DefaultPullConsumer、LitePullConsumer等，默认且仅能使用队列粒度负载均衡策略。
+
+**策略原理**
+
+队列粒度负载均衡策略中，同一消费者分组内的多个消费者将按照队列粒度消费消息，即每个队列仅被一个消费者消费。
+
+
+如上图所示，主题中的三个队列Queue1、Queue2、Queue3被分配给消费者分组中的两个消费者，每个队列只能分配给一个消费者消费，该示例中由于队列数大于消费者数，因此，消费者A2被分配了两个队列。若队列数小于消费者数量，可能会出现部分消费者无绑定队列的情况。
+
+队列粒度的负载均衡，基于队列数量、消费者数量等运行数据进行统一的算法分配，将每个队列绑定到特定的消费者，然后每个消费者按照取消息\>提交消费位点\>持久化消费位点的消费语义处理消息，取消息过程不提交消费状态，因此，为了避免消息被多个消费者重复消费，每个队列仅支持被一个消费者消费。
+:::note
+队列粒度负载均衡策略保证同一个队列仅被一个消费者处理，该策略的实现依赖消费者和服务端的信息协商机制，Apache RocketMQ 并不能保证协商结果完全强一致。因此，在消费者数量、队列数量发生变化时，可能会出现短暂的队列分配结果不一致，从而导致少量消息被重复处理。
+:::
+
+
+**策略特点**
+
+相对于消息粒度负载均衡策略，队列粒度负载均衡策略分配粒度较大，不够灵活。但该策略在流式处理场景下有天然优势，能够保证同一队列的消息被相同的消费者处理，对于批量处理、聚合处理更友好。
+
+**适用场景**
+
+队列粒度负载均衡策略适用于流式计算、数据聚合等需要明确对消息进行聚合、批处理的场景。
+
+**使用示例**
+
+队列粒度负载均衡策略不需要额外设置，对于历史版本（服务端4.x/3.x版本）的消费者类型PullConsumer默认启用。
+
+具体示例代码，请访问[RocketMQ代码库](https://github.com/apache/rocketmq/blob/develop/example/src/main/java/org/apache/rocketmq/example/simple/LitePullConsumerAssign.java)获取。
+
+## 版本兼容性
+
+消息粒度的负载均衡策略从 Apache RocketMQ 服务端5.0版本开始支持，历史版本4.x/3.x版本仅支持队列粒度的负载均衡策略。
+
+当您使用的 Apache RocketMQ 服务端版本为5.x版本时，两种消费者负载均衡策略均支持，具体生效的负载均衡策略依客户端版本和消费者类型而定。
+
+## 使用建议
+
+**针对消费逻辑做消息幂等**
+
+无论是消息粒度负载均衡策略还是队列粒度负载均衡策略，在消费者上线或下线、服务端扩缩容等场景下，都会触发短暂的重新负载均衡动作。此时可能会存在短暂的负载不一致情况，出现少量消息重复的现象。因此，需要在下游消费逻辑中做好消息幂等去重处理。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/09consumerprogress.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/09consumerprogress.md"
new file mode 100644
index 00000000..81ea6d0d
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/09consumerprogress.md"
@@ -0,0 +1,101 @@
+# 消费进度管理
+Apache RocketMQ 通过消费位点管理消费进度，本文为您介绍 Apache RocketMQ 的消费进度管理机制。
+
+## 背景信息
+
+Apache RocketMQ 的生产者和消费者在进行消息收发时，必然会涉及以下场景，消息先生产后订阅或先订阅后生产。这两种场景下，消费者客户端启动后从哪里开始消费？如何标记已消费的消息？这些都是由 Apache RocketMQ 的消费进度管理机制来定义的。
+
+通过了解 Apache RocketMQ 的消费进度管理机制，可以帮助您解答以下问题：
+
+* 消费者启动后从哪里开始消费消息？
+
+* 消费者每次消费成功后如何标记消息状态，确保下次不会再重复处理该消息？
+
+* 某消息被指定消费者消费过一次后，如果业务出现异常需要做故障恢复，该消息能否被重新消费？
+
+
+
+
+## 消费进度原理
+
+
+**消息位点（Offset）**
+
+参考 Apache RocketMQ [主题](../03-领域模型/02topic.md)和[队列](../03-领域模型/03messagequeue.md)的定义，消息是按到达服务端的先后顺序存储在指定主题的多个队列中，每条消息在队列中都有一个唯一的Long类型坐标，这个坐标被定义为消息位点。
+
+任意一个消息队列在逻辑上都是无限存储，即消息位点会从0到Long.MAX无限增加。通过主题、队列和位点就可以定位任意一条消息的位置，具体关系如下图所示：
+
+
+Apache RocketMQ 定义队列中最早一条消息的位点为最小消息位点（MinOffset）；最新一条消息的位点为最大消息位点（MaxOffset）。虽然消息队列逻辑上是无限存储，但由于服务端物理节点的存储空间有限， Apache RocketMQ 会滚动删除队列中存储最早的消息。因此，消息的最小消费位点和最大消费位点会一直递增变化。
+
+**消费位点（ConsumerOffset）**
+
+Apache RocketMQ 领域模型为发布订阅模式，每个主题的队列都可以被多个消费者分组订阅。若某条消息被某个消费者消费后直接被删除，则其他订阅了该主题的消费者将无法消费该消息。
+
+因此，Apache RocketMQ 通过消费位点管理消息的消费进度。每条消息被某个消费者消费完成后不会立即在队列中删除，Apache RocketMQ 会基于每个消费者分组维护一份消费记录，该记录指定消费者分组消费某一个队列时，消费过的最新一条消息的位点，即消费位点。
+
+当消费者客户端离线，又再次重新上线时，会严格按照服务端保存的消费进度继续处理消息。如果服务端保存的历史位点信息已过期被删除，此时消费位点向前移动至服务端存储的最小位点。
+:::info
+消费位点的保存和恢复是基于 Apache RocketMQ 服务端的存储实现，和任何消费者无关。因此 Apache RocketMQ 支持跨消费者的消费进度恢复。
+:::
+
+队列中消息位点MinOffset、MaxOffset和每个消费者分组的消费位点ConsumerOffset的关系如下：
+
+* ConsumerOffset≤MaxOffset：
+ * 当消费速度和生产速度一致，且全部消息都处理完成时，最大消息位点和消费位点相同，即ConsumerOffset=MaxOffset。
+
+ * 当消费速度较慢小于生产速度时，队列中会有部分消息未消费，此时消费位点小于最大消息位点，即ConsumerOffset\<MaxOffset，两者之差就是该队列中堆积的消息量。
+
+* ConsumerOffset≥MinOffset：正常情况下有效的消费位点ConsumerOffset必然大于等于最小消息位点MinOffset。消费位点小于最小消息位点时是无效的，相当于消费者要消费的消息已经从队列中删除了，是无法消费到的，此时服务端会将消费位点强制纠正到合法的消息位点。
+
+**消费位点初始值**
+
+消费位点初始值指的是消费者分组首次启动消费者消费消息时，服务端保存的消费位点的初始值。
+
+Apache RocketMQ 定义消费位点的初始值为消费者首次获取消息时，该时刻队列中的最大消息位点。相当于消费者将从队列中最新的消息开始消费。
+
+## 重置消费位点
+
+若消费者分组的初始消费位点或当前消费位点不符合您的业务预期，您可以通过重置消费位点调整您的消费进度。
+
+**适用场景**
+
+* 初始消费位点不符合需求：因初始消费位点为当前队列的最大消息位点，即客户端会直接从最新消息开始消费。若业务上线时需要消费部分历史消息，您可以通过重置消费位点功能消费到指定时刻前的消息。
+
+* 消费堆积快速清理：当下游消费系统性能不足或消费速度小于生产速度时，会产生大量堆积消息。若这部分堆积消息可以丢弃，您可以通过重置消费位点快速将消费位点更新到指定位置，绕过这部分堆积的消息，减少下游处理压力。
+
+* 业务回溯，纠正处理：由于业务消费逻辑出现异常，消息被错误处理。若您希望重新消费这些已被处理的消息，可以通过重置消费位点快速将消费位点更新到历史指定位置，实现消费回溯。
+
+**重置功能**
+
+Apache RocketMQ 的重置消费位点提供以下能力：
+
+* 重置到队列中的指定位点。
+
+* 重置到某一时刻对应的消费位点，匹配位点时，服务端会根据自动匹配到该时刻最接近的消费位点。
+
+
+
+
+**使用限制**
+
+* 重置消费位点后消费者将直接从重置后的位点开始消费，对于回溯重置类场景，重置后的历史消息大多属于存储冷数据，可能会造成系统压力上升，一般称为冷读现象。因此，需要谨慎评估重置消费位点后的影响。建议严格控制重置消费位点接口的调用权限，避免无意义、高频次的消费位点重置。
+
+* Apache RocketMQ 重置消费位点功能只能重置对消费者可见的消息，不能重置定时中、重试等待中的消息。更多信息，请参见[定时/延时消息](./02delaymessage.md)和[消费重试](./10consumerretrypolicy.md)。
+
+
+## 版本兼容性
+
+关于消费者分组的消费位点初始值，不同的服务端版本中定义如下：
+
+* 服务端历史版本（4.x/3.x版本）：消息位点初始值受当前队列消息状态的影响。
+
+* 服务端5.x版本：明确定义消费位点初始值为消费者获取消息时刻队列中的最大消息位点。
+
+因此，若您将服务端版本从历史版本升级到最新的5.x版本时，需要自行对消费者首次启动时的情况做兼容性判断。
+
+## 使用建议
+
+**严格控制消费位点重置的权限**
+
+重置消费位点会给系统带来额外处理压力，可能会影响新消息的读写性能。 因此该操作请在适用场景下谨慎执行，并提前做好合理性和必要性评估。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/10consumerretrypolicy.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/10consumerretrypolicy.md"
new file mode 100644
index 00000000..43d51f1c
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/10consumerretrypolicy.md"
@@ -0,0 +1,205 @@
+# 消费重试
+
+消费者出现异常，消费某条消息失败时， Apache RocketMQ 会根据消费重试策略重新投递该消息进行故障恢复。本文介绍消费重试机制的原理、版本兼容性和使用建议。
+
+## 应用场景
+
+Apache RocketMQ 的消费重试主要解决的是业务处理逻辑失败导致的消费完整性问题，是一种为业务兜底的策略，不应该被用做业务流程控制。建议以下消费失败场景使用重试机制：
+
+推荐使用消息重试场景如下：
+
+* 业务处理失败，且失败原因跟当前的消息内容相关，比如该消息对应的事务状态还未获取到，预期一段时间后可执行成功。
+
+* 消费失败的原因不会导致连续性，即当前消息消费失败是一个小概率事件，不是常态化的失败，后面的消息大概率会消费成功。此时可以对当前消息进行重试，避免进程阻塞。
+
+典型错误使用场景如下：
+
+* 消费处理逻辑中使用消费失败来做条件判断的结果分流，是不合理的，因为处理逻辑已经预见了一定会大量出现该判断分支。
+
+* 消费处理中使用消费失败来做处理速率限流，是不合理的。限流的目的是将超出流量的消息暂时堆积在队列中达到削峰的作用，而不是让消息进入重试链路。
+
+
+## 应用目的
+
+
+消息中间件做异步解耦时的一个典型问题是如果下游服务处理消息事件失败，如何保证整个调用链路的完整性。Apache RocketMQ 作为金融级的可靠业务消息中间件，在消息投递处理机制的设计上天然支持可靠传输策略，通过完整的确认和重试机制保证每条消息都按照业务的预期被处理。
+
+了解 Apache RocketMQ 的消息确认机制以及消费重试策略可以帮助您分析如下问题：
+
+* 如何保证业务完整处理消息：了解消费重试策略，可以在设计实现消费者逻辑时保证每条消息处理的完整性，避免部分消息出现异常时被忽略，导致业务状态不一致。
+
+* 系统异常时处理中的消息状态如何恢复：帮助您了解当系统出现异常（宕机故障）等场景时，处理中的消息状态如何恢复，是否会出现状态不一致。
+
+
+## 消费重试策略概述
+
+消费重试指的是，消费者在消费某条消息失败后，Apache RocketMQ 服务端会根据重试策略重新消费该消息，超过一次定数后若还未消费成功，则该消息将不再继续重试，直接被发送到死信队列中。
+
+**消息重试的触发条件**
+
+* 消费失败，包括消费者返回消息失败状态标识或抛出非预期异常。
+
+* 消息处理超时，包括在PushConsumer中排队超时。
+
+**消息重试策略主要行为**
+
+* 重试过程状态机：控制消息在重试流程中的状态和变化逻辑。
+
+* 重试间隔：上一次消费失败或超时后，下次重新尝试消费的间隔时间。
+
+* 最大重试次数：消息可被重试消费的最大次数。
+
+**消息重试策略差异**
+
+根据消费者类型不同，消息重试策略的具体内部机制和设置方法有所不同，具体差异如下：
+
+| 消费者类型 | 重试过程状态机 | 重试间隔 | 最大重试次数 |
+|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------|-----------------|
+| PushConsumer | * 已就绪 * 处理中 * 待重试 * 提交 * 死信 | 消费者分组创建时元数据控制。 * 无序消息：阶梯间隔 * 顺序消息：固定间隔时间 | 消费者分组创建时的元数据控制。 |
+| SimpleConsumer | * 已就绪 * 处理中 * 提交 * 死信 | 通过API修改获取消息时的不可见时间。 | 消费者分组创建时的元数据控制。 |
+
+
+具体的重试策略，请参见下文[PushConsumer消费重试策略](#section-qqo-bil-rc6)和[SimpleConsumer消费重试策略](#section-my2-2au-7gl)。
+
+## PushConsumer消费重试策略
+
+
+**重试状态机**
+
+PushConsumer消费消息时，消息的几个主要状态如下：
+
+* Ready：已就绪状态。消息在Apache RocketMQ服务端已就绪，可以被消费者消费。
+
+* Inflight：处理中状态。消息被消费者客户端获取，处于消费中还未返回消费结果的状态。
+
+* WaitingRetry：待重试状态，PushConsumer独有的状态。当消费者消息处理失败或消费超时，会触发消费重试逻辑判断。如果当前重试次数未达到最大次数，则该消息变为待重试状态，经过重试间隔后，消息将重新变为已就绪状态可被重新消费。多次重试之间，可通过重试间隔进行延长，防止无效高频的失败。
+
+* Commit：提交状态。消费成功的状态，消费者返回成功响应即可结束消息的状态机。
+
+* DLQ：死信状态。消费逻辑的最终兜底机制，若消息一直处理失败并不断进行重试，直到超过最大重试次数还未成功，此时消息不会再重试，会被投递至死信队列。您可以通过消费死信队列的消息进行业务恢复。
+
+
+
+
+
+
+消息重试过程中，每次重试消息状态都会经过已就绪\>处理中\>待重试的变化，两次消费间的间隔时间实际由消费耗时及重试间隔控制，消费耗时的最大上限受服务端系统参数控制，一般不应该超过上限时间。
+
+**最大重试次数**
+
+PushConsumer的最大重试次数由消费者分组创建时的元数据控制，具体参数，请参见[消费者分组](../03-领域模型/07consumergroup.md)。
+
+例如，最大重试次数为3次，则该消息最多可被投递4次，1次为原始消息，3次为重试投递次数。
+
+**重试间隔时间**
+
+* 无序消息（非顺序消息）：重试间隔为阶梯时间，具体时间如下：
+
+ | 第几次重试 | 与上次重试的间隔时间 | 第几次重试 | 与上次重试的间隔时间 |
+ |-------|------------|-------|------------|
+ | 1 | 10秒 | 9 | 7分钟 |
+ | 2 | 30秒 | 10 | 8分钟 |
+ | 3 | 1分钟 | 11 | 9分钟 |
+ | 4 | 2分钟 | 12 | 10分钟 |
+ | 5 | 3分钟 | 13 | 20分钟 |
+ | 6 | 4分钟 | 14 | 30分钟 |
+ | 7 | 5分钟 | 15 | 1小时 |
+ | 8 | 6分钟 | 16 | 2小时 |
+
+:::info
+若重试次数超过16次，后面每次重试间隔都为2小时。
+:::
+
+* 顺序消息：重试间隔为固定时间，具体取值，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+**使用示例**
+
+PushConsumer触发消息重试只需要返回消费失败的状态码即可，当出现非预期的异常时，也会被SDK捕获。
+
+```java
+SimpleConsumer simpleConsumer = null;
+ //消费示例：使用PushConsumer消费普通消息，如果消费失败返回错误，即可触发重试。
+ MessageListener messageListener = new MessageListener() {
+ @Override
+ public ConsumeResult consume(MessageView messageView) {
+ System.out.println(messageView);
+ //返回消费失败，会自动重试，直至到达最大重试次数。
+ return ConsumeResult.FAILURE;
+ }
+ };
+
+```
+
+## SimpleConsumer消费重试策略
+
+
+**重试状态机**
+
+SimpleConsumer消费消息时，消息的几个主要状态如下：
+
+* Ready：已就绪状态。消息在Apache RocketMQ服务端已就绪，可以被消费者消费。
+
+* Inflight：处理中状态。消息被消费者客户端获取，处于消费中还未返回消费结果的状态。
+
+* Commit：提交状态。消费成功的状态，消费者返回成功响应即可结束消息的状态机。
+
+* DLQ：死信状态。消费逻辑的最终兜底机制，若消息一直处理失败并不断进行重试，直到超过最大重试次数还未成功，此时消息不会再重试，会被投递至死信队列。您可以通过消费死信队列的消息进行业务恢复。
+
+和PushConsumer消费重试策略不同的是，SimpleConsumer消费者的重试间隔是预分配的，每次获取消息消费者会在调用API时设置一个不可见时间参数 InvisibleDuration，即消息的最大处理时长。若消息消费失败触发重试，不需要设置下一次重试的时间间隔，直接复用不可见时间参数的取值。
+
+
+由于不可见时间为预分配的，可能和实际业务中的消息处理时间差别较大，您可以通过API接口修改不可见时间。
+
+例如，您预设消息处理耗时最多20 ms，但实际业务中20 ms内消息处理不完，您可以修改消息不可见时间，延长消息处理时间，避免消息触发重试机制。
+
+修改消息不可见时间需要满足以下条件：
+
+* 消息处理未超时
+
+* 消息处理未提交消费状态
+
+如下图所示，消息不可见时间修改后立即生效，即从调用API时刻开始，重新计算消息不可见时间。
+
+
+**最大重试次数**
+
+SimpleConsumer的最大重试次数由消费者分组创建时的元数据控制，具体参数，请参见[消费者分组](../03-领域模型/07consumergroup.md)。
+
+**消息重试间隔**
+
+消息重试间隔=不可见时间－消息实际处理时长
+
+SimpleConsumer 的消费重试间隔通过消息的不可见时间控制。例如，消息不可见时间为30 ms，实际消息处理用了10 ms就返回失败响应，则距下次消息重试还需要20 ms，此时的消息重试间隔即为20 ms；若直到30 ms消息还未处理完成且未返回结果，则消息超时，立即重试，此时重试间隔即为0 ms。
+
+**使用示例**
+
+SimpleConsumer 触发消息重试只需要等待即可。
+
+```java
+ //消费示例：使用SimpleConsumer消费普通消息，如果希望重试，只需要静默等待超时即可，服务端会自动重试。
+ List<MessageView> messageViewList = null;
+ try {
+ messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
+ messageViewList.forEach(messageView -> {
+ System.out.println(messageView);
+ //如果处理失败，希望服务端重试，只需要忽略即可，等待消息再次可见后即可重试获取。
+ });
+ } catch (ClientException e) {
+ //如果遇到系统流控等原因造成拉取失败，需要重新发起获取消息请求。
+ e.printStackTrace();
+ }
+```
+## 使用建议
+
+**合理重试，避免因限流等诉求触发消费重试**
+
+上文[应用场景](#section-d2i-0sk-rtf)中提到，消息重试适用业务处理失败且当前消费为小概率事件的场景，不适合在连续性失败的场景下使用，例如消费限流场景。
+
+* 错误示例：如果当前消费速度过高触发限流，则返回消费失败，等待下次重新消费。
+
+* 正确示例：如果当前消费速度过高触发限流，则延迟获取消息，稍后再消费。
+
+
+**合理控制重试次数，避免无限重试**
+
+虽然Apache RocketMQ支持自定义消费重试次数，但是建议通过减少重试次数+延长重试间隔来降低系统压力，避免出现无限重试或大量重试的情况。
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/11messagestorepolicy.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/11messagestorepolicy.md"
new file mode 100644
index 00000000..ada82e8c
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/04-\345\212\237\350\203\275\350\241\214\344\270\272/11messagestorepolicy.md"
@@ -0,0 +1,66 @@
+# 消息存储和清理机制
+
+本文为您介绍 Apache RocketMQ 中消息的存储机制，包括消息的存储粒度、判断依据及后续处理策略等。
+
+## 背景信息
+
+参考 Apache RocketMQ 中[队列](../03-领域模型/03messagequeue.md)的定义，消息按照达到服务器的先后顺序被存储到队列中，理论上每个队列都支持无限存储。
+
+但是在实际部署场景中，服务端节点的物理存储空间有限，消息无法做到永久存储。因此，在实际使用中需要考虑以下问题，消息在服务端中的存储以什么维度为判定条件？消息存储以什么粒度进行管理？消息存储超过限制后如何处理？这些问题都是由消息存储和过期清理机制来定义的。
+
+了解消息存储和过期清理机制，可以从以下方面帮助您更好的进行运维管理：
+
+* 提供消息存储时间SLA，为业务提供安全冗余空间：消息存储时间的承诺本质上代表业务侧可以自由获取消息的时间范围。对于消费时间长、消息堆积、故障恢复等场景非常关键。
+
+* 评估和控制存储成本：Apache RocketMQ 消息一般存储于磁盘介质上，您可以通过存储机制评估消息存储空间，提前预留存储资源。
+
+
+
+
+## 消息存储机制
+
+
+**原理机制**
+
+Apache RocketMQ 使用存储时长作为消息存储的依据，即每个节点对外承诺消息的存储时长。在存储时长范围内的消息都会被保留，无论消息是否被消费；超过时长限制的消息则会被清理掉。
+
+消息存储机制主要定义以下关键问题：
+
+* 消息存储管理粒度：Apache RocketMQ 按存储节点管理消息的存储时长，并不是按照主题或队列粒度来管理。
+
+* 消息存储判断依据：消息存储按照存储时间作为判断依据，相对于消息数量、消息大小等条件，使用存储时间作为判断依据，更利于业务方对消息数据的价值进行评估。
+
+* 消息存储和是否消费状态有关：Apache RocketMQ 的消息存储是按照消息的生产时间计算，和消息是否被消费无关。按照统一的计算策略可以有效地简化存储机制。
+
+
+消息在队列中的存储情况如下：
+
+:::note
+**消息存储管理粒度说明**
+
+Apache RocketMQ 按照服务端节点粒度管理存储时长而非队列或主题，原因如下：
+
+* 消息存储优势权衡：Apache RocketMQ 基于统一的物理日志队列和轻量化逻辑队列的二级组织方式，管理物理数据。这种机制可以带来顺序读写、高吞吐、高性能等优势，但缺点是不支持按主题和队列单独管理。
+
+* 安全生产和容量保障风险要求：即使Apache RocketMQ 按照主题或者队列独立生成存储文件，但存储层本质还是共享存储介质。单独根据主题或队列控制存储时长，这种方式看似更灵活，但实际上整个集群仍然存在容量风险，可能会导致存储时长SLA被打破。从安全生产角度考虑，最合理的方式是将不同存储时长的消息通过不同集群进行分离治理。
+:::
+
+**消息存储和消费状态关系说明**
+
+Apache RocketMQ 统一管理消息的存储时长，无论消息是否被消费。
+
+当消费者不在线或消息消费异常时，会造成队列中大量消息堆积，且该现象暂时无法有效控制。若此时按照消费状态考虑将未消费的消息全部保留，则很容易导致存储空间不足，进而影响到新消息的读写速度。
+
+根据统一地存储时长管理消息，可以帮助消费者业务清晰地判断每条消息的生命周期。只要消息在有效期内可以随时被消费，或通过[重置消费位点](./09consumerprogress.md)功能使消息可被消费多次。
+
+## 消息过期清理机制
+
+在 Apache RocketMQ中，消息保存时长并不能完整控制消息的实际保存时间，因为消息存储仍然使用本地磁盘，本地磁盘空间不足时，为保证服务稳定性消息仍然会被强制清理，导致消息的实际保存时长小于设置的保存时长。
+
+## 使用建议
+
+
+**消息存储时长建议适当增加**
+
+Apache RocketMQ 按存储时长统一控制消息是否保留。建议在存储成本可控的前提下，尽可能延长消息存储时长。延长消息存储时长，可以为紧急故障恢复、应急问题排查和消息回溯带来更多的可操作空间。
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/15bestpractice.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/15bestpractice.md"
deleted file mode 100644
index 58afe6a5..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/15bestpractice.md"
+++ /dev/null
@@ -1,228 +0,0 @@
-# 基本最佳实践
-
-## 生产者
-
-### 发送消息注意事项
-
-#### Tags的使用
-
-一个应用尽可能用一个Topic，而消息子类型则可以用tags来标识。tags可以由应用自由设置，只有生产者在发送消息设置了tags，消费方在订阅消息时才可以利用tags通过broker做消息过滤：message.setTags("TagA")。
-
-#### Keys的使用
-
-每个消息在业务层面的唯一标识码要设置到keys字段，方便将来定位消息丢失问题。服务器会为每个消息创建索引（哈希索引），应用可以通过topic、key来查询这条消息内容，以及消息被谁消费。由于是哈希索引，请务必保证key尽可能唯一，这样可以避免潜在的哈希冲突。
-
-
-```java
- // 订单Id
- String orderId = "20034568923546";
- message.setKeys(orderId);
-```
-#### 日志的打印
-
-消息发送成功或者失败要打印消息日志，务必要打印SendResult和key字段。send消息方法只要不抛异常，就代表发送成功。发送成功会有多个状态，在sendResult里定义。以下对每个状态进行说明：
-
-- **SEND_OK**
-
-消息发送成功。要注意的是消息发送成功也不意味着它是可靠的。要确保不会丢失任何消息，还应启用同步Master服务器或同步刷盘，即SYNC_MASTER或SYNC_FLUSH。
-
-
-- **FLUSH_DISK_TIMEOUT**
-
-消息发送成功但是服务器刷盘超时。此时消息已经进入服务器队列（内存），只有服务器宕机，消息才会丢失。消息存储配置参数中可以设置刷盘方式和同步刷盘时间长度，如果Broker服务器设置了刷盘方式为同步刷盘，即FlushDiskType=SYNC_FLUSH（默认为异步刷盘方式），当Broker服务器未在同步刷盘时间内（默认为5s）完成刷盘，则将返回该状态——刷盘超时。
-
-- **FLUSH_SLAVE_TIMEOUT**
-
-消息发送成功，但是服务器同步到Slave时超时。此时消息已经进入服务器队列，只有服务器宕机，消息才会丢失。如果Broker服务器的角色是同步Master，即SYNC_MASTER（默认是异步Master即ASYNC_MASTER），并且从Broker服务器未在同步刷盘时间（默认为5秒）内完成与主服务器的同步，则将返回该状态——数据同步到Slave服务器超时。
-
-- **SLAVE_NOT_AVAILABLE**
-
-消息发送成功，但是此时Slave不可用。此时消息已经进入Master服务器队列，只有Master服务器宕机，消息才会丢失。如果Broker服务器的角色是同步Master，即SYNC_MASTER（默认是异步Master服务器即ASYNC_MASTER），但没有配置slave Broker服务器，则将返回该状态——无Slave服务器可用。
-
-
-### 消息发送失败处理方式
-
-Producer的send方法本身支持内部重试，重试逻辑如下：
-
-- 至多重试2次（同步发送为2次，异步发送为0次）。
-- 如果发送失败，则轮转到下一个Broker。这个方法的总耗时时间不超过sendMsgTimeout设置的值，默认10s。
-- 如果本身向broker发送消息产生超时异常，就不会再重试。
-
-以上策略也是在一定程度上保证了消息可以发送成功。如果业务对消息可靠性要求比较高，建议应用增加相应的重试逻辑：比如调用send同步方法发送失败时，则尝试将消息存储到db，然后由后台线程定时重试，确保消息一定到达Broker。
-
-上述db重试方式为什么没有集成到MQ客户端内部做，而是要求应用自己去完成，主要基于以下几点考虑：首先，MQ的客户端设计为无状态模式，方便任意的水平扩展，且对机器资源的消耗仅仅是cpu、内存、网络。其次，如果MQ客户端内部集成一个KV存储模块，那么数据只有同步落盘才能较可靠，而同步落盘本身性能开销较大，所以通常会采用异步落盘，又由于应用关闭过程不受MQ运维人员控制，可能经常会发生 kill -9 这样暴力方式关闭，造成数据没有及时落盘而丢失。第三，Producer所在机器的可靠性较低，一般为虚拟机，不适合存储重要数据。综上，建议重试过程交由应用来控制。
-
-### 选择oneway形式发送
-通常消息的发送是这样一个过程：
-
-- 客户端发送请求到服务器
-- 服务器处理请求
-- 服务器向客户端返回应答
-
-所以，一次消息发送的耗时时间是上述三个步骤的总和，而某些场景要求耗时非常短，但是对可靠性要求并不高，例如日志收集类应用，此类应用可以采用oneway形式调用，oneway形式只发送请求不等待应答，而发送请求在客户端实现层面仅仅是一个操作系统系统调用的开销，即将数据写入客户端的socket缓冲区，此过程耗时通常在微秒级。
-
-## 客户端配置
-
-相对于RocketMQ的Broker集群，生产者和消费者都是客户端。本小节主要描述生产者和消费者公共的行为配置。
-
-### 客户端寻址方式
-
-RocketMQ可以令客户端找到Name Server, 然后通过Name Server再找到Broker。如下所示有多种配置方式，优先级由高到低，高优先级会覆盖低优先级。
-
-- 代码中指定Name Server地址，多个namesrv地址之间用分号分割
-
-```java
-producer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");
-
-consumer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");
-```
-- Java启动参数中指定Name Server地址
-
-```text
--Drocketmq.namesrv.addr=192.168.0.1:9876;192.168.0.2:9876
-```
-- 环境变量指定Name Server地址
-
-```text
-export NAMESRV_ADDR=192.168.0.1:9876;192.168.0.2:9876
-```
-- HTTP静态服务器寻址（默认）
-
-客户端启动后，会定时访问一个静态HTTP服务器，地址如下：<http://jmenv.tbsite.net:8080/rocketmq/nsaddr>，这个URL的返回内容如下：
-
-```text
-192.168.0.1:9876;192.168.0.2:9876
-```
-客户端默认每隔2分钟访问一次这个HTTP服务器，并更新本地的Name Server地址。URL已经在代码中硬编码，可通过修改/etc/hosts文件来改变要访问的服务器，例如在/etc/hosts增加如下配置：
-```text
-10.232.22.67 jmenv.taobao.net
-```
-推荐使用HTTP静态服务器寻址方式，好处是客户端部署简单，且Name Server集群可以热升级。
-
-## 消费者
-
-### 消费过程幂等
-
-RocketMQ无法避免消息重复（Exactly-Once），所以如果业务对消费重复非常敏感，务必要在业务层面进行去重处理。可以借助关系数据库进行去重。首先需要确定消息的唯一键，可以是msgId，也可以是消息内容中的唯一标识字段，例如订单Id等。在消费之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。（实际过程要考虑原子性问题，判断是否存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过）
-
-msgId一定是全局唯一标识符，但是实际使用中，可能会存在相同的消息有两个不同msgId的情况（消费者主动重发、因客户端重投机制导致的重复等），这种情况就需要使业务字段进行重复消费。
-
-### 消费速度慢的处理方式
-
-### 提高消费并行度
-
-绝大部分消息消费行为都属于 IO 密集型，即可能是操作数据库，或者调用 RPC，这类消费行为的消费速度在于后端数据库或者外系统的吞吐量，通过增加消费并行度，可以提高总的消费吞吐量，但是并行度增加到一定程度，反而会下降。所以，应用必须要设置合理的并行度。 如下有几种修改消费并行度的方法：
-
-- 同一个 ConsumerGroup 下，通过增加 Consumer 实例数量来提高并行度（需要注意的是超过订阅队列数的 Consumer 实例无效）。可以通过加机器，或者在已有机器启动多个进程的方式。
-- 提高单个 Consumer 的消费并行线程，通过修改参数 consumeThreadMin、consumeThreadMax实现。
-
-### 批量方式消费
-
-某些业务流程如果支持批量方式消费，则可以很大程度上提高消费吞吐量，例如订单扣款类应用，一次处理一个订单耗时 1 s，一次处理 10 个订单可能也只耗时 2 s，这样即可大幅度提高消费的吞吐量，通过设置 consumer的 consumeMessageBatchMaxSize 返个参数，默认是 1，即一次只消费一条消息，例如设置为 N，那么每次消费的消息数小于等于 N。
-
-### 跳过非重要消息
-
-发生消息堆积时，如果消费速度一直追不上发送速度，如果业务对数据要求不高的话，可以选择丢弃不重要的消息。例如，当某个队列的消息数堆积到100000条以上，则尝试丢弃部分或全部消息，这样就可以快速追上发送消息的速度。示例代码如下：
-
-```java
- public ConsumeConcurrentlyStatus consumeMessage(
- List<MessageExt> msgs,
- ConsumeConcurrentlyContext context) {
- long offset = msgs.get(0).getQueueOffset();
- String maxOffset =
- msgs.get(0).getProperty(Message.PROPERTY_MAX_OFFSET);
- long diff = Long.parseLong(maxOffset) - offset;
- if (diff > 100000) {
- // TODO 消息堆积情况的特殊处理
- return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
- }
- // TODO 正常消费过程
- return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
- }
-```
-
-
-#### 优化每条消息消费过程
-
-举例如下，某条消息的消费过程如下：
-
-- 根据消息从 DB 查询【数据 1】
-- 根据消息从 DB 查询【数据 2】
-- 复杂的业务计算
-- 向 DB 插入【数据 3】
-- 向 DB 插入【数据 4】
-
-这条消息的消费过程中有4次与 DB的 交互，如果按照每次 5ms 计算，那么总共耗时 20ms，假设业务计算耗时 5ms，那么总过耗时 25ms，所以如果能把 4 次 DB 交互优化为 2 次，那么总耗时就可以优化到 15ms，即总体性能提高了 40%。所以应用如果对时延敏感的话，可以把DB部署在SSD硬盘，相比于SCSI磁盘，前者的RT会小很多。
-
-### 消费打印日志
-
-如果消息量较少，建议在消费入口方法打印消息，消费耗时等，方便后续排查问题。
-
-
-```java
- public ConsumeConcurrentlyStatus consumeMessage(
- List<MessageExt> msgs,
- ConsumeConcurrentlyContext context) {
- log.info("RECEIVE_MSG_BEGIN: " + msgs.toString());
- // TODO 正常消费过程
- return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
- }
-```
-
-如果能打印每条消息消费耗时，那么在排查消费慢等线上问题时，会更方便。
-
-### 其他消费建议
-
-#### 关于消费者和订阅
-
-第一件需要注意的事情是，不同的消费者组可以独立的消费一些 topic，并且每个消费者组都有自己的消费偏移量，请确保同一组内的每个消费者订阅信息保持一致。
-
-#### 关于有序消息
-
-消费者将锁定每个消息队列，以确保他们被逐个消费，虽然这将会导致性能下降，但是当你关心消息顺序的时候会很有用。我们不建议抛出异常，你可以返回 ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT 作为替代。
-
-#### 关于并发消费
-
-顾名思义，消费者将并发消费这些消息，建议你使用它来获得良好性能，我们不建议抛出异常，你可以返回 ConsumeConcurrentlyStatus.RECONSUME_LATER 作为替代。
-
-#### 关于消费状态Consume Status
-
-对于并发的消费监听器，你可以返回 RECONSUME_LATER 来通知消费者现在不能消费这条消息，并且希望可以稍后重新消费它。然后，你可以继续消费其他消息。对于有序的消息监听器，因为你关心它的顺序，所以不能跳过消息，但是你可以返回SUSPEND_CURRENT_QUEUE_A_MOMENT 告诉消费者等待片刻。
-
-#### 关于Blocking
-
-不建议阻塞监听器，因为它会阻塞线程池，并最终可能会终止消费进程
-
-#### 关于线程数设置
-
-消费者使用 ThreadPoolExecutor 在内部对消息进行消费，所以你可以通过设置 setConsumeThreadMin 或 setConsumeThreadMax 来改变它。
-
-#### 关于消费位点
-
-当建立一个新的消费者组时，需要决定是否需要消费已经存在于 Broker 中的历史消息CONSUME_FROM_LAST_OFFSET 将会忽略历史消息，并消费之后生成的任何消息。CONSUME_FROM_FIRST_OFFSET 将会消费每个存在于 Broker 中的信息。你也可以使用 CONSUME_FROM_TIMESTAMP 来消费在指定时间戳后产生的消息。
-
-## Broker
-
-### Broker 角色
- Broker 角色分为 ASYNC_MASTER（异步主机）、SYNC_MASTER（同步主机）以及SLAVE（从机）。如果对消息的可靠性要求比较严格，可以采用 SYNC_MASTER加SLAVE的部署方式。如果对消息可靠性要求不高，可以采用ASYNC_MASTER加SLAVE的部署方式。如果只是测试方便，则可以选择仅ASYNC_MASTER或仅SYNC_MASTER的部署方式。
-### FlushDiskType
- SYNC_FLUSH（同步刷新）相比于ASYNC_FLUSH（异步处理）会损失很多性能，但是也更可靠，所以需要根据实际的业务场景做好权衡。
-### Broker 配置
-
-| 参数名 | 默认值 | 说明 |
-| -------------------------------- | ----------------------------- | ------------------------------------------------------------ |
-| listenPort | 10911 | 接受客户端连接的监听端口 |
-| namesrvAddr | null | nameServer 地址 |
-| brokerIP1 | 网卡的 InetAddress | 当前 broker 监听的 IP |
-| brokerIP2 | 跟 brokerIP1 一样 | 存在主从 broker 时，如果在 broker 主节点上配置了 brokerIP2 属性，broker 从节点会连接主节点配置的 brokerIP2 进行同步 |
-| brokerName | null | broker 的名称 |
-| brokerClusterName | DefaultCluster | 本 broker 所属的 Cluser 名称 |
-| brokerId | 0 | broker id, 0 表示 master, 其他的正整数表示 slave |
-| storePathCommitLog | $HOME/store/commitlog/ | 存储 commit log 的路径 |
-| storePathConsumerQueue | $HOME/store/consumequeue/ | 存储 consume queue 的路径 |
-| mapedFileSizeCommitLog | 1024 * 1024 * 1024(1G) | commit log 的映射文件大小 |
-| deleteWhen | 04 | 在每天的什么时间删除已经超过文件保留时间的 commit log |
-| fileReserverdTime | 72 | 以小时计算的文件保留时间 |
-| brokerRole | ASYNC_MASTER | SYNC_MASTER/ASYNC_MASTER/SLAVE |
-| flushDiskType | ASYNC_FLUSH | SYNC_FLUSH/ASYNC_FLUSH SYNC_FLUSH 模式下的 broker 保证在收到确认生产者之前将消息刷盘。ASYNC_FLUSH 模式下的 broker 则利用刷盘一组消息的模式，可以取得更好的性能。 |
-
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/17messagetra.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/17messagetra.md"
deleted file mode 100644
index 6f94051d..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/17messagetra.md"
+++ /dev/null
@@ -1,117 +0,0 @@
-# 消息轨迹
-
-## 1. 消息轨迹数据关键属性
-| Producer端| Consumer端 | Broker端 |
-| --- | --- | --- |
-| 生产实例信息 | 消费实例信息 | 消息的Topic |
-| 发送消息时间 | 投递时间,投递轮次 | 消息存储位置 |
-| 消息是否发送成功 | 消息是否消费成功 | 消息的Key值 |
-| 发送耗时 | 消费耗时 | 消息的Tag值 |
-
-## 2. 支持消息轨迹集群部署
-
-### 2.1 Broker端配置文件
-这里贴出Broker端开启消息轨迹特性的properties配置文件内容：
-```
-brokerClusterName=DefaultCluster
-brokerName=broker-a
-brokerId=0
-deleteWhen=04
-fileReservedTime=48
-brokerRole=ASYNC_MASTER
-flushDiskType=ASYNC_FLUSH
-storePathRootDir=/data/rocketmq/rootdir-a-m
-storePathCommitLog=/data/rocketmq/commitlog-a-m
-autoCreateSubscriptionGroup=true
-## if msg tracing is open,the flag will be true
-traceTopicEnable=true
-listenPort=10911
-brokerIP1=XX.XX.XX.XX1
-namesrvAddr=XX.XX.XX.XX:9876
-```
-
-### 2.2 普通模式
-RocketMQ集群中每一个Broker节点均用于存储Client端收集并发送过来的消息轨迹数据。因此，对于RocketMQ集群中的Broker节点数量并无要求和限制。
-
-### 2.3 物理IO隔离模式
-对于消息轨迹数据量较大的场景，可以在RocketMQ集群中选择其中一个Broker节点专用于存储消息轨迹，使得用户普通的消息数据与消息轨迹数据的物理IO完全隔离，互不影响。在该模式下，RockeMQ集群中至少有两个Broker节点，其中一个Broker节点定义为存储消息轨迹数据的服务端。
-
-### 2.4 启动开启消息轨迹的Broker
-`nohup sh mqbroker -c ../conf/2m-noslave/broker-a.properties &`
-
-## 3. 保存消息轨迹的Topic定义
-RocketMQ的消息轨迹特性支持两种存储轨迹数据的方式：
-
-### 3.1 系统级的TraceTopic
-在默认情况下，消息轨迹数据是存储于系统级的TraceTopic中(其名称为：**RMQ_SYS_TRACE_TOPIC**)。该Topic在Broker节点启动时，会自动创建出来（如上所叙，需要在Broker端的配置文件中将**traceTopicEnable**的开关变量设置为**true**）。
-
-### 3.2 用户自定义的TraceTopic
-如果用户不准备将消息轨迹的数据存储于系统级的默认TraceTopic，也可以自己定义并创建用户级的Topic来保存轨迹（即为创建普通的Topic用于保存消息轨迹数据）。下面一节会介绍Client客户端的接口如何支持用户自定义的TraceTopic。
-
-## 4. 支持消息轨迹的Client客户端实践
-为了尽可能地减少用户业务系统使用RocketMQ消息轨迹特性的改造工作量，作者在设计时候采用对原来接口增加一个开关参数(**enableMsgTrace**)来实现消息轨迹是否开启；并新增一个自定义参数(**customizedTraceTopic**)来实现用户存储消息轨迹数据至自己创建的用户级Topic。
-
-### 4.1 发送消息时开启消息轨迹
-```
- DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName",true);
- producer.setNamesrvAddr("XX.XX.XX.XX1");
- producer.start();
- try {
- {
- Message msg = new Message("TopicTest",
- "TagA",
- "OrderID188",
- "Hello world".getBytes(RemotingHelper.DEFAULT_CHARSET));
- SendResult sendResult = producer.send(msg);
- System.out.printf("%s%n", sendResult);
- }
-
- } catch (Exception e) {
- e.printStackTrace();
- }
-```
-
-### 4.2 订阅消息时开启消息轨迹
-```
- DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_JODIE_1",true);
- consumer.subscribe("TopicTest", "*");
- consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);
- consumer.setConsumeTimestamp("20181109221800");
- consumer.registerMessageListener(new MessageListenerConcurrently() {
- @Override
- public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
- System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
- return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
- }
- });
- consumer.start();
- System.out.printf("Consumer Started.%n");
-```
-
-### 4.3 支持自定义存储消息轨迹Topic
-在上面的发送和订阅消息时候分别将DefaultMQProducer和DefaultMQPushConsumer实例的初始化修改为如下即可支持自定义存储消息轨迹Topic。
-```
- ##其中Topic_test11111需要用户自己预先创建，来保存消息轨迹；
- DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName",true,"Topic_test11111");
- ......
-
- DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_JODIE_1",true,"Topic_test11111");
- ......
-```
-
-### 4.4 使用mqadmin命令发送和查看轨迹
-- 发送消息
-```shell
-./mqadmin sendMessage -m true --topic some-topic-name -n 127.0.0.1:9876 -p "your meesgae content"
-```
-- 查询轨迹
-```shell
-./mqadmin QueryMsgTraceById -n 127.0.0.1:9876 -i "some-message-id"
-```
-- 查询轨迹结果
-```
-RocketMQLog:WARN No appenders could be found for logger (io.netty.util.internal.PlatformDependent0).
-RocketMQLog:WARN Please initialize the logger system properly.
-#Type #ProducerGroup #ClientHost #SendTime #CostTimes #Status
-Pub 1623305799667 xxx.xxx.xxx.xxx 2021-06-10 14:16:40 131ms success
-```
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/20log.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/20log.md"
deleted file mode 100644
index 06694426..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/20log.md"
+++ /dev/null
@@ -1,190 +0,0 @@
-# 日志配置
-
-客户端日志用于记录客户端运行过程中的异常，帮助快速定位和修复问题。本文介绍 RocketMQ 的客户端日志的打印方式，以及默认和自定义配置。
-
-## 打印客户端日志
-RocketMQ 的 TCP Java SDK 基于 SLF4J 接口编程。
-- 针对 JavaSDK1.7.8.Final 版本及以上
-
-RocketMQ 的 Java SDK 1.7.8.Final 已内置了日志实现，无需在客户端应用中添加日志实现依赖 即可打印 RocketMQ 客户端日志。
-RocketMQ客户端日志的默认配置和如何修改默认配置，请参见下文的客户端日志配置部分。
-- 针对 JavaSDK1.7.8.Final 以下
-
-RocketMQ 的Java SDK 1.7.8.Final 以下的旧版本不支持 log4j2，只支持 log4j、logback。您需要 在 pom.xml 配置文件 或者 lib 中添加对应的日志实现依赖来打印 RocketMQ 客户端日志。
-
-### 方式一: 依赖 log4j 作为日志实现
-依赖log4j或logback作为日志实现的示例代码如下所示。
-
-```javascript
-<dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>jcl-over-slf4j</artifactId>
- <version>1.7.7</version>
-</dependency>
-<dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>slf4j-log4j12</artifactId>
- <version>1.7.7</version>
-</dependency>
-<dependency>
- <groupId>log4j</groupId>
- <artifactId>log4j</artifactId>
- <version>1.2.17</version>
-</dependency>
-```
-
-使用 log4j 属性配置文件时，配置如下。
-
-```
-log4j.appender.mq=org.apache.rocketmq.logappender.log4j.RocketmqLog4jAppender
-log4j.appender.mq.Tag=yourTag
-log4j.appender.mq.Topic=yourLogTopic
-log4j.appender.mq.ProducerGroup=yourLogGroup
-log4j.appender.mq.NameServerAddress=yourRocketmqNameserverAddress
-log4j.appender.mq.layout=org.apache.log4j.PatternLayout
-log4j.appender.mq.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-4r [%t] (%F:%L) %-5p - %m%n
-```
-
-使用 log4j xml 配置文件时，将其配置为这样并添加一个异步附加程序：
-```
-<appender name="mqAppender1" class="org.apache.rocketmq.logappender.log4j.RocketmqLog4jAppender">
- <param name="Tag" value="yourTag" />
- <param name="Topic" value="yourLogTopic" />
- <param name="ProducerGroup" value="yourLogGroup" />
- <param name="NameServerAddress" value="yourRocketmqNameserverAddress"/>
- <layout class="org.apache.log4j.PatternLayout">
- <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss}-%p %t %c - %m%n" />
- </layout>
-</appender>
-
-<appender name="mqAsyncAppender1" class="org.apache.log4j.AsyncAppender">
- <param name="BufferSize" value="1024" />
- <param name="Blocking" value="false" />
- <appender-ref ref="mqAppender1"/>
-</appender>
-```
-使用 log4j2 时，配置为 this。如果你想要 noneblock，只需为 ref 配置一个 asyncAppender。
-
-```
-<RocketMQ name="rocketmqAppender" producerGroup="yourLogGroup" nameServerAddress="yourRocketmqNameserverAddress"
- topic="yourLogTopic" tag="yourTag">
- <PatternLayout pattern="%d [%p] hahahah %c %m%n"/>
-</RocketMQ>
-```
-
-### 方式二: 依赖 logback 作为日志实现
-
-```
-<dependency>
- <groupId>ch.qos.logback</groupId>
- <artifactId>logback-core</artifactId>
- <version>1.1.2</version>
-</dependency>
-<dependency>
- <groupId>ch.qos.logback</groupId>
- <artifactId>logback-classic</artifactId>
- <version>1.1.2</version>
-</dependency>
-```
-
-```
-<dependency>
- <groupId>ch.qos.logback</groupId>
- <artifactId>logback-core</artifactId>
- <version>1.1.2</version>
-</dependency>
-<dependency>
- <groupId>ch.qos.logback</groupId>
- <artifactId>logback-classic</artifactId>
- <version>1.1.2</version>
-</dependency>
-```
-:::tip
-应用中同时依赖log4j和logback的日志实现会造成日志冲突导致客户端日志打印混乱。确保 应用只依赖其中一个日志实现，是正确打印RocketMQ客户端日志的前提条件，建议通过```mvn
-clean dependency:tree | grep log```命令排查。
-:::
-
-## 客户端日志配置
-
-RocketMQ 客户端支持自定义日志保存路径、日志级别以及保存历史日志文件的最大个数。考虑到日志传输以及阅读的便利性，暂不允许自定义单个日志文件大小，仍保持默认的64 MB。各参数的配置说明如下：
-
-| 参数 | 说明 | 配置参数 | 自定义取值 |
-| ----------------------------- | ------------------------------------------------------------ | ------------------------------- | ------------------------------------------------------------ |
-| 日志保存路径 | 请确保应用进程有对该路径写的权限，否则日志 不会打印。 | rocketmq.client.logRoot | 可自定义为您需要将日志文件保存到本地的路径。请确保您的应用进程有该路径的写权限，否则日志无法打印。 |
-| 保存历史日志文件的最大个数 | 支持1到100之前的数值;若输入的值超出该范围 或格式错误，则系统默认保存10个。 | rocketmq.client.logFileMaxIndex | 取值如下：**ERROR****WARN****INFO****DEBUG** |
-| 日志级别 | 支持ERROR、WARN、INFO、DEBUG中任何一 种，不匹配默认INFO。 | rocketmq.client.logLevel | 取值范围：1~100。若设置的值超出该范围或格式错误，则以系统默认值（10个）为准。 |
-| 单个文件日志大小 | 支持以bytes为单位指定 | rocketmq.client.logFileMaxSize | 取值在0~1GB, 默认1GB, 建议64 MB |
-| logback是否使用父级logger打印 | children-logger是否使用 rootLogger配置的appender进行输出 | rocketmq.client.log.additive | true/false |
-| 使用项目的slf4j实现记录日志 | 如果需要实现记录日志 则为true | rocketmq.client.logUseSlf4j | true/flase |
-
-## 默认配置
-
-请确保应用进程有对该路径写的权限，否则日志 不会打印。 支持 1 到 100 之前的数值;若输入的值超出该范围 或格式错误，则系统默认保存10个。 支持 ERROR、WARN、INFO、DEBUG 中任何一 种，不匹配默认 INFO。
-
-RocketMQ 客户端启动后，会按照如下的默认配置生成日志文件 :
-
-- 日志保存路径:/{user.home}/logs/rocketmqlogs/ 其中{user.home}是指启动当前Java进程的用 户的根目录
-- 保存历史日志文件的最大个数:10个
-- 日志级别:INFO
-- 单个日志文件大小: 1GB
-
-## 自定义配置
-
-如果需要进行自定义配置 参考 ClientLogger的静态变量定义, 参数意义对齐上文客户端配置。
-
-```javascript
- public static final String CLIENT_LOG_USESLF4J = "rocketmq.client.logUseSlf4j";
- public static final String CLIENT_LOG_ROOT = "rocketmq.client.logRoot";
- public static final String CLIENT_LOG_MAXINDEX = "rocketmq.client.logFileMaxIndex";
- public static final String CLIENT_LOG_FILESIZE = "rocketmq.client.logFileMaxSize";
- public static final String CLIENT_LOG_LEVEL = "rocketmq.client.logLevel";
- public static final String CLIENT_LOG_ADDITIVE = "rocketmq.client.log.additive";
- public static final String CLIENT_LOG_FILENAME = "rocketmq.client.logFileName";
- public static final String CLIENT_LOG_ASYNC_QUEUESIZE = "rocketmq.client.logAsyncQueueSize";
- public static final String ROCKETMQ_CLIENT_APPENDER_NAME = "RocketmqClientAppender";
-
- private static final InternalLogger CLIENT_LOGGER;
-
- private static final boolean CLIENT_USE_SLF4J;
-
- //private static Appender rocketmqClientAppender = null;
-
- static {
- CLIENT_USE_SLF4J = Boolean.parseBoolean(System.getProperty(CLIENT_LOG_USESLF4J, "false"));
- if (!CLIENT_USE_SLF4J) {
- InternalLoggerFactory.setCurrentLoggerType(InnerLoggerFactory.LOGGER_INNER);
- CLIENT_LOGGER = createLogger(LoggerName.CLIENT_LOGGER_NAME);
- createLogger(LoggerName.COMMON_LOGGER_NAME);
- createLogger(RemotingHelper.ROCKETMQ_REMOTING);
- } else {
- CLIENT_LOGGER = InternalLoggerFactory.getLogger(LoggerName.CLIENT_LOGGER_NAME);
- }
- }
-```
-
-
-## 示例
-
-以下是一个简单示例
-
-在启动脚本中或者IDE的VM options中添加如下系统参数:
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-<Tabs>
-<TabItem value="Linux示例" label="Linux示例" default >
-
-```
--Drocketmq.client.logRoot=/home/admin/logs -Drocketmq.client.logLevel=WARN -Drocketmq.client.logFileMaxIndex=20 -Drocketmq.client.logFileMaxSize=67108864
-```
-</TabItem>
-<TabItem value="windows示例" label="windows示例">
-
-```
--Drocketmq.client.logRoot=D:\logs -Drocketmq.client.logLevel=WARN -Drocketmq.client.logFileMaxIndex=20 -Drocketmq.client.logFileMaxSize=67108864
-```
-
-</TabItem>
-
-</Tabs>
\ No newline at end of file
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/21subscribe.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/21subscribe.md"
deleted file mode 100644
index b7cb1feb..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/21subscribe.md"
+++ /dev/null
@@ -1,215 +0,0 @@
-# 订阅关系一致
-
-## 前言
-
-订阅关系：一个消费者组订阅一个 Topic 的某一个 Tag，这种记录被称为订阅关系。
-
-订阅关系一致：同一个消费者组下所有消费者实例所订阅的Topic、Tag必须完全一致。如果订阅关系（消费者组名-Topic-Tag）不一致，会导致消费消息紊乱，甚至消息丢失。
-
-## 1 正确订阅关系示例
-
-
-
-### 1.1 订阅一个Topic且订阅一个Tag
-
-如下图所示，同一Group ID下的三个Consumer实例C1、C2和C3分别都订阅了TopicA，且订阅TopicA的Tag也都是Tag1，符合订阅关系一致原则。
-
-
-
-
-
-
-
-**正确示例代码一**
-
-C1、C2、C3的订阅关系一致，即C1、C2、C3订阅消息的代码必须完全一致，代码示例如下：
-
-```java
- Properties properties = new Properties();
- properties.put(PropertyKeyConst.GROUP_ID, "GID_test_1");
- Consumer consumer = ONSFactory.createConsumer(properties);
- consumer.subscribe("TopicA", "Tag1", new MessageListener() {
- public Action consume(Message message, ConsumeContext context) {
- System.out.println(message.getMsgID());
- return Action.CommitMessage;
- }
- });
-```
-
-### 1.2 订阅一个Topic且订阅多个Tag
-
-如下图所示，同一Group ID下的三个Consumer实例C1、C2和C3分别都订阅了TopicB，订阅TopicB的Tag也都是Tag2和Tag3，表示订阅TopicB中所有Tag为Tag2或Tag3的消息，且顺序一致都是Tag2||Tag3，符合订阅关系一致性原则。
-
-
-
-**正确示例代码二**
-
-C1、C2、C3的订阅关系一致，即C1、C2、C3订阅消息的代码必须完全一致，代码示例如下：
-
-```java
- Properties properties = new Properties();
- properties.put(PropertyKeyConst.GROUP_ID, "GID_test_2");
- Consumer consumer = ONSFactory.createConsumer(properties);
- consumer.subscribe("TopicB", "Tag2||Tag3", new MessageListener() {
- public Action consume(Message message, ConsumeContext context) {
- System.out.println(message.getMsgID());
- return Action.CommitMessage;
- }
- });
-```
-
-### 1.3 订阅多个Topic且订阅多个Tag
-
-如下图所示，同一Group ID下的三个Consumer实例C1、C2和C3分别都订阅了TopicA和TopicB，且订阅的TopicA都未指定Tag，即订阅TopicA中的所有消息，订阅的TopicB的Tag都是Tag1和Tag2，表示订阅TopicB中所有Tag为Tag1或Tag2的消息，且顺序一致都是Tag1||Tag2，符合订阅关系一致原则。
-
-
-
-**正确示例代码三**
-
-C1、C2、C3的订阅关系一致，即C1、C2、C3订阅消息的代码必须完全一致，代码示例如下：
-
-```java
- Properties properties = new Properties();
- properties.put(PropertyKeyConst.GROUP_ID, "GID_test_3");
- Consumer consumer = ONSFactory.createConsumer(properties);
- consumer.subscribe("TopicA", "*", new MessageListener() {
- public Action consume(Message message, ConsumeContext context) {
- System.out.println(message.getMsgID());
- return Action.CommitMessage;
- }
- });
- consumer.subscribe("TopicB", "Tag2||Tag3", new MessageListener() {
- public Action consume(Message message, ConsumeContext context) {
- System.out.println(message.getMsgID());
- return Action.CommitMessage;
- }
- });
-```
-
-## 2 订阅关系不一致的排查
-
-**问题描述**
-
-在使用消息队列RocketMQ版实例时，可能会出现订阅关系不一致的情况，具体的问题现象如下：
-
-- 消息队列RocketMQ版控制台中订阅关系是否一致显示为否。
-- 消费者（Consumer）实例未收到订阅的消息。
-
-**请参考以下步骤进行检查**
-
-您可在消息消息队列RocketMQ版控制台Group 详情页面查看指定Group的订阅关系是否一致。若查询结果不一致，请参见本文(3 常见订阅关系不一致问题)排查Consumer实例的消费代码。
-
-1. 检查您Consumer实例中与订阅相关的配置代码，确保配置同一个Group ID的所有Consumer实例均订阅相同的Topic及Tag。
-2. 重启客户端应用。
-3. 登录[消息队列RocketMQ版控制台](https://ons.console.aliyun.com/)，在左侧导航栏中单击实例列表，选择您的目标实例，进入实例详情页面。
-4. 在左侧导航栏中单击Group管理，选择对应的协议后，单击消费者状态，确认订阅关系是否一致显示为是。
-5. 测试并确认消息能够被预期的Consumer实例所消费。
-
-## 3 常见订阅关系不一致问题
-
-### 3.1 同一Group ID下的Consumer实例订阅的Topic不同
-
-如下图所示，同一Group ID下的三个Consumer实例C1、C2和C3分别订阅了TopicA、TopicB和TopicC，订阅的Topic不一致，不符合订阅关系一致性原则。
-
-
-
-**错误示例代码一**
-
-+ Consumer实例1-1：
-
- ```java
- Properties properties = new Properties();
- properties.put(PropertyKeyConst.GROUP_ID, "GID_test_1");
- Consumer consumer = ONSFactory.createConsumer(properties);
- consumer.subscribe("TopicA", "*", new MessageListener() {
- public Action consume(Message message, ConsumeContext context) {
- System.out.println(message.getMsgID());
- return Action.CommitMessage;
- }
- });
- ```
-
-+ Consumer实例1-2：
-
-```java
- Properties properties = new Properties();
- properties.put(PropertyKeyConst.GROUP_ID, "GID_test_1");
- Consumer consumer = ONSFactory.createConsumer(properties);
- consumer.subscribe("TopicB", "*", new MessageListener() {
- public Action consume(Message message, ConsumeContext context) {
- System.out.println(message.getMsgID());
- return Action.CommitMessage;
- }
- });
-```
-
-+ Consumer实例1-3：
-
-```java
- Properties properties = new Properties();
- properties.put(PropertyKeyConst.GROUP_ID, "GID_test_1");
- Consumer consumer = ONSFactory.createConsumer(properties);
- consumer.subscribe("TopicC", "*", new MessageListener() {
- public Action consume(Message message, ConsumeContext context) {
- System.out.println(message.getMsgID());
- return Action.CommitMessage;
- }
- });
-```
-
-### 3.2 同一Group ID下的Consumer实例订阅的Topic相同，但订阅的Tag不一致
-
-如下图所示，同一Group ID下的三个Consumer实例C1、C2和C3分别都订阅了TopicA，但是C1订阅TopicA的Tag为**Tag1**，C2和C3订阅的TopicA的Tag为**Tag2**，订阅同一Topic的Tag不一致，不符合订阅关系一致性原则。
-
-
-
-**错误示例代码二**
-
-+ Consumer实例2-1：
-
- ```java
- Properties properties = new Properties();
- properties.put(PropertyKeyConst.GROUP_ID, "GID_test_2");
- Consumer consumer = ONSFactory.createConsumer(properties);
- consumer.subscribe("TopicA", "Tag1", new MessageListener() {
- public Action consume(Message message, ConsumeContext context) {
- System.out.println(message.getMsgID());
- return Action.CommitMessage;
- }
- });
- ```
-
-
-
-+ Consumer实例2-2：
-
- ```java
- Properties properties = new Properties();
- properties.put(PropertyKeyConst.GROUP_ID, "GID_test_2");
- Consumer consumer = ONSFactory.createConsumer(properties);
- consumer.subscribe("TopicA", "Tag2", new MessageListener() {
- public Action consume(Message message, ConsumeContext context) {
- System.out.println(message.getMsgID());
- return Action.CommitMessage;
- }
- });
- ```
-
-+ Consumer实例2-3：
-
- ```java
- Properties properties = new Properties();
- properties.put(PropertyKeyConst.GROUP_ID, "GID_test_2");
- Consumer consumer = ONSFactory.createConsumer(properties);
- consumer.subscribe("TopicA", "Tag2", new MessageListener() {
- public Action consume(Message message, ConsumeContext context) {
- System.out.println(message.getMsgID());
- return Action.CommitMessage;
- }
- });
- ```
-
-
-
-
-
diff --git "a/versioned_docs/version-5.0/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/15deploy.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/05-\351\203\250\347\275\262\350\277\220\347\273\264/15deploy.md"
similarity index 55%
rename from "versioned_docs/version-5.0/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/15deploy.md"
rename to "i18n/en/docusaurus-plugin-content-docs/5.0/05-\351\203\250\347\275\262\350\277\220\347\273\264/15deploy.md"
index cdd5984c..50be8615 100644
--- "a/versioned_docs/version-5.0/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/15deploy.md"
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/05-\351\203\250\347\275\262\350\277\220\347\273\264/15deploy.md"
@@ -1,14 +1,23 @@
# 部署方式
-<!-- ## 集群搭建 -->
+Apache RocketMQ 5.0 版本完成基本消息收发，包括 NameServer、Broker、Proxy 组件。 在 5.0 版本中 Proxy 和 Broker 根据实际诉求可以分为 Local 模式和 Cluster 模式，一般情况下如果没有特殊需求，或者遵循从早期版本平滑升级的思路，可以选用Local模式。
-## 单Master模式
+- 在 Local 模式下，Broker 和 Proxy 是同进程部署，只是在原有 Broker 的配置基础上新增 Proxy 的简易配置就可以运行。
+- 在 Cluster 模式下，Broker 和 Proxy 分别部署，即在原有的集群基础上，额外再部署 Proxy 即可。
+
+## 部署方案和使用约束
+
+## Local模式部署
+
+由于 Local 模式下 Proxy 和 Broker 是同进程部署，Proxy本身无状态，因此主要的集群配置仍然以 Broker 为基础进行即可。
+
+### 单组节点单副本模式
:::caution
-这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用, 可以用于本地测试。
+这种方式风险较大，因为 Broker 只有一个节点，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用, 可以用于本地测试。
:::
-### 启动 NameServer
+#### 启动 NameServer
```bash
### 首先启动Name Server
@@ -19,20 +28,20 @@ $ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
```
-### 启动 Broker
+#### 启动 Broker+Proxy
```bash
-### 启动Broker
-$ nohup sh bin/mqbroker -n localhost:9876 &
+
+$ nohup sh bin/mqproxy -n localhost:9876 &
### 验证Name Server 是否启动成功，例如Broker的IP为：192.168.1.2，且名称为broker-a
$ tail -f ~/logs/rocketmqlogs/Broker.log
-The broker[broker-a, 192.169.1.2:10911] boot success...
+The broker[xxx, 192.169.1.2:10911] boot success...
```
-## 多Master模式
+### 多组节点（集群）单副本模式
-一个集群无Slave，全是Master，例如2个Master或者3个Master，这种模式的优缺点如下：
+一个集群内全部部署 Master 角色，不部署Slave 副本，例如2个Master或者3个Master，这种模式的优缺点如下：
- 优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；
@@ -43,7 +52,7 @@ The broker[broker-a, 192.169.1.2:10911] boot success...
NameServer需要先于Broker启动，且如果在生产环境使用，为了保证高可用，建议一般规模的集群启动3个NameServer，各节点的启动命令相同，如下：
```bash
-### 首先启动Name Server
+### 首先启动NameServer
$ nohup sh mqnamesrv &
### 验证Name Server 是否启动成功
@@ -51,14 +60,14 @@ $ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
```
-### 启动Broker集群
+#### 启动Broker+Proxy集群
```bash
### 在机器A，启动第一个Master，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties &
### 在机器B，启动第二个Master，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties &
...
```
@@ -69,15 +78,15 @@ $ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker
:::
-## 多Master多Slave模式-异步复制
+## 多节点（集群）多副本模式-异步复制
-每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：
+每个Master配置一个Slave，有多组 Master-Slave，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：
- 优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样；
- 缺点：Master宕机，磁盘损坏情况下会丢失少量消息。
-### 启动NameServer
+#### 启动NameServer
```bash
### 首先启动Name Server
@@ -88,31 +97,31 @@ $ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
```
-### 启动Broker集群
+#### 启动Broker+Proxy集群
```bash
### 在机器A，启动第一个Master，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a.properties &
### 在机器B，启动第二个Master，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties &
### 在机器C，启动第一个Slave，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties &
### 在机器D，启动第二个Slave，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties &
```
-## 多Master多Slave模式-同步双写
+### 多节点（集群）多副本模式-同步双写
-每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：
+每个Master配置一个Slave，有多对 Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：
- 优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；
- 缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。
-### 启动NameServer
+#### 启动NameServer
```bash
### 首先启动Name Server
@@ -123,21 +132,25 @@ $ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
```
-### 启动Broker集群
+#### 启动 Broker+Proxy 集群
```bash
### 在机器A，启动第一个Master，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a.properties &
### 在机器B，启动第二个Master，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties &
### 在机器C，启动第一个Slave，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties &
### 在机器D，启动第二个Slave，例如NameServer的IP为：192.168.1.1
-$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties &
+$ nohup sh mqproxy -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties &
```
:::tip
以上 Broker 与 Slave 配对是通过指定相同的 BrokerName 参数来配对，Master 的 BrokerId 必须是 0，Slave 的 BrokerId 必须是大于 0 的数。另外一个 Master 下面可以挂载多个 Slave，同一 Master 下的多个 Slave 通过指定不同的 BrokerId 来区分。$ROCKETMQ_HOME指的RocketMQ安装目录，需要用户自己设置此环境变量。
-:::
\ No newline at end of file
+:::
+
+
+## Cluster模式部署
+待补充。。。
\ No newline at end of file
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/16admintool.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/05-\351\203\250\347\275\262\350\277\220\347\273\264/16admintool.md"
similarity index 100%
rename from "i18n/en/docusaurus-plugin-content-docs/5.0/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/16admintool.md"
rename to "i18n/en/docusaurus-plugin-content-docs/5.0/05-\351\203\250\347\275\262\350\277\220\347\273\264/16admintool.md"
diff --git "a/versioned_docs/version-5.0/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/17Dashboard.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/05-\351\203\250\347\275\262\350\277\220\347\273\264/17Dashboard.md"
similarity index 95%
rename from "versioned_docs/version-5.0/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/17Dashboard.md"
rename to "i18n/en/docusaurus-plugin-content-docs/5.0/05-\351\203\250\347\275\262\350\277\220\347\273\264/17Dashboard.md"
index 1a219c68..6baa9615 100644
--- "a/versioned_docs/version-5.0/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/17Dashboard.md"
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/05-\351\203\250\347\275\262\350\277\220\347\273\264/17Dashboard.md"
@@ -143,5 +143,3 @@ java -jar target/rocketmq-dashboard-1.0.1-SNAPSHOT.jar
-更多操作详情： [阿里云知行动手实验室-在浏览器沉浸式学习最新云原生技术 (aliyun.com)](https://start.aliyun.com/?accounttraceid=8fda44777a19460a925d871eb408e704qoln)
-
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/18Exporter.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/05-\351\203\250\347\275\262\350\277\220\347\273\264/18Exporter.md"
similarity index 100%
rename from "i18n/en/docusaurus-plugin-content-docs/5.0/04-\351\203\250\347\275\262\344\270\216\350\277\220\347\273\264/18Exporter.md"
rename to "i18n/en/docusaurus-plugin-content-docs/5.0/05-\351\203\250\347\275\262\350\277\220\347\273\264/18Exporter.md"
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/06-\345\217\202\346\225\260\351\205\215\347\275\256/23local.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\345\217\202\346\225\260\351\205\215\347\275\256/23local.md"
deleted file mode 100644
index 4bd1b9f1..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/06-\345\217\202\346\225\260\351\205\215\347\275\256/23local.md"
+++ /dev/null
@@ -1,147 +0,0 @@
-# 客户端配置
-
- 相对于RocketMQ的Broker集群，生产者和消费者都是客户端。本小节主要描述生产者和消费者公共的行为配置。
-
-### 客户端寻址方式
-
-RocketMQ可以令客户端找到Name Server, 然后通过Name Server再找到Broker。如下所示有多种配置方式，优先级由高到低，高优先级会覆盖低优先级。
-
-- 代码中指定Name Server地址，多个namesrv地址之间用分号分割
-
-```java
-producer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");
-
-consumer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");
-```
-
-- Java启动参数中指定Name Server地址
-
-```text
--Drocketmq.namesrv.addr=192.168.0.1:9876;192.168.0.2:9876
-```
-
-- 环境变量指定Name Server地址
-
-```text
-export NAMESRV_ADDR=192.168.0.1:9876;192.168.0.2:9876
-```
-
-- HTTP静态服务器寻址（默认）
-
-客户端启动后，会定时访问一个静态HTTP服务器，地址如下：<http://jmenv.tbsite.net:8080/rocketmq/nsaddr>，这个URL的返回内容如下：
-
-```text
-192.168.0.1:9876;192.168.0.2:9876
-```
-
-客户端默认每隔2分钟访问一次这个HTTP服务器，并更新本地的Name Server地址。URL已经在代码中硬编码，可通过修改/etc/hosts文件来改变要访问的服务器，例如在/etc/hosts增加如下配置：
-
-```text
-10.232.22.67 jmenv.taobao.net
-```
-
-推荐使用HTTP静态服务器寻址方式，好处是客户端部署简单，且Name Server集群可以热升级。
-
-#### 客户端配置
-
-DefaultMQProducer、TransactionMQProducer、DefaultMQPushConsumer、DefaultMQPullConsumer都继承于ClientConfig类，ClientConfig为客户端的公共配置类。客户端的配置都是get、set形式，每个参数都可以用spring来配置，也可以在代码中配置，例如namesrvAddr这个参数可以这样配置，producer.setNamesrvAddr("192.168.0.1:9876")，其他参数同理。
-
-## ClientConfig配置
-
-| 名称 | 描述 | 参数类型 | 默认值 | 有效值 | 重要性 |
-| ------------------------------- | ---------------------------------------------- | ------------- | ------------------------------------------------------------ | ------ | ------ |
-| namesrvAddr | NameServer的地址列表 | String | 从-D系统参数rocketmq.namesrv.addr或环境变量。NAMESRV_ADDR | | |
-| instanceName | 客户端实例名称 | String | 从-D系统参数rocketmq.client.name获取，否则就是DEFAULT | | |
-| clientIP | 客户端IP | String | RemotingUtil.getLocalAddress() | | |
-| namespace | 客户端命名空间 | String | | | |
-| accessChannel | 设置访问通道 | AccessChannel | LOCAL | | |
-| clientCallbackExecutorThreads | 客户端通信层接收到网络请求的时候，处理器的核数 | int | Runtime.getRuntime().availableProcessors() | | |
-| pollNameServerInterval | 轮询从NameServer获取路由信息的时间间隔 | int | 30000，单位毫秒 | | |
-| heartbeatBrokerInterval | 定期发送注册心跳到broker的间隔 | int | 30000，单位毫秒 | | |
-| persistConsumerOffsetInterval | 作用于Consumer，持久化消费进度的间隔 | int | 默认值5000，单位毫秒 | | |
-| pullTimeDelayMillsWhenException | 拉取消息出现异常的延迟时间设置 | long | 1000，单位毫秒 | | |
-| unitName | 单位名称 | String | | | |
-| unitMode | 单位模式 | boolean | false | | |
-| vipChannelEnabled | 是否启用vip netty通道以发送消息 | boolean | 从-D com.rocketmq.sendMessageWithVIPChannel参数的值，若无则是true | | |
-| useTLS | 是否使用安全传输。 | boolean | 从-D系统参数tls.enable获取，否则就是false | | |
-| mqClientApiTimeout | mq客户端api超时设置 | int | 3000，单位毫秒 | | |
-| language | 客户端实现语言 | LanguageCode | LanguageCode.*JAVA* | | |
-
-## DefaultMQProducer配置
-
-| 名称 | 描述 | 参数类型 | 默认值 | 有效值 | 重要性 |
-| -------------------------------- | ------------------------------------------------------------ | --------------- | ------------------------------------------ | ------ | ------ |
-| producerGroup | 生产组的名称，一类Producer的标识 | String | DEFAULT_PRODUCER | | |
-| createTopicKey | 发送消息的时候，如果没有找到topic，若想自动创建该topic，需要一个key topic，这个值即是key topic的值 | String | TopicValidator.AUTO_CREATE_TOPIC_KEY_TOPIC | | |
-| defaultTopicQueueNums | 自动创建topic的话，默认queue数量是多少 | int | 4 | | |
-| sendMsgTimeout | 默认的发送超时时间 | int | 3000，单位毫秒 | | |
-| compressMsgBodyOverHowmuc | 消息body需要压缩的阈值 | int | 1024 * 4，4K | | |
-| retryTimesWhenSendFailed | 同步发送失败的话，rocketmq内部重试多少次 | int | 2 | | |
-| retryTimesWhenSendAsyncFailed | 异步发送失败的话，rocketmq内部重试多少次 | int | 2 | | |
-| retryAnotherBrokerWhenNotStoreOK | 发送的结果如果不是SEND_OK状态，是否当作失败处理而尝试重发 | boolean | false | | |
-| maxMessageSize | 客户端验证，允许发送的最大消息体大小 | int | 1024 * 1024 * 4，4M | | |
-| traceDispatcher | 异步传输数据接口 | TraceDispatcher | null | | |
-
-## DefaultMQPushConsumer配置
-
-| 名称 | 描述 | 参数类型 | 默认值 | 有效值 | 重要性 |
-| ---------------------------------- | ------------------------------------------------------------ | ---------------------------- | --------------------------------------------------- | ------ | ------ |
-| consumerGroup | 消费组的名称，用于标识一类消费者 | String | | | |
-| messageModel | 消费模式 | MessageModel | MessageModel.CLUSTERINGallocateMessageQueueStrategy | | |
-| consumeFromWhere | 启动消费点策略 | ConsumeFromWhere | ConsumeFromWhere.CONSUME_FROM_LAST_OFFSET | | |
-| consumeTimestamp | CONSUME_FROM_LAST_OFFSET的时候使用，从哪个时间点开始消费 | String | 半小时前 | | |
-| allocateMessageQueueStrategy | 负载均衡策略算法 | AllocateMessageQueueStrategy | AllocateMessageQueueAveragely（取模平均分配） | | |
-| subscription | 订阅关系 | Map<String, String> | {} | | |
-| messageListener | 消息处理监听器（回调） | MessageListener | null | | |
-| offsetStore | 消息消费进度存储器 | OffsetStore | null | | |
-| consumeThreadMin | 消费线程池的core size | int | 20 | | |
-| consumeThreadMax | 消费线程池的max size | int | 64 | | |
-| adjustThreadPoolNumsThreshold | 动态扩线程核数的消费堆积阈值 | long | 100000 | | |
-| consumeConcurrentlyMaxSpan | 并发消费下，单条consume queue队列允许的最大offset跨度，达到则触发流控 | int | 2000**pullInterval** | | |
-| pullThresholdForQueue | consume queue流控的阈值 | int | 100 | | |
-| pullInterval | 拉取的间隔 | long | 0，单位毫秒 | | |
-| pullThresholdForTopic | 主题级别的流控制阈值 | int | -1 | | |
-| pullThresholdSizeForTopic | 限制主题级别的缓存消息大小 | int | -1 | | |
-| pullBatchSize | 一次最大拉取的批量大小 | int | 32 | | |
-| consumeMessageBatchMaxSize | 批量消费的最大消息条数 | int | -1 | | |
-| postSubscriptionWhenPull | 每次拉取的时候是否更新订阅关系 | boolean | false | | |
-| unitMode | 订阅组的单位 | boolean | false | | |
-| maxReconsumeTimes | 一个消息如果消费失败的话，最多重新消费多少次才投递到死信队列 | int | -1 | | |
-| suspendCurrentQueueTimeMillis | 串行消费使用，如果返回ROLLBACK或者SUSPEND_CURRENT_QUEUE_A_MOMENT，再次消费的时间间隔 | long | 1000 | | |
-| consumeTimeout | 消费的最长超时时间 | long | 15，单位分钟 | | |
-| awaitTerminationMillisWhenShutdown | 关闭使用者时等待消息的最长时间，0表示无等待。 | long | 0 | | |
-| traceDispatcher | 异步传输数据接口 | TraceDispatcher | null | | |
-
-
-
-## DefaultLitePullConsumer配置
-
-| 名称 | 描述 | 参数类型 | 默认值 | 有效值 | 重要性 |
-| -------------------------------- | -------------------------------------------------------- | ---------------------------- | --------------------------------------------- | ------ | ------ |
-| consumerGroup | 消费组的名称，用于标识一类消费者 | String | | | |
-| brokerSuspendMaxTimeMillis | broker在长轮询下，连接最长挂起的时间 | long | 20000，单位毫秒 | | |
-| consumerTimeoutMillisWhenSuspend | broker在长轮询下，客户端等待broker响应的最长等待超时时间 | long | 30000，单位毫秒 | | |
-| consumerPullTimeoutMillis | pull的socket 超时时间 | long | 10000，单位毫秒 | | |
-| messageModel | 消费模式 | MessageModel | MessageModel.CLUSTERING | | |
-| messageQueueListener | 负载均衡consume queue分配变化的通知监听器 | MessageQueueListener | | | |
-| offsetStore | 消息消费进度存储器 | OffsetStore | | | |
-| allocateMessageQueueStrategy | 负载均衡策略算法 | AllocateMessageQueueStrategy | AllocateMessageQueueAveragely（取模平均分配） | | |
-| unitMode | 订阅组的单位设置 | boolean | false | | |
-| autoCommit | 自动提交偏移的标志设置 | boolean | true | | |
-| pullThreadNums | 拉取线程数设置 | int | 20 | | |
-| MIN_AUTOCOMMIT_INTERVAL_MILLIS | 最小提交偏移间隔时间 | long | 1000，单位为毫秒 | | |
-| autoCommitIntervalMillis | 最大提交偏移间隔时间 | long | 5000，单位为毫秒 | | |
-| pullBatchSize | 每次拉出的信息的最大数量 | long | 10 | | |
-| pullThresholdForAll | 消耗请求的流量控制阈值 | int | 10000 | | |
-| consumeMaxSpan | 消耗最大跨度偏移量 | int | 2000 | | |
-| pullThresholdForQueue | 队列级别的流量控制阈值 | int | 1000 | | |
-| pullThresholdSizeForQueue | 队列级别上限制缓存的消息大小 | int | 100MiB | | |
-| pollTimeoutMillis | 轮询超时设置 | long | 5000，以毫秒为单位 | | |
-| topicMetadataCheckIntervalMillis | 检查主题元数据变化的间隔时间 | long | 30000，单位为毫秒 | | |
-| consumeFromWhere | 消费方式设置 | ConsumeFromWhere | ConsumeFromWhere.CONSUME_FROM_LAST_OFFSET | | |
-| consumeTimestamp | 回溯消费时间 | String | 默认回溯消耗时间为半小时前 | | |
-| traceDispatcher | 异步传输数据的接口 | TraceDispatcher | null | | |
-| enableMsgTrace | 信息跟踪的标志 | boolean | false | | |
-| customizedTraceTopic | 消息跟踪主题的名称 | String | | | |
-
-continue......
\ No newline at end of file
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/06-\345\217\202\346\225\260\351\205\215\347\275\256/24server.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\345\217\202\346\225\260\351\205\215\347\275\256/24server.md"
deleted file mode 100644
index b0e16c66..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/06-\345\217\202\346\225\260\351\205\215\347\275\256/24server.md"
+++ /dev/null
@@ -1,99 +0,0 @@
-# 服务端配置
-
-
-
-## NameServer配置
-
-| 名称 | 描述 | 参数类型 | 默认值 | 有效值 | 重要性 |
-| ------------------ | ------------------------------------------------------------ | -------- | ------ | ------ | ------ |
-| rocketmqHome | RocketMQ主目录，默认用户主目录 | String | | | |
-| namesrvAddr | NameServer地址 | String | | | |
-| kvConfigpath | kv配置文件路径，包含顺序消息主题的配置信息 | String | | | |
-| configStorePath | NameServer配置文件路径，建议使用-c指定NameServer配置文件路径 | String | | | |
-| clusterTest | 是否支持集群测试，默认为false | boolean | | | |
-| orderMessageEnable | 是否支持顺序消息，默认为false | boolean | | | |
-| | | | | | |
-
-
-
-## 网络配置属性
-
-| 名称 | 描述 | 参数类型 | 默认值 | 有效值 | 重要性 |
-| -------------------------------------- | ------------------------------------------------------------ | -------- | ------------ | ---------- | ------ |
-| accessMessageInMemorymaxRatio | 访问消息在内存中的比率 | int | 40(%) | | |
-| adminBrokerThreadPoolNums | 服务端处理控制台管理命令线程池线程数量 | int | 16 | | |
-| autoCreateSubscriptionGroup | 是否自动创建消费组 | boolean | true | true/false | |
-| autoCreateTopicEnable | 是否自动创建主题 | boolean | | | |
-| bitMapLengthConsumeQueueExt | ConsumeQueue扩展过滤bitmap大小 | int | 112 | | |
-| brokerClusterName | Broker集群名称 | String | TestCluster | | |
-| brokerFastFailureEnable | 是否支持broker快速失败 如果为true表示会立即清除发送消息线程池，消息拉取线程池中排队任务 ，直接返回系统错误 | boolean | true | | |
-| brokerId | brokerID 0表示主节点 大于0表示从节点 | int | 0 | | |
-| brokerIP1 | Broker服务地址 | String | | | |
-| brokerIP2 | BrokerHAIP地址，供slave同步消息的地址 | String | | | |
-| brokerName | Broker服务器名称morning服务器hostname | String | broker-a | | |
-| brokerPermission | Broker权限 默认为6表示可读可写 | int | 6 | | |
-| brokerRole | broker角色,分为 ASYNC_MASTER SYNC_MASTER, SLAVE | enum | ASYNC_MASTER | | |
-| brokerTopicEnable | broker名称是否可以用做主体使用 | boolean | | | |
-| channelNotActiveInterval | | long | | | |
-| checkCRCOnRecover | 文件恢复时是否校验CRC | boolean | | | |
-| cleanFileForciblyEnable | 是否支持强行删除过期文件 | boolean | | | |
-| cleanResourceInterval | 清除过期文件线程调度频率 | int | | | |
-| clientAsyncSemaphoreValue | 客户端对invokeAsyncImpl方法的调用频率 | int | | | |
-| clientCallbackExecutorThreads | 客户端执行回调线程数 | int | | | |
-| clientChannelMaxIdleTimeSeconds | 客户端每个channel最大等待时间 | int | | | |
-| clientCloseSocketIfTimeout | 客户端关闭socket是否需要等待 | boolean | false | | |
-| clientManagerThreadPoolQueueCapacity | 客户端管理线程池任务队列初始大小 | int | 1000000 | | |
-| clientManageThreadPoolNums | 服务端处理客户端管理（心跳 注册 取消注册线程数量） | int | 32 | | |
-| clientOnewaySemaphoreValue | 客户端对invokeOnewayImpl方法的调用控制 | int | | | |
-| clientPooledByteBufAllocatorEnable | 客户端池化内存是否开启 | boolean | | | |
-| clientSocketRcvBufSize | 客户端socket接收缓冲区大小 | long | | | |
-| clientSocketSndBufSize | 客户端socket发送缓冲区大小 | long | | | |
-| clientWorkerThreads | worker线程数 | int | | | |
-| clusterTopicEnable | 集群名称是否可用在主题使用 | boolean | | | |
-| commercialBaseCount | | | | | |
-| commercialBigCount | | | | | |
-| commercialEnable | | | | | |
-| commercialTimerCount | | | | | |
-| commitCommitLogLeastPages | 一次提交至少需要脏页的数量,默认4页,针对 commitlog文件 | int | | | |
-| commitCommitLogThoroughInterval | Commitlog两次提交的最大间隔,如果超过该间隔,将忽略commitCommitLogLeastPages直接提交 | int | 200 | | |
-| commitIntervalCommitLog | commitlog提交频率 | int | 200 | | |
-| compressedRegister | 是否开启消息压缩 | boolean | | | |
-| connectTimeoutMillis | 链接超时时间 | long | 3000 | | |
-| consumerFallbehindThreshold | 消息消费堆积阈值默认16GB在disableConsumeifConsumeIfConsumerReadSlowly为true时生效 | long | 17179869184 | | |
-| consumerManagerThreadPoolQueueCapacity | 消费管理线程池任务队列大小 | int | 1000000 | | |
-| consumerManageThreadPoolNums | 服务端处理消费管理 获取消费者列表 更新消费者进度查询消费进度等 | int | 32 | | |
-| debugLockEnable | 是否支持 PutMessage Lock锁打印信息 | boolean | false | | |
-| defaultQueryMaxNum | 查询消息默认返回条数,默认为32 | int | 32 | | |
-| defaultTopicQueueNums | 主体在一个broker上创建队列数量 | int | 8 | | |
-| deleteCommitLogFilesInterval | 删除commitlog文件的时间间隔，删除一个文件后等一下再删除一个文件 | int | 100 | | |
-| deleteConsumeQueueFilesInterval | 删除consumequeue文件时间间隔 | int | 100 | | |
-| deleteWhen | 磁盘文件空间充足情况下，默认每天什么时候执行删除过期文件，默认04表示凌晨4点 | string | 04 | | |
-| destroyMapedFileIntervalForcibly | 销毁MappedFile被拒绝的最大存活时间，默认120s。清除过期文件线程在初次销毁mappedfile时，如果该文件被其他线程引用，引用次数大于0.则设置MappedFile的可用状态为false，并设置第一次删除时间，下一次清理任务到达时，如果系统时间大于初次删除时间加上本参数，则将ref次数一次减1000，知道引用次数小于0，则释放物理资源 | int | 120000 | | |
-| disableConsumeIfConsumerReadSlowly | 如果消费组消息消费堆积是否禁用该消费组继续消费消息 | boolean | false | | |
-| diskFallRecorded | 是否统计磁盘的使用情况,默认为true | boolean | true | | |
-| diskMaxUsedSpaceRatio | commitlog目录所在分区的最大使用比例，如果commitlog目录所在的分区使用比例大于该值，则触发过期文件删除 | int | 75 | | |
-| duplicationEnable | 是否允许重复复制,默认为 false | boolean | false | | |
-| enableCalcFilterBitMap | 是否开启比特位映射 | boolean | false | | |
-| enableConsumeQueueExt | 是否启用ConsumeQueue扩展属性 | boolean | false | | |
-| enablePropertyFilter | 是否支持根据属性过滤 如果使用基于标准的sql92模式过滤消息则改参数必须设置为true | boolean | false | | |
-| endTransactionPoolQueueCapacity | 处理提交和回滚消息线程池线程队列大小 | int | | | |
-| endTransactionThreadPoolNums | 处理提交和回滚消息线程池 | int | 24 | | |
-| expectConsumerNumUseFilter | 布隆过滤器参数 | int | 32 | | |
-| fastFailIfNoBufferInStorePool | 从 transientStorepool中获取 ByteBuffer是否支持快速失败 | boolean | false | | |
-| fetchNamesrvAddrByAddressServer | 是否支持从服务器获取nameServer | boolean | false | | |
-| fileReservedTime | 文件保留时间，默认72小时，表示非当前写文件最后一次更新时间加上filereservedtime小与当前时间，该文件将被清理 | String | 120 | | |
-| filterDataCleanTimeSpan | 清除过滤数据的时间间隔 | long | 86400000 | | |
-| filterServerNums | broker服务器过滤服务器数量 | int | 0 | | |
-| filterSupportRetry | 消息过滤是否支持重试 | boolean | false | | |
-| flushCommitLogLeastPages | 一次刷盘至少需要脏页的数量，针对commitlog文件 | int | 4 | | |
-| flushCommitLogTimed | 表示await方法等待FlushIntervalCommitlog,如果为true表示使用Thread.sleep方法等待 | boolean | false | | |
-| flushConsumeQueueLeastPages | 一次刷盘至少需要脏页的数量,默认2页,针对 Consume文件 | int | 2 | | |
-| flushConsumeQueueThoroughInterval | Consume两次刷盘的最大间隔,如果超过该间隔,将忽略 | int | 60000 | | |
-| flushConsumerOffsetHistoryInterval | fushConsumeQueueLeastPages直接刷盘 | int | 60000 | | |
-| flushConsumerOffsetInterval | 持久化消息消费进度 consumerOffse.json文件的频率ms | int | 5000 | | |
-| flushDelayOffsetInterval | 延迟队列拉取进度刷盘间隔。默认10s | long | 10000 | | |
-| flushDiskType | 刷盘方式,默认为 ASYNC_FLUSH(异步刷盘),可选值SYNC_FLUSH(同步刷盘) | enum | ASYNC_FLUSH | | |
-| flushIntervalCommitLog | commitlog刷盘频率 | int | 500 | | |
-| flushIntervalConsumeQueue | consumuQueue文件刷盘频率 | int | 1000 | | |
-| flushLeastPagesWhenWarmMapedFile | 用字节0填充整个文件的,每多少页刷盘一次。默认4096页,异步刷盘模式生效 | int | 4096 | | |
-
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/15bestpractice.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/15bestpractice.md"
new file mode 100644
index 00000000..9fe8a3ca
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/15bestpractice.md"
@@ -0,0 +1,104 @@
+# 基本最佳实践
+
+## 生产者
+
+### 发送消息注意事项
+
+#### Tag的使用
+
+一个应用尽可能用一个Topic，而消息子类型则可以用tags来标识。tags可以由应用自由设置，只有生产者在发送消息设置了tags，消费方在订阅消息时才可以利用tags通过broker做消息过滤，5.x SDK 可以调用messageBuilder.setTag("messageTag")，历史版本可以调用 message.setTags("messageTag")。
+
+#### Keys的使用
+
+每个消息在业务层面一般建议映射到业务的唯一标识并设置到keys字段，方便将来定位消息丢失问题。服务器会为每个消息创建索引（哈希索引），应用可以通过topic、key来查询这条消息内容，以及消息被谁消费。由于是哈希索引，请务必保证key尽可能唯一，这样可以避免潜在的哈希冲突。常见的设置策略使用订单Id、用户Id、请求Id等比较离散的唯一标识来处理。
+
+#### 日志的打印
+
+消息发送成功或者失败要打印消息日志，用于业务排查问题。Send消息方法只要不抛异常，就代表发送成功。
+### 消息发送失败处理方式
+
+Producer的send方法本身支持内部重试，5.x SDK的重试逻辑参考[发送重试策略](../04-功能行为/05sendretrypolicy.md)：
+
+以上策略也是在一定程度上保证了消息可以发送成功。如果业务要求消息发送不能丢，仍然需要对可能出现的异常做兜底，比如调用send同步方法发送失败时，则尝试将消息存储到db，然后由后台线程定时重试，确保消息一定到达Broker。
+
+上述DB重试方式为什么没有集成到MQ客户端内部做，而是要求应用自己去完成，主要基于以下几点考虑：首先，MQ的客户端设计为无状态模式，方便任意的水平扩展，且对机器资源的消耗仅仅是cpu、内存、网络。其次，如果MQ客户端内部集成一个KV存储模块，那么数据只有同步落盘才能较可靠，而同步落盘本身性能开销较大，所以通常会采用异步落盘，又由于应用关闭过程不受MQ运维人员控制，可能经常会发生 kill -9 这样暴力方式关闭，造成数据没有及时落盘而丢失。第三，Producer所在机器的可靠性较低，一般为虚拟机，不适合存储重要数据。综上，建议重试过程交由应用来控制。
+
+## 消费者
+
+### 消费过程幂等
+
+RocketMQ 无法避免消息重复（Exactly-Once），所以如果业务对消费重复非常敏感，务必要在业务层面进行去重处理。可以借助关系数据库进行去重。首先需要确定消息的唯一键，可以是msgId，也可以是消息内容中的唯一标识字段，例如订单Id等。在消费之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。（实际过程要考虑原子性问题，判断是否存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过）
+
+msgId一定是全局唯一标识符，但是实际使用中，可能会存在相同的消息有两个不同msgId的情况（消费者主动重发、因客户端重投机制导致的重复等），这种情况就需要使业务字段进行重复消费。
+
+### 消费速度慢的处理方式
+
+### 提高消费并行度
+
+绝大部分消息消费行为都属于 IO 密集型，即可能是操作数据库，或者调用 RPC，这类消费行为的消费速度在于后端数据库或者外系统的吞吐量，通过增加消费并行度，可以提高总的消费吞吐量，但是并行度增加到一定程度，反而会下降。所以，应用必须要设置合理的并行度。 如下有几种修改消费并行度的方法：
+
+- 同一个 ConsumerGroup 下，通过增加 Consumer 实例数量来提高并行度。可以通过加机器，或者在已有机器启动多个进程的方式。
+- 提高单个 Consumer 的消费并行线程，5.x PushConsumer SDK 可以通过PushConsumerBuilder.setConsumptionThreadCount() 设置线程数，SimpleConsumer可以由业务线程自由增加并发，底层线程安全；历史版本SDK PushConsumer可以通过修改参数 consumeThreadMin、consumeThreadMax实现。
+
+### 批量方式消费
+
+某些业务流程如果支持批量方式消费，则可以很大程度上提高消费吞吐量，例如订单扣款类应用，一次处理一个订单耗时 1 s，一次处理 10 个订单可能也只耗时 2 s，这样即可大幅度提高消费的吞吐量。建议使用5.x SDK的SimpleConsumer，每次接口调用设置批次大小，一次性拉取消费多条消息。
+
+### 重置位点跳过非重要消息
+
+发生消息堆积时，如果消费速度一直追不上发送速度，如果业务对数据要求不高的话，可以选择丢弃不重要的消息。建议使用重置位点功能直接调整消费位点到指定时刻或者指定位置。
+
+#### 优化每条消息消费过程
+
+举例如下，某条消息的消费过程如下：
+
+- 根据消息从 DB 查询【数据 1】
+- 根据消息从 DB 查询【数据 2】
+- 复杂的业务计算
+- 向 DB 插入【数据 3】
+- 向 DB 插入【数据 4】
+
+这条消息的消费过程中有4次与 DB的 交互，如果按照每次 5ms 计算，那么总共耗时 20ms，假设业务计算耗时 5ms，那么总过耗时 25ms，所以如果能把 4 次 DB 交互优化为 2 次，那么总耗时就可以优化到 15ms，即总体性能提高了 40%。所以应用如果对时延敏感的话，可以把DB部署在SSD硬盘，相比于SCSI磁盘，前者的RT会小很多。
+
+### 消费打印日志
+
+如果消息量较少，建议在消费入口方法打印消息，消费耗时等，方便后续排查问题。
+
+```java
+ new MessageListener() {
+ @Override
+ public ConsumeResult consume(MessageView messageView) {
+ LOGGER.info("Consume message={}", messageView);
+ //Do your consume process
+ return ConsumeResult.SUCCESS;
+ }
+ }
+```
+
+如果能打印每条消息消费耗时，那么在排查消费慢等线上问题时，会更方便。但如果线上环境TPS很高，不建议开启，避免日志太多影响性能。
+
+## Broker
+
+### Broker 角色
+ Broker 角色分为 ASYNC_MASTER（异步主机）、SYNC_MASTER（同步主机）以及SLAVE（从机）。如果对消息的可靠性要求比较严格，可以采用 SYNC_MASTER加SLAVE的部署方式。如果对消息可靠性要求不高，可以采用ASYNC_MASTER加SLAVE的部署方式。如果只是测试方便，则可以选择仅ASYNC_MASTER或仅SYNC_MASTER的部署方式。
+### FlushDiskType
+ SYNC_FLUSH（同步刷新）相比于ASYNC_FLUSH（异步处理）会损失很多性能，但是也更可靠，所以需要根据实际的业务场景做好权衡。
+### Broker 配置
+
+| 参数名 | 默认值 | 说明 |
+| -------------------------------- | ----------------------------- | ------------------------------------------------------------ |
+| listenPort | 10911 | 接受客户端连接的监听端口 |
+| namesrvAddr | null | nameServer 地址 |
+| brokerIP1 | 网卡的 InetAddress | 当前 broker 监听的 IP |
+| brokerIP2 | 跟 brokerIP1 一样 | 存在主从 broker 时，如果在 broker 主节点上配置了 brokerIP2 属性，broker 从节点会连接主节点配置的 brokerIP2 进行同步 |
+| brokerName | null | broker 的名称 |
+| brokerClusterName | DefaultCluster | 本 broker 所属的 Cluser 名称 |
+| brokerId | 0 | broker id, 0 表示 master, 其他的正整数表示 slave |
+| storePathCommitLog | $HOME/store/commitlog/ | 存储 commit log 的路径 |
+| storePathConsumerQueue | $HOME/store/consumequeue/ | 存储 consume queue 的路径 |
+| mapedFileSizeCommitLog | 1024 * 1024 * 1024(1G) | commit log 的映射文件大小 |
+| deleteWhen | 04 | 在每天的什么时间删除已经超过文件保留时间的 commit log |
+| fileReserverdTime | 72 | 以小时计算的文件保留时间 |
+| brokerRole | ASYNC_MASTER | SYNC_MASTER/ASYNC_MASTER/SLAVE |
+| flushDiskType | ASYNC_FLUSH | SYNC_FLUSH/ASYNC_FLUSH SYNC_FLUSH 模式下的 broker 保证在收到确认生产者之前将消息刷盘。ASYNC_FLUSH 模式下的 broker 则利用刷盘一组消息的模式，可以取得更好的性能。 |
+
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/16dledger.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/16dledger.md"
similarity index 94%
rename from "i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/16dledger.md"
rename to "i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/16dledger.md"
index 15833ba9..9b44660e 100644
--- "a/i18n/en/docusaurus-plugin-content-docs/5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/16dledger.md"
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/16dledger.md"
@@ -1,10 +1,10 @@
# Dledger
## Dledger快速搭建
### 前言
-该文档主要介绍如何快速构建和部署基于 DLedger 的可以自动容灾切换的 RocketMQ 集群。
+DLedger是一套基于Raft协议的分布式日志存储组件，部署 RocketMQ 时可以根据需要选择使用DLeger来替换原生的副本存储机制。本文档主要介绍如何快速构建和部署基于 DLedger 的可以自动容灾切换的 RocketMQ 集群。
### 1. 源码构建
-构建分为两个部分，需要先构建 DLedger，然后 构建 RocketMQ
+构建分为两个部分，需要先构建 DLedger，然后 构建 RocketMQ。
#### 1.1 构建 DLedger
diff --git "a/versioned_docs/version-5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/18access.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/18access.md"
similarity index 92%
rename from "versioned_docs/version-5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/18access.md"
rename to "i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/18access.md"
index 09906025..cef1c9f3 100644
--- "a/versioned_docs/version-5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/18access.md"
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/18access.md"
@@ -1,14 +1,16 @@
# 权限控制
## 1.权限控制特性介绍
-权限控制（ACL）主要为RocketMQ提供Topic资源级别的用户访问控制。用户在使用RocketMQ权限控制时，可以在Client客户端通过 RPCHook注入AccessKey和SecretKey签名；同时，将对应的权限控制属性（包括Topic访问权限、IP白名单和AccessKey和SecretKey签名等）设置在distribution/conf/plain_acl.yml的配置文件中。Broker端对AccessKey所拥有的权限进行校验，校验不过，抛出异常；
-ACL客户端可以参考：**org.apache.rocketmq.example.simple**包下面的**AclClient**代码。
+权限控制（ACL）主要为 RocketMQ 提供 Topic 资源级别的高级访问控制功能。用户在使用RocketMQ权限控制时，可以在Client客户端注入用户名和密码参数实现签名，服务端通过权限控制参数实现各个资源的权限管理和校验。
+:::info
+ACL控制在增强集群访问控制安全性的同时也会带来部署流程和运维管理的复杂度。
+
+一般仅建议在网络环境不安全、业务数据敏感、多部门租户混用的场景下使用。如果生产集群本身是私有集群不会被外部部门租户访问，可以不开启。
+:::
## 2. 权限控制的定义与属性值
### 2.1权限定义
对RocketMQ的Topic资源访问权限控制定义主要如下表所示，分为以下四种
-
-
| 权限 | 含义 |
| --- | --- |
| DENY | 拒绝 |
diff --git "a/versioned_docs/version-5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/19JVMOS.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/19JVMOS.md"
similarity index 86%
rename from "versioned_docs/version-5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/19JVMOS.md"
rename to "i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/19JVMOS.md"
index 4ace42a5..20b636b7 100644
--- "a/versioned_docs/version-5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/19JVMOS.md"
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/19JVMOS.md"
@@ -5,7 +5,7 @@
## 1 JVM选项
-推荐使用最新发布的 JDK 1.8 版本。通过设置相同的 Xms 和 Xmx 值来防止 JVM 调整堆大小以获得更好的性能。生产环境 JVM 配置如下所示：
+推荐使用最新发布的 JDK 版本。通过设置相同的 Xms 和 Xmx 值来防止 JVM 调整堆大小以获得更好的性能。生产环境 JVM 配置如下所示：
```text
-server -Xms8g -Xmx8g -Xmn4g
@@ -19,6 +19,9 @@
-XX:+AlwaysPreTouch
```
+:::info
+生产环境集群 Broker 一般建议配置足够的内存，避免使用小规格内存机器部署。因为Broker是重度依赖内存PageCache做性能优化的，内存过小可能造成性能不稳定。
+:::
禁用偏置锁定可能会减少 JVM 暂停：
```text
diff --git "a/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/21subscribe.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/21subscribe.md"
new file mode 100644
index 00000000..b34c071e
--- /dev/null
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/21subscribe.md"
@@ -0,0 +1,100 @@
+# 订阅关系一致
+
+## 前言
+
+订阅关系是 RocketMQ 领域模型中非常重要的环节，用于表达消费者消费消息的控制元数据，完整的概念请参考[订阅关系模型](../03-领域模型/09subscription.md)。
+
+订阅关系一致是指，同一个消费者组下所有消费者实例所订阅的Topic、Tag必须完全一致。如果订阅关系（消费者分组名-Topic-Tag）不一致，会导致消费消息紊乱，甚至消息丢失。
+
+## 1 正确订阅关系示例
+
+### 1.1 订阅的Topic一样，且过滤表达式一致
+
+如下图所示，同一 ConsumerGroup 下的三个Consumer实例C1、C2和C3分别都订阅了TopicA，且订阅TopicA的Tag也都是Tag1，符合订阅关系一致原则。
+
+
+
+
+**正确示例代码一**
+
+C1、C2、C3的订阅关系一致，即C1、C2、C3订阅消息的代码必须完全一致，代码示例如下：
+
+```java
+ PushConsumer consumer1 = provider.newPushConsumerBuilder().setConsumerGroup("GroupA").build();
+ consumer1.subscribe("TopicA", new FilterExpression("TagA", FilterExpressionType.TAG));
+
+ PushConsumer consumer2 = provider.newPushConsumerBuilder().setConsumerGroup("GroupA").build();
+ consumer2.subscribe("TopicA", new FilterExpression("TagA", FilterExpressionType.TAG));
+
+ PushConsumer consumer3 = provider.newPushConsumerBuilder().setConsumerGroup("GroupA").build();
+ consumer3.subscribe("TopicA", new FilterExpression("TagA", FilterExpressionType.TAG));
+```
+:::info
+RocketMQ 强调订阅关系一致，核心是指相同 ConsumerGroup 的每个 Consumer 之间一致，因为在服务端视角看来一个 Group 下的所有 Consumer 都应该是相同的副本逻辑。
+
+强调订阅关系一致，并不是指一个 Consumer 不能订阅多个Topic，每个 Consumer 仍然可以按照需要订阅多个 Topic，但前提是相同消费者分组下的 Consumer 要一致。
+:::
+
+
+## 2 订阅关系不一致的排查
+
+**问题描述**
+
+在使用 Apache RocketMQ 时，可能会出现订阅关系不一致的情况，具体的问题现象如下：
+
+- Apache RocketMQ 控制台中订阅关系是否一致显示为否。
+- 消费者（Consumer）实例未收到订阅的消息。
+
+**请参考以下步骤进行检查**
+
+您可在消息Apache RocketMQ的控制台或者CLi工具查看指定Group的订阅关系是否一致。若查询结果不一致，请参见本文(3 常见订阅关系不一致问题)排查Consumer实例的消费代码。
+
+1. 检查您Consumer实例中与订阅相关的配置代码，确保配置同一个 ConsumerGroup 的所有Consumer实例均订阅相同的Topic及Tag。
+2. 使用控制台或者Cli命令ConsumerConnection 查看生效的订阅关系是否一致。
+3. 测试并确认消息能够被预期的Consumer实例所消费。
+
+## 3 常见订阅关系不一致问题
+
+### 3.1 同一ConsumerGroup下的Consumer实例订阅的Topic不同（3.x、4.x SDK适用）
+
+在早期3.x/4.x 版本的SDK中，如下图所示，同一 ConsumerGroup 下的三个Consumer实例C1、C2和C3分别订阅了TopicA、TopicB和TopicC，订阅的Topic不一致，不符合订阅关系一致性原则。
+:::note
+5.x版本SDK 已经支持同一个 ConsumerGroup 下的Consumer实例订阅不同的Topic。
+:::
+
+
+### 3.2 同一 ConsumerGroup 下的 Consumer 实例订阅的Topic相同，但订阅的Tag不一致
+
+如下图所示，同一 ConsumerGroup 下的三个Consumer实例C1、C2和C3分别都订阅了TopicA，但是C1订阅TopicA的Tag为**Tag1**，C2和C3订阅的TopicA的Tag为**Tag2**，订阅同一Topic的Tag不一致，不符合订阅关系一致性原则。
+
+
+
+**错误示例代码二**
+
++ Consumer实例2-1：
+
+ ```java
+ PushConsumer consumer1 = provider.newPushConsumerBuilder().setConsumerGroup("GroupA").build();
+ consumer1.subscribe("TopicA", new FilterExpression("Tag1", FilterExpressionType.TAG));
+ ```
+
+
+
++ Consumer实例2-2：
+
+ ```java
+ PushConsumer consumer2 = provider.newPushConsumerBuilder().setConsumerGroup("GroupA").build();
+ consumer2.subscribe("TopicA", new FilterExpression("Tag2", FilterExpressionType.TAG));
+ ```
+
++ Consumer实例2-3：
+
+ ```java
+ PushConsumer consumer3 = provider.newPushConsumerBuilder().setConsumerGroup("GroupA").build();
+ consumer3.subscribe("TopicA", new FilterExpression("Tag2", FilterExpressionType.TAG));
+ ```
+
+
+
+
+
diff --git "a/versioned_docs/version-5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/22FAQ.md" "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/22FAQ.md"
similarity index 87%
rename from "versioned_docs/version-5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/22FAQ.md"
rename to "i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/22FAQ.md"
index 58a8b617..0e88cd16 100644
--- "a/versioned_docs/version-5.0/05-\346\234\200\344\275\263\345\256\236\350\267\265/22FAQ.md"
+++ "b/i18n/en/docusaurus-plugin-content-docs/5.0/06-\346\234\200\344\275\263\345\256\236\350\267\265/22FAQ.md"
@@ -14,21 +14,19 @@
## 2 使用
-1. **新创建的 Consumer ID 从哪里开始消费消息？**
+1. **新创建的 ConsumerGroup 从哪里开始消费消息？**
- 1）如果发送的消息在三天之内，那么消费者会从服务器中保存的第一条消息开始消费。
+ 1）5.x SDK，在首次上线时会从服务器中的最新消息开始消费，也就是从队列的尾部开始消费；再次重新启动后，会从最后一次的消费位置继续消费。
- 2）如果发送的消息已经超过三天，则消费者会从服务器中的最新消息开始消费，也就是从队列的尾部开始消费。
+ 2）3.x/4.x SDK 则比较复杂，如果首次启动是在发送的消息在三天之内，那么消费者会从服务器中保存的第一条消息开始消费；如果发送的消息已经超过三天，则消费者会从服务器中的最新消息开始消费，也就是从队列的尾部开始消费。再次重新启动后，会从最后一次的消费位置继续消费。
- 3）如果消费者重新启动，那么它会从最后一个消费位置开始消费消息。
+3. **当消费失败的时候如何重新消费消息？**
-2. **当消费失败的时候如何重新消费消息？**
-
- 1）在集群模式下，消费的业务逻辑代码会返回 Action.ReconsumerLater，NULL，或者抛出异常，如果一条消息消费失败，最多会重试 16 次，之后该消息会被丢弃。
+ 1）在集群模式下，消费的业务逻辑代码会返回消费失败状态，或者抛出异常，如果一条消息消费失败，则会按照设置的最大重试次数重试，之后该消息会被丢弃。
2）在广播消费模式下，广播消费仍然保证消息至少被消费一次，但不提供重发的选项。
-3. **当消费失败的时候如何找到失败的消息？**
+4. **当消费失败的时候如何找到失败的消息？**
1）使用按时间的主题查询，可以查询到一段时间内的消息。
@@ -36,11 +34,11 @@
3）使用主题和消息的 Key 来准确查询所有消息 Key 相同的消息。
-4. **消息只会被传递一次吗？**
+5. **消息只会被传递一次吗？**
RocketMQ 确保所有消息至少传递一次。 在大多数情况下，消息不会重复。
-5. **如何增加一个新的 Broker ？**
+6. **如何增加一个新的 Broker ？**
1）启动一个新的 Broker 并将其注册到NameServer 中的 Broker 列表里。
@@ -60,12 +58,7 @@
3. **怎么设置消费者线程数？**
- 当你启动消费者的时候，可以设置 ConsumeThreadNums 属性的值，举例如下：
-
- ```java
- consumer.setConsumeThreadMin(20);
- consumer.setConsumeThreadMax(20);
- ```
+ 当你启动消费者的时候，可以设置属性。不同版本的参数名不一样。
## 4 错误
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforconsumer.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforconsumer.png
new file mode 100644
index 00000000..ffe2bbac
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforconsumer.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforconsumergroup.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforconsumergroup.png
new file mode 100644
index 00000000..d5abd272
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforconsumergroup.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforproducer.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforproducer.png
new file mode 100644
index 00000000..9cddfe47
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforproducer.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforqueue.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforqueue.png
new file mode 100644
index 00000000..d5366ac0
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforqueue.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforsubsciption.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforsubsciption.png
new file mode 100644
index 00000000..f8c7653b
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archiforsubsciption.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archifortopic.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archifortopic.png
new file mode 100644
index 00000000..0b02f2e0
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/archifortopic.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/asyncarchi.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/asyncarchi.png
new file mode 100644
index 00000000..91719042
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/asyncarchi.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/changeInvisibletime.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/changeInvisibletime.png
new file mode 100644
index 00000000..8337cb7e
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/changeInvisibletime.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/cleanpolicy.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/cleanpolicy.png
new file mode 100644
index 00000000..1dd439b1
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/cleanpolicy.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/clustermode.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/clustermode.png
new file mode 100644
index 00000000..389248b4
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/clustermode.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/clusterqueuemode.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/clusterqueuemode.png
new file mode 100644
index 00000000..395472cf
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/clusterqueuemode.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumemode.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumemode.png
new file mode 100644
index 00000000..88523173
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumemode.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumerflow.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumerflow.png
new file mode 100644
index 00000000..72133fef
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumerflow.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumerprogress.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumerprogress.png
new file mode 100644
index 00000000..75617f14
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumerprogress.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumerprogress1.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumerprogress1.png
new file mode 100644
index 00000000..be0469bb
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/consumerprogress1.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/delaywork.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/delaywork.png
new file mode 100644
index 00000000..ef95a90e
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/delaywork.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/fifo_trade.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/fifo_trade.png
new file mode 100644
index 00000000..a76cdd89
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/fifo_trade.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/fifoinclustermode.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/fifoinclustermode.png
new file mode 100644
index 00000000..6714f9a0
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/fifoinclustermode.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/fifomessagegroup.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/fifomessagegroup.png
new file mode 100644
index 00000000..6855ef44
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/fifomessagegroup.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/lifecyclefordelay.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/lifecyclefordelay.png
new file mode 100644
index 00000000..f1111e26
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/lifecyclefordelay.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/lifecyclefornormal.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/lifecyclefornormal.png
new file mode 100644
index 00000000..f135c38f
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/lifecyclefornormal.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/lifecyclefortrans.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/lifecyclefortrans.png
new file mode 100644
index 00000000..93336cd8
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/lifecyclefortrans.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/mainarchi.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/mainarchi.png
new file mode 100644
index 00000000..da27d58e
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/mainarchi.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/maxoffset.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/maxoffset.png
new file mode 100644
index 00000000..317b432e
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/maxoffset.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/messagefilter.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/messagefilter.png
new file mode 100644
index 00000000..4c474464
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/messagefilter.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/messagefilter0.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/messagefilter0.png
new file mode 100644
index 00000000..649cd71d
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/messagefilter0.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/messagefilter2.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/messagefilter2.png
new file mode 100644
index 00000000..a57a100b
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/messagefilter2.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/offlineprocess.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/offlineprocess.png
new file mode 100644
index 00000000..08d5be72
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/offlineprocess.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/onlineprocess.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/onlineprocess.png
new file mode 100644
index 00000000..2c753d34
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/onlineprocess.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/p2pmode.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/p2pmode.png
new file mode 100644
index 00000000..9f8d04fd
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/p2pmode.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/producer_topic.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/producer_topic.png
new file mode 100644
index 00000000..5c62b840
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/producer_topic.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/pubsub.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/pubsub.png
new file mode 100644
index 00000000..104df69c
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/pubsub.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/pushconsumer.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/pushconsumer.png
new file mode 100644
index 00000000..b23669d8
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/pushconsumer.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/retrymachinestatus.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/retrymachinestatus.png
new file mode 100644
index 00000000..e7aede6c
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/retrymachinestatus.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/retrytimeline.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/retrytimeline.png
new file mode 100644
index 00000000..11856382
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/retrytimeline.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/scheduletask.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/scheduletask.png
new file mode 100644
index 00000000..04daa278
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/scheduletask.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/simplemachinestatus.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/simplemachinestatus.png
new file mode 100644
index 00000000..5cb68687
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/simplemachinestatus.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/simpletimeline.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/simpletimeline.png
new file mode 100644
index 00000000..ca8c75d3
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/simpletimeline.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/subscription_diff_group.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/subscription_diff_group.png
new file mode 100644
index 00000000..b74c2961
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/subscription_diff_group.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/subscription_one_group.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/subscription_one_group.png
new file mode 100644
index 00000000..2512efe7
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/subscription_one_group.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/syncarchi.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/syncarchi.png
new file mode 100644
index 00000000..a801c775
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/syncarchi.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradetrans01.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradetrans01.png
new file mode 100644
index 00000000..52a864d7
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradetrans01.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithfifo.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithfifo.png
new file mode 100644
index 00000000..9a5a51bb
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithfifo.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithnormal.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithnormal.png
new file mode 100644
index 00000000..1593c665
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithnormal.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithrmqtrans.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithrmqtrans.png
new file mode 100644
index 00000000..058bd1f2
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithrmqtrans.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithtrans.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithtrans.png
new file mode 100644
index 00000000..59a60533
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/tradewithtrans.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/transflow.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/transflow.png
new file mode 100644
index 00000000..aeb34445
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/transflow.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/transwithnormal.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/transwithnormal.png
new file mode 100644
index 00000000..2f6aee45
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/transwithnormal.png differ
diff --git a/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/updateprogress.png b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/updateprogress.png
new file mode 100644
index 00000000..317b432e
Binary files /dev/null and b/i18n/en/docusaurus-plugin-content-docs/5.0/picture/v5/updateprogress.png differ
diff --git "a/i18n/en/docusaurus-plugin-content-docs/current/05-\346\234\200\344\275\263\345\256\236\350\267\265/20log.md" "b/i18n/en/docusaurus-plugin-content-docs/current/05-\346\234\200\344\275\263\345\256\236\350\267\265/20log.md"
deleted file mode 100644
index 06694426..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/current/05-\346\234\200\344\275\263\345\256\236\350\267\265/20log.md"
+++ /dev/null
@@ -1,190 +0,0 @@
-# 日志配置
-
-客户端日志用于记录客户端运行过程中的异常，帮助快速定位和修复问题。本文介绍 RocketMQ 的客户端日志的打印方式，以及默认和自定义配置。
-
-## 打印客户端日志
-RocketMQ 的 TCP Java SDK 基于 SLF4J 接口编程。
-- 针对 JavaSDK1.7.8.Final 版本及以上
-
-RocketMQ 的 Java SDK 1.7.8.Final 已内置了日志实现，无需在客户端应用中添加日志实现依赖 即可打印 RocketMQ 客户端日志。
-RocketMQ客户端日志的默认配置和如何修改默认配置，请参见下文的客户端日志配置部分。
-- 针对 JavaSDK1.7.8.Final 以下
-
-RocketMQ 的Java SDK 1.7.8.Final 以下的旧版本不支持 log4j2，只支持 log4j、logback。您需要 在 pom.xml 配置文件 或者 lib 中添加对应的日志实现依赖来打印 RocketMQ 客户端日志。
-
-### 方式一: 依赖 log4j 作为日志实现
-依赖log4j或logback作为日志实现的示例代码如下所示。
-
-```javascript
-<dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>jcl-over-slf4j</artifactId>
- <version>1.7.7</version>
-</dependency>
-<dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>slf4j-log4j12</artifactId>
- <version>1.7.7</version>
-</dependency>
-<dependency>
- <groupId>log4j</groupId>
- <artifactId>log4j</artifactId>
- <version>1.2.17</version>
-</dependency>
-```
-
-使用 log4j 属性配置文件时，配置如下。
-
-```
-log4j.appender.mq=org.apache.rocketmq.logappender.log4j.RocketmqLog4jAppender
-log4j.appender.mq.Tag=yourTag
-log4j.appender.mq.Topic=yourLogTopic
-log4j.appender.mq.ProducerGroup=yourLogGroup
-log4j.appender.mq.NameServerAddress=yourRocketmqNameserverAddress
-log4j.appender.mq.layout=org.apache.log4j.PatternLayout
-log4j.appender.mq.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-4r [%t] (%F:%L) %-5p - %m%n
-```
-
-使用 log4j xml 配置文件时，将其配置为这样并添加一个异步附加程序：
-```
-<appender name="mqAppender1" class="org.apache.rocketmq.logappender.log4j.RocketmqLog4jAppender">
- <param name="Tag" value="yourTag" />
- <param name="Topic" value="yourLogTopic" />
- <param name="ProducerGroup" value="yourLogGroup" />
- <param name="NameServerAddress" value="yourRocketmqNameserverAddress"/>
- <layout class="org.apache.log4j.PatternLayout">
- <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss}-%p %t %c - %m%n" />
- </layout>
-</appender>
-
-<appender name="mqAsyncAppender1" class="org.apache.log4j.AsyncAppender">
- <param name="BufferSize" value="1024" />
- <param name="Blocking" value="false" />
- <appender-ref ref="mqAppender1"/>
-</appender>
-```
-使用 log4j2 时，配置为 this。如果你想要 noneblock，只需为 ref 配置一个 asyncAppender。
-
-```
-<RocketMQ name="rocketmqAppender" producerGroup="yourLogGroup" nameServerAddress="yourRocketmqNameserverAddress"
- topic="yourLogTopic" tag="yourTag">
- <PatternLayout pattern="%d [%p] hahahah %c %m%n"/>
-</RocketMQ>
-```
-
-### 方式二: 依赖 logback 作为日志实现
-
-```
-<dependency>
- <groupId>ch.qos.logback</groupId>
- <artifactId>logback-core</artifactId>
- <version>1.1.2</version>
-</dependency>
-<dependency>
- <groupId>ch.qos.logback</groupId>
- <artifactId>logback-classic</artifactId>
- <version>1.1.2</version>
-</dependency>
-```
-
-```
-<dependency>
- <groupId>ch.qos.logback</groupId>
- <artifactId>logback-core</artifactId>
- <version>1.1.2</version>
-</dependency>
-<dependency>
- <groupId>ch.qos.logback</groupId>
- <artifactId>logback-classic</artifactId>
- <version>1.1.2</version>
-</dependency>
-```
-:::tip
-应用中同时依赖log4j和logback的日志实现会造成日志冲突导致客户端日志打印混乱。确保 应用只依赖其中一个日志实现，是正确打印RocketMQ客户端日志的前提条件，建议通过```mvn
-clean dependency:tree | grep log```命令排查。
-:::
-
-## 客户端日志配置
-
-RocketMQ 客户端支持自定义日志保存路径、日志级别以及保存历史日志文件的最大个数。考虑到日志传输以及阅读的便利性，暂不允许自定义单个日志文件大小，仍保持默认的64 MB。各参数的配置说明如下：
-
-| 参数 | 说明 | 配置参数 | 自定义取值 |
-| ----------------------------- | ------------------------------------------------------------ | ------------------------------- | ------------------------------------------------------------ |
-| 日志保存路径 | 请确保应用进程有对该路径写的权限，否则日志 不会打印。 | rocketmq.client.logRoot | 可自定义为您需要将日志文件保存到本地的路径。请确保您的应用进程有该路径的写权限，否则日志无法打印。 |
-| 保存历史日志文件的最大个数 | 支持1到100之前的数值;若输入的值超出该范围 或格式错误，则系统默认保存10个。 | rocketmq.client.logFileMaxIndex | 取值如下：**ERROR****WARN****INFO****DEBUG** |
-| 日志级别 | 支持ERROR、WARN、INFO、DEBUG中任何一 种，不匹配默认INFO。 | rocketmq.client.logLevel | 取值范围：1~100。若设置的值超出该范围或格式错误，则以系统默认值（10个）为准。 |
-| 单个文件日志大小 | 支持以bytes为单位指定 | rocketmq.client.logFileMaxSize | 取值在0~1GB, 默认1GB, 建议64 MB |
-| logback是否使用父级logger打印 | children-logger是否使用 rootLogger配置的appender进行输出 | rocketmq.client.log.additive | true/false |
-| 使用项目的slf4j实现记录日志 | 如果需要实现记录日志 则为true | rocketmq.client.logUseSlf4j | true/flase |
-
-## 默认配置
-
-请确保应用进程有对该路径写的权限，否则日志 不会打印。 支持 1 到 100 之前的数值;若输入的值超出该范围 或格式错误，则系统默认保存10个。 支持 ERROR、WARN、INFO、DEBUG 中任何一 种，不匹配默认 INFO。
-
-RocketMQ 客户端启动后，会按照如下的默认配置生成日志文件 :
-
-- 日志保存路径:/{user.home}/logs/rocketmqlogs/ 其中{user.home}是指启动当前Java进程的用 户的根目录
-- 保存历史日志文件的最大个数:10个
-- 日志级别:INFO
-- 单个日志文件大小: 1GB
-
-## 自定义配置
-
-如果需要进行自定义配置 参考 ClientLogger的静态变量定义, 参数意义对齐上文客户端配置。
-
-```javascript
- public static final String CLIENT_LOG_USESLF4J = "rocketmq.client.logUseSlf4j";
- public static final String CLIENT_LOG_ROOT = "rocketmq.client.logRoot";
- public static final String CLIENT_LOG_MAXINDEX = "rocketmq.client.logFileMaxIndex";
- public static final String CLIENT_LOG_FILESIZE = "rocketmq.client.logFileMaxSize";
- public static final String CLIENT_LOG_LEVEL = "rocketmq.client.logLevel";
- public static final String CLIENT_LOG_ADDITIVE = "rocketmq.client.log.additive";
- public static final String CLIENT_LOG_FILENAME = "rocketmq.client.logFileName";
- public static final String CLIENT_LOG_ASYNC_QUEUESIZE = "rocketmq.client.logAsyncQueueSize";
- public static final String ROCKETMQ_CLIENT_APPENDER_NAME = "RocketmqClientAppender";
-
- private static final InternalLogger CLIENT_LOGGER;
-
- private static final boolean CLIENT_USE_SLF4J;
-
- //private static Appender rocketmqClientAppender = null;
-
- static {
- CLIENT_USE_SLF4J = Boolean.parseBoolean(System.getProperty(CLIENT_LOG_USESLF4J, "false"));
- if (!CLIENT_USE_SLF4J) {
- InternalLoggerFactory.setCurrentLoggerType(InnerLoggerFactory.LOGGER_INNER);
- CLIENT_LOGGER = createLogger(LoggerName.CLIENT_LOGGER_NAME);
- createLogger(LoggerName.COMMON_LOGGER_NAME);
- createLogger(RemotingHelper.ROCKETMQ_REMOTING);
- } else {
- CLIENT_LOGGER = InternalLoggerFactory.getLogger(LoggerName.CLIENT_LOGGER_NAME);
- }
- }
-```
-
-
-## 示例
-
-以下是一个简单示例
-
-在启动脚本中或者IDE的VM options中添加如下系统参数:
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-<Tabs>
-<TabItem value="Linux示例" label="Linux示例" default >
-
-```
--Drocketmq.client.logRoot=/home/admin/logs -Drocketmq.client.logLevel=WARN -Drocketmq.client.logFileMaxIndex=20 -Drocketmq.client.logFileMaxSize=67108864
-```
-</TabItem>
-<TabItem value="windows示例" label="windows示例">
-
-```
--Drocketmq.client.logRoot=D:\logs -Drocketmq.client.logLevel=WARN -Drocketmq.client.logFileMaxIndex=20 -Drocketmq.client.logFileMaxSize=67108864
-```
-
-</TabItem>
-
-</Tabs>
\ No newline at end of file
diff --git "a/i18n/en/docusaurus-plugin-content-docs/current/06-\345\217\202\346\225\260\351\205\215\347\275\256/24server.md" "b/i18n/en/docusaurus-plugin-content-docs/current/06-\345\217\202\346\225\260\351\205\215\347\275\256/24server.md"
deleted file mode 100644
index b0e16c66..00000000
--- "a/i18n/en/docusaurus-plugin-content-docs/current/06-\345\217\202\346\225\260\351\205\215\347\275\256/24server.md"
+++ /dev/null
@@ -1,99 +0,0 @@
-# 服务端配置
-
-
-
-## NameServer配置
-
-| 名称 | 描述 | 参数类型 | 默认值 | 有效值 | 重要性 |
-| ------------------ | ------------------------------------------------------------ | -------- | ------ | ------ | ------ |
-| rocketmqHome | RocketMQ主目录，默认用户主目录 | String | | | |
-| namesrvAddr | NameServer地址 | String | | | |
-| kvConfigpath | kv配置文件路径，包含顺序消息主题的配置信息 | String | | | |
-| configStorePath | NameServer配置文件路径，建议使用-c指定NameServer配置文件路径 | String | | | |
-| clusterTest | 是否支持集群测试，默认为false | boolean | | | |
-| orderMessageEnable | 是否支持顺序消息，默认为false | boolean | | | |
-| | | | | | |
-
-
-
-## 网络配置属性
-
-| 名称 | 描述 | 参数类型 | 默认值 | 有效值 | 重要性 |
-| -------------------------------------- | ------------------------------------------------------------ | -------- | ------------ | ---------- | ------ |
-| accessMessageInMemorymaxRatio | 访问消息在内存中的比率 | int | 40(%) | | |
-| adminBrokerThreadPoolNums | 服务端处理控制台管理命令线程池线程数量 | int | 16 | | |
-| autoCreateSubscriptionGroup | 是否自动创建消费组 | boolean | true | true/false | |
-| autoCreateTopicEnable | 是否自动创建主题 | boolean | | | |
-| bitMapLengthConsumeQueueExt | ConsumeQueue扩展过滤bitmap大小 | int | 112 | | |
-| brokerClusterName | Broker集群名称 | String | TestCluster | | |
-| brokerFastFailureEnable | 是否支持broker快速失败 如果为true表示会立即清除发送消息线程池，消息拉取线程池中排队任务 ，直接返回系统错误 | boolean | true | | |
-| brokerId | brokerID 0表示主节点 大于0表示从节点 | int | 0 | | |
-| brokerIP1 | Broker服务地址 | String | | | |
-| brokerIP2 | BrokerHAIP地址，供slave同步消息的地址 | String | | | |
-| brokerName | Broker服务器名称morning服务器hostname | String | broker-a | | |
-| brokerPermission | Broker权限 默认为6表示可读可写 | int | 6 | | |
-| brokerRole | broker角色,分为 ASYNC_MASTER SYNC_MASTER, SLAVE | enum | ASYNC_MASTER | | |
-| brokerTopicEnable | broker名称是否可以用做主体使用 | boolean | | | |
-| channelNotActiveInterval | | long | | | |
-| checkCRCOnRecover | 文件恢复时是否校验CRC | boolean | | | |
-| cleanFileForciblyEnable | 是否支持强行删除过期文件 | boolean | | | |
-| cleanResourceInterval | 清除过期文件线程调度频率 | int | | | |
-| clientAsyncSemaphoreValue | 客户端对invokeAsyncImpl方法的调用频率 | int | | | |
-| clientCallbackExecutorThreads | 客户端执行回调线程数 | int | | | |
-| clientChannelMaxIdleTimeSeconds | 客户端每个channel最大等待时间 | int | | | |
-| clientCloseSocketIfTimeout | 客户端关闭socket是否需要等待 | boolean | false | | |
-| clientManagerThreadPoolQueueCapacity | 客户端管理线程池任务队列初始大小 | int | 1000000 | | |
-| clientManageThreadPoolNums | 服务端处理客户端管理（心跳 注册 取消注册线程数量） | int | 32 | | |
-| clientOnewaySemaphoreValue | 客户端对invokeOnewayImpl方法的调用控制 | int | | | |
-| clientPooledByteBufAllocatorEnable | 客户端池化内存是否开启 | boolean | | | |
-| clientSocketRcvBufSize | 客户端socket接收缓冲区大小 | long | | | |
-| clientSocketSndBufSize | 客户端socket发送缓冲区大小 | long | | | |
-| clientWorkerThreads | worker线程数 | int | | | |
-| clusterTopicEnable | 集群名称是否可用在主题使用 | boolean | | | |
-| commercialBaseCount | | | | | |
-| commercialBigCount | | | | | |
-| commercialEnable | | | | | |
-| commercialTimerCount | | | | | |
-| commitCommitLogLeastPages | 一次提交至少需要脏页的数量,默认4页,针对 commitlog文件 | int | | | |
-| commitCommitLogThoroughInterval | Commitlog两次提交的最大间隔,如果超过该间隔,将忽略commitCommitLogLeastPages直接提交 | int | 200 | | |
-| commitIntervalCommitLog | commitlog提交频率 | int | 200 | | |
-| compressedRegister | 是否开启消息压缩 | boolean | | | |
-| connectTimeoutMillis | 链接超时时间 | long | 3000 | | |
-| consumerFallbehindThreshold | 消息消费堆积阈值默认16GB在disableConsumeifConsumeIfConsumerReadSlowly为true时生效 | long | 17179869184 | | |
-| consumerManagerThreadPoolQueueCapacity | 消费管理线程池任务队列大小 | int | 1000000 | | |
-| consumerManageThreadPoolNums | 服务端处理消费管理 获取消费者列表 更新消费者进度查询消费进度等 | int | 32 | | |
-| debugLockEnable | 是否支持 PutMessage Lock锁打印信息 | boolean | false | | |
-| defaultQueryMaxNum | 查询消息默认返回条数,默认为32 | int | 32 | | |
-| defaultTopicQueueNums | 主体在一个broker上创建队列数量 | int | 8 | | |
-| deleteCommitLogFilesInterval | 删除commitlog文件的时间间隔，删除一个文件后等一下再删除一个文件 | int | 100 | | |
-| deleteConsumeQueueFilesInterval | 删除consumequeue文件时间间隔 | int | 100 | | |
-| deleteWhen | 磁盘文件空间充足情况下，默认每天什么时候执行删除过期文件，默认04表示凌晨4点 | string | 04 | | |
-| destroyMapedFileIntervalForcibly | 销毁MappedFile被拒绝的最大存活时间，默认120s。清除过期文件线程在初次销毁mappedfile时，如果该文件被其他线程引用，引用次数大于0.则设置MappedFile的可用状态为false，并设置第一次删除时间，下一次清理任务到达时，如果系统时间大于初次删除时间加上本参数，则将ref次数一次减1000，知道引用次数小于0，则释放物理资源 | int | 120000 | | |
-| disableConsumeIfConsumerReadSlowly | 如果消费组消息消费堆积是否禁用该消费组继续消费消息 | boolean | false | | |
-| diskFallRecorded | 是否统计磁盘的使用情况,默认为true | boolean | true | | |
-| diskMaxUsedSpaceRatio | commitlog目录所在分区的最大使用比例，如果commitlog目录所在的分区使用比例大于该值，则触发过期文件删除 | int | 75 | | |
-| duplicationEnable | 是否允许重复复制,默认为 false | boolean | false | | |
-| enableCalcFilterBitMap | 是否开启比特位映射 | boolean | false | | |
-| enableConsumeQueueExt | 是否启用ConsumeQueue扩展属性 | boolean | false | | |
-| enablePropertyFilter | 是否支持根据属性过滤 如果使用基于标准的sql92模式过滤消息则改参数必须设置为true | boolean | false | | |
-| endTransactionPoolQueueCapacity | 处理提交和回滚消息线程池线程队列大小 | int | | | |
-| endTransactionThreadPoolNums | 处理提交和回滚消息线程池 | int | 24 | | |
-| expectConsumerNumUseFilter | 布隆过滤器参数 | int | 32 | | |
-| fastFailIfNoBufferInStorePool | 从 transientStorepool中获取 ByteBuffer是否支持快速失败 | boolean | false | | |
-| fetchNamesrvAddrByAddressServer | 是否支持从服务器获取nameServer | boolean | false | | |
-| fileReservedTime | 文件保留时间，默认72小时，表示非当前写文件最后一次更新时间加上filereservedtime小与当前时间，该文件将被清理 | String | 120 | | |
-| filterDataCleanTimeSpan | 清除过滤数据的时间间隔 | long | 86400000 | | |
-| filterServerNums | broker服务器过滤服务器数量 | int | 0 | | |
-| filterSupportRetry | 消息过滤是否支持重试 | boolean | false | | |
-| flushCommitLogLeastPages | 一次刷盘至少需要脏页的数量，针对commitlog文件 | int | 4 | | |
-| flushCommitLogTimed | 表示await方法等待FlushIntervalCommitlog,如果为true表示使用Thread.sleep方法等待 | boolean | false | | |
-| flushConsumeQueueLeastPages | 一次刷盘至少需要脏页的数量,默认2页,针对 Consume文件 | int | 2 | | |
-| flushConsumeQueueThoroughInterval | Consume两次刷盘的最大间隔,如果超过该间隔,将忽略 | int | 60000 | | |
-| flushConsumerOffsetHistoryInterval | fushConsumeQueueLeastPages直接刷盘 | int | 60000 | | |
-| flushConsumerOffsetInterval | 持久化消息消费进度 consumerOffse.json文件的频率ms | int | 5000 | | |
-| flushDelayOffsetInterval | 延迟队列拉取进度刷盘间隔。默认10s | long | 10000 | | |
-| flushDiskType | 刷盘方式,默认为 ASYNC_FLUSH(异步刷盘),可选值SYNC_FLUSH(同步刷盘) | enum | ASYNC_FLUSH | | |
-| flushIntervalCommitLog | commitlog刷盘频率 | int | 500 | | |
-| flushIntervalConsumeQueue | consumuQueue文件刷盘频率 | int | 1000 | | |
-| flushLeastPagesWhenWarmMapedFile | 用字节0填充整个文件的,每多少页刷盘一次。默认4096页,异步刷盘模式生效 | int | 4096 | | |
-
diff --git a/i18n/en/docusaurus-plugin-content-docs/version-5.0.json b/i18n/en/docusaurus-plugin-content-docs/version-5.0.json
index fd28a76a..34c6fb91 100644
--- a/i18n/en/docusaurus-plugin-content-docs/version-5.0.json
+++ b/i18n/en/docusaurus-plugin-content-docs/version-5.0.json
@@ -1,7 +1,7 @@
{
"version.label": {
"message": "5.0",
- "description": "The label for version current"
+ "description": "The label for version 5.0"
},
"sidebar.myAutogeneratedSidebar.category.介绍": {
"message": "Introduction",
@@ -30,5 +30,25 @@
"sidebar.myAutogeneratedSidebar.category.贡献指南": {
"message": "Contribution Guide",
"description": "The label for category 贡献指南 in sidebar myAutogeneratedSidebar"
+ },
+ "sidebar.myAutogeneratedSidebar.category.基础介绍": {
+ "message": "Basic Introduction",
+ "description": "The label for category 基础介绍 in sidebar myAutogeneratedSidebar"
+ },
+ "sidebar.myAutogeneratedSidebar.category.快速入门": {
+ "message": "Quick Start",
+ "description": "The label for category 快速入门 in sidebar myAutogeneratedSidebar"
+ },
+ "sidebar.myAutogeneratedSidebar.category.领域模型": {
+ "message": "Domain Model",
+ "description": "The label for category 领域模型 in sidebar myAutogeneratedSidebar"
+ },
+ "sidebar.myAutogeneratedSidebar.category.功能行为": {
+ "message": "Feature Behavior",
+ "description": "The label for category 功能行为 in sidebar myAutogeneratedSidebar"
+ },
+ "sidebar.myAutogeneratedSidebar.category.部署运维": {
+ "message": "Deployment Operations",
+ "description": "The label for category 部署运维 in sidebar myAutogeneratedSidebar"
}
}
\ No newline at end of file
diff --git a/i18n/en/docusaurus-theme-classic/footer.json b/i18n/en/docusaurus-theme-classic/footer.json
index 68ea0243..565908e5 100644
--- a/i18n/en/docusaurus-theme-classic/footer.json
+++ b/i18n/en/docusaurus-theme-classic/footer.json
@@ -30,5 +30,65 @@
"link.item.label.GitHub": {
"message": "GitHub",
"description": "The label of footer link with label=GitHub linking to https://github.com/apache/rocketmq"
+ },
+ "link.title.Learn": {
+ "message": "Learn",
+ "description": "The title of the footer links column with title=Learn in the footer"
+ },
+ "link.title.Community": {
+ "message": "Community",
+ "description": "The title of the footer links column with title=Community in the footer"
+ },
+ "link.title.More": {
+ "message": "More",
+ "description": "The title of the footer links column with title=More in the footer"
+ },
+ "link.title.Legal": {
+ "message": "Legal",
+ "description": "The title of the footer links column with title=Legal in the footer"
+ },
+ "link.item.label.Introduction": {
+ "message": "Introduction",
+ "description": "The label of footer link with label=Introduction linking to /docs/介绍/03whatis"
+ },
+ "link.item.label.Installation": {
+ "message": "Installation",
+ "description": "The label of footer link with label=Installation linking to /docs/介绍/02quickstart"
+ },
+ "link.item.label.Migration from 4.x to 5.0": {
+ "message": "Migration from 4.x to 5.0",
+ "description": "The label of footer link with label=Migration from 4.x to 5.0 linking to /version"
+ },
+ "link.item.label.Twitter": {
+ "message": "Twitter",
+ "description": "The label of footer link with label=Twitter linking to https://twitter.com/docusaurus"
+ },
+ "link.item.label.Help": {
+ "message": "Help",
+ "description": "The label of footer link with label=Help linking to https://github.com/apache/rocketmq"
+ },
+ "link.item.label.Blog": {
+ "message": "Blog",
+ "description": "The label of footer link with label=Blog linking to /blog"
+ },
+ "link.item.label.Licenses": {
+ "message": "Licenses",
+ "description": "The label of footer link with label=Licenses linking to https://www.apache.org/licenses/"
+ },
+ "link.item.label.Security": {
+ "message": "Security",
+ "description": "The label of footer link with label=Security linking to https://www.apache.org/security/"
+ },
+ "link.item.label.Thanks": {
+ "message": "Thanks",
+ "description": "The label of footer link with label=Thanks linking to https://www.apache.org/foundation/thanks.html"
+ },
+ "link.item.label.Sponsorship": {
+ "message": "Sponsorship",
+ "description": "The label of footer link with label=Sponsorship linking to https://www.apache.org/foundation/sponsorship.html"
+ },
+ "copyright": {
+ "message": "Copyright © 2022 The Apache Software Foundation. Licensed under the Apache License, Version 2.0.",
+ "description": "The footer copyright"
}
}
\ No newline at end of file
diff --git a/i18n/en/docusaurus-theme-classic/navbar.json b/i18n/en/docusaurus-theme-classic/navbar.json
index a3a01abd..9a8c22f5 100644
--- a/i18n/en/docusaurus-theme-classic/navbar.json
+++ b/i18n/en/docusaurus-theme-classic/navbar.json
@@ -43,8 +43,24 @@
"message": "Contribute",
"description": "Navbar item with label 贡献团队"
},
+ "item.label.项目起源": {
+ "message": "Origin",
+ "description": "Navbar item with label 项目起源"
+ },
"item.label.贡献说明": {
"message": "Contribute Instructions",
"description": "Navbar item with label 贡献说明"
+ },
+ "item.label.GitHub": {
+ "message": "GitHub",
+ "description": "Navbar item with label GitHub"
+ },
+ "item.label.4.x": {
+ "message": "4.x",
+ "description": "Navbar item with label 4.x"
+ },
+ "item.label.5.0": {
+ "message": "5.0",
+ "description": "Navbar item with label 5.0"
}
}
\ No newline at end of file
diff --git a/src/pages/origin.md b/src/pages/origin.md
index 9ef38fb5..6b6dff61 100644
--- a/src/pages/origin.md
+++ b/src/pages/origin.md
@@ -1,4 +1,4 @@
-# RocketMQ 相关信息
+# 项目起源
### 起源
@@ -11,7 +11,7 @@ RocketMQ是阿里巴巴在2012年开发的分布式消息中间件，专为万
从诞生到成熟，再到成为Apache TLP，RocketMQ的成功与它的创始团队和众多开发者多年来的努力是分不开的。
-### 创始人
+### 创始团队
| Image | Name | Apache Id | Github Id | When |
|:---|:---|:---|:---|:---|
diff --git "a/versioned_docs/version-5.0/01-\344\273\213\347\273\215/02quickstart.md" "b/versioned_docs/version-5.0/01-\344\273\213\347\273\215/02quickstart.md"
deleted file mode 100644
index f02b6670..00000000
--- "a/versioned_docs/version-5.0/01-\344\273\213\347\273\215/02quickstart.md"
+++ /dev/null
@@ -1,104 +0,0 @@
-# 快速开始
-
-这一节介绍如何快速部署一个单 Master RocketMQ 集群，并完成简单的消息收发。
-
-:::tip 系统要求
-
-1. 64位操作系统，推荐 Linux/Unix/macOS
-2. 64位 JDK 1.8+
-
-:::
-
-## 1.下载安装Apache RocketMQ
-
-:::tip RocketMQ下载
-
-RocketMQ 的安装包分为两种，二进制包和源码包。点击[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-source-release.zip) 下载 Apache RocketMQ 4.9.4的源码包。你也可以从[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-bin-release.zip) 下载到二进制包。二进制包是已经编译完成后可以直接运行的，源码包是需要编译后运行的，
-
-:::
-
-这里以在Linux环境下利用社区4.9.4的源码包为例，介绍RocketMQ安装过程。
-
-解压4.9.4的源码包并编译构建二进制可执行文件
-
-```shell
- > unzip rocketmq-all-4.9.4-source-release.zip
- > cd rocketmq-all-4.9.4-source-release/
- > mvn -Prelease-all -DskipTests clean install -U
- > cd distribution/target/rocketmq-4.9.4/rocketmq-4.9.4
-```
-## 2. 启动NameServer
-
-安装完RocketMQ包后，我们启动NameServer
-
-```shell
-### 启动namesrv
-$ nohup sh bin/mqnamesrv &
-
-### 验证namesrv是否启动成功
-$ tail -f ~/logs/rocketmqlogs/namesrv.log
-The Name Server boot success...
-```
-
-:::info
-
-我们可以在namesrv.log 中看到 **'The Name Server boot success..'，** 表示NameServer 已成功启动。
-
-:::
-
-
-
-## 3. 启动Broker
-
-NameServer成功启动后，我们启动Broker
-
-```shell
-### 先启动broker
-$ nohup sh bin/mqbroker -n localhost:9876 &
-
-### 验证broker是否启动成功, 比如, broker的ip是192.168.1.2 然后名字是broker-a
-$ tail -f ~/logs/rocketmqlogs/Broker.log
-The broker[broker-a,192.169.1.2:10911] boot success...
-```
-
-:::info
-
-我们可以在 Broker.log 中看到“The broker[brokerName,ip:port] boot success..”，这表明 broker 已成功启动。
-
-:::
-
-:::note
-
-至此，一个单Master的RocketMQ集群已经部署起来了，我们可以利用脚本进行简单的消息收发。
-
-:::
-
-## 4. 消息收发
-
-在进行消息收发之前，我们需要告诉客户端NameServer的地址，RocketMQ有多种方式在客户端中设置NameServer地址，这里我们利用环境变量`NAMESRV_ADDR`
-
-``` shell
- > export NAMESRV_ADDR=localhost:9876
- > sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer
- SendResult [sendStatus=SEND_OK, msgId= ...
-
- > sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer
- ConsumeMessageThread_%d Receive New Messages: [MessageExt...
-```
-
-
-
-## 5. 关闭服务器
-
-完成实验后，我们可以通过以下方式关闭服务
-
-```shell
-> sh bin/mqshutdown broker
-The mqbroker(36695) is running...
-Send shutdown request to mqbroker(36695) OK
-
-> sh bin/mqshutdown namesrv
-The mqnamesrv(36664) is running...
-Send shutdown request to mqnamesrv(36664) OK
-```
-
diff --git "a/versioned_docs/version-5.0/01-\344\273\213\347\273\215/03whatis.md" "b/versioned_docs/version-5.0/01-\344\273\213\347\273\215/03whatis.md"
deleted file mode 100644
index 8a142394..00000000
--- "a/versioned_docs/version-5.0/01-\344\273\213\347\273\215/03whatis.md"
+++ /dev/null
@@ -1,153 +0,0 @@
-# 初识RocketMQ
-
-我们平时使用一些体育新闻软件，会订阅自己喜欢的一些球队板块，当有作者发表文章到相关的板块，我们就能收到相关的新闻推送。
-
-发布-订阅（Pub/Sub）是一种消息范式，消息的发送者（称为发布者、生产者、Producer）会将消息直接发送给特定的接收者（称为订阅者、消费者、Comsumer）。而RocketMQ的基础消息模型就是一个简单的Pub/Sub模型。
-
-import Tabs from '@theme/Tabs';
-
-import TabItem from '@theme/TabItem';
-
-:::tip 相关概念
-
-<Tabs>
- <TabItem value="生产者" label="生产者" default>
- 负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。
-
-更多详见 ➡️ [生产者](/docs/生产者/04concept1)
- </TabItem>
- <TabItem value="消费者" label="消费者">
- 负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。
-
-更多详见 ➡️ [消费者](/docs/消费者/11concept2)
-
- </TabItem>
- <TabItem value="消息主题" label="主题">
- 表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。
-
-更多详见 ➡️ [基本概念](/docs/生产者/04concept1)
-
- </TabItem>
-</Tabs>
-
-:::
-
-
-## RocketMQ的基础消息模型，一个简单的Pub/Sub模型
-
-
-
-
-
-
-
-:::note 基本消息系统模型
-
-上图就是是一个基本的消息系统模型，包括**生产者 (Producer)**，**消费者 (Consumer)**，中间进行基于**消息主题（Topic）**的消息传送。
-
-:::
-
-在**基于主题**的系统中，消息被发布到主题或命名通道上。消费者将收到其订阅的主题上的所有消息，生产者负责定义订阅者所订阅的消息类别。这是一个基础的概念模型，而在实际的应用中，结构会更复杂。例如为了支持高并发和水平扩展，中间的消息主题需要进行分区，同一个Topic会有多个生产者，同一个信息会有多个消费者，消费者之间要进行负载均衡等。
-
-
-
-
-
-## RocketMQ 扩展后的消息模型
-
-
-
-
-
-
-
-:::note 扩展的消息系统模型
-
-上图就是一个扩展后的消息模型，包括**两个生产者**，**两个消息Topic**，以及**两组消费者 Comsumer**。
-
-存储消息Topic的 **代理服务器**( **Broker** )，是实际部署过程的对应的代理服务器。
-
-:::
-
-- 为了**水平扩展**，RocketMQ 对 Topic进行了分区，这种操作被称为**队列**（MessageQueue）。
-
-- 为了**并发消费**，Consumer Group的概念应运而生。
-
-:::info
-
-- Consumer主要有两种消费方式，即**广播模式**，和**集群模式**（图中是最常用的集群模式）。
-- 同一个 Consumer Group 中的 Consumer 实例是负载均衡消费，如图中 ConsumerGroupA 订阅 TopicA，TopicA 对应 3个队列，则 GroupA 中的 Consumer1 消费的是 MessageQueue 0和 MessageQueue 1的消息，Consumer2是消费的是MessageQueue2的消息。
-
-:::
-
-## RocketMQ的部署模型
-
-Producer、Consumer又是如何找到Topic和Broker的地址呢？消息的具体发送和接收又是怎么进行的呢？
-
-
-
-Apache RocketMQ 部署架构上主要分为四部分:
-
-### 生产者 Producer
-
-发布消息的角色。Producer通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败和重试。
-
-### **消费者 Consumer**
-
-消息消费的角色。
-
-- 支持以推（push），拉（pull）两种模式对消息进行消费。
-- 同时也支持**集群方式**和广播方式的消费
-- 提供实时消息订阅机制，可以满足大多数用户的需求。
-
-## 名字服务器 **NameServer**
-
-NameServer是 一个简单的 Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现。
-
-主要包括两个功能：
-
-- **Broker管理**，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
-- **路由信息管理**，每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。
-
-NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息。
-
-## 代理服务器 Broker
-
-Broker主要负责消息的存储、投递和查询以及服务高可用保证。
-
-NameServer几乎无状态节点，因此可集群部署，节点之间无任何信息同步。Broker部署相对复杂。
-
-在 Master-Slave 架构中，Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。
-
-
-
-:::note 部署模型小结
-
-- 每个 **Broker** 与 **NameServer** 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。
-
-- **Producer** 与 **NameServer** 集群中的其中一个节点建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。
-- **Consumer** 与 **NameServer** 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave发送心跳。Consumer 既可以从 Master 订阅消息，也可以从Slave订阅消息。
-
-:::
-
-## RocketMQ集群工作流程
-
-### 1. 启动NameServer
-
-启动NameServer。NameServer启动后监听端口，等待Broker、Producer、Consumer连接，相当于一个路由控制中心。
-
-### 2. 启动 Broker
-
-启动 Broker。与所有 NameServer 保持长连接，定时发送心跳包。心跳包中包含当前 Broker 信息以及存储所有 Topic 信息。注册成功后，NameServer 集群中就有 Topic跟Broker 的映射关系。
-
-### 3. 创建 Topic
-
-创建 Topic 时需要指定该 Topic 要存储在哪些 Broker 上，也可以在发送消息时自动创建Topic。
-
-### 4. 生产者发送消息
-
-生产者发送消息。启动时先跟 NameServer 集群中的其中一台建立长连接，并从 NameServer 中获取当前发送的 Topic存在于哪些 Broker 上，轮询从队列列表中选择一个队列，然后与队列所在的 Broker建立长连接从而向 Broker发消息。
-
-### 5. 消费者接受消息
-
-消费者接受消息。跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，然后开始消费消息。
diff --git "a/versioned_docs/version-5.0/01-\344\273\213\347\273\215/01whychoose.md" "b/versioned_docs/version-5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/01whychoose.md"
similarity index 100%
rename from "versioned_docs/version-5.0/01-\344\273\213\347\273\215/01whychoose.md"
rename to "versioned_docs/version-5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/01whychoose.md"
diff --git "a/versioned_docs/version-5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/02concepts.md" "b/versioned_docs/version-5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/02concepts.md"
new file mode 100644
index 00000000..33d28a3c
--- /dev/null
+++ "b/versioned_docs/version-5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/02concepts.md"
@@ -0,0 +1,79 @@
+# 基本概念
+
+本文介绍 Apache RocketMQ 的基本概念，以便您更好地理解和使用 Apache RocketMQ 。
+
+## 主题（Topic）
+Apache RocketMQ 中消息传输和存储的顶层容器，用于标识同一类业务逻辑的消息。主题通过TopicName来做唯一标识和区分。更多信息，请参见[主题（Topic）](../03-领域模型/02topic.md)。
+
+## 消息类型（MessageType）
+Apache RocketMQ 中按照消息传输特性的不同而定义的分类，用于类型管理和安全校验。 Apache RocketMQ 支持的消息类型有普通消息、顺序消息、事务消息和定时/延时消息。
+
+## 消息队列（MessageQueue）
+队列是 Apache RocketMQ 中消息存储和传输的实际容器，也是消息的最小存储单元。 Apache RocketMQ 的所有主题都是由多个队列组成，以此实现队列数量的水平拆分和队列内部的流式存储。队列通过QueueId来做唯一标识和区分。更多信息，请参见[队列（MessageQueue）](../03-领域模型/03messagequeue.md)。
+
+## 消息（Message）
+消息是 Apache RocketMQ 中的最小数据传输单元。生产者将业务数据的负载和拓展属性包装成消息发送到服务端，服务端按照相关语义将消息投递到消费端进行消费。更多信息，请参见[消息（Message）](../03-领域模型/04message.md)。
+
+## 消息视图（MessageView）
+消息视图是 Apache RocketMQ 面向开发视角提供的一种消息只读接口。通过消息视图可以读取消息内部的多个属性和负载信息，但是不能对消息本身做任何修改。
+
+## 消息标签（MessageTag）
+消息标签是Apache RocketMQ 提供的细粒度消息分类属性，可以在主题层级之下做消息类型的细分。消费者通过订阅特定的标签来实现细粒度过滤。更多信息，请参见[消息过滤](../04-功能行为/07messagefilter.md)。
+
+## 消息位点（MessageQueueOffset）
+消息是按到达Apache RocketMQ 服务端的先后顺序存储在指定主题的多个队列中，每条消息在队列中都有一个唯一的Long类型坐标，这个坐标被定义为消息位点。更多信息，请参见[消费进度管理](../04-功能行为/09consumerprogress.md)。
+
+## 消费位点（ConsumerOffset）
+一条消息被某个消费者消费完成后不会立即从队列中删除，Apache RocketMQ 会基于每个消费者分组记录消费过的最新一条消息的位点，即消费位点。更多信息，请参见[消费进度管理](../04-功能行为/09consumerprogress.md)。
+
+## 消息索引（MessageKey）
+消息索引是Apache RocketMQ 提供的面向消息的索引属性。通过设置的消息索引可以快速查找到对应的消息内容。
+
+## 生产者（Producer）
+生产者是Apache RocketMQ 系统中用来构建并传输消息到服务端的运行实体。生产者通常被集成在业务系统中，将业务消息按照要求封装成消息并发送至服务端。更多信息，请参见[生产者（Producer）](../03-领域模型/04producer.md)。
+
+## 事务检查器（TransactionChecker）
+Apache RocketMQ 中生产者用来执行本地事务检查和异常事务恢复的监听器。事务检查器应该通过业务侧数据的状态来检查和判断事务消息的状态。更多信息，请参见[事务消息](../04-功能行为/04transactionmessage.md)。
+
+## 事务状态（TransactionResolution）
+Apache RocketMQ 中事务消息发送过程中，事务提交的状态标识，服务端通过事务状态控制事务消息是否应该提交和投递。事务状态包括事务提交、事务回滚和事务未决。更多信息，请参见[事务消息](../04-功能行为/04transactionmessage.md)。
+
+## 消费者分组（ConsumerGroup）
+消费者分组是Apache RocketMQ 系统中承载多个消费行为一致的消费者的负载均衡分组。和消费者不同，消费者分组并不是运行实体，而是一个逻辑资源。在 Apache RocketMQ 中，通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾。更多信息，请参见[消费者分组（ConsumerGroup）](../03-领域模型/07consumergroup.md)。
+
+## 消费者（Consumer）
+消费者是Apache RocketMQ 中用来接收并处理消息的运行实体。消费者通常被集成在业务系统中，从服务端获取消息，并将消息转化成业务可理解的信息，供业务逻辑处理。更多信息，请参见[消费者（Consumer）](../03-领域模型/08consumer.md)。
+
+## 消费结果（ConsumeResult）
+Apache RocketMQ 中PushConsumer消费监听器处理消息完成后返回的处理结果，用来标识本次消息是否正确处理。消费结果包含消费成功和消费失败。
+
+## 订阅关系（Subscription）
+订阅关系是Apache RocketMQ 系统中消费者获取消息、处理消息的规则和状态配置。订阅关系由消费者分组动态注册到服务端系统，并在后续的消息传输中按照订阅关系定义的过滤规则进行消息匹配和消费进度维护。更多信息，请参见[订阅关系（Subscription）](../03-领域模型/09subscription.md)。
+
+## 消息过滤
+消费者可以通过订阅指定消息标签（Tag）对消息进行过滤，确保最终只接收被过滤后的消息合集。过滤规则的计算和匹配在Apache RocketMQ
+的服务端完成。更多信息，请参见[消息过滤](../04-功能行为/07messagefilter.md)。
+
+## 重置消费位点
+以时间轴为坐标，在消息持久化存储的时间范围内，重新设置消费者分组对已订阅主题的消费进度，设置完成后消费者将接收设定时间点之后，由生产者发送到Apache RocketMQ 服务端的消息。更多信息，请参见[重置消费位点](../04-功能行为/09consumerprogress.md)。
+
+## 消息轨迹
+在一条消息从生产者发出到消费者接收并处理过程中，由各个相关节点的时间、地点等数据汇聚而成的完整链路信息。通过消息轨迹，您能清晰定位消息从生产者发出，经由Apache RocketMQ 服务端，投递给消费者的完整链路，方便定位排查问题。
+
+## 消息堆积
+生产者已经将消息发送到Apache RocketMQ 的服务端，但由于消费者的消费能力有限，未能在短时间内将所有消息正确消费掉，此时在服务端保存着未被消费的消息，该状态即消息堆积。
+
+
+
+## 事务消息
+事务消息是Apache RocketMQ 提供的一种高级消息类型，支持在分布式场景下保障消息生产和本地事务的最终一致性。
+
+
+
+## 定时/延时消息
+定时/延时消息是Apache RocketMQ 提供的一种高级消息类型，消息被发送至服务端后，在指定时间后才能被消费者消费。通过设置一定的定时时间可以实现分布式场景的延时调度触发效果。
+
+
+## 顺序消息
+顺序消息是Apache RocketMQ 提供的一种高级消息类型，支持消费者按照发送消息的先后顺序获取消息，从而实现业务场景中的顺序处理。
+
diff --git "a/versioned_docs/version-5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/03limits.md" "b/versioned_docs/version-5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/03limits.md"
new file mode 100644
index 00000000..05b1f03e
--- /dev/null
+++ "b/versioned_docs/version-5.0/01-\345\237\272\347\241\200\344\273\213\347\273\215/03limits.md"
@@ -0,0 +1,24 @@
+# 参数约束和建议
+
+Apache RocketMQ 系统中存在很多自定义参数和资源命名，您在使用 Apache RocketMQ 时建议参考如下说明规范系统设置，避对某些具体参数设置不合理导致应用出现异常。
+
+
+| 参数 | [...]
+|-----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [...]
+| Topic名称 | 字符建议：字母a\~z或A\~Z、数字0\~9以及下划线（_）、短划线（-）和百分号（%）。 <br></br> 长度建议：1\~64个字符。 <br></br> 系统保留字符：Topic名称不允许使用以下保留字符或含有特殊前缀的字符命名。 <br></br> 保留字符: TBW102 * BenchmarkTest * SELF_TEST_TOPIC * OFFSET_MOVED_EVENT * SCHEDULE_TOPIC_XXXX * RMQ_SYS_TRANS_HALF_TOPIC * RMQ_SYS_TRACE_TOPIC * RMQ_SYS_TRANS_OP_HALF_TOPIC <br></br> 特殊前缀: * rmq_sys_ %RETRY%_ %DLQ%_ rocketmq-broker- [...]
+| ConsumerGroup名称 | 字符建议：支持字母a\~z或A\~Z、数字0\~9以及下划线（_）、短划线（-）和百分号（%）。 <br></br> 长度建议：1\~64个字符。 <br></br> 系统保留字符：ConsumerGroup不允许使用以下保留字符或含有特殊前缀的字符命名。 <br></br> 保留字符: * DEFAULT_CONSUMER * DEFAULT_PRODUCER * TOOLS_CONSUMER * FILTERSRV_CONSUMER * __MONITOR_CONSUMER * CLIENT_INNER_PRODUCER * SELF_TEST_P_GROUP * SELF_TEST_C_GROUP * CID_ONS-HTTP-PROXY * CID_ONSAPI_PERMISSION * CID_ONSAPI_OWNER * CID_ONSAPI_PULL * CID_RMQ_SYS_TRANS * 特殊字符 * CID_RMQ_SYS_ * CID_HOUSEKEEPIN [...]
+| ACL Credentials | 字符建议：AK（AccessKey ID）、SK（AccessKey Secret）和Token仅支持字母a\~z或A\~Z、数字0\~9。 <br></br> 长度建议：不超过1024个字符。 [...]
+| 请求超时时间 | 默认值：3000毫秒。 <br></br> 取值范围：该参数为客户端本地行为，取值范围建议不要超过30000毫秒。 [...]
+| 消息大小 | 默认值：不超过4 MB。不涉及消息压缩，仅计算消息体body的大小。 <br></br>取值范围：建议不超过4 MB。 [...]
+| 消息自定义属性 | 字符限制：所有可见字符。 <br></br>长度建议：属性的Key和Value总长度不超过16 KB。 <br></br>系统保留属性：不允许使用以下保留属性作为自定义属性的Key。 保留属性Key [...]
+| MessageGroup | 字符限制：所有可见字符。 <br></br>长度建议：1\~64字节。 [...]
+| 消息发送重试次数 | 默认值：3次。 <br></br>取值范围：无限制。 [...]
+| 消息消费重试次数 | 默认值：16次。 [...]
+| 事务异常检查间隔 | 默认值：60秒。 [...]
+| 半事务消息第一次回查时间 | 默认值：取值等于\[事务异常检查间隔\] * 最大限制：不超过1小时。 [...]
+| 半事务消息最大超时时长 | 默认值：4小时。 * 取值范围：不支持自定义修改。 [...]
+| PushConsumer本地缓存 |默认值： <br></br> * 最大缓存数量：1024条。 <br></br>* 最大缓存大小：64 M。 <br></br>取值范围：支持用户自定义设置，无限制。 [...]
+| PushConsumer重试间隔时长 | 默认值： <br></br>* 非顺序性投递：间隔时间阶梯变化，具体取值，请参见PushConsumer消费重试策略。 <br></br>* 顺序性投递：3000毫秒。 [...]
+| PushConsumer消费并发度 | 默认值：20个线程。 [...]
+| 获取消息最大批次 | 默认值：32条。 [...]
+| SimpleConsumer最大不可见时间 | 默认值：用户必填参数，无默认值。 <br></br> 取值范围建议：最小10秒；最大12小时。 [...]
\ No newline at end of file
diff --git "a/versioned_docs/version-5.0/02-\345\277\253\351\200\237\345\205\245\351\227\250/02quickstart.md" "b/versioned_docs/version-5.0/02-\345\277\253\351\200\237\345\205\245\351\227\250/02quickstart.md"
new file mode 100644
index 00000000..75e13ae2
--- /dev/null
+++ "b/versioned_docs/version-5.0/02-\345\277\253\351\200\237\345\205\245\351\227\250/02quickstart.md"
@@ -0,0 +1,224 @@
+# 快速开始
+
+这一节介绍如何快速部署一个单节点单副本 RocketMQ 服务，并完成简单的消息收发。
+
+:::tip 系统要求
+
+1. 64位操作系统，推荐 Linux/Unix/macOS
+2. 64位 JDK 1.8+
+
+:::
+
+## 1.下载安装Apache RocketMQ
+
+:::tip RocketMQ下载
+
+RocketMQ 的安装包分为两种，二进制包和源码包。 点击[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-source-release.zip) 下载 Apache RocketMQ 4.9.4的源码包。你也可以从[这里](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-bin-release.zip) 下载到二进制包。二进制包是已经编译完成后可以直接运行的，源码包是需要编译后运行的，
+
+:::
+
+这里以在Linux环境下利用社区5.0.0的源码包为例，介绍RocketMQ安装过程。
+
+解压4.9.4的源码包并编译构建二进制可执行文件
+
+```shell
+$ unzip rocketmq-all-5.0.0-source-release.zip
+$ cd rocketmq-all-5.0.0-source-release/
+$ mvn -Prelease-all -DskipTests clean install -U
+$ cd distribution/target/rocketmq-5.0.0/rocketmq-5.0.0
+```
+## 2. 启动NameServer
+
+安装完RocketMQ包后，我们启动NameServer
+
+```shell
+### 启动namesrv
+$ nohup sh bin/mqnamesrv &
+
+### 验证namesrv是否启动成功
+$ tail -f ~/logs/rocketmqlogs/namesrv.log
+The Name Server boot success...
+```
+
+:::info
+
+我们可以在namesrv.log 中看到 **'The Name Server boot success..'，** 表示NameServer 已成功启动。
+
+:::
+
+
+
+## 3. 启动Broker+Proxy
+
+NameServer成功启动后，我们启动Broker和Proxy，5.x 版本下我们建议使用 Local 模式部署，即 Broker 和 Proxy 同进程部署。5.x 版本也支持 Broker 和 Proxy 分离部署以实现更灵活的集群能力。详情参考[部署教程](../05-部署运维/15deploy.md)。
+
+```shell
+### 先启动broker
+$ nohup sh bin/mqbroker -n localhost:9876 &
+
+### 验证broker是否启动成功, 比如, broker的ip是192.168.1.2 然后名字是broker-a
+$ tail -f ~/logs/rocketmqlogs/Broker.log
+The broker[broker-a,192.169.1.2:10911] boot success...
+```
+
+:::info
+
+我们可以在 Broker.log 中看到“The broker[brokerName,ip:port] boot success..”，这表明 broker 已成功启动。
+
+:::
+
+:::note
+
+至此，一个单节点副本的 RocketMQ 集群已经部署起来了，我们可以利用脚本进行简单的消息收发。
+
+:::
+
+## 4. 工具测试消息收发
+
+在进行工具测试消息收发之前，我们需要告诉客户端NameServer的地址，RocketMQ有多种方式在客户端中设置NameServer地址，这里我们利用环境变量`NAMESRV_ADDR`
+
+``` shell
+$ export NAMESRV_ADDR=localhost:9876
+$ sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer
+ SendResult [sendStatus=SEND_OK, msgId= ...
+
+$ sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer
+ ConsumeMessageThread_%d Receive New Messages: [MessageExt...
+```
+
+## 5. SDK测试消息收发
+
+工具测试完成后，我们可以尝试使用 SDK 收发消息。这里以 Java SDK 为例介绍一下消息收发过程。
+
+1. 在IDEA中创建一个Java工程。
+
+2. 在 *pom.xml* 文件中添加以下依赖引入Java依赖库。
+
+ ```xml
+ <dependency>
+ <groupId>org.apache.rocketmq</groupId>
+ <artifactId>rocketmq-client-java</artifactId>
+ <version>5.0.0</version>
+ </dependency>
+ ```
+
+3. 在已创建的Java工程中，创建发送普通消息程序并运行，示例代码如下：
+
+ ```java
+ import org.apache.rocketmq.client.apis.*;
+ import org.apache.rocketmq.client.apis.consumer.ConsumeResult;
+ import org.apache.rocketmq.client.apis.consumer.MessageListener;
+ import org.apache.rocketmq.client.apis.consumer.SimpleConsumer;
+ import org.apache.rocketmq.client.apis.message.Message;
+ import org.apache.rocketmq.client.apis.message.MessageBuilder;
+ import org.apache.rocketmq.client.apis.message.MessageView;
+ import org.apache.rocketmq.client.apis.producer.Producer;
+ import org.apache.rocketmq.client.apis.producer.SendReceipt;
+ import java.time.Duration;
+ import java.util.List;
+ public class ProducerExample {
+ public static void main(String[] args) throws ClientException {
+ //接入点地址，需要设置成Proxy的地址和端口列表，一般是xxx:8081;xxx:8081。
+ String endpoint = "localhost:8081";
+ //消息发送的目标Topic名称，需要提前创建。
+ String topic = "Your Topic";
+ ClientServiceProvider provider = ClientServiceProvider.loadService();
+ ClientConfigurationBuilder builder = ClientConfiguration.newBuilder().setEndpoints(endpoint);
+ ClientConfiguration configuration = builder.build();
+ //初始化Producer时需要设置通信配置以及预绑定的Topic。
+ Producer producer = provider.newProducerBuilder()
+ .setTopics(topic)
+ .setClientConfiguration(configuration)
+ .build();
+ //普通消息发送。
+ Message message = provider.newMessageBuilder()
+ .setTopic(topic)
+ //设置消息索引键，可根据关键字精确查找某条消息。
+ .setKeys("messageKey")
+ //设置消息Tag，用于消费端根据指定Tag过滤消息。
+ .setTag("messageTag")
+ //消息体。
+ .setBody("messageBody".getBytes())
+ .build();
+ try {
+ //发送消息，需要关注发送结果，并捕获失败等异常。
+ SendReceipt sendReceipt = producer.send(message);
+ System.out.println(sendReceipt.getMessageId());
+ } catch (ClientException e) {
+ e.printStackTrace();
+ }
+ }
+ }
+ ```
+
+
+4. 在已创建的Java工程中，创建订阅普通消息程序并运行。Apache RocketMQ 支持[SimpleConsumer](../04-功能行为/06consumertype.md)和[PushConsumer](../04-功能行为/06consumertype.md)两种消费者类型，您可以选择以下任意一种方式订阅消息。
+
+ ```java
+ import org.apache.rocketmq.client.apis.*;
+ import org.apache.rocketmq.client.apis.consumer.ConsumeResult;
+ import org.apache.rocketmq.client.apis.consumer.FilterExpression;
+ import org.apache.rocketmq.client.apis.consumer.FilterExpressionType;
+ import org.apache.rocketmq.client.apis.consumer.PushConsumer;
+
+ import java.io.IOException;
+ import java.util.Collections;
+ import org.slf4j.Logger;
+ import org.slf4j.LoggerFactory;
+
+ public class PushConsumerExample {
+ private static final Logger LOGGER = LoggerFactory.getLogger(PushConsumerExample.class);
+
+ private PushConsumerExample() {
+ }
+
+ public static void main(String[] args) throws ClientException, IOException, InterruptedException {
+ final ClientServiceProvider provider = ClientServiceProvider.loadService();
+ //接入点地址，需要设置成Proxy的地址和端口列表，一般是xxx:8081;xxx:8081。
+ String endpoints = "localhost:8081";
+ ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
+ .setEndpoints(endpoints)
+ .build();
+ //订阅消息的过滤规则，表示订阅所有Tag的消息。
+ String tag = "*";
+ FilterExpression filterExpression = new FilterExpression(tag, FilterExpressionType.TAG);
+ //为消费者指定所属的消费者分组，Group需要提前创建。
+ String consumerGroup = "Your ConsumerGroup";
+ //指定需要订阅哪个目标Topic，Topic需要提前创建。
+ String topic = "Your Topic";
+ //初始化PushConsumer，需要绑定消费者分组ConsumerGroup、通信参数以及订阅关系。
+ PushConsumer pushConsumer = provider.newPushConsumerBuilder()
+ .setClientConfiguration(clientConfiguration)
+ //设置消费者分组。
+ .setConsumerGroup(consumerGroup)
+ //设置预绑定的订阅关系。
+ .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
+ //设置消费监听器。
+ .setMessageListener(messageView -> {
+ //处理消息并返回消费结果。
+ // LOGGER.info("Consume message={}", messageView);
+ System.out.println("Consume message!!");
+ return ConsumeResult.SUCCESS;
+ })
+ .build();
+ Thread.sleep(Long.MAX_VALUE);
+ //如果不需要再使用PushConsumer，可关闭该进程。
+ //pushConsumer.close();
+ }
+ }
+ ```
+
+## 6. 关闭服务器
+
+完成实验后，我们可以通过以下方式关闭服务
+
+```shell
+$ sh bin/mqshutdown broker
+The mqbroker(36695) is running...
+Send shutdown request to mqbroker(36695) OK
+
+$ sh bin/mqshutdown namesrv
+The mqnamesrv(36664) is running...
+Send shutdown request to mqnamesrv(36664) OK
+```
+
diff --git "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/04concept1.md" "b/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/04concept1.md"
deleted file mode 100644
index 1bb5f75c..00000000
--- "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/04concept1.md"
+++ /dev/null
@@ -1,87 +0,0 @@
-# 基本概念
-
-在生产者一章的基本概念包括**消息，Tag，Keys，队列和生产者**的介绍。
-
-## 消息
-
-RocketMQ 消息构成非常简单，如下图所示。
-
-- **topic**，表示要发送的消息的主题。
-- **body** 表示消息的存储内容
-- **properties** 表示消息属性
-- **transactionId** 会在事务消息中使用。
-
-:::tip
-- Tag: 不管是 RocketMQ 的 Tag 过滤还是延迟消息等都会利用 Properties 消息属性的能力
-
-- Keys: 服务器会根据 keys 创建哈希索引，设置后，可以在 Console 系统根据 Topic、Keys 来查询消息，由于是哈希索引，请尽可能保证 key 唯一，例如订单号，商品 Id 等。
-:::
-
-<center>
-<img src="../picture/Message.png" width="500"></img>
-</center>
-
-Message 可以设置的属性值包括：
-
-
-| 字段名 | 默认值 | 必要性 | 说明 |
-| :------------: | -------- | ------------- | ------------- |
-| Topic | null | 必填 | 消息所属 topic 的名称 |
-| Body | null | 必填 | 消息体 |
-| Tags | null | 选填 | 消息标签，方便服务器过滤使用。目前只支持每个消息设置一个 |
-| Keys | null | 选填 | 代表这条消息的业务关键词 |
-| Flag | 0 | 选填 | 完全由应用来设置，RocketMQ 不做干预 |
-| DelayTimeLevel | 0 | 选填 | 消息延时级别，0 表示不延时，大于 0 会延时特定的时间才会被消费 |
-| WaitStoreMsgOK | true | 选填 | 表示消息是否在服务器落盘后才返回应答。 |
-
-## Tag
-
-Topic 与 Tag 都是业务上用来归类的标识，区别在于 Topic 是一级分类，而 Tag 可以理解为是二级分类。使用 Tag 可以实现对 Topic 中的消息进行过滤。
-
-:::tip
-- Topic：消息主题，通过 Topic 对不同的业务消息进行分类。
-- Tag：消息标签，用来进一步区分某个 Topic 下的消息分类，消息从生产者发出即带上的属性。
-:::
-
-
-
-
-Topic 和 Tag 的关系如下图所示。
-
-
-
-### 什么时候该用 Topic，什么时候该用 Tag？
-
-可以从以下几个方面进行判断：
-
-- 消息类型是否一致：如普通消息、事务消息、定时（延时）消息、顺序消息，不同的消息类型使用不同的 Topic，无法通过 Tag 进行区分。
-
-- 业务是否相关联：没有直接关联的消息，如淘宝交易消息，京东物流消息使用不同的 Topic 进行区分；而同样是天猫交易消息，电器类订单、女装类订单、化妆品类订单的消息可以用 Tag 进行区分。
-
-- 消息优先级是否一致：如同样是物流消息，盒马必须小时内送达，天猫超市 24 小时内送达，淘宝物流则相对会慢一些，不同优先级的消息用不同的 Topic 进行区分。
-
-- 消息量级是否相当：有些业务消息虽然量小但是实时性要求高，如果跟某些万亿量级的消息使用同一个 Topic，则有可能会因为过长的等待时间而“饿死”，此时需要将不同量级的消息进行拆分，使用不同的 Topic。
-
-总的来说，针对消息分类，您可以选择创建多个 Topic，或者在同一个 Topic 下创建多个 Tag。但通常情况下，不同的 Topic 之间的消息没有必然的联系，而 Tag 则用来区分同一个 Topic 下相互关联的消息，例如全集和子集的关系、流程先后的关系。
-
-## Keys
-
-Apache RocketMQ 每个消息可以在业务层面的设置唯一标识码 keys 字段，方便将来定位消息丢失问题。 Broker 端会为每个消息创建索引（哈希索引），应用可以通过 topic、key 来查询这条消息内容，以及消息被谁消费。由于是哈希索引，请务必保证 key 尽可能唯一，这样可以避免潜在的哈希冲突。
-
-```java
- // 订单Id
- String orderId = "20034568923546";
- message.setKeys(orderId);
-```
-
-## 队列
-
-为了支持高并发和水平扩展，需要对 Topic 进行分区，在 RocketMQ 中这被称为队列，一个 Topic 可能有多个队列，并且可能分布在不同的 Broker 上。
-
-
-
-一般来说一条消息，如果没有重复发送（比如因为服务端没有响应而进行重试），则只会存在在 Topic 的其中一个队列中，消息在队列中按照先进先出的原则存储，每条消息会有自己的位点，每个队列会统计当前消息的总条数，这个称为最大位点 MaxOffset；队列的起始位置对应的位置叫做起始位点 MinOffset。队列可以提升消息发送和消费的并发度。
-
-## 生产者
-
-生产者（Producer）就是消息的发送者，Apache RocketMQ 拥有丰富的消息类型，可以支持不用的应用场景，在不同的场景中，需要使用不同的消息进行发送。比如在电商交易中超时未支付关闭订单的场景，在订单创建时会发送一条延时消息。这条消息将会在 30 分钟以后投递给消费者，消费者收到此消息后需要判断对应的订单是否已完成支付。如支付未完成，则关闭订单。如已完成支付则忽略，此时就需要用到延迟消息；电商场景中，业务上要求同一订单的消息保持严格顺序，此时就要用到顺序消息。在日志处理场景中，可以接受的比较大的发送延迟，但对吞吐量的要求很高，希望每秒能处理百万条日志，此时可以使用批量消息。在银行扣款的场景中，要保持上游的扣款操作和下游的短信通知保持一致，此时就要使用事务消息，下一节将会介绍各种类型
消息的发送。
diff --git "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/05message1.md" "b/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/05message1.md"
deleted file mode 100644
index 336e1010..00000000
--- "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/05message1.md"
+++ /dev/null
@@ -1,178 +0,0 @@
-# 普通消息发送
-
-## 1.向集群中创建 Topic
-
-RocketMQ集群是默认开启了 **autoCreateTopicEnable** 配置，会自动为发送的消息创建 Topic，如果 autoCreateTopicEnable 没有开启，也可以利用 RocketMQ Admin 工具创建目标 Topic 。
-
-```shell
-> sh bin/mqadmin updateTopic -c DefaultCluster -t TopicTest -n 127.0.0.1:9876
-create topic to 127.0.0.1:10911 success.
-TopicConfig [topicName=TopicTest, readQueueNums=8, writeQueueNums=8, perm=RW-, topicFilterType=SINGLE_TAG, topicSysFlag=0, order=false, attributes=null]
-```
-
-可以看到在执行完命令后，在该台Broker机器上创建了8个队列，名为TopicTest的Topic。
-
-## 2.添加客户端依赖
-
-首先需要在 JAVA 程序中添加 RocketMQ 的客户端依赖。
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-<Tabs>
-<TabItem value="Maven" label="Maven" default >
-
-```java
-<dependency>
- <groupId>org.apache.rocketmq</groupId>
- <artifactId>rocketmq-client</artifactId>
- <version>4.9.4</version>
-</dependency>
-```
-</TabItem>
-<TabItem value="Gradle" label="Gradle">
-
-```java
-compile 'org.apache.rocketmq:rocketmq-client:4.9.4'
-```
-
-</TabItem>
-
-</Tabs>
-
-
-## 3.消息发送
-
-Apache RocketMQ可用于以三种方式发送消息：**同步、异步和单向传输**。前两种消息类型是可靠的，因为无论它们是否成功发送都有响应。
-
-### 3.1 同步发送
-
-同步发送是指消息发送方发出一条消息后，会在收到服务端同步响应之后才发下一条消息的通讯方式，可靠的同步传输被广泛应用于各种场景，如重要的通知消息、短消息通知等。
-
-
-<center>
-<img src="../picture/同步发送.png" width="500"></img>
-</center>
-
-同步发送的整个代码流程如下：
-1. **首先会创建一个producer**。普通消息可以创建 DefaultMQProducer，创建时需要填写生产组的名称，生产者组是指同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。
-2. **设置 NameServer 的地址**。Apache RocketMQ很多方式设置NameServer地址(客户端配置中有介绍)，这里是在代码中调用producer的API setNamesrvAddr进行设置，如果有多个NameServer，中间以分号隔开，比如"127.0.0.2:9876;127.0.0.3:9876"。
-3. **第三步是构建消息**。指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤。
-4. **最后调用send接口将消息发送出去**。同步发送等待结果最后返回SendResult，SendResut包含实际发送状态还包括SEND_OK（发送成功）, FLUSH_DISK_TIMEOUT（刷盘超时）, FLUSH_SLAVE_TIMEOUT（同步到备超时）, SLAVE_NOT_AVAILABLE（备不可用），如果发送失败会抛出异常。
-``` javascript {16,15}
-public class SyncProducer {
- public static void main(String[] args) throws Exception {
- // 初始化一个producer并设置Producer group name
- DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name"); //（1）
- // 设置NameServer地址
- producer.setNamesrvAddr("localhost:9876"); //（2）
- // 启动producer
- producer.start();
- for (int i = 0; i < 100; i++) {
- // 创建一条消息，并指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤
- Message msg = new Message("TopicTest" /* Topic */,
- "TagA" /* Tag */,
- ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
- ); //（3）
- // 利用producer进行发送，并同步等待发送结果
- SendResult sendResult = producer.send(msg); //（4）
- System.out.printf("%s%n", sendResult);
- }
- // 一旦producer不再使用，关闭producer
- producer.shutdown();
- }
-}
-```
-
-
-
-### 3.2 异步发送
-
-<center>
-<img src="../picture/异步发送.png" width="500"></img>
-</center>
-
-
-异步发送是指发送方发出一条消息后，不等服务端返回响应，接着发送下一条消息的通讯方式。异步发送需要实现**异步发送回调接口**（SendCallback）。
-:::note
-异步发送需要实现**异步发送回调接口**（SendCallback）。
-:::
-消息发送方在发送了一条消息后，不需要等待服务端响应即可发送第二条消息，发送方通过回调接口接收服务端响应，并处理响应结果。异步发送一般用于链路耗时较长，对响应时间较为敏感的业务场景。例如，视频上传后通知启动转码服务，转码完成后通知推送转码结果等。
-
-如下是示例代码。
-
-``` javascript {16,17}
-public class AsyncProducer {
- public static void main(String[] args) throws Exception {
- // 初始化一个producer并设置Producer group name
- DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
- // 设置NameServer地址
- producer.setNamesrvAddr("localhost:9876");
- // 启动producer
- producer.start();
- producer.setRetryTimesWhenSendAsyncFailed(0);
- for (int i = 0; i < 100; i++) {
- final int index = i;
- // 创建一条消息，并指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤
- Message msg = new Message("TopicTest",
- "TagA",
- "Hello world".getBytes(RemotingHelper.DEFAULT_CHARSET));
- // 异步发送消息, 发送结果通过callback返回给客户端
- producer.send(msg, new SendCallback() {
- @Override
- public void onSuccess(SendResult sendResult) {
- System.out.printf("%-10d OK %s %n", index,
- sendResult.getMsgId());
- }
- @Override
- public void onException(Throwable e) {
- System.out.printf("%-10d Exception %s %n", index, e);
- e.printStackTrace();
- }
- });
- }
- // 一旦producer不再使用，关闭producer
- producer.shutdown();
- }
-}
-```
-
-:::note
-异步发送与同步发送代码唯一区别在于调用send接口的参数不同，异步发送不会等待发送返回，取而代之的是send方法需要传入 SendCallback 的实现，SendCallback 接口主要有onSuccess 和 onException 两个方法，表示消息发送成功和消息发送失败。
-:::
-
-### 3.3 单向模式发送
-
-<center>
-<img src="../picture/Oneway发送.png" width="500"></img>
-</center>
-
-
-
-发送方只负责发送消息，不等待服务端返回响应且没有回调函数触发，即只发送请求不等待应答。此方式发送消息的过程耗时非常短，一般在微秒级别。适用于某些耗时非常短，但对可靠性要求并不高的场景，例如日志收集。
-
-``` javascript {16}
-public class OnewayProducer {
- public static void main(String[] args) throws Exception{
- // 初始化一个producer并设置Producer group name
- DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
- // 设置NameServer地址
- producer.setNamesrvAddr("localhost:9876");
- // 启动producer
- producer.start();
- for (int i = 0; i < 100; i++) {
- // 创建一条消息，并指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤
- Message msg = new Message("TopicTest" /* Topic */,
- "TagA" /* Tag */,
- ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /* Message body */
- );
- // 由于在oneway方式发送消息时没有请求应答处理，如果出现消息发送失败，则会因为没有重试而导致数据丢失。若数据不可丢，建议选用可靠同步或可靠异步发送方式。
- producer.sendOneway(msg);
- }
- // 一旦producer不再使用，关闭producer
- producer.shutdown();
- }
-}
-```
-
-单向模式调用sendOneway，不会对返回结果有任何等待和处理。
diff --git "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/06message2.md" "b/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/06message2.md"
deleted file mode 100644
index a89b26bc..00000000
--- "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/06message2.md"
+++ /dev/null
@@ -1,76 +0,0 @@
-# 顺序消息发送
-
-## 顺序消息介绍
-顺序消息是一种对消息发送和消费顺序有严格要求的消息。
-
-对于一个指定的Topic，消息严格按照先进先出（FIFO）的原则进行消息发布和消费，即先发布的消息先消费，后发布的消息后消费。在 Apache RocketMQ 中支持分区顺序消息，如下图所示。我们可以按照某一个标准对消息进行分区（比如图中的ShardingKey），同一个ShardingKey的消息会被分配到同一个队列中，并按照顺序被消费。
-
-
-
-顺序消息的应用场景也非常广泛，比如在创建订单的例子中，需要保证同一个订单的生成、付款和发货，这三个操作被顺序执行。如果是普通消息，订单A的消息可能会被轮询发送到不同的队列中，不同队列的消息将无法保持顺序，而顺序消息发送时将ShardingKey相同（同一订单号）的消息序路由到一个逻辑队列中。
-
-## 顺序消息示例代码
-
-顺序消息的代码如下所示：
-
-```jsx {13}
-public class Producer {
- public static void main(String[] args) throws UnsupportedEncodingException {
- try {
- DefaultMQProducer producer = new DefaultMQProducer("please_rename_unique_group_name");
- producer.start();
-
- String[] tags = new String[] {"TagA", "TagB", "TagC", "TagD", "TagE"};
- for (int i = 0; i < 100; i++) {
- int orderId = i % 10;
- Message msg =
- new Message("TopicTest", tags[i % tags.length], "KEY" + i,
- ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET));
- SendResult sendResult = producer.send(msg, new MessageQueueSelector() {
- @Override
- public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
- Integer id = (Integer) arg;
- int index = id % mqs.size();
- return mqs.get(index);
- }
- }, orderId);
-
- System.out.printf("%s%n", sendResult);
- }
-
- producer.shutdown();
- } catch (MQClientException | RemotingException | MQBrokerException | InterruptedException e) {
- e.printStackTrace();
- }
- }
-}
-```
-
-这里的区别主要是调用了```SendResult send(Message msg, MessageQueueSelector selector, Object arg)```方法，MessageQueueSelector 是队列选择器，arg 是一个 Java Object 对象，可以传入作为消息发送分区的分类标准。
-
-:::tip
-MessageQueueSelector的接口如下：
-
-```jsx
-public interface MessageQueueSelector {
- MessageQueue select(final List<MessageQueue> mqs, final Message msg, final Object arg);
-}
-```
-
-其中 mqs 是可以发送的队列，msg是消息，arg是上述send接口中传入的Object对象，返回的是该消息需要发送到的队列。上述例子里，是以orderId作为分区分类标准，对所有队列个数取余，来对将相同orderId的消息发送到同一个队列中。
-:::
-
-
-## 顺序消息的一致性
-
-如果一个Broker掉线，那么此时队列总数是否会发化？
-
-如果发生变化，那么同一个 ShardingKey 的消息就会发送到不同的队列上，造成乱序。如果不发生变化，那消息将会发送到掉线Broker的队列上，必然是失败的。因此 Apache RocketMQ 提供了两种模式，如果要保证严格顺序而不是可用性，创建 Topic 是要指定 ```-o``` 参数（--order）为true，表示顺序消息:
-
-```shell {1}
-> sh bin/mqadmin updateTopic -c DefaultCluster -t TopicTest -o true -n 127.0.0.1:9876
-create topic to 127.0.0.1:10911 success.
-TopicConfig [topicName=TopicTest, readQueueNums=8, writeQueueNums=8, perm=RW-, topicFilterType=SINGLE_TAG, topicSysFlag=0, order=true, attributes=null]
-```
-
-其次要保证NameServer中的配置 ```orderMessageEnable``` 和 ```returnOrderTopicConfigToBroker``` 必须是 true。如果上述任意一个条件不满足，则是保证可用性而不是严格顺序。
diff --git "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/07message3.md" "b/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/07message3.md"
deleted file mode 100644
index 0daf28dd..00000000
--- "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/07message3.md"
+++ /dev/null
@@ -1,45 +0,0 @@
-# 延迟消息发送
-
-延时消息是指消息发送到Apache RocketMQ后，并不期望立马投递这条消息，而是延迟一定时间后才投递到Consumer进行消费。
-
-Apache RocketMQ 一共支持18个等级的延迟投递，具体时间如下：
-
-| 投递等级（delay level） | 延迟时间 | 投递等级（delay level） | 延迟时间 |
-|-------------------|------|-------------------|-------|
-| 1 | 1s | 10 | 6min |
-| 2 | 5s | 11 | 7min |
-| 3 | 10s | 12 | 8min |
-| 4 | 30s | 13 | 9min |
-| 5 | 1min | 14 | 10min |
-| 6 | 2min | 15 | 20min |
-| 7 | 3min | 16 | 30min |
-| 8 | 4min | 17 | 1h |
-| 9 | 5min | 18 | 2h |
-
-延迟消息的示例代码如下：
-
-```javascript {10,11}
-public class ScheduledMessageProducer {
- public static void main(String[] args) throws Exception {
- // Instantiate a producer to send scheduled messages
- DefaultMQProducer producer = new DefaultMQProducer("ExampleProducerGroup");
- // Launch producer
- producer.start();
- int totalMessagesToSend = 100;
- for (int i = 0; i < totalMessagesToSend; i++) {
- Message message = new Message("TestTopic", ("Hello scheduled message " + i).getBytes());
- // This message will be delivered to consumer 10 seconds later.
- message.setDelayTimeLevel(3);
- // Send the message
- producer.send(message);
- }
-
- // Shutdown producer after use.
- producer.shutdown();
- }
-
-}
-```
-:::tip
-这里最重要的是message中设置延迟等级，例子中设置的等级是3，也就是发送者发送后，10s后消费者才能收到消息。
-:::
\ No newline at end of file
diff --git "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/08message4.md" "b/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/08message4.md"
deleted file mode 100644
index 04892f74..00000000
--- "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/08message4.md"
+++ /dev/null
@@ -1,29 +0,0 @@
-# 批量消息发送
-
-在对吞吐率有一定要求的情况下，Apache RocketMQ可以将一些消息聚成一批以后进行发送，可以增加吞吐率，并减少API和网络调用次数。
-
-
-
-```javascript {10,11,12,13}
-public class SimpleBatchProducer {
-
- public static void main(String[] args) throws Exception {
- DefaultMQProducer producer = new DefaultMQProducer("BatchProducerGroupName");
- producer.start();
-
- //If you just send messages of no more than 1MiB at a time, it is easy to use batch
- //Messages of the same batch should have: same topic, same waitStoreMsgOK and no schedule support
- String topic = "BatchTest";
- List<Message> messages = new ArrayList<>();
- messages.add(new Message(topic, "Tag", "OrderID001", "Hello world 0".getBytes()));
- messages.add(new Message(topic, "Tag", "OrderID002", "Hello world 1".getBytes()));
- messages.add(new Message(topic, "Tag", "OrderID003", "Hello world 2".getBytes()));
-
- producer.send(messages);
- }
-}
-```
-
-:::note
-这里调用非常简单，将消息打包成 Collection`<Message>` msgs传入方法中即可，需要注意的是批量消息的大小不能超过 1MiB（否则需要自行分割），其次同一批 batch 中 topic 必须相同。
-:::
\ No newline at end of file
diff --git "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/09message5.md" "b/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/09message5.md"
deleted file mode 100644
index e85ce461..00000000
--- "a/versioned_docs/version-5.0/02-\347\224\237\344\272\247\350\200\205/09message5.md"
+++ /dev/null
@@ -1,149 +0,0 @@
-# 事务消息发送
-
-## 事务消息介绍
-
-在一些对数据一致性有强需求的场景，可以用 Apache RocketMQ 事务消息来解决，从而保证上下游数据的一致性。
-
-
-
-事务消息发送分为两个阶段。第一阶段会发送一个**半事务消息**，半事务消息是指暂不能投递的消息，生产者已经成功地将消息发送到了 Broker，但是Broker 未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，如果发送成功则执行本地事务，并根据本地事务执行成功与否，向 Broker 半事务消息状态（commit或者rollback），半事务消息只有 commit 状态才会真正向下游投递。如果由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，Broker 端会通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit或是Rollback）。这样最终保证了本地事务执行成功，下游就能收到消息，本地事务执行失败，下游就收不到消息。总而保证了上下游数据的一致性。
-
-整个事务消息的详细交互流程如下图所示：
-
-
-
-## 事务消息步骤
-
-事务消息**发送**步骤如下：
-
-1. 生产者将半事务消息发送至 `RocketMQ Broker`。
-2. `RocketMQ Broker` 将消息持久化成功之后，向生产者返回 Ack 确认消息已经发送成功，此时消息为半事务消息。
-3. 生产者开始执行本地事务逻辑。
-4. 生产者根据本地事务执行结果向服务端提交二次确认结果（Commit或是Rollback），服务端收到确认结果后处理逻辑如下：
-- 二次确认结果为Commit：服务端将半事务消息标记为可投递，并投递给消费者。
-- 二次确认结果为Rollback：服务端将回滚事务，不会将半事务消息投递给消费者。
-5. 在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为Unknown未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。
-
-事务消息**回查**步骤如下：
-1. 生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
-2. 生产者根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行处理。
-
-## 示例代码
-
-示例代码如下：
-
-```javascript {39}
-public class TransactionProducer {
- public static void main(String[] args) throws MQClientException, InterruptedException {
- TransactionListener transactionListener = new TransactionListenerImpl();
- TransactionMQProducer producer = new TransactionMQProducer("please_rename_unique_group_name");
- ExecutorService executorService = new ThreadPoolExecutor(2, 5, 100, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(2000), new ThreadFactory() {
- @Override
- public Thread newThread(Runnable r) {
- Thread thread = new Thread(r);
- thread.setName("client-transaction-msg-check-thread");
- return thread;
- }
- });
-
- producer.setExecutorService(executorService);
- producer.setTransactionListener(transactionListener);
- producer.start();
-
- String[] tags = new String[] {"TagA", "TagB", "TagC", "TagD", "TagE"};
- for (int i = 0; i < 10; i++) {
- try {
- Message msg =
- new Message("TopicTest", tags[i % tags.length], "KEY" + i,
- ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET));
- SendResult sendResult = producer.sendMessageInTransaction(msg, null);
- System.out.printf("%s%n", sendResult);
-
- Thread.sleep(10);
- } catch (MQClientException | UnsupportedEncodingException e) {
- e.printStackTrace();
- }
- }
-
- for (int i = 0; i < 100000; i++) {
- Thread.sleep(1000);
- }
- producer.shutdown();
- }
-
- static class TransactionListenerImpl implements TransactionListener {
- private AtomicInteger transactionIndex = new AtomicInteger(0);
-
- private ConcurrentHashMap<String, Integer> localTrans = new ConcurrentHashMap<>();
-
- @Override
- public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
- int value = transactionIndex.getAndIncrement();
- int status = value % 3;
- localTrans.put(msg.getTransactionId(), status);
- return LocalTransactionState.UNKNOW;
- }
-
- @Override
- public LocalTransactionState checkLocalTransaction(MessageExt msg) {
- Integer status = localTrans.get(msg.getTransactionId());
- if (null != status) {
- switch (status) {
- case 0:
- return LocalTransactionState.UNKNOW;
- case 1:
- return LocalTransactionState.COMMIT_MESSAGE;
- case 2:
- return LocalTransactionState.ROLLBACK_MESSAGE;
- default:
- return LocalTransactionState.COMMIT_MESSAGE;
- }
- }
- return LocalTransactionState.COMMIT_MESSAGE;
- }
- }
-}
-```
-
-事务消息的发送不再使用 DefaultMQProducer，而是使用 `TransactionMQProducer` 进行发送，上述的例子中设置了事务回查的线程池，如果不设置也会默认生成一个，最重要的是需要实现 `TransactionListener` 接口，并传入 `TransactionMQProducer`。
-
-:::note
-
-TransactionListener接口的定义如下：
-
-````javascript {9,18}
-public interface TransactionListener {
- /**
- * When send transactional prepare(half) message succeed, this method will be invoked to execute local transaction.
- *
- * @param msg Half(prepare) message
- * @param arg Custom business parameter
- * @return Transaction state
- */
- LocalTransactionState executeLocalTransaction(final Message msg, final Object arg);
-
- /**
- * When no response to prepare(half) message. broker will send check message to check the transaction status, and this
- * method will be invoked to get local transaction status.
- *
- * @param msg Check message
- * @return Transaction state
- */
- LocalTransactionState checkLocalTransaction(final MessageExt msg);
-}
-````
-:::
-
-`executeLocalTransaction` 是半事务消息发送成功后，执行本地事务的方法，具体执行完本地事务后，可以在该方法中返回以下三种状态：
-
-- `LocalTransactionState.COMMIT_MESSAGE`：提交事务，允许消费者消费该消息
-- `LocalTransactionState.ROLLBACK_MESSAGE`：回滚事务，消息将被丢弃不允许消费。
-- `LocalTransactionState.UNKNOW`：暂时无法判断状态，等待固定时间以后Broker端根据回查规则向生产者进行消息回查。
-
-`checkLocalTransaction`是由于二次确认消息没有收到，Broker端回查事务状态的方法。回查规则：本地事务执行完成后，若Broker端收到的本地事务返回状态为LocalTransactionState.UNKNOW，或生产者应用退出导致本地事务未提交任何状态。则Broker端会向消息生产者发起事务回查，第一次回查后仍未获取到事务状态，则之后每隔一段时间会再次回查。
-
-:::caution
-
-此外，需要注意的是事务消息的生产组名称 ProducerGroupName不能随意设置。事务消息有回查机制，回查时Broker端如果发现原始生产者已经崩溃崩溃，则会联系同一生产者组的其他生产者实例回查本地事务执行情况以Commit或Rollback半事务消息。
-
-:::
\ No newline at end of file
diff --git "a/versioned_docs/version-5.0/03-\346\266\210\350\264\271\350\200\205/11concept2.md" "b/versioned_docs/version-5.0/03-\346\266\210\350\264\271\350\200\205/11concept2.md"
deleted file mode 100644
index 8c47747f..00000000
--- "a/versioned_docs/version-5.0/03-\346\266\210\350\264\271\350\200\205/11concept2.md"
+++ /dev/null
@@ -1,60 +0,0 @@
-# 基础概念
-
-消息通过生产者发送到某一个Topic，如果需要订阅该Topic并消费里面的消息的话，就要创建对应的消费者进行消费。在介绍消费者的使用方法之前，我们先介绍**消费组**、**消费位点**、**推和拉**等概念。
-
-## 消费者与消费组
-
-消息系统的重要作用之一是削峰填谷，但比如在电商大促的场景中，如果下游的消费者消费能力不足的话，大量的瞬时流量进入会后堆积在服务端。此时，消息的端到端延迟（从发送到被消费的时间）就会增加，对服务端而言，一直消费历史数据也会产生冷读。因此需要增加消费能力来解决这个问题，除了去优化消息消费的时间，最简单的方式就是扩容消费者。
-
-但是否随意增加消费者就能提升消费能力？ 首先需要了解消费组的概念。在消费者中消费组的有非常重要的作用，如果多个消费者设置了相同的Consumer Group，我们认为这些消费者在同一个消费组内。
-
-在 Apache RocketMQ 有两种消费模式，分别是：
-
-- 集群消费模式：当使用集群消费模式时，RocketMQ 认为任意一条消息只需要被消费组内的任意一个消费者处理即可。
-- 广播消费模式：当使用广播消费模式时，RocketMQ 会将每条消息推送给消费组所有的消费者，保证消息至少被每个消费者消费一次。
-
-集群消费模式适用于每条消息只需要被处理一次的场景，也就是说整个消费组会Topic收到全量的消息，而消费组内的消费分担消费这些消息，因此可以通过扩缩消费者数量，来提升或降低消费能力，具体示例如下图所示，是最常见的消费方式。
-
-
-
-广播消费模式适用于每条消息需要被消费组的每个消费者处理的场景，也就是说消费组内的每个消费者都会收到订阅Topic的全量消息，因此即使扩缩消费者数量也无法提升或降低消费能力，具体示例如下图所示。
-
-
-
-## 负载均衡
-
-集群模式下，同一个消费组内的消费者会分担收到的全量消息，这里的分配策略是怎样的？如果扩容消费者是否一定能提升消费能力？
-
-Apache RocketMQ 提供了多种集群模式下的分配策略，包括平均分配策略、机房优先分配策略、一致性hash分配策略等，可以通过如下代码进行设置相应负载均衡策略
-
-```java
- consumer.setAllocateMessageQueueStrategy(new AllocateMessageQueueAveragely());
-```
-
-默认的分配策略是平均分配，这也是最常见的策略。平均分配策略下消费组内的消费者会按照类似分页的策略均摊消费。
-
-在平均分配的算法下，可以通过增加消费者的数量来提高消费的并行度。比如下图中，通过增加消费者来提高消费能力。
-
-
-
-
-
-但也不是一味地增加消费者就能提升消费能力的，比如下图中Topic的总队列数小于消费者的数量时，消费者将分配不到队列，即使消费者再多也无法提升消费能力。
-
-
-
-## 消费位点
-
-
-
-如上图所示，在Apache RocketMQ中每个队列都会记录自己的最小位点、最大位点。针对于消费组，还有消费位点的概念，在集群模式下，消费位点是由客户端提给交服务端保存的，在广播模式下，消费位点是由客户端自己保存的。一般情况下消费位点正常更新，不会出现消息重复，但如果消费者发生崩溃或有新的消费者加入群组，就会触发重平衡，重平衡完成后，每个消费者可能会分配到新的队列，而不是之前处理的队列。为了能继续之前的工作，消费者需要读取每个队列最后一次的提交的消费位点，然后从消费位点处继续拉取消息。但在实际执行过程中，由于客户端提交给服务端的消费位点并不是实时的，所以重平衡就可能会导致消息少量重复。
-
-## 推、拉和长轮询
-
-MQ的消费模式可以大致分为两种，一种是推Push，一种是拉Pull。
-
-- Push是服务端主动推送消息给客户端，优点是及时性较好，但如果客户端没有做好流控，一旦服务端推送大量消息到客户端时，就会导致客户端消息堆积甚至崩溃。
-
-- Pull是客户端需要主动到服务端取数据，优点是客户端可以依据自己的消费能力进行消费，但拉取的频率也需要用户自己控制，拉取频繁容易造成服务端和客户端的压力，拉取间隔长又容易造成消费不及时。
-
-Apache RocketMQ既提供了Push模式也提供了Pull模式。
\ No newline at end of file
diff --git "a/versioned_docs/version-5.0/03-\346\266\210\350\264\271\350\200\205/12push.md" "b/versioned_docs/version-5.0/03-\346\266\210\350\264\271\350\200\205/12push.md"
deleted file mode 100644
index 0e54cc7b..00000000
--- "a/versioned_docs/version-5.0/03-\346\266\210\350\264\271\350\200\205/12push.md"
+++ /dev/null
@@ -1,233 +0,0 @@
-# Push消费
-
-RocketMQ Push消费的示例代码如下
-
-```javascript
-public class Consumer {
- public static void main(String[] args) throws InterruptedException, MQClientException {
- // 初始化consumer，并设置consumer group name
- DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name");
-
- // 设置NameServer地址
- consumer.setNamesrvAddr("localhost:9876");
- //订阅一个或多个topic，并指定tag过滤条件，这里指定*表示接收所有tag的消息
- consumer.subscribe("TopicTest", "*");
- //注册回调接口来处理从Broker中收到的消息
- consumer.registerMessageListener(new MessageListenerConcurrently() {
- @Override
- public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
- System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
- // 返回消息消费状态，ConsumeConcurrentlyStatus.CONSUME_SUCCESS为消费成功
- return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
- }
- });
- // 启动Consumer
- consumer.start();
- System.out.printf("Consumer Started.%n");
- }
-}
-```
-
-首先需要初始化消费者，初始化消费者时，必须填写ConsumerGroupName，同一个消费组的ConsumerGroupName是相同的，这是判断消费者是否属于同一个消费组的重要属性。然后是设置NameServer地址，这里与Producer一样不再介绍。然后是调用subscribe方法订阅Topic，subscribe方法需要指定需要订阅的Topic名，也可以增加消息过滤的条件，比如TagA等，上述代码中指定*表示接收所有tag的消息。除了订阅之外，还需要注册回调接口编写消费逻辑来处理从Broker中收到的消息，调用registerMessageListener方法，需要传入MessageListener的实现，上述代码中是并发消费，因此是MessageListenerConcurrently的实现，其接口如下
-
-:::note MessageListenerConcurrently 接口
-```javascript
-/**
- * A MessageListenerConcurrently object is used to receive asynchronously delivered messages concurrently
- */
-public interface MessageListenerConcurrently extends MessageListener {
- /**
- * It is not recommend to throw exception,rather than returning ConsumeConcurrentlyStatus.RECONSUME_LATER if
- * consumption failure
- *
- * @param msgs msgs.size() >= 1<br> DefaultMQPushConsumer.consumeMessageBatchMaxSize=1,you can modify here
- * @return The consume status
- */
- ConsumeConcurrentlyStatus consumeMessage(final List<MessageExt> msgs,
- final ConsumeConcurrentlyContext context);
-}
-```
-:::
-
-其中，msgs是从Broker端获取的需要被消费消息列表，用户实现该接口，并把自己对消息的消费逻辑写在consumeMessage方法中，然后返回消费状态，ConsumeConcurrentlyStatus.CONSUME_SUCCESS表示消费成功，或者表示RECONSUME_LATER表示消费失败，一段时间后再重新消费。
-
-可以看到RocketMQ提供的消费者API却非常简单，用户并不需要关注重平衡或者拉取的逻辑，只需要写好自己的消费逻辑即可。
-
-## 集群模式和广播模式
-
-我们可以通过以下代码来设置采用集群模式，RocketMQ Push Consumer默认为集群模式，同一个消费组内的消费者分担消费。
-
-```java
-consumer.setMessageModel(MessageModel.CLUSTERING);
-```
-
-通过以下代码来设置采用广播模式，广播模式下，消费组内的每一个消费者都会消费全量消息。
-
-```java
-consumer.setMessageModel(MessageModel.BROADCASTING);
-```
-
-## 并发消费和顺序消费
-
-上面已经介绍设置Push Consumer并发消费的方法，通过在注册消费回调接口时传入MessageListenerConcurrently接口的实现来完成。在并发消费中，可能会有多个线程同时消费一个队列的消息，因此即使发送端通过发送顺序消息保证消息在同一个队列中按照FIFO的顺序，也无法保证消息实际被顺序消费。
-
-因此RocketMQ提供了顺序消费的方式， 顺序消费设置与并发消费API层面只有一处不同，在注册消费回调接口时传入MessageListenerOrderly接口的实现。
-
-```javascript
-consumer.registerMessageListener(new MessageListenerOrderly() {
- AtomicLong consumeTimes = new AtomicLong(0);
- @Override
- public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, ConsumeOrderlyContext context) {
- System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
- this.consumeTimes.incrementAndGet();
- if ((this.consumeTimes.get() % 2) == 0) {
- return ConsumeOrderlyStatus.SUCCESS;
- } else if ((this.consumeTimes.get() % 5) == 0) {
- context.setSuspendCurrentQueueTimeMillis(3000);
- return ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT;
- }
- return ConsumeOrderlyStatus.SUCCESS;
- }
- });
-```
-
-顺序消费也有两种返回结果，ConsumeOrderlyStatus.SUCCESS表示消费成功，ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT表示消费失败。
-
-## 消息过滤
-
-消息过滤是指消息生产者向Topic中发送消息时，设置消息属性对消息进行分类，消费者订阅Topic时，根据消息属性设置过滤条件对消息进行过滤，只有符合过滤条件的消息才会被投递到消费端进行消费。
-
-消费者订阅Topic时若未设置过滤条件，无论消息发送时是否有设置过滤属性，Topic中的所有消息都将被投递到消费端进行消费。
-
-RocketMQ支持的消息过滤方式有两种，Tag过滤和SQL92过滤。
-
-| 过滤方式 | 说明 | 场景 |
-|---------|------------------------------------------------|---------------------|
-| Tag过滤 | 消费者订阅的Tag和发送者设置的消息Tag相互匹配，则消息被投递给消费端进行消费。 | 简单过滤场景。一条消息支持设置一个Tag，仅需要对Topic中的消息进行一级分类并过滤时可以使用此方式。 |
-| SQL92过滤 | 发送者设置Tag或消息属性，消费者订阅满足SQL92过滤表达式的消息被投递给消费端进行消费。 | 复杂过滤场景。一条消息支持设置多个属性，可根据SQL语法自定义组合多种类型的表达式对消息进行多级分类并实现多维度的过滤。 |
-
-### Tag过滤
-
-Tag在生产者章节已经介绍过，用于对某个Topic下的消息进行分类。生产者在发送消息时，指定消息的Tag，消费者需根据已经指定的Tag来进行订阅。
-
-以下图电商交易场景为例，从客户下单到收到商品这一过程会生产一系列消息，以如下消息为例：
-- 订单消息
-- 支付消息
-- 物流消息
-
-这些消息会发送到名称为Trade_Topic的Topic中，被各个不同的系统所订阅，以如下系统为例：
-- 支付系统：只需订阅支付消息。
-- 物流系统：只需订阅物流消息。
-- 实时计算系统：需要订阅所有和交易相关的消息。
-- 交易成功率分析系统：需订阅订单和支付消息。
-
-过滤示意图如下所示
-
-
-
-对于物流系统和支付系统来说，它们都只订阅但个Tag，此时只需要在调用subcribe接口时明确标明Tag即可。
-
-```java
-consumer.subscribe("TagFilterTest", "TagA");
-```
-
-对于实时计算系统来说，它订阅交易Topic下所有的消息，Tag用星号（*）表示即可。
-
-```java
-consumer.subscribe("TagFilterTest", "*");
-```
-
-对于交易成功率分析系统来说，它订阅了订单和支付两个Tag的消息，在多个Tag之间用两个竖线（||）分隔即可。
-
-```java
-consumer.subscribe("TagFilterTest", "TagA||TagB");
-```
-
-这里需要注意的是，如果同一个消费者多次订阅某个Topic下的Tag，以最后一次订阅为准。
-
-```java
-//如下错误代码中，Consumer只能订阅到TagFilterTest下TagB的消息，而不能订阅TagA的消息。
-consumer.subscribe("TagFilterTest", "TagA");
-consumer.subscribe("TagFilterTest", "TagB");
-```
-
-### SQL92过滤
-
-SQL92过滤是在消息发送时设置消息的Tag或自定义属性，消费者订阅时使用SQL语法设置过滤表达式，根据自定义属性或Tag过滤消息。
->Tag属于一种特殊的消息属性，在SQL语法中，Tag的属性值为TAGS。
-开启属性过滤首先要在Broker端设置配置enablePropertyFilter=true，该值默认为false。
-
-以下图电商交易场景为例，从客户下单到收到商品这一过程会生产一系列消息，按照类型将消息分为订单消息和物流消息，其中给物流消息定义地域属性，按照地域分为杭州和上海：
-- 订单消息
-- 物流消息
- - 物流消息且地域为杭州
- - 物流消息且地域为上海
-
-这些消息会发送到名称为Trade_Topic的Topic中，被各个不同的系统所订阅，以如下系统为例：
-- 物流系统1：只需订阅物流消息且消息地域为杭州。
-- 物流系统2：只需订阅物流消息且消息地域为杭州或上海。
-- 订单跟踪系统：只需订阅订单消息。
-
-SQL92过滤示意图如下所示：
-
-
-
-地域将作为自定义属性设置在消息中。
-
-- 消息发送端：
- 设置消息的自定义属性。
-
-```java
-Message msg = new Message("topic", "tagA", "Hello MQ".getBytes());
-// 设置自定义属性A，属性值为1。
-msg.putUserProperties("a", "1");
-```
-
-- 消息消费端：
- 使用SQL语法设置过滤表达式，并根据自定义属性过滤消息。
-```java
-consumer.subscribe("SqlFilterTest",
- MessageSelector.bySql("(TAGS is not null and TAGS in ('TagA', 'TagB'))" +
- "and (a is not null and a between 0 and 3)"));
-```
-
-## 消息重试和死信队列
-
-### 消息重试
-
-若Consumer消费某条消息失败，则RockettMQ会在重试间隔时间后，将消息重新投递给Consumer消费，若达到最大重试次数后消息还没有成功被消费，则消息将被投递至死信队列
->消息重试只针对集群消费模式生效；广播消费模式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息
-- 最大重试次数：消息消费失败后，可被重复投递的最大次数。
-```java
-consumer.setMaxReconsumeTimes(10);
-```
-- 重试间隔：消息消费失败后再次被投递给Consumer消费的间隔时间，只在顺序消费中起作用。
-```java
-consumer.setSuspendCurrentQueueTimeMillis(5000);
-```
-
-顺序消费和并发消费的重试机制并不相同，顺序消费消费失败后是先在客户端本地重试，并且为了保证顺序性消费失败的消息不会被跳过先去消费下一条而是一直重试到最大重试次数，而并发消费消费失败后会将消费失败的消息重新投递回服务端，再等待服务端重新投递回来，在这期间会正常消费队列后面的消息。
->并发消费失败后并不是投递回原Topic，而是投递到一个特殊Topic，其命名为%RETRY%ConsumerGroupName，集群模式下并发消费每一个ConsumerGroup会对应一个特殊Topic，并会订阅该Topic。
-两者参数差别如下
-
-| 消费类型 | 重试间隔 | 最大重试次数 |
-|------|--------------------------------------------|--------------------------------------------------------------|
-| 顺序消费 | 间隔时间可通过自定义设置，SuspendCurrentQueueTimeMillis | 最大重试次数可通过自定义参数MaxReconsumeTimes取值进行配置。该参数取值无最大限制。若未设置参数值，默认最大重试次数为Integer.MAX |
-| 并发消费 | 间隔时间根据重试次数阶梯变化，取值范围：1秒～2小时。不支持自定义配置 | 最大重试次数可通过自定义参数MaxReconsumeTimes取值进行配置。默认值为16次，该参数取值无最大限制，建议使用默认值 |
-
-并发消费重试间隔如下，可以看到与延迟消息第三个等级开始的时间完全一致。
-
-| 第几次重试 | 与上次重试的间隔时间 | 第几次重试 | 与上次重试的间隔时间 |
-|-------|------------|-------|------------|
-| 1 | 10s | 9 | 7min |
-| 2 | 30s | 10 | 8min |
-| 3 | 1min | 11 | 9min |
-| 4 | 2min | 12 | 10min |
-| 5 | 3min | 13 | 20min |
-| 6 | 4min | 14 | 30min |
-| 7 | 5min | 15 | 1h |
-| 8 | 6min | 16 | 2h |
-
-### 死信队列
-
-当一条消息初次消费失败，RocketMQ会自动进行消息重试，达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息。此时，该消息不会立刻被丢弃，而是将其发送到该消费者对应的特殊队列中，这类消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列（Dead-Letter Queue），死信队列是死信Topic下分区数为一的单独队列。如果产生了死信消息，那对应的ConsumerGroup的死信Topic名称为%DLQ%ConsumerGroupName，死信队列的消息将不会再被消费。可以利用RocketMQ Admin工具或者RocketMQ Dashboard上查询到对应死信消息的信息。
diff --git "a/versioned_docs/version-5.0/03-\346\266\210\350\264\271\350\200\205/13pull.md" "b/versioned_docs/version-5.0/03-\346\266\210\350\264\271\350\200\205/13pull.md"
deleted file mode 100644
index 1c0e53cd..00000000
--- "a/versioned_docs/version-5.0/03-\346\266\210\350\264\271\350\200\205/13pull.md"
+++ /dev/null
@@ -1,120 +0,0 @@
-# Pull消费
-
-在RocketMQ中有两种Pull方式，一种是比较原始`Pull Consumer`，它不提供相关的订阅方法，需要调用pull方法时指定队列进行拉取，并需要自己更新位点。另一种是`Lite Pull Consumer`，它提供了Subscribe和Assign两种方式，使用起来更加方便。
-
-## Pull Consumer
-
-Pull Consumer示例如下
-
-```javascript
-public class PullConsumerTest {
- public static void main(String[] args) throws MQClientException {
- DefaultMQPullConsumer consumer = new DefaultMQPullConsumer("please_rename_unique_group_name_5");
- consumer.setNamesrvAddr("127.0.0.1:9876");
- consumer.start();
- try {
- MessageQueue mq = new MessageQueue();
- mq.setQueueId(0);
- mq.setTopic("TopicTest");
- mq.setBrokerName("jinrongtong-MacBook-Pro.local");
- long offset = 26;
- PullResult pullResult = consumer.pull(mq, "*", offset, 32);
- if (pullResult.getPullStatus().equals(PullStatus.FOUND)) {
- System.out.printf("%s%n", pullResult.getMsgFoundList());
- consumer.updateConsumeOffset(mq, pullResult.getNextBeginOffset());
- }
- } catch (Exception e) {
- e.printStackTrace();
- }
- consumer.shutdown();
- }
-}
-```
-
-首先需要初始化`DefaultMQPullConsumer`并启动，然后构造需要拉取的队列`MessageQueue`，除了构造外也可以如下所示调用`fetchSubscribeMessageQueues`方法获取某个Topic的所有队列，然后挑选队列进行拉取。
-
-```java
-Set<MessageQueue> queueSet = consumer.fetchSubscribeMessageQueues("TopicTest");
-```
-
-找到或者构造完队列之后，调用pull方法就可以进行拉取，需要传入拉取的队列，过滤表达式，拉取的位点，最大拉取消息条数等参数。拉取完成后会返回拉取结果`PullResult`，PullResult中的PullStatus表示结果状态，如下所示
-
-```javascript
-public enum PullStatus {
- /**
- * Founded
- */
- FOUND,
- /**
- * No new message can be pull
- */
- NO_NEW_MSG,
- /**
- * Filtering results can not match
- */
- NO_MATCHED_MSG,
- /**
- * Illegal offset,may be too big or too small
- */
- OFFSET_ILLEGAL
-}
-```
-
-FOUND表示拉取到消息，NO_NEW_MSG表示没有发现新消息，NO_MATCHED_MSG表示没有匹配的消息，OFFSET_ILLEGAL表示传入的拉取位点是非法的，有可能偏大或偏小。如果拉取状态是FOUND，我们可以通过`pullResult`的`getMsgFoundList`方法获取拉取到的消息列表。最后，如果消费完成，通过`updateConsumeOffset`方法更新消费位点。
-
-## Lite Pull Consumer
-
-Lite Pull Consumer是RocketMQ 4.6.0推出的Pull Consumer，相比于原始的Pull Consumer更加简单易用，它提供了Subscribe和Assign两种模式，Subscribe模式示例如下
-
-```javascript
-public class LitePullConsumerSubscribe {
- public static volatile boolean running = true;
- public static void main(String[] args) throws Exception {
- DefaultLitePullConsumer litePullConsumer = new DefaultLitePullConsumer("lite_pull_consumer_test");
- litePullConsumer.subscribe("TopicTest", "*");
- litePullConsumer.setPullBatchSize(20);
- litePullConsumer.start();
- try {
- while (running) {
- List<MessageExt> messageExts = litePullConsumer.poll();
- System.out.printf("%s%n", messageExts);
- }
- } finally {
- litePullConsumer.shutdown();
- }
- }
-}
-```
-
-首先还是初始化`DefaultLitePullConsumer`并设置`ConsumerGroupName`，调用subscribe方法订阅topic并启动。与Push Consumer不同的是，`LitePullConsumer`拉取消息调用的是轮询poll接口，如果能拉取到消息则返回对应的消息列表，否则返回null。通过`setPullBatchSize`可以设置每一次拉取的最大消息数量，此外如果不额外设置，`LitePullConsumer`默认是自动提交位点。在subscribe模式下，同一个消费组下的多个`LitePullConsumer`会负载均衡消费，与PushConsumer一致。
-
-如下是Assign模式的示例
-```javascript
-public class LitePullConsumerAssign {
- public static volatile boolean running = true;
- public static void main(String[] args) throws Exception {
- DefaultLitePullConsumer litePullConsumer = new DefaultLitePullConsumer("please_rename_unique_group_name");
- litePullConsumer.setAutoCommit(false);
- litePullConsumer.start();
- Collection<MessageQueue> mqSet = litePullConsumer.fetchMessageQueues("TopicTest");
- List<MessageQueue> list = new ArrayList<>(mqSet);
- List<MessageQueue> assignList = new ArrayList<>();
- for (int i = 0; i < list.size() / 2; i++) {
- assignList.add(list.get(i));
- }
- litePullConsumer.assign(assignList);
- litePullConsumer.seek(assignList.get(0), 10);
- try {
- while (running) {
- List<MessageExt> messageExts = litePullConsumer.poll();
- System.out.printf("%s %n", messageExts);
- litePullConsumer.commitSync();
- }
- } finally {
- litePullConsumer.shutdown();
- }
- }
-}
-```
-
-Assign模式一开始仍然是初始化`DefaultLitePullConsumer`，这里我们采用手动提交位点的方式，因此设置AutoCommit为false，然后启动consumer。与Subscribe模式不同的是，Assign模式下没有自动的负载均衡机制，需要用户自行指定需要拉取的队列，因此在例子中，先用fetchMessageQueues获取了Topic下的队列，再取前面的一半队列进行拉取，示例中还调用了seek方法，将第一个队列拉取的位点设置从10开始。紧接着进入循环不停地调用poll方法拉取消息，拉取到消息后调用commitSync方法手动提交位点。
\ No newline at end of file
diff --git "a/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/01main.md" "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/01main.md"
new file mode 100644
index 00000000..b2813ffc
--- /dev/null
+++ "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/01main.md"
@@ -0,0 +1,120 @@
+# 领域模型概述
+
+本文为您介绍 Apache RocketMQ 的领域模型。
+
+Apache RocketMQ 是一款典型的分布式架构下的中间件产品，使用异步通信方式和发布订阅的消息传输模型。通信方式和传输模型的具体说明，请参见下文**通信方式介绍**和**消息传输模型**介绍。
+Apache RocketMQ 产品具备异步通信的优势，系统拓扑简单、上下游耦合较弱，主要应用于异步解耦，流量削峰填谷等场景。
+
+## Apache RocketMQ领域模型
+
+
+
+如上图所示，Apache RocketMQ 中消息的生命周期主要分为消息生产、消息存储、消息消费这三部分。
+
+生产者生产消息并发送至 Apache RocketMQ 服务端，消息被存储在服务端的主题中，消费者通过订阅主题消费消息。
+
+**消息生产**
+
+[生产者（Producer）](../03-领域模型/04producer.md)：
+
+Apache RocketMQ 中用于产生消息的运行实体，一般集成于业务调用链路的上游。生产者是轻量级匿名无身份的。
+
+**消息存储**
+
+* [主题（Topic）](../03-领域模型/02topic.md)：
+
+ Apache RocketMQ 消息传输和存储的分组容器，主题内部由多个队列组成，消息的存储和水平扩展实际是通过主题内的队列实现的。
+
+* [队列（MessageQueue）](../03-领域模型/03messagequeue.md)：
+
+ Apache RocketMQ 消息传输和存储的实际单元容器，类比于其他消息队列中的分区。 Apache RocketMQ 通过流式特性的无限队列结构来存储消息，消息在队列内具备顺序性存储特征。
+
+* [消息（Message）](../03-领域模型/04message.md)：
+
+ Apache RocketMQ 的最小传输单元。消息具备不可变性，在初始化发送和完成存储后即不可变。
+
+
+
+
+**消息消费**
+
+* [消费者分组（ConsumerGroup）](../03-领域模型/07consumergroup.md)：
+
+ Apache RocketMQ 发布订阅模型中定义的独立的消费身份分组，用于统一管理底层运行的多个消费者（Consumer）。同一个消费组的多个消费者必须保持消费逻辑和配置一致，共同分担该消费组订阅的消息，实现消费能力的水平扩展。
+
+* [消费者（Consumer）](../03-领域模型/08consumer.md)：
+
+ Apache RocketMQ 消费消息的运行实体，一般集成在业务调用链路的下游。消费者必须被指定到某一个消费组中。
+
+* [订阅关系（Subscription）](../03-领域模型/09subscription.md)：
+
+ Apache RocketMQ 发布订阅模型中消息过滤、重试、消费进度的规则配置。订阅关系以消费组粒度进行管理，消费组通过定义订阅关系控制指定消费组下的消费者如何实现消息过滤、消费重试及消费进度恢复等。
+
+ Apache RocketMQ 的订阅关系除过滤表达式之外都是持久化的，即服务端重启或请求断开，订阅关系依然保留。
+
+
+
+
+
+
+## 通信方式介绍
+
+分布式系统架构思想下，将复杂系统拆分为多个独立的子模块，例如微服务模块。此时就需要考虑子模块间的远程通信，典型的通信模式分为以下两种，一种是同步的RPC远程调用；一种是基于中间件代理的异步通信方式。
+
+同步RPC调用模型
+
+
+同步RPC调用模型下，不同系统之间直接进行调用通信，每个请求直接从调用方发送到被调用方，然后要求被调用方立即返回响应结果给调用方，以确定本次调用结果是否成功。
+**注意** 此处的同步并不代表RPC的编程接口方式，RPC也可以有异步非阻塞调用的编程方式，但本质上仍然是需要在指定时间内得到目标端的直接响应。
+
+异步通信模型
+
+
+异步消息通信模式下，各子系统之间无需强耦合直接连接，调用方只需要将请求转化成异步事件（消息）发送给中间代理，发送成功即可认为该异步链路调用完成，剩下的工作中间代理会负责将事件可靠通知到下游的调用系统，确保任务执行完成。该中间代理一般就是消息中间件。
+
+异步通信的优势如下：
+
+* 系统拓扑简单由于调用方和被调用方统一和中间代理通信，系统是星型结构，易于维护和管理。
+
+
+
+* 上下游耦合性弱上下游系统之间弱耦合，结构更灵活，由中间代理负责缓冲和异步恢复。 上下游系统间可以独立升级和变更，不会互相影响。
+
+
+
+* 容量削峰填谷基于消息的中间代理往往具备很强的流量缓冲和整形能力，业务流量高峰到来时不会击垮下游。
+
+
+
+## 消息传输模型介绍
+
+主流的消息中间件的传输模型主要为点对点模型和发布订阅模型。
+
+点对点模型
+
+
+点对点模型也叫队列模型，具有如下特点：
+
+* 消费匿名：消息上下游沟通的唯一的身份就是队列，下游消费者从队列获取消息无法申明独立身份。
+
+* 一对一通信：基于消费匿名特点，下游消费者即使有多个，但都没有自己独立的身份，因此共享队列中的消息，每一条消息都只会被唯一一个消费者处理。因此点对点模型只能实现一对一通信。
+
+
+
+
+发布订阅模型
+
+
+发布订阅模型具有如下特点：
+
+* 消费独立：相比队列模型的匿名消费方式，发布订阅模型中消费方都会具备的身份，一般叫做订阅组（订阅关系），不同订阅组之间相互独立不会相互影响。
+
+* 一对多通信：基于独立身份的设计，同一个主题内的消息可以被多个订阅组处理，每个订阅组都可以拿到全量消息。因此发布订阅模型可以实现一对多通信。
+
+
+
+
+传输模型对比
+
+点对点模型和发布订阅模型各有优势，点对点模型更为简单，而发布订阅模型的扩展性更高。 Apache RocketMQ 使用的传输模型为发布订阅模型，因此也具有发布订阅模型的特点。
+
diff --git "a/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/02topic.md" "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/02topic.md"
new file mode 100644
index 00000000..54fe601f
--- /dev/null
+++ "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/02topic.md"
@@ -0,0 +1,131 @@
+# 主题（Topic）
+
+本文介绍 Apache RocketMQ 中主题（Topic）的定义、模型关系、内部属性、行为约束、版本兼容性及使用建议。
+
+## 定义
+
+主题是 Apache RocketMQ 中消息传输和存储的顶层容器，用于标识同一类业务逻辑的消息。 主题的作用主要如下：
+
+* **定义数据的分类隔离：** 在 Apache RocketMQ 的方案设计中，建议将不同业务类型的数据拆分到不同的主题中管理，通过主题实现存储的隔离性和订阅隔离性。
+
+* **定义数据的身份和权限：** Apache RocketMQ 的消息本身是匿名无身份的，同一分类的消息使用相同的主题来做身份识别和权限管理。
+
+
+## 模型关系
+
+
+在整个 Apache RocketMQ 的领域模型中，主题所处的流程和位置如下：
+
+
+
+主题是 Apache RocketMQ 的顶层存储，所有消息资源的定义都在主题内部完成，但主题是一个逻辑概念，并不是实际的消息容器。
+
+主题内部由多个队列组成，消息的存储和水平扩展能力最终是由队列实现的；并且针对主题的所有约束和属性设置，最终也是通过主题内部的队列来实现。
+
+## 内部属性
+
+**主题名称**
+
+* 定义：主题的名称，用于标识主题，主题名称集群内全局唯一。
+
+* 取值：由用户创建主题时定义。
+
+* 约束：请参见[参数限制](../01-基础介绍/03limits.md)。
+
+
+
+
+**队列列表**
+
+* 定义：队列作为主题的组成单元，是消息存储的实际容器，一个主题内包含一个或多个队列，消息实际存储在主题的各队列内。更多信息，请参见[队列（MessageQueue）](../03-领域模型/03messagequeue.md)。
+
+* 取值：系统根据队列数量给主题分配队列，队列数量创建主题时定义。
+
+* 约束：一个主题内至少包含一个队列。
+
+
+
+
+**消息类型**
+
+* 定义：主题所支持的消息类型。
+
+* 取值：创建主题时选择消息类型。Apache RocketMQ 支持的主题类型如下：
+ * Normal：[普通消息](../04-功能行为/01normalmessage.md)，消息本身无特殊语义，消息之间也没有任何关联。
+
+ * FIFO：[顺序消息](../04-功能行为/03fifomessage.md)，Apache RocketMQ 通过消息分组MessageGroup标记一组特定消息的先后顺序，可以保证消息的投递顺序严格按照消息发送时的顺序。
+
+ * Delay：[定时/延时消息](../04-功能行为/02delaymessage.md)，通过指定延时时间控制消息生产后不要立即投递，而是在延时间隔后才对消费者可见。
+
+ * Transaction：[事务消息](../04-功能行为/04transactionmessage.md)，Apache RocketMQ 支持分布式事务消息，支持应用数据库更新和消息调用的事务一致性保障。
+
+* 约束：每个主题只支持一种消息类型。
+
+
+
+
+## 行为约束
+
+**消息类型强制校验**
+
+Apache RocketMQ 5.x版本将消息类型拆分到主题中进行独立运维和处理，因此系统会对发送的消息类型和主题定的消息类型进行强制校验，若校验不通过，则消息发送请求会被拒绝，并返回类型不匹配异常。校验原则如下：
+
+* 消息类型必须一致发送的消息的类型，必须和目标主题定义的消息类型一致。
+
+* 主题类型必须单一每个主题只支持一种消息类型，不允许将多种类型的消息发送到同一个主题中。
+
+**常见错误使用场景**
+
+* 发送的消息类型不匹配例如，创建主题时消息类型定义为顺序消息，发送消息时发送事务消息到该主题中，此时消息发送请求会被拒绝，并返回类型不匹配异常。
+
+* 单一消息主题混用例如，创建主题时消息类型定义为普通消息，发送消息时同时发送普通消息和顺序消息到该主题中，则顺序消息的发送请求会被拒绝，并返回类型不匹配异常。
+
+
+## 版本兼容性
+
+
+消息类型的强制校验，仅针对 Apache RocketMQ 服务端5.x版本生效。 Apache RocketMQ 服务端4.x和3.x历史版本的SDK不支持强制校验，您需要自己保证消息类型一致。 如果您使用的服务端版本为历史版本，建议您升级到
+Apache RocketMQ 服务端5.x版本。
+
+## 使用建议
+
+**按照业务分类合理拆分主题**
+
+
+
+Apache RocketMQ 的主题拆分设计应遵循大类统一原则，即将相同业务域内同一功能属性的消息划分为同一主题。拆分主题时，您可以从以下角度考虑拆分粒度：
+
+* 消息类型是否一致：不同类型的消息，如顺序消息和普通消息需要使用不同的主题。
+
+* 消息业务是否关联：如果业务没有直接关联，比如，淘宝交易消息和盒马物流消息没有业务交集，需要使用不同的消息主题；同样是淘宝交易消息，女装类订单和男装类订单可以使用同一个订单。当然，如果业务量较大或其他子模块应用处理业务时需要进一步拆分订单类型，您也可以将男装订单和女装订单的消息拆分到两个主题中。
+
+* 消息量级是否一样：数量级不同或时效性不同的业务消息建议使用不同的主题，例如某些业务消息量很小但是时效性要求很强，如果跟某些万亿级消息量的业务使用同一个主题，会增加消息的等待时长。
+
+
+
+
+**正确拆分示例：** 线上商品购买场景下，订单交易如订单创建、支付、取消等流程消息使用一个主题，物流相关消息使用一个主题，积分管理相关消息使用一个主题。
+
+**错误拆分示例：**
+
+* 拆分粒度过粗：会导致业务隔离性差，不利于独立运维和故障处理。例如，所有交易消息和物流消息都共用一个主题。
+
+* 拆分粒度过细：会消耗大量主题资源，造成系统负载过重。例如，按照用户ID区分，每个用户ID使用一个主题。
+
+
+
+
+**单一主题只收发一种类型消息，避免混用**
+
+
+
+Apache RocketMQ 主题的设计原则为通过主题隔离业务，不同业务逻辑的消息建议使用不同的主题。同一业务逻辑消息的类型都相同，因此，对于指定主题，应该只收发同一种类型的消息。
+
+**主题管理尽量避免自动化机制**
+
+在 Apache RocketMQ 架构中，主题属于顶层资源和容器，拥有独立的权限管理、可观测性指标采集和监控等能力，创建和管理主题会占用一定的系统资源。因此，生产环境需要严格管理主题资源，请勿随意进行增、删、改、查操作。
+
+
+
+Apache RocketMQ 虽然提供了自动创建主题的功能，但是建议仅在测试环境使用，生产环境请勿打开，避免产生大量垃圾主题，无法管理和回收并浪费系统资源。
+
diff --git "a/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/03messagequeue.md" "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/03messagequeue.md"
new file mode 100644
index 00000000..a40e7a08
--- /dev/null
+++ "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/03messagequeue.md"
@@ -0,0 +1,107 @@
+# 队列（MessageQueue）
+
+
+本文介绍 Apache RocketMQ 中队列（MessageQueue）的定义、模型关系、内部属性、版本兼容性及使用建议。
+
+## 定义
+
+
+队列是 Apache RocketMQ 中消息存储和传输的实际容器，也是 Apache RocketMQ 消息的最小存储单元。 Apache RocketMQ 的所有主题都是由多个队列组成，以此实现队列数量的水平拆分和队列内部的流式存储。
+
+队列的主要作用如下：
+
+* 存储顺序性
+
+ 队列天然具备顺序性，即消息按照进入队列的顺序写入存储，同一队列间的消息天然存在顺序关系，队列头部为最早写入的消息，队列尾部为最新写入的消息。消息在队列中的位置和消息之间的顺序通过位点（Offset）进行标记管理。
+
+* 流式操作语义
+
+ Apache RocketMQ 基于队列的存储模型可确保消息从任意位点读取任意数量的消息，以此实现类似聚合读取、回溯读取等特性，这些特性是RabbitMQ、ActiveMQ等非队列存储模型不具备的。
+
+
+
+
+
+
+## 模型关系
+
+在整个 Apache RocketMQ 的领域模型中，队列所处的流程和位置如下：
+
+
+
+Apache RocketMQ 默认提供消息可靠存储机制，所有发送成功的消息都被持久化存储到队列中，配合生产者和消费者客户端的调用可实现至少投递一次的可靠性语义。
+
+Apache RocketMQ 队列模型和Kafka的分区（Partition）模型类似。在 Apache RocketMQ 消息收发模型中，队列属于主题的一部分，虽然所有的消息资源以主题粒度管理，但实际的操作实现是面向队列。例如，生产者指定某个主题，向主题内发送消息，但实际消息发送到该主题下的某个队列中。
+
+Apache RocketMQ 中通过修改队列数量，以此实现横向的水平扩容和缩容。
+
+## 内部属性
+
+读写权限
+
+* 定义：当前队列是否可以读写数据。
+
+* 取值：由服务端定义，枚举值如下
+ * 6：读写状态，当前队列同时允许写入消息和读取消息操作。
+
+ * 4：只读状态，当前队列只允许读取历史消息，不允许向队列写入新的消息。
+
+ * 2：只写状态，当前队列只允许写入新消息，不允许读取消息。
+
+ * 0：不可读写状态，当前队列不允许任何读写操作。
+
+
+
+
+* 约束：队列的读写权限属于运维侧操作，不建议频繁修改。
+
+
+
+
+## 行为约束
+
+每个主题下会由一到多个队列来存储消息，每个主题对应的队列数与消息类型以及实例所处地域（Region）相关，队列数暂不支持修改。
+
+## 版本兼容性
+
+队列的名称属性在 Apache RocketMQ 服务端的不同版本中有如下差异：
+
+* 服务端3.x/4.x版本：队列名称由{主题名称}+{BrokerID}+{QueueID}三元组组成，和物理节点绑定。
+
+* 服务端5.x版本：队列名称为一个集群分配的全局唯一的字符串组成，和物理节点解耦。
+
+
+
+
+因此，在开发过程中，建议不要对队列名称做任何假设和绑定。如果您在代码中自定义拼接队列名称并和其他操作进行绑定，一旦服务端版本升级，可能会出现队列名称无法解析的兼容性问题。
+
+## 使用建议
+
+**按照实际业务消耗设置队列数**
+
+Apache RocketMQ 的队列数可在创建主题或变更主题时设置修改，队列数量的设置应遵循少用够用原则，避免随意增加队列数量。
+
+主题内队列数过多可能对导致如下问题：
+
+* 集群元数据膨胀
+
+ Apache RocketMQ 会以队列粒度采集指标和监控数据，队列过多容易造成管控元数据膨胀。
+
+* 客户端压力过大
+
+ Apache RocketMQ 的消息读写都是针对队列进行操作，队列过多容易产生空轮询请求，增加系统负荷。
+
+**常见队列增加场景**
+
+* 需要增加队列实现物理节点负载均衡
+
+ Apache RocketMQ 每个主题的多个队列可以分布在不同的服务节点上，在集群水平扩容增加节点后，为了保证集群流量的负载均衡，建议在新的服务节点上新增队列，或将旧的队列迁移到新的服务节点上。
+
+* 需要增加队列实现顺序消息性能扩展
+
+ 在 Apache RocketMQ 服务端4.x版本中，顺序消息的顺序性在队列内生效的，因此顺序消息的并发度会在一定程度上受队列数量的影响，因此建议仅在系统性能瓶颈时再增加队列。
+
+
+
+
+
diff --git "a/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04message.md" "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04message.md"
new file mode 100644
index 00000000..6cbe1f75
--- /dev/null
+++ "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04message.md"
@@ -0,0 +1,231 @@
+# 消息（Message）
+
+本文介绍 Apache RocketMQ 中消息（Message）的定义、模型关系、内部属性、行为约束及使用建议。
+
+## 定义
+
+
+消息是 Apache RocketMQ 中的最小数据传输单元。生产者将业务数据的负载和拓展属性包装成消息发送到 Apache RocketMQ 服务端，服务端按照相关语义将消息投递到消费端进行消费。
+
+
+
+Apache RocketMQ 的消息模型具备如下特点：
+
+* **消息不可变性**
+
+ 消息本质上是已经产生并确定的事件，一旦产生后，消息的内容不会发生改变。即使经过传输链路的控制也不会发生变化，消费端获取的消息都是只读消息视图。
+
+
+
+* **消息持久化**
+
+ Apache RocketMQ 会默认对消息进行持久化，即将接收到的消息存储到 Apache RocketMQ 服务端的存储文件中，保证消息的可回溯性和系统故障场景下的可恢复性。
+
+
+
+## 模型关系
+
+在整个 Apache RocketMQ 的领域模型中，消息所处的流程和位置如下：
+
+1. 消息由生产者初始化并发送到Apache RocketMQ 服务端。
+
+2. 消息按照到达Apache RocketMQ 服务端的顺序存储到队列中。
+
+3. 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
+
+
+
+
+## 消息内部属性
+
+**系统保留属性**
+
+**主题名称**
+
+* 定义：当前消息所属的主题的名称。集群内全局唯一。更多信息，请参见[主题（Topic）](./02topic.md)。
+
+* 取值：从客户端SDK接口获取。
+
+
+
+
+**消息类型**
+
+* 定义：当前消息的类型。
+
+* 取值：从客户端SDK接口获取。Apache RocketMQ 支持的消息类型如下：
+ * Normal：[普通消息](../04-功能行为/01normalmessage.md)，消息本身无特殊语义，消息之间也没有任何关联。
+
+ * FIFO：[顺序消息](../04-功能行为/03fifomessage.md)，Apache RocketMQ 通过消息分组MessageGroup标记一组特定消息的先后顺序，可以保证消息的投递顺序严格按照消息发送时的顺序。
+
+ * Delay：[定时/延时消息](../04-功能行为/02delaymessage.md)，通过指定延时时间控制消息生产后不要立即投递，而是在延时间隔后才对消费者可见。
+
+ * Transaction：[事务消息](../04-功能行为/04transactionmessage.md)，Apache RocketMQ 支持分布式事务消息，支持应用数据库更新和消息调用的事务一致性保障。
+
+
+
+
+
+
+
+**消息队列**
+
+* 定义：实际存储当前消息的队列。更多信息，请参见[队列（MessageQueue）](./03messagequeue.md)。
+
+* 取值：由服务端指定并填充。
+
+
+
+
+**消息位点**
+
+* 定义：当前消息存储在队列中的位置。更多信息，请参见[消费进度原理](../04-功能行为/09consumerprogress.md)。
+
+* 取值：由服务端指定并填充。取值范围：0\~long.Max。
+
+
+
+
+**消息ID**
+
+* 定义：消息的唯一标识，集群内每条消息的ID全局唯一。
+
+* 取值：生产者客户端系统自动生成。固定为数字和大写字母组成的32位字符串。
+
+
+
+
+**索引Key列表（可选）**
+
+* 定义：消息的索引键，可通过设置不同的Key区分消息和快速查找消息。
+
+* 取值：由生产者客户端定义。
+
+
+
+
+**过滤标签Tag（可选）**
+
+* 定义：消息的过滤标签。消费者可通过Tag对消息进行过滤，仅接收指定标签的消息。
+
+* 取值：由生产者客户端定义。
+
+* 约束：一条消息仅支持设置一个标签。
+
+
+
+
+**定时时间（可选）**
+
+* 定义：定时场景下，消息触发延时投递的毫秒级时间戳。更多信息，请参见[定时/延时消息](../04-功能行为/02delaymessage.md)。
+
+* 取值：由消息生产者定义。
+
+* 约束：最大可设置定时时长为40天。
+
+
+
+
+**消息发送时间**
+
+* 定义：消息发送时，生产者客户端系统的本地毫秒级时间戳。
+
+* 取值：由生产者客户端系统填充。
+
+* 说明：客户端系统时钟和服务端系统时钟可能存在偏差，消息发送时间是以客户端系统时钟为准。
+
+
+
+
+**消息保存时间戳**
+
+* 定义：消息在Apache RocketMQ 服务端完成存储时，服务端系统的本地毫秒级时间戳。 对于定时消息和事务消息，消息保存时间指的是消息生效对消费方可见的服务端系统时间。
+
+
+* 取值：由服务端系统填充。
+
+* 说明：客户端系统时钟和服务端系统时钟可能存在偏差，消息保留时间是以服务端系统时钟为准。
+
+
+
+
+**消费重试次数**
+
+* 定义：消息消费失败后，Apache RocketMQ 服务端重新投递的次数。每次重试后，重试次数加1。更多信息，请参见[消费重试](../04-功能行为/10consumerretrypolicy.md)。
+
+* 取值：由服务端系统标记。首次消费，重试次数为0；消费失败首次重试时，重试次数为1。
+
+
+
+
+**业务自定义属性**
+
+
+* 定义：生产者可以自定义设置的扩展信息。
+
+* 取值：由消息生产者自定义，按照字符串键值对设置。
+
+
+
+
+**消息负载**
+
+* 定义：业务消息的实际报文数据。
+
+* 取值：由生产者负责序列化编码，按照二进制字节传输。
+
+* 约束：请参见[参数限制](../01-基础介绍/03limits.md)。
+
+
+
+
+## 行为约束
+
+
+消息大小不得超过其类型所对应的限制，否则消息会发送失败。
+
+系统默认的消息最大限制如下：
+
+* 普通和顺序消息：4 MB
+
+* 事务和定时或延时消息：64 KB
+
+
+
+
+## 使用建议
+
+
+**单条消息不建议传输超大负载**
+
+作为一款消息中间件产品，Apache RocketMQ 一般传输的是都是业务事件数据。单个原子消息事件的数据大小需要严格控制，如果单条消息过大容易造成网络传输层压力，不利于异常重试和流量控制。
+
+生产环境中如果需要传输超大负载，建议按照固定大小做报文拆分，或者结合文件存储等方法进行传输。
+
+**消息中转时做好不可变设计**
+
+Apache RocketMQ 服务端5.x版本中，消息本身不可编辑，消费端获取的消息都是只读消息视图。
+但在历史版本3.x和4.x版本中消息不可变性没有强约束，因此如果您需要在使用过程中对消息进行中转操作，务必将消息重新初始化。
+
+* 正确使用示例如下：
+
+ ```java
+ Message m = Consumer.receive();
+ Message m2= MessageBuilder.buildFrom(m);
+ Producer.send(m2);
+ ```
+
+
+
+* 错误使用示例如下：
+
+ ```java
+ Message m = Consumer.receive();
+ m.update()；
+ Producer.send(m);
+ ```
+
+
+
+
+
diff --git "a/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04producer.md" "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04producer.md"
new file mode 100644
index 00000000..af3fb409
--- /dev/null
+++ "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/04producer.md"
@@ -0,0 +1,133 @@
+# 生产者（Producer）
+
+本文介绍 Apache RocketMQ 中生产者（Producer）的定义、模型关系、内部属性、版本兼容性及使用建议。
+
+## 定义
+
+生产者是 Apache RocketMQ 系统中用来构建并传输消息到服务端的运行实体。
+
+生产者通常被集成在业务系统中，将业务消息按照要求封装成 Apache RocketMQ 的[消息（Message）](./04message.md)并发送至服务端。
+
+在消息生产者中，可以定义如下传输行为：
+
+* 发送方式：生产者可通过API接口设置消息发送的方式。Apache RocketMQ 支持同步传输和异步传输。
+
+* 批量发送：生产者可通过API接口设置消息批量传输的方式。例如，批量发送的消息条数或消息大小。
+
+* 事务行为：Apache RocketMQ 支持事务消息，对于事务消息需要生产者配合进行事务检查等行为保障事务的最终一致性。具体信息，请参见[事务消息](../04-功能行为/04transactionmessage.md)。
+
+
+
+
+生产者和主题的关系为多对多关系，即同一个生产者可以向多个主题发送消息，对于平台类场景如果需要发送消息到多个主题，并不需要创建多个生产者；同一个主题也可以接收多个生产者的消息，以此可以实现生产者性能的水平扩展和容灾。
+
+
+## 模型关系
+
+在 Apache RocketMQ 的领域模型中，生产者的位置和流程如下：
+
+1. 消息由生产者初始化并发送到Apache RocketMQ 服务端。
+
+2. 消息按照到达Apache RocketMQ 服务端的顺序存储到主题的指定队列中。
+
+3. 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
+
+
+
+
+## 内部属性
+
+
+**客户端ID**
+
+* 定义：生产者客户端的标识，用于区分不同的生产者。集群内全局唯一。
+
+* 取值：客户端ID由Apache RocketMQ 的SDK自动生成，主要用于日志查看、问题定位等运维场景，不支持修改。
+
+
+
+
+**通信参数**
+
+* 接入点信息 **（必选）** ：连接服务端的接入地址，用于识别服务端集群。 接入点必须按格式配置，建议使用域名，避免使用IP地址，防止节点变更无法进行热点迁移。
+
+* 身份认证信息 **（可选）** ：客户端用于身份验证的凭证信息。 仅在服务端开启身份识别和认证时需要传输。
+
+* 请求超时时间 **（可选）** ：客户端网络请求调用的超时时间。取值范围和默认值，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+
+
+
+**预绑定主题列表**
+
+* 定义：Apache RocketMQ 的生产者需要将消息发送到的目标主题列表，主要作用如下：
+ * 事务消息 **（必须设置）** ：事务消息场景下，生产者在故障、重启恢复时，需要检查事务消息的主题中是否有未提交的事务消息。避免生产者发送新消息后，主题中的旧事务消息一直处于未提交状态，造成业务延迟。
+
+ * 非事务消息 **（建议设置）** ：服务端会在生产者初始化时根据预绑定主题列表，检查目标主题的访问权限和合法性，而不需要等到应用启动后再检查。
+
+ 若未设置，或后续消息发送的目标主题动态变更， Apache RocketMQ 会对目标主题进行动态补充检验。
+
+* 约束：对于事务消息，预绑定列表必须设置，且需要和事务检查器一起配合使用。
+
+
+
+
+**事务检查器**
+
+* 定义：Apache RocketMQ 的事务消息机制中，为保证异常场景下事务的最终一致性，生产者需要主动实现事务检查器的接口。具体信息，请参见[事务消息](../04-功能行为/04transactionmessage.md)。
+
+* 发送事务消息时，事务检查器必须设置，且需要和预绑定主题列表一起配合使用。
+
+
+
+
+**发送重试策略**：
+
+* 定义: 生产者在消息发送失败时的重试策略。具体信息，请参见[消息发送重试机制](../04-功能行为/05sendretrypolicy.md)。
+
+## 版本兼容性
+
+Apache RocketMQ 服务端5.x版本开始，生产者是匿名的，无需管理生产者分组（ProducerGroup）；对于历史版本服务端3.x和4.x版本，已经使用的生产者分组可以废弃无需再设置，且不会对当前业务产生影响。
+
+## 使用建议
+
+**不建议单一进程创建大量生产者**
+
+
+
+Apache RocketMQ 的生产者和主题是多对多的关系，支持同一个生产者向多个主题发送消息。对于生产者的创建和初始化，建议遵循够用即可、最大化复用原则，如果有需要发送消息到多个主题的场景，无需为每个主题都创建一个生产者。
+
+**不建议频繁创建和销毁生产者**
+
+
+
+Apache RocketMQ 的生产者是可以重复利用的底层资源，类似数据库的连接池。因此不需要在每次发送消息时动态创建生产者，且在发送结束后销毁生产者。这样频繁的创建销毁会在服务端产生大量短连接请求，严重影响系统性能。
+
+* 正确示例
+
+ ```java
+ Producer p = ProducerBuilder.build();
+ for (int i =0;i<n;i++){
+ Message m= MessageBuilder.build();
+ p.send(m);
+ }
+ p.shutdown();
+ ```
+
+
+
+* 典型错误示例
+
+ ```java
+ for (int i =0;i<n;i++){
+ Producer p = ProducerBuilder.build();
+ Message m= MessageBuilder.build();
+ p.send(m);
+ p.shutdown();
+ }
+ ```
+
+
+
+
+
diff --git "a/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/07consumergroup.md" "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/07consumergroup.md"
new file mode 100644
index 00000000..9e3e79bb
--- /dev/null
+++ "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/07consumergroup.md"
@@ -0,0 +1,121 @@
+# 消费者分组（ConsumerGroup）
+
+本文介绍 Apache RocketMQ 中消费者分组（ConsumerGroup）的定义、模型关系、内部属性、行为约束、版本兼容性及使用建议。
+
+## 定义
+
+
+消费者分组是 Apache RocketMQ 系统中承载多个消费行为一致的消费者的负载均衡分组。
+
+和消费者不同，消费者分组并不是运行实体，而是一个逻辑资源。在 Apache RocketMQ 中，通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾。
+
+在消费者分组中，统一定义以下消费行为，同一分组下的多个消费者将按照分组内统一的消费行为和负载均衡策略消费消息。
+
+* 订阅关系：Apache RocketMQ 以消费者分组的粒度管理订阅关系，实现订阅关系的管理和追溯。具体信息，请参见[订阅关系（Subscription）](./09subscription.md)。
+
+* 投递顺序性：Apache RocketMQ 的服务端将消息投递给消费者消费时，支持顺序投递和并发投递，投递方式在消费者分组中统一配置。具体信息，请参见[顺序消息](../04-功能行为/03fifomessage.md)。
+
+* 消费重试策略： 消费者消费消息失败时的重试策略，包括重试次数、死信队列设置等。具体信息，请参见[消费重试](../04-功能行为/10consumerretrypolicy.md)。
+
+
+
+
+## 模型关系
+
+
+在 Apache RocketMQ 的领域模型中，消费者分组的位置和流程如下：
+
+1. 消息由生产者初始化并发送到Apache RocketMQ 服务端。
+
+2. 消息按照到达Apache RocketMQ 服务端的顺序存储到主题的指定队列中。
+
+3. 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
+
+
+
+
+## 内部属性
+
+
+**消费者分组名称**
+
+* 定义：消费者分组的名称，用于区分不同的消费者分组。集群内全局唯一。
+
+* 取值：消费者分组由用户设置并创建。具体命名规范，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+
+
+
+**投递顺序性**
+
+* 定义：消费者消费消息时，Apache RocketMQ 向消费者客户端投递消息的顺序。
+
+ 根据不同的消费场景，Apache RocketMQ 提供顺序投递和并发投递两种方式。具体信息，请参见[顺序消息](../04-功能行为/03fifomessage.md)。
+
+* 取值：默认投递方式为并发投递。
+
+
+
+
+**消费重试策略**
+
+* 定义：消费者消费消息失败时，系统的重试策略。消费者消费消息失败时，系统会按照重试策略，将指定消息投递给消费者重新消费。具体信息，请参见[消费重试](../04-功能行为/10consumerretrypolicy.md)。
+
+* 取值：重试策略包括：
+
+ * 最大重试次数：表示消息可以重新被投递的最大次数，超过最大重试次数还没被成功消费，消息将被投递至死信队列或丢弃。
+
+ * 重试间隔：Apache RocketMQ 服务端重新投递消息的间隔时间。 最大重试次数和重试间隔的取值范围及默认值，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+* 约束：重试间隔仅在PushConsumer消费类型下有效。
+
+
+**订阅关系**
+
+* 定义：当前消费者分组关联的订阅关系集合。包括消费者订阅的主题，以及消息的过滤规则等。订阅关系由消费者动态注册到消费者分组中，Apache RocketMQ 服务端会持久化订阅关系并匹配消息的消费进度。更多信息，请参见[订阅关系（Subscription）](./09subscription.md)。
+
+## 行为约束
+
+在 Apache RocketMQ 领域模型中，消费者的管理通过消费者分组实现，同一分组内的消费者共同分摊消息进行消费。因此，为了保证分组内消息的正常负载和消费，
+
+Apache RocketMQ 要求同一分组下的所有消费者以下消费行为保持一致：
+
+* **投递顺序**
+
+* **消费重试策略**
+
+
+
+
+## 版本兼容性
+
+如行为约束中所述，同一分组内所有消费者的投递顺序和消费重试策略需要保持一致。
+
+* Apache RocketMQ 服务端5.x版本：上述消费者的消费行为从关联的消费者分组中统一获取，因此，同一分组内所有消费者的消费行为必然是一致的，客户端无需关注。
+
+* Apache RocketMQ 服务端3.x/4.x历史版本：上述消费逻辑由消费者客户端接口定义，因此，您需要自己在消费者客户端设置时保证同一分组下的消费者的消费行为一致。
+
+
+
+
+若您使用 Apache RocketMQ 服务端5.x版本，客户端使用历史版本SDK，则消费者的消费逻辑以消费者客户端接口的设置为准。
+
+## 使用建议
+
+**按照业务合理拆分分组**
+
+Apache RocketMQ 的消费者和主题是多对多的关系，对于消费者分组的拆分设计，建议遵循以下原则：
+
+* 消费者的投递顺序一致：同一消费者分组下所有消费者的消费投递顺序是相同的，统一都是顺序投递或并发投递，不同业务场景不能混用消费者分组。
+
+* 消费者业务类型一致：一般消费者分组和主题对应，不同业务域对消息消费的要求不同，例如消息过滤属性、消费重试策略不同。因此，不同业务域主题的消费建议使用不同的消费者分组，避免一个消费者分组消费超过10个主题。
+
+
+
+
+**消费者分组管理尽量避免自动化机制**
+
+在 Apache RocketMQ 架构中，消费分组属于状态管理类的逻辑资源，每个消费分组都会涉及关联的消费状态、堆积信息、可观测指标和监控采集数据。因此，生产环境需要严格管理消费者分组资源，请勿随意进行增、删、改、查操作。
+
+Apache RocketMQ 虽然提供了自动创建消费者分组的功能，但是建议仅在测试环境使用，生产环境请勿打开，避免产生大量消费者分组，无法管理和回收，且浪费系统资源。
+
diff --git "a/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/08consumer.md" "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/08consumer.md"
new file mode 100644
index 00000000..db14f07f
--- /dev/null
+++ "b/versioned_docs/version-5.0/03-\351\242\206\345\237\237\346\250\241\345\236\213/08consumer.md"
@@ -0,0 +1,150 @@
+# 消费者（Consumer）
+
+本文介绍 Apache RocketMQ 中消费者（Consumer）的定义、模型关系、内部属性、行为约束、版本兼容性及使用建议。
+
+## 定义
+
+
+消费者是 Apache RocketMQ 中用来接收并处理消息的运行实体。 消费者通常被集成在业务系统中，从 Apache RocketMQ 服务端获取消息，并将消息转化成业务可理解的信息，供业务逻辑处理。
+
+在消息消费端，可以定义如下传输行为：
+
+* 消费者身份：消费者必须关联一个指定的消费者分组，以获取分组内统一定义的行为配置和消费状态。
+
+* 消费者类型：Apache RocketMQ 面向不同的开发场景提供了多样的消费者类型，包括PushConsumer类型、SimpleConsumer类型、PullConsumer类型（仅推荐流处理场景使用）等。具体信息，请参见[消费者分类](../04-功能行为/06consumertype.md)。
+
+* 消费者本地运行配置：消费者根据不同的消费者类型，控制消费者客户端本地的运行配置。例如消费者客户端的线程数，消费并发度等，实现不同的传输效果。
+
+
+
+
+## 模型关系
+
+
+在 Apache RocketMQ 的领域模型中，消费者的位置和流程如下：
+
+1. 消息由生产者初始化并发送到Apache RocketMQ 服务端。
+
+2. 消息按照到达Apache RocketMQ 服务端的顺序存储到主题的指定队列中。
+
+3. 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
+
+
+
+
+## 内部属性
+
+**消费者分组名称**
+
+* 定义：当前消费者关联的消费者分组名称，消费者必须关联到指定的消费者分组，通过消费者分组获取消费行为。更多信息，请参见[消费者分组（ConsumerGroup）](./07consumergroup.md)。
+
+* 取值：消费者分组为Apache RocketMQ 的逻辑资源，需要您提前通过控制台或OpenAPI创建。具体命名格式，请参见[使用限制](../01-基础介绍/03limits.md)。
+
+
+
+
+**客户端ID**
+
+* 定义：消费者客户端的标识，用于区分不同的消费者。集群内全局唯一。
+
+* 取值：客户端ID由Apache RocketMQ 的SDK自动生成，主要用于日志查看、问题定位等运维场景，不支持修改。
+
+
+
+
+**通信参数**
+
+* 接入点信息 **（必选）** ：连接服务端的接入地址，用于识别服务端集群。 接入点必须按格式配置，建议使用域名，避免使用IP地址，防止节点变更无法进行热点迁移。
+
+* 身份认证信息 **（可选）** ：客户端用于身份验证的凭证信息。 仅在服务端开启身份识别和认证时需要传输。
+
+* 请求超时时间 **（可选）** ：客户端网络请求调用的超时时间。取值范围和默认值，请参见[参数限制](../01-基础介绍/03limits.md)。
+
+
+
+
+**预绑定订阅关系列表**
+
+* 定义：指定消费者的订阅关系列表。 Apache RocketMQ 服务端可在消费者初始化阶段，根据预绑定的订阅关系列表对目标主题进行权限及合法性校验，无需等到应用启动后才能校验。
+
+
+* 取值：建议在消费者初始化阶段明确订阅关系即要订阅的主题列表，若未设置，或订阅的主题动态变更，Apache RocketMQ 会对目标主题进行动态补充校验。
+
+
+
+
+**消费监听器**
+
+* 定义：Apache RocketMQ 服务端将消息推送给消费者后，消费者调用消息消费逻辑的监听器。
+
+* 取值：由消费者客户端本地配置。
+
+* 约束：使用PushConsumer类型的消费者消费消息时，消费者客户端必须设置消费监听器。消费者类型的具体信息，请参见[消费者分类](../04-功能行为/06consumertype.md)。
+
+
+
+
+## 行为约束
+
+
... 4173 lines suppressed ...