[rocketmq-site] branch new-official-website updated: Fix: add spaces between . (periods) and letters (#532)

[ji...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

jinrongtong 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 8970c97ca Fix: add spaces between . (periods) and letters (#532)
8970c97ca is described below

commit 8970c97caa7b5a9bb3477885812deac151480423
Author: elenacliu <44...@users.noreply.github.com>
AuthorDate: Thu Mar 23 21:12:23 2023 +0800

    Fix: add spaces between . (periods) and letters (#532)
---
 .../current/01-introduction/03whatis.md              | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/i18n/en/docusaurus-plugin-content-docs/current/01-introduction/03whatis.md b/i18n/en/docusaurus-plugin-content-docs/current/01-introduction/03whatis.md
index ee1dfb64e..eefa8bdfe 100644
--- a/i18n/en/docusaurus-plugin-content-docs/current/01-introduction/03whatis.md
+++ b/i18n/en/docusaurus-plugin-content-docs/current/01-introduction/03whatis.md
@@ -50,7 +50,7 @@ learn more  ➡️ [basic concept](../02-producer/01concept1.md)
 
 :::
 
-In a **topic-based** system, messages are published on topics or channels.Consumers will receive all messages on the topics they subscribe to, and producers are responsible for defining the message categories that subscribers subscribe to.This is a basic conceptual model, and in practical applications, the structure will be more complex.For example, in order to support high concurrency and horizontal scaling, the topics need to be partitioned.The same topic will have multiple producers,  [...]
+In a **topic-based** system, messages are published on topics or channels. Consumers will receive all messages on the topics they subscribe to, and producers are responsible for defining the message categories that subscribers subscribe to. This is a basic conceptual model, and in practical applications, the structure will be more complex. For example, in order to support high concurrency and horizontal scaling, the topics need to be partitioned. The same topic will have multiple produce [...]
 
 
 
@@ -77,7 +77,7 @@ The **Broker** that stores message topics is the proxy server for the actual dep
 :::info
 
 - Consumer mainly has two consumption modes, namely **broadcast mode** and **cluster mode** (the most commonly used cluster mode is shown in the figure).
-- Consumer instances in the same Consumer Group are load balancing consumption.As shown in the figure, ConsumerGroupA subscribes to TopicA and TopicA corresponds to 3 queues.Then Consumer1 in GroupA consumes messages from MessageQueue 0 and MessageQueue 1, and Consumer2 consumes messages from MessageQueue2.
+- Consumer instances in the same Consumer Group are load balancing consumption. As shown in the figure, ConsumerGroupA subscribes to TopicA and TopicA corresponds to 3 queues. Then Consumer1 in GroupA consumes messages from MessageQueue 0 and MessageQueue 1, and Consumer2 consumes messages from MessageQueue2.
 
 :::
 
@@ -91,7 +91,7 @@ The main Apache RocketMQ components are Producers, Consumers, NameServers, and B
 
 ###  **Producer**
 
-A  producer serves as a data source that optimizes, writes, and publishes messages to one or more  topics.Producers load balance data among brokers through MessageQueue.It supports fail-fast and retries during sending messages.
+A  producer serves as a data source that optimizes, writes, and publishes messages to one or more  topics. Producers load balance data among brokers through MessageQueue. It supports fail-fast and retries during sending messages.
 
 ### **Consumer**
 
@@ -106,29 +106,29 @@ Consumers read data by reading messages from the topics to which they subscribe.
 NameServer is a simple Topic routing registry that supports dynamic registration and discovery of Topic and Broker.
 
 Mainly includes two functions：
-- **Broker management**:The NameServer accepts the registration information of the Broker cluster and saves it as the basic data of the routing information.And it provides a heartbeat detection mechanism to check whether the Broker is still alive.
-- **Routing Information Management**:Each NameServer will hold the entire routing information about the Broker cluster and queue information for client queries.The Producer and Consumer can know the routing information of the entire Broker cluster through the NameServer, so as to produce and consume messages.
+- **Broker management**:The NameServer accepts the registration information of the Broker cluster and saves it as the basic data of the routing information. And it provides a heartbeat detection mechanism to check whether the Broker is still alive.
+- **Routing Information Management**:Each NameServer will hold the entire routing information about the Broker cluster and queue information for client queries. The Producer and Consumer can know the routing information of the entire Broker cluster through the NameServer, so as to produce and consume messages.
 
-NameServer usually has multiple instances deployed, and each instance does not communicate with each other.Broker registers its own routing information with each NameServer, so each NameServer instance saves a complete routing information.The client can still obtain routing information from other NameServers, When a NameServer goes offline for some reason.
+NameServer usually has multiple instances deployed, and each instance does not communicate with each other. Broker registers its own routing information with each NameServer, so each NameServer instance saves a complete routing information. The client can still obtain routing information from other NameServers, When a NameServer goes offline for some reason.
 
 ##  Broker
 
 Broker is mainly responsible for message storage, delivery and query, as well as service high availability guarantee.
 
-NameServer is stateless, so it can be deployed in clusters without any information synchronization between nodes.Compared with nameserver, broker is more complicated.
+NameServer is stateless, so it can be deployed in clusters without any information synchronization between nodes. Compared with nameserver, broker is more complicated.
 
 In the Master-Slave architecture, the Broker is divided into Master and Slave.
 A Master can correspond to multiple Slaves, but a Slave can only correspond to one Master.
-The correspondence between Master and Slave is defined by specifying the same BrokerName and different BrokerId. A BrokerId of 0 means Master, and non-0 means Slave.Master can also deploy multiple.
+The correspondence between Master and Slave is defined by specifying the same BrokerName and different BrokerId. A BrokerId of 0 means Master, and non-0 means Slave. Master can also deploy multiple.
 
 
 
 :::note RocketMQ Architecture Summary
 
 - Each **Broker** establishes long-term connections with all nodes in the **NameServer** cluster, and regularly registers Topic information to all NameServers.
-- **Producer** establishes a persistent connection with one of the nodes in the **NameServer** cluster, regularly obtains topic routing information from NameServer, establishes a persistent connection to the Master that provides Topic services, and regularly sends a heartbeat to the Master.Producers are completely stateless.
+- **Producer** establishes a persistent connection with one of the nodes in the **NameServer** cluster, regularly obtains topic routing information from NameServer, establishes a persistent connection to the Master that provides Topic services, and regularly sends a heartbeat to the Master. Producers are completely stateless.
 - **Consumer** establishes a persistent connection to one of the nodes in the **NameServer** cluster
-，regularly obtains Topic routing information from NameServer,establishes long connections to Master and Slave that provide Topic services, and send heartbeats to Master and Slave regularly.Consumer subscribes to topic from Master or Slave.
+，regularly obtains Topic routing information from NameServer, establishes long connections to Master and Slave that provide Topic services, and send heartbeats to Master and Slave regularly. Consumer subscribes to topic from Master or Slave.
 
 :::