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
commit 47622e6ad56c1811e835dd439eb81d653ea221a3 Author: dongeforever <[email protected]> AuthorDate: Thu Dec 23 15:40:01 2021 +0800 Polish doc, add todo list --- .../common/statictopic/TopicQueueMappingUtils.java | 2 +- ..._Topic_Logic_Queue_\350\256\276\350\256\241.md" | 31 ++++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/common/src/main/java/org/apache/rocketmq/common/statictopic/TopicQueueMappingUtils.java b/common/src/main/java/org/apache/rocketmq/common/statictopic/TopicQueueMappingUtils.java index 75f0a4f..6a1c39c 100644 --- a/common/src/main/java/org/apache/rocketmq/common/statictopic/TopicQueueMappingUtils.java +++ b/common/src/main/java/org/apache/rocketmq/common/statictopic/TopicQueueMappingUtils.java @@ -384,8 +384,8 @@ public class TopicQueueMappingUtils { throw new RuntimeException(String.format("The queue number %s is not in globalIdMap", i)); } } + checkIfReusePhysicalQueue(globalIdMap.values()); } - checkIfReusePhysicalQueue(globalIdMap.values()); return globalIdMap; } 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 bf59688..c06d83f 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" @@ -6,6 +6,8 @@ | 2021-12-01 | 更新问题与风险，增加关于一致性、OutOfRange、拉取中断的详细说明| dongforever | | 2021-12-03 | 增加代码走读的说明| dongforever | | 2021-12-10 | 引入Scope概念，保留『多集群动态零耦合』的集群设计模型 | dongforever | +| 2021-12-23 | 梳理待完成事项；讨论Admin接口的适配方式 | dongforever | + 中文文档在描述特定专业术语时，仍然使用英文。 @@ -424,6 +426,15 @@ Command操作时，提前预判Master是否存在，如果不存在，则提前 #### pullResult 位点由谁设置的问题 类似于Batch，由客户端设置，避免服务端解开消息： 在PullResultExt中新增字段 offsetDelta。 +#### Admin接口与User接口的适配方式区别 +User 接口，使用范围广泛如多语言等，应该尽可能简单，把适配逻辑做在服务端，对『客户端』透明。 +那么 Admin 接口呢，比如 examineTopicStats，适配逻辑是做在『服务端』还是『客户端』？ +一个 Admin 接口，通常需要访问所有 Broker 的所有队列。 +如果做在服务端，则可能产生交叉访问，在极端情况下，性能会非常差，举个例子： +100 个 Broker，相互交叉映射过一遍，则Admin客户端首先要向 100 个 Broker 发请求，然后这 100 个 Broker 为了获取远程信息，各自向其余 Broker 发请求。 +其实际网络请求数就是 100 * 100 = 10000 个网络请求。放大效应十分明显。 +同时, 考虑到 Admin 接口，使用范围是有限的，无需考虑多语言适配等问题，可以把适配逻辑做在 Admin 客户端。 + #### 远程读的性能问题 从实战经验来看，性能损耗几乎不计。 #### 使用习惯的改变 @@ -437,6 +448,26 @@ Command操作时，提前预判Master是否存在，如果不存在，则提前 二阶消息需要支持远程读写操作。 一期的LogicQueue不支持『二阶消息』。 +### 待完成事项 +#### 阻止旧客户端的请求 +旧的客户端无法解析逻辑路由，但可以识别物理路由。如果错误使用，则会影响映射关系的准确性。 +#### 阻止Pop模式、事务消息、定时消息使用 LogicQueue +不兼容 事务消息和定时消息。 +LogicQueue 当前不支持Pop模式消费。 +#### ConsumeQueue 的 correctMinOffset 逻辑存在缺陷 +可能导致 LogicQueue 无法清除已经过期的 MappingItem。 +#### getOffsetInQueueByTime 语义有缺陷 +可能导致 LogicQueue 时间搜索不准确。需要专项修复。 +#### Metadata 更新机制 +当前的更新机制太慢。且访问『不存在Broker』时，会频繁访问Nameserver，有打爆Nameserver的风险。 +#### examineConsumeStats 接口获取不到『最近消费时间』 +位点相关的消息可能不在本机，需要远程访问。 +#### resetOffset 需要适配 +当前没有适配。重置位点，可能会得到不符合预期的结果。 +#### MessageQueue 没有被物理清除 +当前只是产生遗留数据，占用一点点存储空间，没有太大影响。 +如果将来要实现 物理 Queue 复用，则需要先完善相关逻辑。 + ### 代码走读要点 #### Admin 入口 主要看两个类：
