Pulsar-topic 学习笔记

持久化PartitionedTopic 创建流程: 校验(topic名称,权限,NameSpace上限)->检查Topic是否存在->在ZK中写入Topic元数据->创建Ledger信息,其中记录这个分区都写在哪个Bookie节点上->Topic信息缓存在Broker中

　　其余类型Topic创建流程基本相似 如果非分区的 则不会向zk写入元数据; 如果是非持久化的 则不会创建账本信息

 

Topic的归属问题: Pulsar集群可以承载很多Topic/分区 如果有一百万个topic/分区 每个持久化Topic都将向zk写入数据的话 zk中将承载很多数据 Pulsar对此进行了优化
Bundle的概念 就是哈希环的扣 ZK只记录Bundle和Broker的关系 Topic归属于哪个Topic 通过一致性哈希动态计算得出.

 

那么如果Broker进行了动态扩容 Client还是不清楚Broker到底有多少 不知道去哪个Broker找自己的Topic, 类似服务发现的机制--Lookup机制

如果一个bundle刚创建 它会依赖Lookup机制来绑定Broker

 

如果Bundle被卸载 落在此处的Broker必将转移给另一个Broker 如果有过多Topic归属这个Bundle 转移不动这么多Topic怎么办 Pulsar提供了自动分裂Bundle 如果这个Bundle上所有Topic负载数值之后达到分裂阈值 则自动触发分裂

但是 线上环境通常将关闭此功能 Bundle分裂时 Bundle管理的Topic会有短暂的重连 查找过程 客户端会明显感知到. 因此通常是等待流量洪峰过去之后再重新分裂.

 

压缩topic原理: 底层有一个单线程调度器compactionMonitor定时触发压缩->创建Reader 异步读取源Topic->Reader创建CompactorSubcription-一阶段压缩->二阶段压缩->结束并清理