pulsar commiter问与答

>>> 问题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