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 <[email protected]>
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.
:::
