一、Topic Discovery
1. Topic Assignment
首先看一下层次化结构
根据图上所示，topic 的分配是按照 namespace 来划分的
一个 namespace 下面会有很多个 topic，namespace 会把所有的 topic 组成一个环（namespace hash ring）。在 topic 分配之前，会把 topic 的名字 hash 到 namespace hash ring 里。然后根据不同 topic 的 hash 值 又会分为几个小组， 也就是 namespace bundle， bundle 的数量可以在创建 namespace 时就可以指定确认了。
topic 映射 到 bundle 后，接下来就会将 bundle 分配给 broker。 也就是 topic 的分配不在于 topic 本身，而是 bundle 操作。处理过程依靠 load Maneger 进行，对 bundle 进行分配。
load manager 是从 broker 中选出来的一台。 topic 分配到 broker 的过程，全程是由 load manager 来执行的。
2. Topic lookup
topic 如何找到对应的那台 broker呢？
先介绍一个概念：Topic owner ，又可以称为 namespace bundle owner 。
topic 与 broker 的映射关系，存储在 owner 中， owner存储在zookeeper中，任何一个 broker 都可以获取到 topic 到 owner 的映射关系。
lookup 流程：
pulsar 客户端发起 topic lookup 请求给 broker，broker 开启 lookup模式，根据 namespace 去检测出映射的 bundle， 然后将此反馈发给 zookeeper 去查找对应，最后将请求结果返回给客户端。
客户端这时， 会根据请求结果和目标 broker 进行 tcp 长链接。
有个问题，这个时候如果目标 broker 的地址不能直接链接，该怎么办？
解决方案：
使用 pulsar proxy 。它提供了 topic 查询路由功能，可以作为 tcp 反向代理来使用
二、ServiceURL
知道了整个 topic discovery 之后。对 service URL 的使用就会更加准确了
service URL 高可用的几种方式
DNS：在 broker 之前配置一个 DNS，落实到 broker 里。 缺点是 过期时间和缓存限制
Load Balance：可以探测活跃的 broker，可以及时清理 broker。
Multi-Hosts：把所有机器当做一个列表，pulsar客户端进行负载均衡，第一次用第一个broker，链接失败用第二个，以此类推
三、Clusters
部署 pulsar 集群的时候，需要制定 cluster name， 集群配置信息作为元数据保存到 zookeeper 上。
在 cluster 配置文件里，主要是四个接入端口，分为两大类。
HTTP service：即提供 admin 操作的接口
- Web service URL (http://)
- Web service URL TLS (https://)
Broker service：即客户端、producer、consumer 等需要连接的 6650 端口。
- Broker service URL (pulsar://)
- Broker service URL TLS (pulsar+ssl://)
这几个参数只有在进行跨机房复制时才使用。