This is an automated email from the ASF dual-hosted git repository.
ShannonDing 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 fd076ce377 [ISSUE #800] Fix typos and grammar in the RocketMQ
introduction (#801)
fd076ce377 is described below
commit fd076ce3777a04f18bdc4ad7c6aff22ec031082b
Author: FenjuFu <[email protected]>
AuthorDate: Wed Oct 14 16:57:26 2026 +0800
[ISSUE #800] Fix typos and grammar in the RocketMQ introduction (#801)
Signed-off-by: FenjuFu <[email protected]>
---
docs/00-introduction/02whatis.md | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/docs/00-introduction/02whatis.md b/docs/00-introduction/02whatis.md
index 3276286f8f..dc0f355474 100644
--- a/docs/00-introduction/02whatis.md
+++ b/docs/00-introduction/02whatis.md
@@ -47,7 +47,7 @@ import TabItem from '@theme/TabItem';
:::
-在**基于主题**的系统中，消息被发布到主题或命名通道上。消费者将收到其订阅主题上的所有消息，生产者负责定义订阅者所订阅的消息类别。这是一个基础的概念模型，而在实际的应用中，结构会更复杂。例如为了支持高并发和水平扩展，中间的消息主题需要进行分区，同一个Topic会有多个生产者，同一个信息会有多个消费者，消费者之间要进行负载均衡等。
+在**基于主题**的系统中，消息被发布到主题或命名通道上。消费者将收到其订阅主题上的所有消息，生产者负责定义订阅者所订阅的消息类别。这是一个基础的概念模型，而在实际的应用中，结构会更复杂。例如为了支持高并发和水平扩展，中间的消息主题需要进行分区，同一个Topic会有多个生产者，同一个消息会有多个消费者，消费者之间要进行负载均衡等。
@@ -76,7 +76,7 @@ import TabItem from '@theme/TabItem';
:::info
- 相同的ConsumerGroup下的消费者主要有两种负载均衡模式，即**广播模式**，和**集群模式**（图中是最常用的集群模式）。
-- 在集群模式下，同一个 ConsumerGroup 中的 Consumer 实例是负载均衡消费，如图中 ConsumerGroupA 订阅
TopicA，TopicA 对应 3个队列，则 GroupA 中的 Consumer1 消费的是 MessageQueue 0和 MessageQueue
1的消息，Consumer2是消费的是MessageQueue2的消息。
+- 在集群模式下，同一个 ConsumerGroup 中的 Consumer 实例是负载均衡消费，如图中 ConsumerGroupA 订阅
TopicA，TopicA 对应 3个队列，则 GroupA 中的 Consumer1 消费的是 MessageQueue 0和 MessageQueue
1的消息，Consumer2 消费的是 MessageQueue2 的消息。
- 在广播模式下，同一个 ConsumerGroup 中的每个 Consumer 实例都处理全部的队列。需要注意的是，广播模式下因为每个 Consumer
实例都需要处理全部的消息，因此这种模式仅推荐在通知推送、配置同步类小流量场景使用。
:::
@@ -107,7 +107,7 @@ NameServer是一个简单的 Topic 路由注册中心，支持 Topic、Broker
主要包括两个功能：
--
**Broker管理**，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
+-
**Broker管理**，NameServer接收Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
- **路由信息管理**，每个NameServer将保存关于 Broker
集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。
NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息。
@@ -116,7 +116,7 @@ NameServer通常会有多个实例部署，各实例间相互不进行信息通
Broker主要负责消息的存储、投递和查询以及服务高可用保证。
-NameServer几乎无状态节点，因此可集群部署，节点之间无任何信息同步。Broker部署相对复杂。
+NameServer 几乎是无状态节点，因此可集群部署，节点之间无任何信息同步。Broker部署相对复杂。
在 Master-Slave 架构中，Broker 分为 Master 与
Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave
的对应关系通过指定相同的BrokerName，不同的BrokerId
来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。
@@ -139,7 +139,7 @@ NameServer几乎无状态节点，因此可集群部署，节点之间无任何
### 2. 启动 Broker
-启动 Broker。与所有 NameServer 保持长连接，定时发送心跳包。心跳包中包含当前 Broker 信息以及存储所有 Topic
信息。注册成功后，NameServer 集群中就有 Topic跟Broker 的映射关系。
+启动 Broker。与所有 NameServer 保持长连接，定时发送心跳包。心跳包中包含当前 Broker 信息以及存储的所有 Topic
信息。注册成功后，NameServer 集群中就有 Topic跟Broker 的映射关系。
### 3. 创建 Topic
@@ -149,6 +149,6 @@ NameServer几乎无状态节点，因此可集群部署，节点之间无任何
生产者发送消息。启动时先跟 NameServer 集群中的其中一台建立长连接，并从 NameServer 中获取当前发送的 Topic存在于哪些
Broker 上，轮询从队列列表中选择一个队列，然后与队列所在的 Broker建立长连接从而向 Broker发消息。
-### 5. 消费者接受消息
+### 5. 消费者接收消息
-消费者接受消息。跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，然后开始消费消息。
+消费者接收消息。跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，然后开始消费消息。
