>>> 问题1: 核心组件中,不是说去Zookeeper嘛?
目前所有的发行版中还没有去掉zookeeper的版本,可能会在2.9.0发布去掉zookeeper的版本,去zookeeper是 Pulsar Hackathon 的一个项目,后面会有更多的内容出来
>>>问题2: pulsar新增broker的时候,是如何去别的broker里面拿topic的呢?这个负载均衡过程是怎么样的? 以及在重新分配broker的topic的时候,producer和consumer会断连么?
1.寻找 Topic 的 owner 是通过 Topic lookup 请求获得 Topic 的owner
2.Topic 分配到那个 broker 是根据 Topic 所在的 namespace bundle 来分配的
3. Pulsar 的负载均衡指的就是 bundle 的负载均衡,如果要搬迁 bundles,是需要 close producer 和 consumer 的连接的,相当于一次 producer consumer 重连的过程
>>>问题3: 1.寻找 Topic 的 owner 是通过 Topic lookup 请求获得 Topic 的owner
lookup是去zk里面去拿到数据么?
>>>问题4: 如果有百万级topics,topic怎么管理呀?
目前可以使用的一个方案可以参考:
https://github.com/apache/pulsar/wiki/PIP-8:-Pulsar-beyond-1M-topics
我们目前也在和腾讯合作一起做 metadata 的一些优化,为了能够在一个local cluster支持百万级以上的 topics
>>>问题5: lookup是去zk里面去拿到数据么?
分情况,如果是当前 topic 所属的 bundle 没有broker 服务,这时候会 assign 一个 broker 去zk 上去拿锁,拿到锁的broker会成为 owner,如果所属 bundle 已经被一个 broker 负责了,那就直接返回 owner broker 的地址
>>>问题6: broker中会存哪些数据?
broker 并不存储任何数据
>>>问题7: 只是单纯的做计算节点吗,partition的segment信息数据和consumer的消费的offset数据都是在zk存储的吗
broker 中会缓存 segment 信息,本身一个 topic 的所有 segments metadata 还是在zk管理的
offset 是用一个单独的 Ledger 管理的,不是每次update offset 都更新 zk
>>>问题8: 那consumer是如何通过topic去查找到bookie中的数据呢
consumer 并不负责找数据的事情,这个工作是由broker完成的,broker 会连接zk,并且会cache topic 的metadata,寻找数据放在那个 bk,其实是通过 2 个metadata,一个是 topic metadata,从这里可以获取到 topic 一共有多少个 segments,也就是多少个 ledgers,第二个是,查找这个 Ledger 的数据存放到那写 bookies,这个是从 bookkeeper 的 metadata server 中的获得的,本身 broker 就是 bookie 的 client,所以broker 也是通过 bookie 的 client 来完成数据读取的
问题9:是每一个bookie节点都存在一个 bookkeeper 的 metadata server吗
Bookie metadata server 目前指的就是 zookeeper,和 bookie的节点数量没有关系
>>>问题10:key_shared模式的话需要producer disable batching,这个是为啥?
因为 producer 端默认开启 batch 会把不同key的消息打包到一个 batch 里面,而broker分发给consumer消息是一个batch一个batch的发,这样就无法保证同一个key的消息只能分发到一个consumer的保证了,
当然也不是一定要关掉 batch,
那consumer是如何通过topic去查找到bookie中的数据呢
2.7.1 是支持 key_based batcher 的,需要client的version不是服务端。创建 producer 的时候通过 .batchBuilder 来指定就ok了
>>>问题11 对了,还是我那个问题,就是如果key_shared模式,但是producer没有disable batching到时不同key分到一个batch,这种情况下consumer会怎么样?无法拉取消息么?
不会,consumer 还是会正常消费,但是可能同一个key 的消息被分发到两个consumer,因为分发的时候只是用一个 batch 的第一个消息的key来计算的,
>>>问题12:所以这个所谓的batch不是producer client提交消息的batch,而是consumer消费时候的batch,那一个batch在bookie上也是存储到一块儿的么?
都是一个batch,一个batch 相当于对应一个 bookie 的 entry,producer 把多条消息合并到一个 batch 发送,broker 接收到直接把batch 写到bookie,读的时候也是读出来batch 直接发给consumer,所以打包batch和解包batch都是在client 做的
>>>问题13:pulsar中都有哪些主要的metadata和缓存数据,比如刚才说到的:
1、zk中存的topic metadata:topic–segments
2、zk中存的bookie metadata:segment–bookie
3、broker中存的topic cache
4、bookie的write cache:ledgerId+enryId–data