This is an automated email from the ASF dual-hosted git repository.
dinglei pushed a commit to branch develop
in repository https://gitbox.apache.org/repos/asf/rocketmq.git
The following commit(s) were added to refs/heads/develop by this push:
new e9bc366 fix typo (#1232)
e9bc366 is described below
commit e9bc3661bcfa400b89509a390804bd642a2f4193
Author: Zhang Chao <[email protected]>
AuthorDate: Thu Jun 13 18:27:01 2019 +0800
fix typo (#1232)
---
docs/en/Concept.md | 2 +-
docs/en/architecture.md | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/en/Concept.md b/docs/en/Concept.md
index 76788b9..75f084e 100644
--- a/docs/en/Concept.md
+++ b/docs/en/Concept.md
@@ -22,7 +22,7 @@ A type of Consumer, Under this high real-time performance
mode, it will push the
## 9 Producer Group
A collection of the same type of Producer, which sends the same type of
messages with consistent logic. If a transaction message is sent and the
original producer crashes after sending, the broker server will contact other
producers in the same producer group to commit or rollback the transactional
message.
## 10 Consumer Group
-A collection of the same type of Consumer, which sends the same type of
messages with consistent logic. The consumer group makes load-balance and
fault-tolerance super easy in terms of message consuming.
+A collection of the same type of Consumer, which consume the same type of
messages with consistent logic. The consumer group makes load-balance and
fault-tolerance super easy in terms of message consuming.
Warning: consumer instances of one consumer group must have exactly the same
topic subscription(s).
RocketMQ supports two types of consumption mode:Clustering and Broadcasting.
diff --git a/docs/en/architecture.md b/docs/en/architecture.md
index 0e36266..18e1cc0 100644
--- a/docs/en/architecture.md
+++ b/docs/en/architecture.md
@@ -10,7 +10,7 @@ The RocketMQ architecture is divided into four parts, as
shown in the figure abo
- 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 [...]
+- 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 [...]
- 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.
