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 3bdc563e Organize English-Version Documents (#180)
3bdc563e is described below
commit 3bdc563e804176ad53655fb1cd7c7c6bc1c50a9c
Author: Jack Tsai <[email protected]>
AuthorDate: Tue Aug 16 10:37:41 2022 +0800
Organize English-Version Documents (#180)
Co-authored-by: tsaitsung-han.tht <[email protected]>
---
.../01-Introduction/03whatis.md" | 157 -------------------
.../02-Producer/04concept1.md" | 97 ------------
.../02-Producer/05message1.md" | 174 ---------------------
.../02-Producer/06message2.md" | 75 ---------
.../02-Producer/07message3.md" | 45 ------
.../02-Producer/08message4.md" | 29 ----
.../02-producer/09message5.md" | 150 ------------------
.../01-\344\273\213\347\273\215/02quickstart.md" | 60 ++++---
.../01-\344\273\213\347\273\215/03whatis.md" | 152 +++++++++++++++++-
.../04concept1.md" | 90 ++++++-----
.../05message1.md" | 98 ++++++------
.../06message2.md" | 31 ++--
.../07message3.md" | 12 +-
.../08message4.md" | 8 +-
.../09message5.md" | 61 ++++----
15 files changed, 332 insertions(+), 907 deletions(-)
diff --git "a/docs/09-\350\213\261\346\226\207/01-Introduction/03whatis.md"
"b/docs/09-\350\213\261\346\226\207/01-Introduction/03whatis.md"
deleted file mode 100644
index a36fc6c9..00000000
--- "a/docs/09-\350\213\261\346\226\207/01-Introduction/03whatis.md"
+++ /dev/null
@@ -1,157 +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 Concepts
-
-<Tabs>
- <TabItem value="Producer" label="生产者" default>
- The producer is responsible for producing messages, and the business system
is generally responsible for producing messages. A producer sends messages
generated in the business application system to the broker server.RocketMQ
provides a variety of sending methods, synchronous sending, asynchronous
sending, sequential sending, and one-way sending.
-
-learn more ➡️ [Producer](/docs/生产者/04concept1)
- </TabItem>
- <TabItem value="Consumer" label="消费者">
- Aims to consume messages, which are generally responsible by the backend
system (asynchronous consumption). A message consumer pulls messages from the
Broker server and serves them to the application. From the perspective of user
applications, two consumption methods are provided: pull consumption and push
consumption.
-
-learn more ➡️ [Consumer](/docs/消费者/11concept2)
-
- </TabItem>
- <TabItem value="Topic" label="主题">
- RocketMQ's fundamental unit of event organization is called Topic. Each
Topic contains several messages, and each message can only belong to one topic.
-
-learn more ➡️ [basic concept](/docs/生产者/04concept1)
-
- </TabItem>
-</Tabs>
-
-:::
-
-
-## RocketMQ's message model, a simple Pub/Sub model
-
-
-
-
-
-
-
-:::note Basic Messaging System Model
-
- The figure above is an extended message model, including **two Producers**,
**two Topics**, and **two sets of Consumers**.
-
-:::
-
-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, [...]
-
-
-
-
-## RocketMQ extended message model
-
-
-
-
-
-
-
-:::note Extended message model
-
-The above picture is an extended message model, including **two producers**,
**two topics**, and **two sets of consumers Comsumer**.
-
-The **Broker** that stores message topics is the proxy server for the actual
deployment process.
-:::
-
-- for**Horizontal scaling**, RocketMQ partitions Topic through **MessageQueue**
-
-- for**Concurrent consumption**, the concept of Consumer Group came into being.
-
-:::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.
-
-:::
-
-## RocketMQ Architecture
-
-How do Producer and Consumer find the addresses of Topic and Broker? How are
messages sent and received?
-
-
-
-The main Apache RocketMQ components are Producers, Consumers, NameServers, and
Brokers:
-
-### **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.
-
-### **Consumer**
-
-Consumers read data by reading messages from the topics to which they
subscribe.
-
-- Supports message consumption in two modes: push and pull.
-- Supports **cluster mode** and broadcast mode consumption
-- Provide real-time message subscription mechanism
-
-## **NameServer**
-
-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.
-
-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.
-
-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.
-
-
-
-:::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.
-- **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.
-
-:::
-
-## RocketMQ Workflow
-
-### 1. Start the RocketMQ NameServer
-
-The NameServer listens to the port and waits for the connection of the Broker,
Producer, and Consumer after startup.
-
-### 2. Start the RocketMQ Broker
-
-The Broker maintains long connections with all NameServers, gets current
Broker information, and stores all Topic information after startup. After
successful registration, a mapping relationship will be built between Topic and
Broker in the NameServer cluster.
-
-### 3. Create a topic
-
-The Broker should be specified before creating a Topic, or automatically
create one while sending messages.
-
-### 4. Write messages to the topic
-
-The Producer starts by establishing a long-term connection with one device of
the NameServer clusters, obtains the Broker information where the current topic
exists from the NameServer, polls to select a queue from the queue list, and
establishes a long-term connection where the queue is located. This enables the
Producer to send messages to the Broker.
-
-### 5. Read messages from the topic
-
-The Consumer establishes a long-term connection with one of the NameServers,
obtains which brokers the current subscription topic exists on, and then
directly establishes a connection channel with the Broker, and then starts to
consume messages.
-
-
diff --git "a/docs/09-\350\213\261\346\226\207/02-Producer/04concept1.md"
"b/docs/09-\350\213\261\346\226\207/02-Producer/04concept1.md"
deleted file mode 100644
index c03cdf93..00000000
--- "a/docs/09-\350\213\261\346\226\207/02-Producer/04concept1.md"
+++ /dev/null
@@ -1,97 +0,0 @@
-# Core Concept
-
-Introduction to the basic concepts of the Producer section, including
**Message, Tag, Keys, Message Queue and Producer**.
-
-## Message
-
-The composition of RocketMQ messages is simple, as shown in the following
figure.
-
-- **topic**: the topic of the message to be sent.
-- **body**: the storage content of the message.
-- **properties**: the message properties.
-- **transactionId**: the id of the transaction message.
-
-:::tip
-- Tag: Whether it is RocketMQ Tag filtering or delayed message feature, etc.,
the capabilities of Properties will be used.
-
-- Keys: The server will create a hash index based on Keys. You are able to
query messages based on Topic and Keys in the Console after setting. Please
ensure that the keys (e.g. order number, product ID, etc) are unique since it
is a hash index.
- :::
-
-<center>
-<img src="../picture/Message.png" width="500"></img>
-</center>
-
-The properties that could be set in the Message include:
-
-
-| Field | Default | Required | Description
|
-| :------------: | ------- | --------
|--------------------------------------------------------------------------------------------------------------|
-| Topic | null | Required | Topic name to which the message
belongs. |
-| Body | null | Required | Message body.
|
-| Tags | null | Optional | Message tag, which is for filtering in
server. Currently only one per message is supported. |
-| Keys | null | Optional | Keywords representing the message.
|
-| Flag | 0 | Optional | Completely set by the client, RocketMQ
does not intervene. |
-| DelayTimeLevel | 0 | Optional | Message delay level, 0 means no delay,
greater than 0 will delay a specific time before it will be consumed. |
-| WaitStoreMsgOK | true | Optional | Indicates whether the response is
returned after the server is flushed. |
-
-## Tag
-
-Topic and Tag are both business identifiers for classification. The difference
is that Topic is a first-level classification, and Tag can be regarded as a
second-level classification. Tag can be used to achieve message filtering in
Topic.
-
-:::tip
-- Topic：Message topic, which categorizes different business messages through
Topic.
-- Tag：Message tag, which is used to further distinguish the message under a
topic. This is the property that the message carries when it is sent from the
producer.
- :::
-
-
-
-
-The relationship between Topic and Tag is shown in the following figure.
-
-
-
-### When to use Topic/Tag?
-
-It can be determined from the following aspects:
-
-- Whether the message types are consistent: Such as simple messages,
transaction messages, timed (delayed) messages, and ordered messages. Different
message types use different Topics, which cannot be distinguished by Tags.
-
-- Whether the business is related: The messages that are not directly related,
such as Taobao messages and JD Logistics messages, are distinguished by
different Topics. In contrast, the messages belonging to Tmall transaction,
including electrical order, women's clothing order, cosmetics order messages
could be distinguished by Tags.
-
-- Whether the message priority is identical：For example, as logistics message,
Hema must be delivered within an hour, Tmall supermarket must be delivered
within 24 hours, and Taobao logistics is relatively slower. Messages with
different priorities could be distinguished by different topics.
-
-- Whether the message volume is equivalent: Some business messages are small
in volume but require high real-time performance. If they stay under the same
Topic with trillion-level messages, it may be "starve" due to the long waiting
time. Therefore, it is necessary to split messages of different volumes into
different Topics.
-
-In general, you can choose to create multiple Topics, or create multiple Tags
under a single Topic for message classification. There is no necessary
connection between messages under different Topics, and Tags are used to
distinguish interrelated messages under the same topic, such as the complete
sets and subsets, or the sequence of processes.
-
-## Keys
-
-Each message of Apache RocketMQ can place a unique identification —— Keys
field at the business level, which is convenient for locating the problem of
message loss in the future. The broker side will create an index (hash index)
for each message so that the client can query the content of the message
through Topic and Key, as well as who consumes the message. Since it is a hash
index, please make sure that the key is as unique as possible to avoid
potential hash collisions.
-
-```java
- // Order Id
- String orderId = "20034568923546";
- message.setKeys(orderId);
-```
-
-## Message Queue
-
-To support high concurrency and horizontal expansion, Topic needs to be
partitioned, which is called Message Queue in RocketMQ. A Topic may have
multiple queues and may be distributed on different Brokers.
-
-
-
-In general, a message will only exist in one of the queues under a Topic if it
is not sent repeatedly (e.g., a client resents messages since the server does
not respond). The message will be stored in a queue according to the principle
of FIFO (First In, First Out). Each message will have its own position, and
each queue will calculate the total number of the messages, which is called
MaxOffset; the position corresponding to the starting point of the queue is
called MinOffset. Message Qu [...]
-
-## Producer
-
-The Producer is the sender of the message. Apache RocketMQ owns rich message
types and is able to support various scenarios.
-
-For instance, an order will be closed due to the payment timeout in an
e-commerce transaction, so a delayed message should be sent when the order is
created. This message will be delivered to the Consumer after 30 minutes. After
receiving the message, the Consumer needs to determine whether the
corresponding order has been paid. If the payment is not completed, the order
will be closed. If the payment has been completed, then ignore it.
-
-In the e-commerce scenario, the business requires the messages of the same
order to be kept in strict sequence, the ordered messages could therefore be
applied.
-
-In the log processing scenario, a relatively large sending delay is
acceptable, but it has a high throughput requirement. It is expected that
millions of logs need to be processed within a second. In this case, the batch
messages could be sent.
-
-In the bank deduction scenarios, in order to keep the upstream deduction
operation consistent with the downstream SMS notification, transaction messages
could be utilized.
-
-The next section will introduce the sending of various types of messages.
\ No newline at end of file
diff --git "a/docs/09-\350\213\261\346\226\207/02-Producer/05message1.md"
"b/docs/09-\350\213\261\346\226\207/02-Producer/05message1.md"
deleted file mode 100644
index 8758f50e..00000000
--- "a/docs/09-\350\213\261\346\226\207/02-Producer/05message1.md"
+++ /dev/null
@@ -1,174 +0,0 @@
-# Simple Message Sending
-
-## 1.Creating Topic in Cluster
-
-RocketMQ cluster is enabled by default with **autoCreateTopicEnable**
configuration, which will automatically create Topics for the sent messages. If
autoCreateTopicEnable is not enabled, you can also use the RocketMQ Admin tool
to create the target 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]
-```
-
-After executing the command above, 8 queues are created on the Broker machine
with the Topic named TopicTest.
-
-## 2.Adding Client-Side Dependency
-
-Firstly, add RocketMQ client-side dependency to JAVA application.
-
-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.Message Sending
-
-Apache RocketMQ sends messages in three ways: **synchronous, asynchronous, and
one-way**. The first two message types are reliable since the response will be
returned from the server regardless of whether their messages are successfully
sent or not.
-
-### 3.1 Synchronous Sending
-
-Synchronous Sending is a communication method in which the message sender
sends a message and will send the next message only after receiving a
synchronous response from the server. Reliable synchronous transmission is
widely used in various scenarios, such as important notification messages,
short message notifications, etc.
-
-
-
-
-The entire code for synchronous sending is as follows:
-1. **Create a Producer**. Create a DefaultMQProducer in advance. The Producer
should contain the name of the Producer group, which is a collection of
Producer, they would send the same type of messages with identical logic.
-2. **Set the address of NameServer**. Apache RocketMQ is able to set the
address of the NameServer (described in the client configuration) in many ways.
The following example is set by calling the producer's setNamesrvAddr() method
in the code, separated by a semicolon if there is more than one NameServer,
such as "127.0.0.2:9876;127.0.0.3:9876".
-3. **Build the message**. Set the topic, tag, body, and so on. The tag can be
understood as a label to categorize the message, and RocketMQ can filter the
tag on the Consumer side.
-4. **Call the send() method to send the message**. Ultimately, the send()
method will return a SendResult. The SendResut contains the actual send status
including SEND_OK (send success), FLUSH_DISK_TIMEOUT (disk flush timeout),
FLUSH_SLAVE_TIMEOUT (sync to slave timeout), SLAVE_NOT_AVAILABLE (slave can not
be used), and an exception is thrown if it fails.
-
-``` javascript {16,15}
-public class SyncProducer {
- public static void main(String[] args) throws Exception {
- // Initialize a producer and set the Producer group name
- DefaultMQProducer producer = new
DefaultMQProducer("please_rename_unique_group_name"); //（1）
- // Set the address of NameServer
- producer.setNamesrvAddr("localhost:9876"); //（2）
- // Start Producer
- producer.start();
- for (int i = 0; i < 100; i++) {
- // Create a message and set the topic, tag, body and so on. The tag can
be understood as a label to categorize the message, and RocketMQ can filter the
tag on the consumer side.
- Message msg = new Message("TopicTest" /* Topic */,
- "TagA" /* Tag */,
- ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /*
Message body */
- ); //（3）
- // Use the producer to send and wait for the result of sending
synchronously
- SendResult sendResult = producer.send(msg); //（4）
- System.out.printf("%s%n", sendResult);
- }
- // Close the producer once it is no longer in use
- producer.shutdown();
- }
-}
-```
-
-
-
-### 3.2 Asynchronous Sending
-
-
-
-
-Asynchronous sending is a sending method in which the sender sends messages
continuously without waiting for the server to return a response.
-Asynchronous sending requires the implementation of the **Asynchronous Send
Callback Interface** (SendCallback).
-:::note
-Asynchronous sending requires the implementation of the **Asynchronous
SendCallback Interface**.
-:::
-After sending a message, the sender does not need to wait for a response from
the server to send the next message. The sender receives the response from the
server through the callback interface and handles the result. Asynchronous
sending is generally used in time-consuming and response time sensitive
business scenarios. For example, the video upload notifies the start of
transcoding service, and notifies the push of transcoding result after
transcoding is completed.
-
-The following is the sample code.
-
-``` javascript {16,17}
-public class AsyncProducer {
- public static void main(String[] args) throws Exception {
- // Initialize a producer and set the Producer group name
- DefaultMQProducer producer = new
DefaultMQProducer("please_rename_unique_group_name");
- // Set the address of NameServer
- producer.setNamesrvAddr("localhost:9876");
- // Start Producer
- producer.start();
- producer.setRetryTimesWhenSendAsyncFailed(0);
- for (int i = 0; i < 100; i++) {
- final int index = i;
- // Create a message and set the topic, tag, body and so on. The tag can
be understood as a label to categorize the message, and RocketMQ can filter the
tag on the consumer side.
- Message msg = new Message("TopicTest",
- "TagA",
- "Hello world".getBytes(RemotingHelper.DEFAULT_CHARSET));
- // Send a message asynchronously, the result is returned to the client
by 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();
- }
- });
- }
- // Close the producer once it is no longer in use
- producer.shutdown();
- }
-}
-```
-
-:::note
-The only difference between asynchronous and synchronous sending methods is
the parameters for calling the sending interface. Asynchronous sending does not
wait for the return of send() method, instead, it will carry the SendCallback
implementation. The SendCallback interface has two methods (onSuccess and
onException), indicating that the message is sent successfully or failed.
-:::
-
-### 3.3 One-Way Sending
-
-
-
-
-
-The sender is only responsible for sending the message and does not wait for
the server to return a response and no callback function is triggered, in other
words, it only sends the request and does not wait for the answer. The process
of sending messages in this way is very short, usually in the microsecond
level. It is suitable for some scenarios where the time consumption is very
short, but the reliability requirement is not high, such as log collection.
-
-``` javascript {16}
-public class OnewayProducer {
- public static void main(String[] args) throws Exception{
- // Initialize a producer and set the Producer group name
- DefaultMQProducer producer = new
DefaultMQProducer("please_rename_unique_group_name");
- // Set the address of NameServer
- producer.setNamesrvAddr("localhost:9876");
- // Start Producer
- producer.start();
- for (int i = 0; i < 100; i++) {
- // Create a message and set the topic, tag, body and so on. The tag can
be understood as a label to categorize the message, and RocketMQ can filter the
tag on the consumer side.
- Message msg = new Message("TopicTest" /* Topic */,
- "TagA" /* Tag */,
- ("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /*
Message body */
- );
- // Since there is no request-answer processing when sending messages in
the oneway method, if there is a message sending failure, data will be lost
because there is no retry. If data cannot be lost, it is recommended to use the
reliable synchronous or reliable asynchronous sending method.
- producer.sendOneway(msg);
- }
- // Close the producer once it is no longer in use
- producer.shutdown();
- }
-}
-```
-
-One-way mode will call the sendOneway() method, which does not wait or process
the returned result.
diff --git "a/docs/09-\350\213\261\346\226\207/02-Producer/06message2.md"
"b/docs/09-\350\213\261\346\226\207/02-Producer/06message2.md"
deleted file mode 100644
index 571775b8..00000000
--- "a/docs/09-\350\213\261\346\226\207/02-Producer/06message2.md"
+++ /dev/null
@@ -1,75 +0,0 @@
-# Ordered Message Sending
-
-## Ordered Message Introduction
-Ordered messages have strict requirements on the order in which they are sent
and consumed.
-
-For a given Topic, messages are published and consumed strictly on a
first-in-first-out (FIFO) basis, i.e., messages published first will be
consumed first. Furthermore, as shown in the following figure, partitioned
ordered messages are supported in Apache RocketMQ. The messages can be
partitioned according to a certain criterion (e.g., ShardingKey). Messages with
the same ShardingKey are assigned to the identical queue and consumed in order.
-
-
-Ordered messages are also used in a wide range of application scenarios, such
as the example of creating orders, the same order generation, payment, and
shipment should be executed sequentially. In the case of simple messages, the
messages of Order A may be polled and sent to different queues. The messages of
different queues will not be able to maintain order. In contrast, ordered
messages are sent by routing the sequence of messages with the same ShardingKey
(same order number) to a lo [...]
-
-## Ordered Message Sample Code
-
-The ordered message sample code is as follows:
-
-```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();
- }
- }
-}
-```
-
-The difference here is mainly the call to the ```SendResult send(Message msg,
MessageQueueSelector selector, Object arg)``` method, where
MessageQueueSelector is the queue selector and arg is a Object in Java that can
be passed in as a sorting criterion for sending partitioned messages.
-
-:::tip
-MessageQueueSelector interface is as follows:
-
-```jsx
-public interface MessageQueueSelector {
- MessageQueue select(final List<MessageQueue> mqs, final Message msg, final
Object arg);
-}
-```
-
-In the interface, mqs is the queue, msg is the message, and arg is the object
passed in, the queue that message are sent to will be returned. In the above
example, the orderId is used as the partitioning criterion, and the remainder
of all queues is used to send messages with the same orderId to the same queue.
-:::
-
-
-## Consistency of Ordered Messages
-
-If a Broker drops out, does the total number of queues change at that point?
-
-If a change occurs, messages with the same ShardingKey will be sent to a
different queue causing disorder. If no change occurs, messages will be sent to
the queue of the offline Broker, which is bound to fail. Therefore, Apache
RocketMQ provides two modes, to guarantee strict order over availability,
create Topic by specifying the ```-o``` parameter (--order) to be true, which
represents ordered messages:
-
-```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]
-```
-
-Secondly, make sure that the configuration ```orderMessageEnable``` and
```returnOrderTopicConfigToBroker``` in the NameServer must be true. If either
of the above conditions is not met, availability is guaranteed rather than
strict order.
diff --git "a/docs/09-\350\213\261\346\226\207/02-Producer/07message3.md"
"b/docs/09-\350\213\261\346\226\207/02-Producer/07message3.md"
deleted file mode 100644
index 416701b3..00000000
--- "a/docs/09-\350\213\261\346\226\207/02-Producer/07message3.md"
+++ /dev/null
@@ -1,45 +0,0 @@
-# Delayed Message Sending
-
-The delayed message sending means that when a message is sent to Apache
RocketMQ, instead of delivering the message immediately, it would be delivered
to the Consumer for consumption after delaying a certain period of time.
-
-Apache RocketMQ supports a total of 18 levels of delayed delivery, the details
are as follows:
-
-| delay level | delay time | delay level | delay time |
-|-------------------|------|-------------------|-------|
-| 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 |
-
-The sample code for the delayed message sending is as follows:
-
-```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
-The most important thing is to set the delay level for the message. In the
sample code above, the delay level is set to 3, which means that after the
sender sends the message, it would take 10s for the consumer to receive it.
-:::
\ No newline at end of file
diff --git "a/docs/09-\350\213\261\346\226\207/02-Producer/08message4.md"
"b/docs/09-\350\213\261\346\226\207/02-Producer/08message4.md"
deleted file mode 100644
index b938c29f..00000000
--- "a/docs/09-\350\213\261\346\226\207/02-Producer/08message4.md"
+++ /dev/null
@@ -1,29 +0,0 @@
-# Batch Message Sending
-
-In the case of certain requirements on throughput, Apache RocketMQ can send
messages after grouping them into batches. The approach is able to increase
throughput and decrease the times of API and network calls.
-
-
-
-```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
-The call here is simple, where it packages the message as `Collection<Message>
msgs` and passes it into the method as a parameter. There are two things to
note here. First of all, the size of the batch message cannot exceed 1 MiB,
otherwise, it needs to be split. Secondly, the message topic within the same
batch must be identical.
-:::
\ No newline at end of file
diff --git "a/docs/09-\350\213\261\346\226\207/02-producer/09message5.md"
"b/docs/09-\350\213\261\346\226\207/02-producer/09message5.md"
deleted file mode 100644
index 8efcd903..00000000
--- "a/docs/09-\350\213\261\346\226\207/02-producer/09message5.md"
+++ /dev/null
@@ -1,150 +0,0 @@
-# Transactional Message Sending
-
-## Introduction
-
-In some scenarios where there is a strong need for data consistency, Apache
RocketMQ transactional messages can be used to ensure consistency of upstream
and downstream data.
-
-
-
-Transactional messages are send in two phases. At first, a half message will
be delivered, which refers to a message is successfully sent to the MQ server,
but the server did not receive the second acknowledgement of the message from
the Producer, then the message will be marked as “temporarily undeliverable”
state.
-
-The local transaction will be executed if the message is sent successfully,
and a half message status (commit or rollback) will be delivered to the Broker
depending on the local transaction results.
-
-If the second acknowledgement of a transactional message is lost due to
network flashback, Producer restart, etc., the Broker will find the message
which is in "half message" state for a long time, and take the initiative to
check the transaction status of the message (Commit or Rollback) from the
Producer. Therefore, the downstream will receive the message if the local
transaction is executed successfully, otherwise it will not. This ultimately
ensures the consistency of the upstream an [...]
-
-The detailed execute flow of the transactional message is shown in the
following diagram:
-
-
-
-## Transactional Message Sending Procedure
-
-1. The Producer sends the half message to the `RocketMQ Broker`.
-2. After the `RocketMQ Broker` persists the message successfully, it returns
an Ack to the Producer confirming that the message was sent successfully and it
is a half message.
-3. The Producer starts executing the local transaction.
-4. The Producer submits a second acknowledgement (Commit or Rollback) to the
server based on the result of the local transaction, and the server receives
the acknowledgment and processes the logic as follows.
- - If the second acknowledgement result is Commit: the server marks the half
message as deliverable and delivers it to the Consumer.
- - If the second acknowledgement result is Rollback: the server will
rollback the transaction and will not deliver the half message to the Consumer.
-
-4. In the special case of network disconnection or the Producer restarts, if
the server does not receive the second acknowledgment result from the Producer,
or the second acknowledgment result received by the server is Unknown, the
server will initiate a rollback message to a Producer after a fixed time.
-
-The procedure of the transaction status check are as follows.
-1. After receiving the transaction status check request, the Producer needs to
verify the final result of the local transaction of the corresponding message.
-2. The producer submits the second acknowledgment again based on the final
result of the local transaction, and the server side will still processes the
half message according to step 4.
-
-## Example
-
-```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;
- }
- }
-}
-```
-
-Transactional messages are no longer sent by DefaultMQProducer, but using
`TransactionMQProducer`. The above sample sets the thread pool for the
transactional message check, if not, one will be generated by default. The most
important thing is to implement the `TransactionListener` interface and pass
`TransactionMQProducer` into it.
-
-:::note
-
-The TransactionListener interface is defined as follows:
-
-````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` is the method that executes the local transaction
after the half message has been sent successfully. After executing the local
transaction, the following three states can be returned in this method.
-
-- `LocalTransactionState.COMMIT_MESSAGE`: the transaction is committed,
allowing the consumer to consume the message.
-- `LocalTransactionState.ROLLBACK_MESSAGE`: the transaction is rolled back,
and the message will be discarded without being allowed to be consumed.
-- `LocalTransactionState.UNKNOW`: temporarily unable to determine the state.
After waiting for a fixed time, the Broker send the transaction status check
message back to the producer.
-
-`checkLocalTransaction` is a method to check the transaction state on the
Broker side because the second acknowledgement is not received. Transaction
status check rule: After the execution of the local transaction is completed,
if the local transaction returns LocalTransactionState.UNKNOW status to the
Broker, or the Producer exits causing no status returned from the Producer.
Then the Broker will initiate a transaction status check message to the
Producer, and it will check again at reg [...]
-
-:::caution
-
-It is important to note that the ProducerGroupName of a transactional message
cannot be set arbitrarily. Transactional messages have a transaction status
check mechanism. If the original Producer is found to have crashed and
collapsed, the Broker will contact other Producer instances within the same
Producer group to check the local transaction execution and Commit or Rollback
half messages.
-
-:::
diff --git
"a/i18n/en/docusaurus-plugin-content-docs/current/01-\344\273\213\347\273\215/02quickstart.md"
"b/i18n/en/docusaurus-plugin-content-docs/current/01-\344\273\213\347\273\215/02quickstart.md"
index f02b6670..d1e88bf5 100644
---
"a/i18n/en/docusaurus-plugin-content-docs/current/01-\344\273\213\347\273\215/02quickstart.md"
+++
"b/i18n/en/docusaurus-plugin-content-docs/current/01-\344\273\213\347\273\215/02quickstart.md"
@@ -1,25 +1,25 @@
-# 快速开始
+# Quickstart
-这一节介绍如何快速部署一个单 Master RocketMQ 集群，并完成简单的消息收发。
+This section will introduce the method of quickly building and deploying a
single-Master RocketMQ cluster to complete simple message sending and receiving.
-:::tip 系统要求
+:::tip System Requirement
-1. 64位操作系统，推荐 Linux/Unix/macOS
-2. 64位 JDK 1.8+
+1. 64-bit OS，Linux/Unix/macOS is recommended
+2. 64-bit JDK 1.8+
:::
-## 1.下载安装Apache RocketMQ
+## 1. Get Apache RocketMQ
-:::tip RocketMQ下载
+:::tip Download 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's installation is divided into two types: binary and source. Click
[here](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-source-release.zip)
to download Apache RocketMQ 4.9.4 source package, or download the binary
package from
[here](https://www.apache.org/dyn/closer.cgi?path=rocketmq/4.9.4/rocketmq-all-4.9.4-bin-release.zip).
The binary package can be run directly since it has been compiled, and the
source package needs to be compiled and run.
:::
-这里以在Linux环境下利用社区4.9.4的源码包为例，介绍RocketMQ安装过程。
+The following instruction takes the application of RocketMQ 4.9.4 source
package in Linux environment as an example in order to introduce the
installation process of RocketMQ.
-解压4.9.4的源码包并编译构建二进制可执行文件
+Extract the source package of RocketMQ 4.9.4, then compile and build the
binary executables:
```shell
> unzip rocketmq-all-4.9.4-source-release.zip
@@ -27,55 +27,54 @@ RocketMQ 的安装包分为两种，二进制包和源码包。点击[这里](ht
> mvn -Prelease-all -DskipTests clean install -U
> cd distribution/target/rocketmq-4.9.4/rocketmq-4.9.4
```
-## 2. 启动NameServer
-安装完RocketMQ包后，我们启动NameServer
+## 2. Start the NameServer
+
+After the installation of RocketMQ, start the NameServer:
```shell
-### 启动namesrv
+### Start the namesrv service
$ nohup sh bin/mqnamesrv &
-### 验证namesrv是否启动成功
+### Verify that the namesrv service is started successfully
$ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
```
:::info
-我们可以在namesrv.log 中看到 **'The Name Server boot success..'，** 表示NameServer 已成功启动。
+Once we see **'The Name Server boot success..'** from namesrv.log, it means
the NameServer has been started successfully.
:::
+## 3. Start the Broker
-
-## 3. 启动Broker
-
-NameServer成功启动后，我们启动Broker
+Start the Broker after the NameServer has been launched:
```shell
-### 先启动broker
+### Start the broker service
$ nohup sh bin/mqbroker -n localhost:9876 &
-### 验证broker是否启动成功, 比如, broker的ip是192.168.1.2 然后名字是broker-a
-$ tail -f ~/logs/rocketmqlogs/Broker.log
+### Verify that the broker service is started successfully, for example, the
broker's ip is 192.168.1.2 and the name is 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
已成功启动。
+Once we see “The broker[brokerName,ip:port] boot success..” from broker.log,
it means the Broker has been started successfully.
:::
:::note
-至此，一个单Master的RocketMQ集群已经部署起来了，我们可以利用脚本进行简单的消息收发。
+Thus far, a single-Master RocketMQ cluster has been deployed, and we are able
to send and receive simple messages by scripts.
:::
-## 4. 消息收发
+## 4. Send and Receive Messages
-在进行消息收发之前，我们需要告诉客户端NameServer的地址，RocketMQ有多种方式在客户端中设置NameServer地址，这里我们利用环境变量`NAMESRV_ADDR`
+Before sending and receiving messages, the clients need to identify the
address of the NameServer. RocketMQ has multiple ways to set the NameServer
address on the client side. One of them is to modify the environment variable
`NAMESRV_ADDR` :
``` shell
> export NAMESRV_ADDR=localhost:9876
@@ -86,11 +85,9 @@ The broker[broker-a,192.169.1.2:10911] boot success...
ConsumeMessageThread_%d Receive New Messages: [MessageExt...
```
+## 5. Shutdown Servers
-
-## 5. 关闭服务器
-
-完成实验后，我们可以通过以下方式关闭服务
+After finishing the practice, we could shut down the service by the following
commands:
```shell
> sh bin/mqshutdown broker
@@ -100,5 +97,4 @@ Send shutdown request to mqbroker(36695) OK
> sh bin/mqshutdown namesrv
The mqnamesrv(36664) is running...
Send shutdown request to mqnamesrv(36664) OK
-```
-
+```
\ No newline at end of file
diff --git
"a/i18n/en/docusaurus-plugin-content-docs/current/01-\344\273\213\347\273\215/03whatis.md"
"b/i18n/en/docusaurus-plugin-content-docs/current/01-\344\273\213\347\273\215/03whatis.md"
index 027de58e..b4163fe3 100644
---
"a/i18n/en/docusaurus-plugin-content-docs/current/01-\344\273\213\347\273\215/03whatis.md"
+++
"b/i18n/en/docusaurus-plugin-content-docs/current/01-\344\273\213\347\273\215/03whatis.md"
@@ -4,4 +4,154 @@ 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.
\ No newline at end of file
+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 Concepts
+
+<Tabs>
+ <TabItem value="Producer" label="生产者" default>
+ The producer is responsible for producing messages, and the business system
is generally responsible for producing messages. A producer sends messages
generated in the business application system to the broker server.RocketMQ
provides a variety of sending methods, synchronous sending, asynchronous
sending, sequential sending, and one-way sending.
+
+learn more ➡️ [Producer](/docs/生产者/04concept1)
+ </TabItem>
+ <TabItem value="Consumer" label="消费者">
+ Aims to consume messages, which are generally responsible by the backend
system (asynchronous consumption). A message consumer pulls messages from the
Broker server and serves them to the application. From the perspective of user
applications, two consumption methods are provided: pull consumption and push
consumption.
+
+learn more ➡️ [Consumer](/docs/消费者/11concept2)
+
+ </TabItem>
+ <TabItem value="Topic" label="主题">
+ RocketMQ's fundamental unit of event organization is called Topic. Each
Topic contains several messages, and each message can only belong to one topic.
+
+learn more ➡️ [basic concept](/docs/生产者/04concept1)
+
+ </TabItem>
+</Tabs>
+
+:::
+
+
+## RocketMQ's message model, a simple Pub/Sub model
+
+
+
+
+
+
+
+:::note Basic Messaging System Model
+
+ The figure above is an extended message model, including **two Producers**,
**two Topics**, and **two sets of Consumers**.
+
+:::
+
+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, [...]
+
+
+
+
+## RocketMQ extended message model
+
+
+
+
+
+
+
+:::note Extended message model
+
+The above picture is an extended message model, including **two producers**,
**two topics**, and **two sets of consumers Comsumer**.
+
+The **Broker** that stores message topics is the proxy server for the actual
deployment process.
+:::
+
+- for**Horizontal scaling**, RocketMQ partitions Topic through **MessageQueue**
+
+- for**Concurrent consumption**, the concept of Consumer Group came into being.
+
+:::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.
+
+:::
+
+## RocketMQ Architecture
+
+How do Producer and Consumer find the addresses of Topic and Broker? How are
messages sent and received?
+
+
+
+The main Apache RocketMQ components are Producers, Consumers, NameServers, and
Brokers:
+
+### **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.
+
+### **Consumer**
+
+Consumers read data by reading messages from the topics to which they
subscribe.
+
+- Supports message consumption in two modes: push and pull.
+- Supports **cluster mode** and broadcast mode consumption
+- Provide real-time message subscription mechanism
+
+## **NameServer**
+
+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.
+
+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.
+
+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.
+
+
+
+:::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.
+- **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.
+
+:::
+
+## RocketMQ Workflow
+
+### 1. Start the RocketMQ NameServer
+
+The NameServer listens to the port and waits for the connection of the Broker,
Producer, and Consumer after startup.
+
+### 2. Start the RocketMQ Broker
+
+The Broker maintains long connections with all NameServers, gets current
Broker information, and stores all Topic information after startup. After
successful registration, a mapping relationship will be built between Topic and
Broker in the NameServer cluster.
+
+### 3. Create a topic
+
+The Broker should be specified before creating a Topic, or automatically
create one while sending messages.
+
+### 4. Write messages to the topic
+
+The Producer starts by establishing a long-term connection with one device of
the NameServer clusters, obtains the Broker information where the current topic
exists from the NameServer, polls to select a queue from the queue list, and
establishes a long-term connection where the queue is located. This enables the
Producer to send messages to the Broker.
+
+### 5. Read messages from the topic
+
+The Consumer establishes a long-term connection with one of the NameServers,
obtains which brokers the current subscription topic exists on, and then
directly establishes a connection channel with the Broker, and then starts to
consume messages.
+
+
diff --git
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/04concept1.md"
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/04concept1.md"
index 1bb5f75c..c03cdf93 100644
---
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/04concept1.md"
+++
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/04concept1.md"
@@ -1,87 +1,97 @@
-# 基本概念
+# Core Concept
-在生产者一章的基本概念包括**消息，Tag，Keys，队列和生产者**的介绍。
+Introduction to the basic concepts of the Producer section, including
**Message, Tag, Keys, Message Queue and Producer**.
-## 消息
+## Message
-RocketMQ 消息构成非常简单，如下图所示。
+The composition of RocketMQ messages is simple, as shown in the following
figure.
-- **topic**，表示要发送的消息的主题。
-- **body** 表示消息的存储内容
-- **properties** 表示消息属性
-- **transactionId** 会在事务消息中使用。
+- **topic**: the topic of the message to be sent.
+- **body**: the storage content of the message.
+- **properties**: the message properties.
+- **transactionId**: the id of the transaction message.
:::tip
-- Tag: 不管是 RocketMQ 的 Tag 过滤还是延迟消息等都会利用 Properties 消息属性的能力
+- Tag: Whether it is RocketMQ Tag filtering or delayed message feature, etc.,
the capabilities of Properties will be used.
-- Keys: 服务器会根据 keys 创建哈希索引，设置后，可以在 Console 系统根据 Topic、Keys
来查询消息，由于是哈希索引，请尽可能保证 key 唯一，例如订单号，商品 Id 等。
-:::
+- Keys: The server will create a hash index based on Keys. You are able to
query messages based on Topic and Keys in the Console after setting. Please
ensure that the keys (e.g. order number, product ID, etc) are unique since it
is a hash index.
+ :::
<center>
<img src="../picture/Message.png" width="500"></img>
</center>
-Message 可以设置的属性值包括：
+The properties that could be set in the Message include:
-| 字段名 | 默认值 | 必要性 | 说明
|
-| :------------: | -------- | ------------- | ------------- |
-| Topic | null | 必填 | 消息所属 topic 的名称
|
-| Body | null | 必填 | 消息体
|
-| Tags | null | 选填 | 消息标签，方便服务器过滤使用。目前只支持每个消息设置一个
|
-| Keys | null | 选填 | 代表这条消息的业务关键词 |
-| Flag | 0 | 选填 | 完全由应用来设置，RocketMQ 不做干预
|
-| DelayTimeLevel | 0 | 选填 | 消息延时级别，0 表示不延时，大于 0 会延时特定的时间才会被消费
|
-| WaitStoreMsgOK | true | 选填 | 表示消息是否在服务器落盘后才返回应答。
|
+| Field | Default | Required | Description
|
+| :------------: | ------- | --------
|--------------------------------------------------------------------------------------------------------------|
+| Topic | null | Required | Topic name to which the message
belongs. |
+| Body | null | Required | Message body.
|
+| Tags | null | Optional | Message tag, which is for filtering in
server. Currently only one per message is supported. |
+| Keys | null | Optional | Keywords representing the message.
|
+| Flag | 0 | Optional | Completely set by the client, RocketMQ
does not intervene. |
+| DelayTimeLevel | 0 | Optional | Message delay level, 0 means no delay,
greater than 0 will delay a specific time before it will be consumed. |
+| WaitStoreMsgOK | true | Optional | Indicates whether the response is
returned after the server is flushed. |
## Tag
-Topic 与 Tag 都是业务上用来归类的标识，区别在于 Topic 是一级分类，而 Tag 可以理解为是二级分类。使用 Tag 可以实现对 Topic
中的消息进行过滤。
+Topic and Tag are both business identifiers for classification. The difference
is that Topic is a first-level classification, and Tag can be regarded as a
second-level classification. Tag can be used to achieve message filtering in
Topic.
:::tip
-- Topic：消息主题，通过 Topic 对不同的业务消息进行分类。
-- Tag：消息标签，用来进一步区分某个 Topic 下的消息分类，消息从生产者发出即带上的属性。
-:::
+- Topic：Message topic, which categorizes different business messages through
Topic.
+- Tag：Message tag, which is used to further distinguish the message under a
topic. This is the property that the message carries when it is sent from the
producer.
+ :::
-Topic 和 Tag 的关系如下图所示。
+The relationship between Topic and Tag is shown in the following figure.
-### 什么时候该用 Topic，什么时候该用 Tag？
+### When to use Topic/Tag?
-可以从以下几个方面进行判断：
+It can be determined from the following aspects:
-- 消息类型是否一致：如普通消息、事务消息、定时（延时）消息、顺序消息，不同的消息类型使用不同的 Topic，无法通过 Tag 进行区分。
+- Whether the message types are consistent: Such as simple messages,
transaction messages, timed (delayed) messages, and ordered messages. Different
message types use different Topics, which cannot be distinguished by Tags.
-- 业务是否相关联：没有直接关联的消息，如淘宝交易消息，京东物流消息使用不同的 Topic
进行区分；而同样是天猫交易消息，电器类订单、女装类订单、化妆品类订单的消息可以用 Tag 进行区分。
+- Whether the business is related: The messages that are not directly related,
such as Taobao messages and JD Logistics messages, are distinguished by
different Topics. In contrast, the messages belonging to Tmall transaction,
including electrical order, women's clothing order, cosmetics order messages
could be distinguished by Tags.
-- 消息优先级是否一致：如同样是物流消息，盒马必须小时内送达，天猫超市 24 小时内送达，淘宝物流则相对会慢一些，不同优先级的消息用不同的 Topic
进行区分。
+- Whether the message priority is identical：For example, as logistics message,
Hema must be delivered within an hour, Tmall supermarket must be delivered
within 24 hours, and Taobao logistics is relatively slower. Messages with
different priorities could be distinguished by different topics.
-- 消息量级是否相当：有些业务消息虽然量小但是实时性要求高，如果跟某些万亿量级的消息使用同一个
Topic，则有可能会因为过长的等待时间而“饿死”，此时需要将不同量级的消息进行拆分，使用不同的 Topic。
+- Whether the message volume is equivalent: Some business messages are small
in volume but require high real-time performance. If they stay under the same
Topic with trillion-level messages, it may be "starve" due to the long waiting
time. Therefore, it is necessary to split messages of different volumes into
different Topics.
-总的来说，针对消息分类，您可以选择创建多个 Topic，或者在同一个 Topic 下创建多个 Tag。但通常情况下，不同的 Topic
之间的消息没有必然的联系，而 Tag 则用来区分同一个 Topic 下相互关联的消息，例如全集和子集的关系、流程先后的关系。
+In general, you can choose to create multiple Topics, or create multiple Tags
under a single Topic for message classification. There is no necessary
connection between messages under different Topics, and Tags are used to
distinguish interrelated messages under the same topic, such as the complete
sets and subsets, or the sequence of processes.
## Keys
-Apache RocketMQ 每个消息可以在业务层面的设置唯一标识码 keys 字段，方便将来定位消息丢失问题。 Broker
端会为每个消息创建索引（哈希索引），应用可以通过 topic、key 来查询这条消息内容，以及消息被谁消费。由于是哈希索引，请务必保证 key
尽可能唯一，这样可以避免潜在的哈希冲突。
+Each message of Apache RocketMQ can place a unique identification —— Keys
field at the business level, which is convenient for locating the problem of
message loss in the future. The broker side will create an index (hash index)
for each message so that the client can query the content of the message
through Topic and Key, as well as who consumes the message. Since it is a hash
index, please make sure that the key is as unique as possible to avoid
potential hash collisions.
```java
- // 订单Id
+ // Order Id
String orderId = "20034568923546";
message.setKeys(orderId);
```
-## 队列
+## Message Queue
-为了支持高并发和水平扩展，需要对 Topic 进行分区，在 RocketMQ 中这被称为队列，一个 Topic 可能有多个队列，并且可能分布在不同的
Broker 上。
+To support high concurrency and horizontal expansion, Topic needs to be
partitioned, which is called Message Queue in RocketMQ. A Topic may have
multiple queues and may be distributed on different Brokers.
-一般来说一条消息，如果没有重复发送（比如因为服务端没有响应而进行重试），则只会存在在 Topic
的其中一个队列中，消息在队列中按照先进先出的原则存储，每条消息会有自己的位点，每个队列会统计当前消息的总条数，这个称为最大位点
MaxOffset；队列的起始位置对应的位置叫做起始位点 MinOffset。队列可以提升消息发送和消费的并发度。
+In general, a message will only exist in one of the queues under a Topic if it
is not sent repeatedly (e.g., a client resents messages since the server does
not respond). The message will be stored in a queue according to the principle
of FIFO (First In, First Out). Each message will have its own position, and
each queue will calculate the total number of the messages, which is called
MaxOffset; the position corresponding to the starting point of the queue is
called MinOffset. Message Qu [...]
-## 生产者
+## Producer
-生产者（Producer）就是消息的发送者，Apache RocketMQ
拥有丰富的消息类型，可以支持不用的应用场景，在不同的场景中，需要使用不同的消息进行发送。比如在电商交易中超时未支付关闭订单的场景，在订单创建时会发送一条延时消息。这条消息将会在
30
分钟以后投递给消费者，消费者收到此消息后需要判断对应的订单是否已完成支付。如支付未完成，则关闭订单。如已完成支付则忽略，此时就需要用到延迟消息；电商场景中，业务上要求同一订单的消息保持严格顺序，此时就要用到顺序消息。在日志处理场景中，可以接受的比较大的发送延迟，但对吞吐量的要求很高，希望每秒能处理百万条日志，此时可以使用批量消息。在银行扣款的场景中，要保持上游的扣款操作和下游的短信通知保持一致，此时就要使用事务消息，下一节将会介绍各种类型
消息的发送。
+The Producer is the sender of the message. Apache RocketMQ owns rich message
types and is able to support various scenarios.
+
+For instance, an order will be closed due to the payment timeout in an
e-commerce transaction, so a delayed message should be sent when the order is
created. This message will be delivered to the Consumer after 30 minutes. After
receiving the message, the Consumer needs to determine whether the
corresponding order has been paid. If the payment is not completed, the order
will be closed. If the payment has been completed, then ignore it.
+
+In the e-commerce scenario, the business requires the messages of the same
order to be kept in strict sequence, the ordered messages could therefore be
applied.
+
+In the log processing scenario, a relatively large sending delay is
acceptable, but it has a high throughput requirement. It is expected that
millions of logs need to be processed within a second. In this case, the batch
messages could be sent.
+
+In the bank deduction scenarios, in order to keep the upstream deduction
operation consistent with the downstream SMS notification, transaction messages
could be utilized.
+
+The next section will introduce the sending of various types of messages.
\ No newline at end of file
diff --git
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/05message1.md"
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/05message1.md"
index 336e1010..e5dd6f93 100644
---
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/05message1.md"
+++
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/05message1.md"
@@ -1,8 +1,8 @@
-# 普通消息发送
+# Simple Message Sending
-## 1.向集群中创建 Topic
+## 1.Creating Topic in Cluster
-RocketMQ集群是默认开启了 **autoCreateTopicEnable** 配置，会自动为发送的消息创建 Topic，如果
autoCreateTopicEnable 没有开启，也可以利用 RocketMQ Admin 工具创建目标 Topic 。
+RocketMQ cluster is enabled by default with **autoCreateTopicEnable**
configuration, which will automatically create Topics for the sent messages. If
autoCreateTopicEnable is not enabled, you can also use the RocketMQ Admin tool
to create the target Topic.
```shell
> sh bin/mqadmin updateTopic -c DefaultCluster -t TopicTest -n 127.0.0.1:9876
@@ -10,11 +10,11 @@ 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。
+After executing the command above, 8 queues are created on the Broker machine
with the Topic named TopicTest.
-## 2.添加客户端依赖
+## 2.Adding Client-Side Dependency
-首先需要在 JAVA 程序中添加 RocketMQ 的客户端依赖。
+Firstly, add RocketMQ client-side dependency to JAVA application.
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
@@ -41,44 +41,43 @@ compile 'org.apache.rocketmq:rocketmq-client:4.9.4'
</Tabs>
-## 3.消息发送
+## 3.Message Sending
-Apache RocketMQ可用于以三种方式发送消息：**同步、异步和单向传输**。前两种消息类型是可靠的，因为无论它们是否成功发送都有响应。
+Apache RocketMQ sends messages in three ways: **synchronous, asynchronous, and
one-way**. The first two message types are reliable since the response will be
returned from the server regardless of whether their messages are successfully
sent or not.
-### 3.1 同步发送
+### 3.1 Synchronous Sending
-同步发送是指消息发送方发出一条消息后，会在收到服务端同步响应之后才发下一条消息的通讯方式，可靠的同步传输被广泛应用于各种场景，如重要的通知消息、短消息通知等。
+Synchronous Sending is a communication method in which the message sender
sends a message and will send the next message only after receiving a
synchronous response from the server. Reliable synchronous transmission is
widely used in various scenarios, such as important notification messages,
short message notifications, etc.
-<center>
-<img src="../picture/同步发送.png" width="500"></img>
-</center>
+
+
+The entire code for synchronous sending is as follows:
+1. **Create a Producer**. Create a DefaultMQProducer in advance. The Producer
should contain the name of the Producer group, which is a collection of
Producer, they would send the same type of messages with identical logic.
+2. **Set the address of NameServer**. Apache RocketMQ is able to set the
address of the NameServer (described in the client configuration) in many ways.
The following example is set by calling the producer's setNamesrvAddr() method
in the code, separated by a semicolon if there is more than one NameServer,
such as "127.0.0.2:9876;127.0.0.3:9876".
+3. **Build the message**. Set the topic, tag, body, and so on. The tag can be
understood as a label to categorize the message, and RocketMQ can filter the
tag on the Consumer side.
+4. **Call the send() method to send the message**. Ultimately, the send()
method will return a SendResult. The SendResut contains the actual send status
including SEND_OK (send success), FLUSH_DISK_TIMEOUT (disk flush timeout),
FLUSH_SLAVE_TIMEOUT (sync to slave timeout), SLAVE_NOT_AVAILABLE (slave can not
be used), and an exception is thrown if it fails.
-同步发送的整个代码流程如下：
-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
+ // Initialize a producer and set the Producer group name
DefaultMQProducer producer = new
DefaultMQProducer("please_rename_unique_group_name"); //（1）
- // 设置NameServer地址
+ // Set the address of NameServer
producer.setNamesrvAddr("localhost:9876"); //（2）
- // 启动producer
+ // Start Producer
producer.start();
for (int i = 0; i < 100; i++) {
- // 创建一条消息，并指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤
+ // Create a message and set the topic, tag, body and so on. The tag can
be understood as a label to categorize the message, and RocketMQ can filter the
tag on the consumer side.
Message msg = new Message("TopicTest" /* Topic */,
"TagA" /* Tag */,
("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /*
Message body */
); //（3）
- // 利用producer进行发送，并同步等待发送结果
+ // Use the producer to send and wait for the result of sending
synchronously
SendResult sendResult = producer.send(msg); //（4）
System.out.printf("%s%n", sendResult);
}
- // 一旦producer不再使用，关闭producer
+ // Close the producer once it is no longer in use
producer.shutdown();
}
}
@@ -86,38 +85,37 @@ public class SyncProducer {
-### 3.2 异步发送
+### 3.2 Asynchronous Sending
-<center>
-<img src="../picture/异步发送.png" width="500"></img>
-</center>
+
-异步发送是指发送方发出一条消息后，不等服务端返回响应，接着发送下一条消息的通讯方式。异步发送需要实现**异步发送回调接口**（SendCallback）。
+Asynchronous sending is a sending method in which the sender sends messages
continuously without waiting for the server to return a response.
+Asynchronous sending requires the implementation of the **Asynchronous Send
Callback Interface** (SendCallback).
:::note
-异步发送需要实现**异步发送回调接口**（SendCallback）。
+Asynchronous sending requires the implementation of the **Asynchronous
SendCallback Interface**.
:::
-消息发送方在发送了一条消息后，不需要等待服务端响应即可发送第二条消息，发送方通过回调接口接收服务端响应，并处理响应结果。异步发送一般用于链路耗时较长，对响应时间较为敏感的业务场景。例如，视频上传后通知启动转码服务，转码完成后通知推送转码结果等。
+After sending a message, the sender does not need to wait for a response from
the server to send the next message. The sender receives the response from the
server through the callback interface and handles the result. Asynchronous
sending is generally used in time-consuming and response time sensitive
business scenarios. For example, the video upload notifies the start of
transcoding service, and notifies the push of transcoding result after
transcoding is completed.
-如下是示例代码。
+The following is the sample code.
``` javascript {16,17}
public class AsyncProducer {
public static void main(String[] args) throws Exception {
- // 初始化一个producer并设置Producer group name
+ // Initialize a producer and set the Producer group name
DefaultMQProducer producer = new
DefaultMQProducer("please_rename_unique_group_name");
- // 设置NameServer地址
+ // Set the address of NameServer
producer.setNamesrvAddr("localhost:9876");
- // 启动producer
+ // Start Producer
producer.start();
producer.setRetryTimesWhenSendAsyncFailed(0);
for (int i = 0; i < 100; i++) {
final int index = i;
- // 创建一条消息，并指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤
+ // Create a message and set the topic, tag, body and so on. The tag can
be understood as a label to categorize the message, and RocketMQ can filter the
tag on the consumer side.
Message msg = new Message("TopicTest",
"TagA",
"Hello world".getBytes(RemotingHelper.DEFAULT_CHARSET));
- // 异步发送消息, 发送结果通过callback返回给客户端
+ // Send a message asynchronously, the result is returned to the client
by callback
producer.send(msg, new SendCallback() {
@Override
public void onSuccess(SendResult sendResult) {
@@ -131,48 +129,46 @@ public class AsyncProducer {
}
});
}
- // 一旦producer不再使用，关闭producer
+ // Close the producer once it is no longer in use
producer.shutdown();
}
}
```
:::note
-异步发送与同步发送代码唯一区别在于调用send接口的参数不同，异步发送不会等待发送返回，取而代之的是send方法需要传入 SendCallback
的实现，SendCallback 接口主要有onSuccess 和 onException 两个方法，表示消息发送成功和消息发送失败。
+The only difference between asynchronous and synchronous sending methods is
the parameters for calling the sending interface. Asynchronous sending does not
wait for the return of send() method, instead, it will carry the SendCallback
implementation. The SendCallback interface has two methods (onSuccess and
onException), indicating that the message is sent successfully or failed.
:::
-### 3.3 单向模式发送
+### 3.3 One-Way Sending
-<center>
-<img src="../picture/Oneway发送.png" width="500"></img>
-</center>
+
-发送方只负责发送消息，不等待服务端返回响应且没有回调函数触发，即只发送请求不等待应答。此方式发送消息的过程耗时非常短，一般在微秒级别。适用于某些耗时非常短，但对可靠性要求并不高的场景，例如日志收集。
+The sender is only responsible for sending the message and does not wait for
the server to return a response and no callback function is triggered, in other
words, it only sends the request and does not wait for the answer. The process
of sending messages in this way is very short, usually in the microsecond
level. It is suitable for some scenarios where the time consumption is very
short, but the reliability requirement is not high, such as log collection.
``` javascript {16}
public class OnewayProducer {
public static void main(String[] args) throws Exception{
- // 初始化一个producer并设置Producer group name
+ // Initialize a producer and set the Producer group name
DefaultMQProducer producer = new
DefaultMQProducer("please_rename_unique_group_name");
- // 设置NameServer地址
+ // Set the address of NameServer
producer.setNamesrvAddr("localhost:9876");
- // 启动producer
+ // Start Producer
producer.start();
for (int i = 0; i < 100; i++) {
- // 创建一条消息，并指定topic、tag、body等信息，tag可以理解成标签，对消息进行再归类，RocketMQ可以在消费端对tag进行过滤
+ // Create a message and set the topic, tag, body and so on. The tag can
be understood as a label to categorize the message, and RocketMQ can filter the
tag on the consumer side.
Message msg = new Message("TopicTest" /* Topic */,
"TagA" /* Tag */,
("Hello RocketMQ " + i).getBytes(RemotingHelper.DEFAULT_CHARSET) /*
Message body */
);
- //
由于在oneway方式发送消息时没有请求应答处理，如果出现消息发送失败，则会因为没有重试而导致数据丢失。若数据不可丢，建议选用可靠同步或可靠异步发送方式。
+ // Since there is no request-answer processing when sending messages in
the oneway method, if there is a message sending failure, data will be lost
because there is no retry. If data cannot be lost, it is recommended to use the
reliable synchronous or reliable asynchronous sending method.
producer.sendOneway(msg);
}
- // 一旦producer不再使用，关闭producer
+ // Close the producer once it is no longer in use
producer.shutdown();
}
}
```
-单向模式调用sendOneway，不会对返回结果有任何等待和处理。
+One-way mode will call the sendOneway() method, which does not wait or process
the returned result.
diff --git
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/06message2.md"
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/06message2.md"
index a89b26bc..41e7f8eb 100644
---
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/06message2.md"
+++
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/06message2.md"
@@ -1,17 +1,16 @@
-# 顺序消息发送
+# Ordered Message Sending
-## 顺序消息介绍
-顺序消息是一种对消息发送和消费顺序有严格要求的消息。
+## Ordered Message Introduction
+Ordered messages have strict requirements on the order in which they are sent
and consumed.
-对于一个指定的Topic，消息严格按照先进先出（FIFO）的原则进行消息发布和消费，即先发布的消息先消费，后发布的消息后消费。在 Apache
RocketMQ
中支持分区顺序消息，如下图所示。我们可以按照某一个标准对消息进行分区（比如图中的ShardingKey），同一个ShardingKey的消息会被分配到同一个队列中，并按照顺序被消费。
+For a given Topic, messages are published and consumed strictly on a
first-in-first-out (FIFO) basis, i.e., messages published first will be
consumed first. Furthermore, as shown in the following figure, partitioned
ordered messages are supported in Apache RocketMQ. The messages can be
partitioned according to a certain criterion (e.g., ShardingKey). Messages with
the same ShardingKey are assigned to the identical queue and consumed in order.
+
-
+Ordered messages are also used in a wide range of application scenarios, such
as the example of creating orders, the same order generation, payment, and
shipment should be executed sequentially. In the case of simple messages, the
messages of Order A may be polled and sent to different queues. The messages of
different queues will not be able to maintain order. In contrast, ordered
messages are sent by routing the sequence of messages with the same ShardingKey
(same order number) to a lo [...]
-顺序消息的应用场景也非常广泛，比如在创建订单的例子中，需要保证同一个订单的生成、付款和发货，这三个操作被顺序执行。如果是普通消息，订单A的消息可能会被轮询发送到不同的队列中，不同队列的消息将无法保持顺序，而顺序消息发送时将ShardingKey相同（同一订单号）的消息序路由到一个逻辑队列中。
+## Ordered Message Sample Code
-## 顺序消息示例代码
-
-顺序消息的代码如下所示：
+The ordered message sample code is as follows:
```jsx {13}
public class Producer {
@@ -46,10 +45,10 @@ public class Producer {
}
```
-这里的区别主要是调用了```SendResult send(Message msg, MessageQueueSelector selector,
Object arg)```方法，MessageQueueSelector 是队列选择器，arg 是一个 Java Object
对象，可以传入作为消息发送分区的分类标准。
+The difference here is mainly the call to the ```SendResult send(Message msg,
MessageQueueSelector selector, Object arg)``` method, where
MessageQueueSelector is the queue selector and arg is a Object in Java that can
be passed in as a sorting criterion for sending partitioned messages.
:::tip
-MessageQueueSelector的接口如下：
+MessageQueueSelector interface is as follows:
```jsx
public interface MessageQueueSelector {
@@ -57,15 +56,15 @@ public interface MessageQueueSelector {
}
```
-其中 mqs
是可以发送的队列，msg是消息，arg是上述send接口中传入的Object对象，返回的是该消息需要发送到的队列。上述例子里，是以orderId作为分区分类标准，对所有队列个数取余，来对将相同orderId的消息发送到同一个队列中。
+In the interface, mqs is the queue, msg is the message, and arg is the object
passed in, the queue that message are sent to will be returned. In the above
example, the orderId is used as the partitioning criterion, and the remainder
of all queues is used to send messages with the same orderId to the same queue.
:::
-## 顺序消息的一致性
+## Consistency of Ordered Messages
-如果一个Broker掉线，那么此时队列总数是否会发化？
+If a Broker drops out, does the total number of queues change at that point?
-如果发生变化，那么同一个 ShardingKey
的消息就会发送到不同的队列上，造成乱序。如果不发生变化，那消息将会发送到掉线Broker的队列上，必然是失败的。因此 Apache RocketMQ
提供了两种模式，如果要保证严格顺序而不是可用性，创建 Topic 是要指定 ```-o``` 参数（--order）为true，表示顺序消息:
+If a change occurs, messages with the same ShardingKey will be sent to a
different queue causing disorder. If no change occurs, messages will be sent to
the queue of the offline Broker, which is bound to fail. Therefore, Apache
RocketMQ provides two modes, to guarantee strict order over availability,
create Topic by specifying the ```-o``` parameter (--order) to be true, which
represents ordered messages:
```shell {1}
> sh bin/mqadmin updateTopic -c DefaultCluster -t TopicTest -o true -n
> 127.0.0.1:9876
@@ -73,4 +72,4 @@ 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。如果上述任意一个条件不满足，则是保证可用性而不是严格顺序。
+Secondly, make sure that the configuration ```orderMessageEnable``` and
```returnOrderTopicConfigToBroker``` in the NameServer must be true. If either
of the above conditions is not met, availability is guaranteed rather than
strict order.
diff --git
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/07message3.md"
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/07message3.md"
index 0daf28dd..416701b3 100644
---
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/07message3.md"
+++
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/07message3.md"
@@ -1,10 +1,10 @@
-# 延迟消息发送
+# Delayed Message Sending
-延时消息是指消息发送到Apache RocketMQ后，并不期望立马投递这条消息，而是延迟一定时间后才投递到Consumer进行消费。
+The delayed message sending means that when a message is sent to Apache
RocketMQ, instead of delivering the message immediately, it would be delivered
to the Consumer for consumption after delaying a certain period of time.
-Apache RocketMQ 一共支持18个等级的延迟投递，具体时间如下：
+Apache RocketMQ supports a total of 18 levels of delayed delivery, the details
are as follows:
-| 投递等级（delay level） | 延迟时间 | 投递等级（delay level） | 延迟时间 |
+| delay level | delay time | delay level | delay time |
|-------------------|------|-------------------|-------|
| 1 | 1s | 10 | 6min |
| 2 | 5s | 11 | 7min |
@@ -16,7 +16,7 @@ Apache RocketMQ 一共支持18个等级的延迟投递，具体时间如下：
| 8 | 4min | 17 | 1h |
| 9 | 5min | 18 | 2h |
-延迟消息的示例代码如下：
+The sample code for the delayed message sending is as follows:
```javascript {10,11}
public class ScheduledMessageProducer {
@@ -41,5 +41,5 @@ public class ScheduledMessageProducer {
}
```
:::tip
-这里最重要的是message中设置延迟等级，例子中设置的等级是3，也就是发送者发送后，10s后消费者才能收到消息。
+The most important thing is to set the delay level for the message. In the
sample code above, the delay level is set to 3, which means that after the
sender sends the message, it would take 10s for the consumer to receive it.
:::
\ No newline at end of file
diff --git
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/08message4.md"
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/08message4.md"
index 04892f74..1a3e4d3f 100644
---
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/08message4.md"
+++
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/08message4.md"
@@ -1,8 +1,8 @@
-# 批量消息发送
+# Batch Message Sending
-在对吞吐率有一定要求的情况下，Apache RocketMQ可以将一些消息聚成一批以后进行发送，可以增加吞吐率，并减少API和网络调用次数。
+In the case of certain requirements on throughput, Apache RocketMQ can send
messages after grouping them into batches. The approach is able to increase
throughput and decrease the times of API and network calls.
-
+
```javascript {10,11,12,13}
public class SimpleBatchProducer {
@@ -25,5 +25,5 @@ public class SimpleBatchProducer {
```
:::note
-这里调用非常简单，将消息打包成 Collection`<Message>` msgs传入方法中即可，需要注意的是批量消息的大小不能超过
1MiB（否则需要自行分割），其次同一批 batch 中 topic 必须相同。
+The call here is simple, where it packages the message as `Collection<Message>
msgs` and passes it into the method as a parameter. There are two things to
note here. First of all, the size of the batch message cannot exceed 1 MiB,
otherwise, it needs to be split. Secondly, the message topic within the same
batch must be identical.
:::
\ No newline at end of file
diff --git
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/09message5.md"
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/09message5.md"
index e85ce461..5d8e92fa 100644
---
"a/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/09message5.md"
+++
"b/i18n/en/docusaurus-plugin-content-docs/current/02-\347\224\237\344\272\247\350\200\205/09message5.md"
@@ -1,36 +1,37 @@
-# 事务消息发送
+# Transactional Message Sending
-## 事务消息介绍
+## Introduction
-在一些对数据一致性有强需求的场景，可以用 Apache RocketMQ 事务消息来解决，从而保证上下游数据的一致性。
+In some scenarios where there is a strong need for data consistency, Apache
RocketMQ transactional messages can be used to ensure consistency of upstream
and downstream data.
-
+
-事务消息发送分为两个阶段。第一阶段会发送一个**半事务消息**，半事务消息是指暂不能投递的消息，生产者已经成功地将消息发送到了
Broker，但是Broker
未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，如果发送成功则执行本地事务，并根据本地事务执行成功与否，向 Broker
半事务消息状态（commit或者rollback），半事务消息只有 commit
状态才会真正向下游投递。如果由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，Broker
端会通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit或是Rollback）。这样最终保证了本地事务执行成功，下游就能收到消息，本地事务执行失败，下游就收不到消息。总而保证了上下游数据的一致性。
+Transactional messages are send in two phases. At first, a half message will
be delivered, which refers to a message is successfully sent to the MQ server,
but the server did not receive the second acknowledgement of the message from
the Producer, then the message will be marked as “temporarily undeliverable”
state.
-整个事务消息的详细交互流程如下图所示：
+The local transaction will be executed if the message is sent successfully,
and a half message status (commit or rollback) will be delivered to the Broker
depending on the local transaction results.
-
+If the second acknowledgement of a transactional message is lost due to
network flashback, Producer restart, etc., the Broker will find the message
which is in "half message" state for a long time, and take the initiative to
check the transaction status of the message (Commit or Rollback) from the
Producer. Therefore, the downstream will receive the message if the local
transaction is executed successfully, otherwise it will not. This ultimately
ensures the consistency of the upstream an [...]
-## 事务消息步骤
+The detailed execute flow of the transactional message is shown in the
following diagram:
-事务消息**发送**步骤如下：
+
-1. 生产者将半事务消息发送至 `RocketMQ Broker`。
-2. `RocketMQ Broker` 将消息持久化成功之后，向生产者返回 Ack 确认消息已经发送成功，此时消息为半事务消息。
-3. 生产者开始执行本地事务逻辑。
-4. 生产者根据本地事务执行结果向服务端提交二次确认结果（Commit或是Rollback），服务端收到确认结果后处理逻辑如下：
-- 二次确认结果为Commit：服务端将半事务消息标记为可投递，并投递给消费者。
-- 二次确认结果为Rollback：服务端将回滚事务，不会将半事务消息投递给消费者。
-5.
在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为Unknown未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。
+## Transactional Message Sending Procedure
-事务消息**回查**步骤如下：
-1. 生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
-2. 生产者根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行处理。
+1. The Producer sends the half message to the `RocketMQ Broker`.
+2. After the `RocketMQ Broker` persists the message successfully, it returns
an Ack to the Producer confirming that the message was sent successfully and it
is a half message.
+3. The Producer starts executing the local transaction.
+4. The Producer submits a second acknowledgement (Commit or Rollback) to the
server based on the result of the local transaction, and the server receives
the acknowledgment and processes the logic as follows.
+ - If the second acknowledgement result is Commit: the server marks the half
message as deliverable and delivers it to the Consumer.
+ - If the second acknowledgement result is Rollback: the server will
rollback the transaction and will not deliver the half message to the Consumer.
-## 示例代码
+4. In the special case of network disconnection or the Producer restarts, if
the server does not receive the second acknowledgment result from the Producer,
or the second acknowledgment result received by the server is Unknown, the
server will initiate a rollback message to a Producer after a fixed time.
-示例代码如下：
+The procedure of the transaction status check are as follows.
+1. After receiving the transaction status check request, the Producer needs to
verify the final result of the local transaction of the corresponding message.
+2. The producer submits the second acknowledgment again based on the final
result of the local transaction, and the server side will still processes the
half message according to step 4.
+
+## Example
```javascript {39}
public class TransactionProducer {
@@ -105,11 +106,11 @@ public class TransactionProducer {
}
```
-事务消息的发送不再使用 DefaultMQProducer，而是使用 `TransactionMQProducer`
进行发送，上述的例子中设置了事务回查的线程池，如果不设置也会默认生成一个，最重要的是需要实现 `TransactionListener` 接口，并传入
`TransactionMQProducer`。
+Transactional messages are no longer sent by DefaultMQProducer, but using
`TransactionMQProducer`. The above sample sets the thread pool for the
transactional message check, if not, one will be generated by default. The most
important thing is to implement the `TransactionListener` interface and pass
`TransactionMQProducer` into it.
:::note
-TransactionListener接口的定义如下：
+The TransactionListener interface is defined as follows:
````javascript {9,18}
public interface TransactionListener {
@@ -134,16 +135,16 @@ public interface TransactionListener {
````
:::
-`executeLocalTransaction` 是半事务消息发送成功后，执行本地事务的方法，具体执行完本地事务后，可以在该方法中返回以下三种状态：
+`executeLocalTransaction` is the method that executes the local transaction
after the half message has been sent successfully. After executing the local
transaction, the following three states can be returned in this method.
-- `LocalTransactionState.COMMIT_MESSAGE`：提交事务，允许消费者消费该消息
-- `LocalTransactionState.ROLLBACK_MESSAGE`：回滚事务，消息将被丢弃不允许消费。
-- `LocalTransactionState.UNKNOW`：暂时无法判断状态，等待固定时间以后Broker端根据回查规则向生产者进行消息回查。
+- `LocalTransactionState.COMMIT_MESSAGE`: the transaction is committed,
allowing the consumer to consume the message.
+- `LocalTransactionState.ROLLBACK_MESSAGE`: the transaction is rolled back,
and the message will be discarded without being allowed to be consumed.
+- `LocalTransactionState.UNKNOW`: temporarily unable to determine the state.
After waiting for a fixed time, the Broker send the transaction status check
message back to the producer.
-`checkLocalTransaction`是由于二次确认消息没有收到，Broker端回查事务状态的方法。回查规则：本地事务执行完成后，若Broker端收到的本地事务返回状态为LocalTransactionState.UNKNOW，或生产者应用退出导致本地事务未提交任何状态。则Broker端会向消息生产者发起事务回查，第一次回查后仍未获取到事务状态，则之后每隔一段时间会再次回查。
+`checkLocalTransaction` is a method to check the transaction state on the
Broker side because the second acknowledgement is not received. Transaction
status check rule: After the execution of the local transaction is completed,
if the local transaction returns LocalTransactionState.UNKNOW status to the
Broker, or the Producer exits causing no status returned from the Producer.
Then the Broker will initiate a transaction status check message to the
Producer, and it will check again at reg [...]
:::caution
-此外，需要注意的是事务消息的生产组名称
ProducerGroupName不能随意设置。事务消息有回查机制，回查时Broker端如果发现原始生产者已经崩溃崩溃，则会联系同一生产者组的其他生产者实例回查本地事务执行情况以Commit或Rollback半事务消息。
+It is important to note that the ProducerGroupName of a transactional message
cannot be set arbitrarily. Transactional messages have a transaction status
check mechanism. If the original Producer is found to have crashed and
collapsed, the Broker will contact other Producer instances within the same
Producer group to check the local transaction execution and Commit or Rollback
half messages.
-:::
\ No newline at end of file
+:::
