Fixed intermixing of punctuation marks in English documents (#5086)

docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_设计.md

@@ -2,7 +2,7 @@
 | 时间 | 主要内容 | 作者 |
 | --- | --- | --- |
 | 2021-11-01 | 初稿，包括背景、目标、SOT定义与持久化、SOT生命周期、SOT的使用、API逻辑修改、问题与风险 | dongeforever |
-| 2021-11-15 | 修改 LogicQueue 的定义，不要引入新字段，完全复用旧的MessageQueue; RemappingStaticTopic时，不要迁移『位点』『幂等数据』等，而是采用Double-Check-Read 的机制| dongforever |
+| 2021-11-15 | 修改 LogicQueue 的定义，不要引入新字段，完全复用旧的MessageQueue；RemappingStaticTopic时，不要迁移『位点』『幂等数据』等，而是采用Double-Check-Read 的机制| dongforever |
 | 2021-12-01 | 更新问题与风险，增加关于一致性、OutOfRange、拉取中断的详细说明| dongforever |
 | 2021-12-03 | 增加代码走读的说明| dongforever |
 | 2021-12-10 | 引入Scope概念，保留『多集群动态零耦合』的集群设计模型 | dongforever |

docs/en/Configuration_TLS.md

@@ -34,7 +34,7 @@ openssl pkcs8 -topk8 -v1 PBE-SHA1-RC4-128 -in client_rsa.key -out client.key
 ```
 
 ## 2 Create tls.properties
-Create tls.properties，correctly configure the path and password of the generated certificates.
+Create tls.properties, correctly configure the path and password of the generated certificates.
 
 ```properties
 # The flag to determine whether use test mode when initialize TLS context. default is true
@@ -76,13 +76,13 @@ Edit the configuration file under the rocketmq/bin path to make tls.properties c
 The value of "tls.config.file" needs to be replaced by the file path created in step 2.
 
 ### 3.1 Edit runserver.sh
-Add following content in JAVA_OPT：
+Add following content in JAVA_OPT:
 ```shell
 JAVA_OPT="${JAVA_OPT} -Dtls.server.mode=enforcing -Dtls.config.file=/opt/rocketmq-4.9.3/conf/tls.properties"
 ```
 
 ### 3.2 Edit runbroker.sh
-Add following content in JAVA_OPT：
+Add following content in JAVA_OPT:
 
 ```shell
 JAVA_OPT="${JAVA_OPT} -Dorg.apache.rocketmq.remoting.ssl.mode=enforcing -Dtls.config.file=/opt/rocketmq-4.9.3/conf/tls.properties  -Dtls.enable=true"
@@ -102,7 +102,7 @@ tls.client.certPath=/opt/certFiles/client.pem
 tls.client.trustCertPath=/opt/certFiles/ca.pem
 ```
 
-Add following parameters in JVM. The value of "tls.config.file" needs to be replaced by the file path we created：
+Add following parameters in JVM. The value of "tls.config.file" needs to be replaced by the file path we created:
 ```properties
 -Dtls.client.authServer=true -Dtls.enable=true  -Dtls.test.mode.enable=false  -Dtls.config.file=/opt/certs/tlsclient.properties
 ```

docs/en/Design_Remoting.md

@@ -28,7 +28,7 @@ From the above figure, the transport content can be divided into four parts:
 
  (1) Message length: total length, four bytes of storage, occupying an int type; 
 
-(2) Serialization type header length: occupying an int type. The first byte represents the serialization type, and the last three bytes represent the header length；
+(2) Serialization type header length: occupying an int type. The first byte represents the serialization type, and the last three bytes represent the header length;
 
 (3) Header data: serialized header data;
 

docs/en/Design_Store.md

@@ -14,7 +14,7 @@ Message storage is the most complicated and important part of RocketMQ. This sec
 The message storage architecture diagram consists of 3 files related to message storage: `CommitLog` file, `ConsumeQueue` file, and `IndexFile`.
 
 
-* `CommitLog`：The `CommitLog` file stores message body and metadata sent by producer, and the message content is not fixed length. The default size of one `CommitLog` file is 1G, the length of the file name is 20 digits, the left side is zero padded, and the remaining is the starting offset. For example, `00000000000000000000` represents the first file, the starting offset is 0, and the file size is 1G=1073741824, when the first `CommitLog` file is full, the second `CommitLog` file is `00000000001073741824`, the starting offset is 1073741824, and so on. The message is mainly appended to the log file sequentially. When one `CommitLog` file is full, the next will be written.
+* `CommitLog`: The `CommitLog` file stores message body and metadata sent by producer, and the message content is not fixed length. The default size of one `CommitLog` file is 1G, the length of the file name is 20 digits, the left side is zero padded, and the remaining is the starting offset. For example, `00000000000000000000` represents the first file, the starting offset is 0, and the file size is 1G=1073741824, when the first `CommitLog` file is full, the second `CommitLog` file is `00000000001073741824`, the starting offset is 1073741824, and so on. The message is mainly appended to the log file sequentially. When one `CommitLog` file is full, the next will be written.
 * `ConsumeQueue`: The `ConsumeQueue` is used to improve the performance of message consumption. Since RocketMQ uses topic-based subscription mode, message consumption is specific to the topic. Traversing the commitlog file to retrieve messages of one topic is very inefficient. The consumer can find the messages to be consumed according to the `ConsumeQueue`. The `ConsumeQueue`(logic consume queue) as an index of the consuming message stores the starting physical offset `offset` in `CommitLog` of the specified topic, the message size `size` and the hash code of the message tag. The `ConsumeQueue` file can be regarded as a topic-based `CommitLog` index file, so the consumequeue folder is organized as follows: `topic/queue/file` three-layer organization structure, the specific storage path is `$HOME/store/consumequeue/{topic}/{queueId }/{fileName}`. The consumequeue file uses a fixed-length design, each entry occupies 20 bytes, which is an 8-byte commitlog physical offset, a 4-byte message length, and an 8-byte tag hashcode. One consumequeue file consists of 0.3 million entries, each entry can be randomly accessed like an array, each `ConsumeQueue` file's size is about 5.72MB.
 * `IndexFile`: The `IndexFile` provides a way to query messages by key or time interval. The path of the `IndexFile` is `$HOME/store/index/${fileName}`, the file name `fileName` is named after the timestamp when it was created. One IndexFile's size is about 400M, and it can store 2000W indexes. The underlying storage of `IndexFile` is designed to implement the `HashMap` structure in the file system, so RocketMQ's index file is a hash index.
 

docs/en/FAQ.md

@@ -70,7 +70,7 @@ consumer.setConsumeThreadMax(20);
 
 ### 1. If you start a producer or consumer failed and the error message is producer group or consumer repeat.
 
-Reason：Using the same Producer /Consumer Group to launch multiple instances of Producer/Consumer in the same JVM may cause the client fail to start.
+Reason: Using the same Producer /Consumer Group to launch multiple instances of Producer/Consumer in the same JVM may cause the client fail to start.
 
 Solution: Make sure that a JVM corresponding to one Producer /Consumer Group starts only with one Producer/Consumer instance.
 

docs/en/Operations_Trace.md

@@ -46,10 +46,10 @@ For scenarios with large amount of trace message data , one of the Broker nodes
 RocketMQ's message trace feature supports two ways to store trace data:
 
 ### 3.1 System-level TraceTopic
-By default, message track data is stored in the system-level TraceTopic(names：**RMQ_SYS_TRACE_TOPIC**)。This Topic is automatically created when the Broker node is started(As described above, the switch variable **traceTopicEnable** needs to be set to **true** in the Broker  configuration file）。
+By default, message track data is stored in the system-level TraceTopic(names: **RMQ_SYS_TRACE_TOPIC**).This Topic is automatically created when the Broker node is started(As described above, the switch variable **traceTopicEnable** needs to be set to **true** in the Broker  configuration file）.
 
 ### 3.2 Custom TraceTopic 
-If the user is not prepared to store the message track data in the system-level default TraceTopic, you can also define and create a user-level Topic to save the track (that is, to create a regular Topic to save the message track data)。The following section introduces how the Client interface supports the user-defined TraceTopic.
+If the user is not prepared to store the message track data in the system-level default TraceTopic, you can also define and create a user-level Topic to save the track (that is, to create a regular Topic to save the message track data).The following section introduces how the Client interface supports the user-defined TraceTopic.
 
 ## 4 Client Practices that Support Message Trace
 In order to reduce as much as possible the transformation work of RocketMQ message trace feature used in the user service system, the author added a switch parameter (**enableMsgTrace**) to the original interface in the design to realize whether the message trace is opened or not.
@@ -95,7 +95,7 @@ In order to reduce as much as possible the transformation work of RocketMQ messa
 The initialization of `DefaultMQProducer` and `DefaultMQPushConsumer` instances can be changed to support the custom storage message trace Topic as follows when sending and subscribing messages above.
 
 ```
-        ##Where Topic_test11111 needs to be pre-created by the user to save the message trace；
+        ##Where Topic_test11111 needs to be pre-created by the user to save the message trace;
         DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName",true,"Topic_test11111");
         ......
 

docs/en/README.md

@@ -5,39 +5,39 @@
 
 ### 1. Concepts & Features
 
-- [Concept](Concept.md)：introduce basic concepts in RocketMQ.
+- [Concept](Concept.md): introduce basic concepts in RocketMQ.
 
-- [Feature](Feature.md)：introduce functional features of RocketMQ's implementations.
+- [Feature](Feature.md): introduce functional features of RocketMQ's implementations.
 
 
 ### 2. Architecture Design
 
-- [Architecture](architecture.md)：introduce RocketMQ's deployment and technical architecture.
+- [Architecture](architecture.md): introduce RocketMQ's deployment and technical architecture.
 
-- [Design](design.md)：introduce design concept of RocketMQ's key mechanisms, including message storage, communication mechanisms, message filter, loadbalance, transaction message, etc.
+- [Design](design.md): introduce design concept of RocketMQ's key mechanisms, including message storage, communication mechanisms, message filter, loadbalance, transaction message, etc.
 
 
 ### 3. Example
 
-- [Example](RocketMQ_Example.md) ：introduce RocketMQ's common usage, including basic example, sequence message example, delay message example, batch message example, filter message example, transaction message example, etc.
+- [Example](RocketMQ_Example.md): introduce RocketMQ's common usage, including basic example, sequence message example, delay message example, batch message example, filter message example, transaction message example, etc.
 
 
 ### 4. Best Practice
-- [Best Practice](best_practice.md)：introduce RocketMQ's best practice, including producer, consumer, broker, NameServer, configuration of client, and the best parameter configuration of JVM, linux.
+- [Best Practice](best_practice.md): introduce RocketMQ's best practice, including producer, consumer, broker, NameServer, configuration of client, and the best parameter configuration of JVM, linux.
 
-- [Message Trace](msg_trace/user_guide.md)：introduce how to use RocketMQ's message tracing feature.
+- [Message Trace](msg_trace/user_guide.md): introduce how to use RocketMQ's message tracing feature.
 
-- [Auth Management](acl/Operations_ACL.md)：introduce how to deployment quickly and how to use RocketMQ cluster enabling auth management feature.
+- [Auth Management](acl/Operations_ACL.md): introduce how to deployment quickly and how to use RocketMQ cluster enabling auth management feature.
 
-- [Quick Start](dledger/quick_start.md)：introduce how to deploy Dledger quickly.
+- [Quick Start](dledger/quick_start.md): introduce how to deploy Dledger quickly.
 
-- [Cluster Deployment](dledger/deploy_guide.md)：introduce how to deploy Dledger in cluster.
+- [Cluster Deployment](dledger/deploy_guide.md): introduce how to deploy Dledger in cluster.
 
 - [Proxy Deployment](proxy/deploy_guide.md)
   Introduce how to deploy proxy (both `Local` mode and `Cluster` mode).
 
 ### 5. Operation and maintenance management
-- [Operation](operation.md)：introduce RocketMQ's deployment modes that including single-master mode, multi-master mode, multi-master multi-slave mode and so on, as well as the usage of operation tool mqadmin.
+- [Operation](operation.md): introduce RocketMQ's deployment modes that including single-master mode, multi-master mode, multi-master multi-slave mode and so on, as well as the usage of operation tool mqadmin.
 
 
 ### 6. API Reference（TODO）

docs/en/Troubleshoopting.md

@@ -2,7 +2,7 @@
 
 ## 1 RocketMQ's mqadmin command error.
 
->  Problem: Sometimes after deploying the RocketMQ cluster, when you try to execute some commands of "mqadmin", the following exception will appear：
+>  Problem: Sometimes after deploying the RocketMQ cluster, when you try to execute some commands of "mqadmin", the following exception will appear:
 >
 >  ```java
 >  org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <null> failed
@@ -72,5 +72,5 @@ After sending message with RocketMQ, you will usually see the following log:
 SendResult [sendStatus=SEND_OK, msgId=0A42333A0DC818B4AAC246C290FD0000, offsetMsgId=0A42333A00002A9F000000000134F1F5, messageQueue=MessageQueue [topic=topicTest1, BrokerName=mac.local, queueId=3], queueOffset=4]
 ```
 
-- msgId，for the client, the msgId is generated by the producer instance. Specifically, the method `MessageClientIDSetter.createUniqIDBuffer()` is called to generate a unique Id.
+- msgId, for the client, the msgId is generated by the producer instance. Specifically, the method `MessageClientIDSetter.createUniqIDBuffer()` is called to generate a unique Id.
 - offsetMsgId, offsetMsgId is generated by the Broker server when writing a message ( string consists of "IP address + port" and "CommitLog's physical offset address"), and offsetMsgId is the messageId used to query in the RocketMQ console.

docs/en/architecture.md

@@ -6,18 +6,18 @@
 The RocketMQ architecture is divided into four parts, as shown in the figure above:
 
 
-- Producer：The role of message publishing supports distributed cluster mode deployment. Producer selects the corresponding Broker cluster queue for message delivery through MQ's load balancing module. The delivery process supports fast failure and low latency.
+- Producer: The role of message publishing supports distributed cluster mode deployment. Producer selects the corresponding Broker cluster queue for message delivery through MQ's load balancing module. The delivery process supports fast failure and low latency.
 
-- Consumer：The role of message consumption supports distributed cluster deployment. Support push, pull two modes to consume messages. It also supports cluster mode and broadcast mode consumption, and it provides a real-time message subscription mechanism to meet the needs of most users.
+- Consumer: The role of message consumption supports distributed cluster deployment. Support push, pull two modes to consume messages. It also supports cluster mode and broadcast mode consumption, and it provides a real-time message subscription mechanism to meet the needs of most users.
 
-- NameServer：NameServer is a very simple Topic routing registry with a role similar to ZooKeeper in Dubbo, which supports dynamic registration and discovery of Broker. It mainly includes two functions: Broker management, NameServer accepts the registration information of the Broker cluster and saves it as the basic data of the routing information. Then provide a heartbeat detection mechanism to check whether the broker is still alive; routing information management, each NameServer will save the entire routing information about the Broker cluster and the queue information for the client query. Then the Producer and Consumer can know the routing information of the entire Broker cluster through the NameServer, so as to deliver and consume the message. The NameServer is usually deployed in a cluster mode, and each instance does not communicate with each other. Broker registers its own routing information with each NameServer, so each NameServer instance stores a complete routing information. When a NameServer is offline for some reason, the Broker can still synchronize its routing information with other NameServers. The Producer and Consumer can still dynamically sense the information of the Broker's routing.
+- NameServer: NameServer is a very simple Topic routing registry with a role similar to ZooKeeper in Dubbo, which supports dynamic registration and discovery of Broker. It mainly includes two functions: Broker management, NameServer accepts the registration information of the Broker cluster and saves it as the basic data of the routing information. Then provide a heartbeat detection mechanism to check whether the broker is still alive; routing information management, each NameServer will save the entire routing information about the Broker cluster and the queue information for the client query. Then the Producer and Consumer can know the routing information of the entire Broker cluster through the NameServer, so as to deliver and consume the message. The NameServer is usually deployed in a cluster mode, and each instance does not communicate with each other. Broker registers its own routing information with each NameServer, so each NameServer instance stores a complete routing information. When a NameServer is offline for some reason, the Broker can still synchronize its routing information with other NameServers. The Producer and Consumer can still dynamically sense the information of the Broker's routing.
 
-- BrokerServer：Broker is responsible for the storage, delivery and query of messages and high availability guarantees. In order to achieve these functions, Broker includes the following important sub-modules.
-1. Remoting Module：The entire broker entity handles requests from the clients side.
-2. Client Manager：Topic subscription information for managing the client (Producer/Consumer) and maintaining the Consumer
-3. Store Service：Provides a convenient and simple API interface for handling message storage to physical hard disks and query functions.
-4. HA Service：Highly available service that provides data synchronization between Master Broker and Slave Broker.
-5. Index Service：The message delivered to the Broker is indexed according to a specific Message key to provide a quick query of the message.
+- BrokerServer: Broker is responsible for the storage, delivery and query of messages and high availability guarantees. In order to achieve these functions, Broker includes the following important sub-modules.
+1. Remoting Module: The entire broker entity handles requests from the clients side.
+2. Client Manager: Topic subscription information for managing the client (Producer/Consumer) and maintaining the Consumer
+3. Store Service: Provides a convenient and simple API interface for handling message storage to physical hard disks and query functions.
+4. HA Service: Highly available service that provides data synchronization between Master Broker and Slave Broker.
+5. Index Service: The message delivered to the Broker is indexed according to a specific Message key to provide a quick query of the message.
 
 ![](image/rocketmq_architecture_2.png)
 

docs/en/best_practice.md

@@ -72,7 +72,7 @@ Thirdly, the producer is a virtual machine with low reliability, which is not su
 In conclusion, it is recommended that the retry process must be controlled by the application.
 
 ### 1.3 Send message by oneway
-Typically, this is the process by which messages are sent：
+Typically, this is the process by which messages are sent:
 
 - Client send request to server
 - Server process request