Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Kwan的解忧杂货铺@新空间代码工作室
Rocketmq
提交
085f2392
R
Rocketmq
项目概览
Kwan的解忧杂货铺@新空间代码工作室
/
Rocketmq
与 Fork 源项目一致
Fork自
Apache RocketMQ / Rocketmq
通知
1
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
R
Rocketmq
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
提交
085f2392
编写于
12月 01, 2021
作者:
D
dongeforever
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Polish newline for doc
上级
e002c74c
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
18 addition
and
17 deletion
+18
-17
docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_设计.md
docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_设计.md
+18
-17
未找到文件。
docs/cn/statictopic/RocketMQ_Static_Topic_Logic_Queue_设计.md
浏览文件 @
085f2392
...
...
@@ -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 的判断
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录