This is an automated email from the ASF dual-hosted git repository.
duhengforever 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 c204199e1 fix `notAvailableDuration` description in doc file (#4511)
c204199e1 is described below
commit c204199e1d4bcc59985197d084ba7655518a7dd3
Author: ethan <[email protected]>
AuthorDate: Sat Jun 25 11:49:12 2022 +0800
fix `notAvailableDuration` description in doc file (#4511)
---
docs/cn/design.md | 2 +-
docs/en/Design_LoadBlancing.md | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/cn/design.md b/docs/cn/design.md
index b19d50ce2..04718127e 100644
--- a/docs/cn/design.md
+++ b/docs/cn/design.md
@@ -107,7 +107,7 @@ RocketMQ分布式消息队列的消息过滤方式有别于其它MQ中间件，
### 4 负载均衡
RocketMQ中的负载均衡都在Client端完成，具体来说的话，主要可以分为Producer端发送消息时候的负载均衡和Consumer端订阅消息的负载均衡。
#### 4.1 Producer的负载均衡
-Producer端在发送消息的时候，会先根据Topic找到指定的TopicPublishInfo，在获取了TopicPublishInfo路由信息后，RocketMQ的客户端在默认方式下selectOneMessageQueue()方法会从TopicPublishInfo中的messageQueueList中选择一个队列（MessageQueue）进行发送消息。具体的容错策略均在MQFaultStrategy这个类中定义。这里有一个sendLatencyFaultEnable开关变量，如果开启，在随机递增取模的基础上，再过滤掉not
available的Broker代理。所谓的"latencyFaultTolerance"，是指对之前失败的，按一定的时间做退避。例如，如果上次请求的latency超过550Lms，就退避3000Lms；超过1000L，就退避60000L；如果关闭，采用随机递增取模的方式选择一个队列（MessageQueue）来发送消息，latencyFaultTolerance机制是实现消息发送高可用的核心关键所在。
+Producer端在发送消息的时候，会先根据Topic找到指定的TopicPublishInfo，在获取了TopicPublishInfo路由信息后，RocketMQ的客户端在默认方式下selectOneMessageQueue()方法会从TopicPublishInfo中的messageQueueList中选择一个队列（MessageQueue）进行发送消息。具体的容错策略均在MQFaultStrategy这个类中定义。这里有一个sendLatencyFaultEnable开关变量，如果开启，在随机递增取模的基础上，再过滤掉not
available的Broker代理。所谓的"latencyFaultTolerance"，是指对之前失败的，按一定的时间做退避。例如，如果上次请求的latency超过550L
ms，就退避30000L
ms；超过1000L，就退避60000L；如果关闭，采用随机递增取模的方式选择一个队列（MessageQueue）来发送消息，latencyFaultTolerance机制是实现消息发送高可用的核心关键所在。
#### 4.2 Consumer的负载均衡
在RocketMQ中，Consumer端的两种消费模式（Push/Pull）都是基于拉模式来获取消息的，而在Push模式只是对pull模式的一种封装，其本质实现为消息拉取线程在从服务器拉取到一批消息后，然后提交到消息消费线程池后，又“马不停蹄”的继续向服务器再次尝试拉取消息。如果未拉取到消息，则延迟一下又继续拉取。在两种基于拉模式的消费方式（Push/Pull）中，均需要Consumer端知道从Broker端的哪一个消息队列中去获取消息。因此，有必要在Consumer端来做负载均衡，即Broker端中多个MessageQueue分配给同一个ConsumerGroup中的哪些Consumer消费。
diff --git a/docs/en/Design_LoadBlancing.md b/docs/en/Design_LoadBlancing.md
index 106f019b7..86c47b165 100644
--- a/docs/en/Design_LoadBlancing.md
+++ b/docs/en/Design_LoadBlancing.md
@@ -3,7 +3,7 @@ Load balancing in RocketMQ is accomplished on Client side.
Specifically, it can
### Producer Load Balancing
When the Producer sends a message, it will first find the specified
TopicPublishInfo according to Topic. After getting the routing information of
TopicPublishInfo, the RocketMQ client will select a queue (MessageQueue) from
the messageQueue List in TopicPublishInfo to send the message by
default.Specific fault-tolerant strategies are defined in the MQFaultStrategy
class.
-Here is a sendLatencyFaultEnable switch variable, which, if turned on, filters
out the Broker agent of not available on the basis of randomly gradually
increasing modular arithmetic selection. The so-called "latencyFault Tolerance"
refers to a certain period of time to avoid previous failures. For example, if
the latency of the last request exceeds 550 Lms, it will evade 3000 Lms; if it
exceeds 1000L, it will evade 60000 L; if it is closed, it will choose a queue
(MessageQueue) to send m [...]
+Here is a sendLatencyFaultEnable switch variable, which, if turned on, filters
out the Broker agent of not available on the basis of randomly gradually
increasing modular arithmetic selection. The so-called "latencyFault Tolerance"
refers to a certain period of time to avoid previous failures. For example, if
the latency of the last request exceeds 550 Lms, it will evade 30000 Lms; if it
exceeds 1000L, it will evade 60000L; if it is closed, it will choose a queue
(MessageQueue) to send m [...]
### Consumer Load Balancing
In RocketMQ, the two consumption modes (Push/Pull) on the Consumer side are
both based on the pull mode to get the message, while in the Push mode it is
only a kind of encapsulation of the pull mode, which is essentially implemented
as the message pulling thread after pulling a batch of messages from the
server. After submitting to the message consuming thread pool, it continues to
try again to pull the message to the server. If the message is not pulled, the
pull is delayed and continue [...]
