[rocketmq] branch 5.0.0-alpha-static-topic updated: Polish newline for doc

[do...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

dongeforever pushed a commit to branch 5.0.0-alpha-static-topic
in repository https://gitbox.apache.org/repos/asf/rocketmq.git


The following commit(s) were added to refs/heads/5.0.0-alpha-static-topic by this push:
     new 085f239  Polish newline for doc
085f239 is described below

commit 085f239263e7be841a404e0a190ccf13ba7e6581
Author: dongeforever <do...@apache.org>
AuthorDate: Wed Dec 1 19:17:32 2021 +0800

    Polish newline for doc
---
 ..._Topic_Logic_Queue_\350\256\276\350\256\241.md" | 35 +++++++++++-----------
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git "a/docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_\350\256\276\350\256\241.md" "b/docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_\350\256\276\350\256\241.md"
index 1ad9183..9d41f00 100644
--- "a/docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_\350\256\276\350\256\241.md"
+++ "b/docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_\350\256\276\350\256\241.md"
@@ -350,8 +350,10 @@ Offset的存储，无需转换，直接存储在 LogicQueue 所对应的最新 P
 RocketMQ 没有引入中心化的存储组件，那么如何保证 SOT 的全局一致性呢？
 主要利用两个信息
 * TopicQueueMapping 带上的 epoch
-* TopicQueueMapping 带上 totalQueues
+* TopicQueueMapping 带上 totalQueues  
+
 在更新或者切换时，获取所有Broker上的 TopicQueueMapping，校验 epoch 和 totalQueues，并且根据 TopicQueueMapping 可以完整地构建出对应的Logic Queue，则说明数据是完整一致的。
+
 如果发现数据不一致，可能是以下因素引入的：
 * 集群中有Broker宕机
 * 上次更新没有完全成功
@@ -359,38 +361,37 @@ RocketMQ 没有引入中心化的存储组件，那么如何保证 SOT 的全局
 应该要先修复数据，再执行 更新或切换 操作
 
 #### No Target Brokers
-Target Brokers 是指拥有 LogicQueue 的 Broker。
-考察1个场景，如果某个Topic 只有1个 LogicQueue，而拥有这个 LogicQueue 的 Broker 正好宕机了。此时去更新 Topic，会不会误认为该 Topic 不存在？
-解决这个问题的办法是引入 No Target Brokers，也即集群中除去『Target Brokers』之外的 Broker。
-对于 No Target Broker，依然需要写入一份 TopicQueueMapping，带上 epoch 和 totalQueues，但不拥有任何 LogicQueue。
-有了这个信息之后，在进行一致性校验时，就可以识别出上述场景。
+Target Brokers 是指拥有 LogicQueue 的 Broker。  
+考察1个场景，如果某个Topic 只有1个 LogicQueue，而拥有这个 LogicQueue 的 Broker 正好宕机了。此时去更新 Topic，会不会误认为该 Topic 不存在？  
+解决这个问题的办法是引入 No Target Brokers，也即集群中除去『Target Brokers』之外的 Broker。  
+对于 No Target Broker，依然需要写入一份 TopicQueueMapping，带上 epoch 和 totalQueues，但不拥有任何 LogicQueue。  
+有了这个信息之后，在进行一致性校验时，就可以识别出上述场景。  
 
 尤其要注意，如果 Nameserver 中没有任何信息，则需要主动去所有 Broker 拉取一遍。
 
 #### 切换时最新 LogicQueueMappingItem 的 logicOffset 决策问题
-logicOffset的决策，依赖于上一个 PhysicalQueue 的最大位点。
-此时，要么跳跃位点，要么等待上一个 PhysicalQueue 确保已经禁写。
-
-当前实现，为了保障高可用，采用『切新禁旧再切新』的方式，同时跳跃位点。
+logicOffset的决策，依赖于上一个 PhysicalQueue 的最大位点。  
+此时，要么跳跃位点，要么等待上一个 PhysicalQueue 确保已经禁写。  
+当前实现，为了保障高可用，采用『切新禁旧再切新』的方式，同时跳跃位点。  
 
 #### logicOffset 为 -1 时的处理
-此时，可以写，但返回给 客户端的 offset 也是-1
-此时，不可以读最新 PhysicalQueue。
-需要确保，相关查找  MappingItem 的操作，忽略 logicOffset 为-1的Item，否则可能触发位点被重置！
+此时，可以写，但返回给 客户端的 offset 也是-1。  
+此时，不可以读最新 PhysicalQueue。  
+需要确保，相关查找  MappingItem 的操作，忽略 logicOffset 为-1的Item，否则可能触发位点被重置！  
 
 #### 队列重复映射
-如果允许1个 PhysicalQueue 被重复利用，也即多段映射给多个 LogicQueue，或者从非0开始映射。
+如果允许1个 PhysicalQueue 被重复利用，也即多段映射给多个 LogicQueue，或者从非0开始映射。  
 会带来以下麻烦：
 * 所有位点相关的API，需要考虑 MappingItem endOffset，因为超过了 endOffset 可能已经不属于 当前 LogicQueue 了
-* 新建 MappingItem，需要先获取 旧 MappingItem 的 endOffset
+* 新建 MappingItem，需要先获取 旧 MappingItem 的 endOffset  
 
 当前实现，为了保证简洁，禁止 PhysicalQueue 被重复利用，每次更新映射都会让物理层面的 writeQueues++ 和 readQueues++
 后续实现，可以考虑复用已经被清除掉的Physical，也即已经没有数据，位点从0开始。
 
 
 #### 备机更新映射
-当前，admin操作都是要求在Master操作的。因此，没有这个问题。
-Command操作时，提前预判Master是否存在，如果不存在，则提前报错，减少中间失败率。
+当前，admin操作都是要求在Master操作的。因此，没有这个问题。  
+Command操作时，提前预判Master是否存在，如果不存在，则提前报错，减少中间失败率。  
 
 #### 拉取消息时 OutOfRange 的判断
 以下情况会影响 OutOfRange 的判断