写在前面

上一篇主要介绍了 Pulsar 的总体架构和源码的目录结构，是我们分析源码的基础。这一篇，我们一起聊一下消息队列的核心概念--Topic，Pulsar 是如何实现的。

Topic 简介

Topic 是消息队列的核心概念，生产者发送的消息都会保存在 Topic 中。生产者在发送消息时可以指定要发送到哪一个 Topic，消费者也是以 Topic 的维度订阅并消费某个 Topic 下的消息。

Pulsar 中的 Topic 分类比较细，根据存储形式分为普通 Topic 和分区 Topic。普通 Topic 的消息只会落在一个 Broker 上，而单个 Broker 的性能始终有限，所以普通 Topic 承载的消息吞吐量不高。那么，就需要分区 Topic，每个分区在一个 Broker 上，可以让多个 Broker 承载流量。

根据消息是否持久化，又分为持久化 Topic 和非持久化 Topic，详细内容会后续介绍。

Pulsar 中 Topic 的格式：

{persistent | non-persistent}://tenant/namespace/topic

Topic 会以 persistent 或者 non-persistent 开头，前者说明这是一个持久化 Topic，当消息发送到该 Topic 后，消息会持久化存储到 Bookie 中；后者说明消息只会保存在 Broker 的内存中，当 Broker 重启或崩溃时，消息就会丢失。Topic 一旦创建，持久化类型就不能再修改。

Topic 的第二部分是租户名称；第三部分是命名空间名称；第四部分是定义的 Topic 名字。

Topic 可以自动创建，也可以调用管理流 API 进行创建。自动创建需要在 Broker 的配置文件 broker.conf 中设置两个参数：

allowAutoTopicCreation = true# non-partitioned  或   partitionedallowAutoTopicCreationType = non-partitioned 

只要设置了 allowAutoTopicCreation = true ，就会在创建 Producer、Consumer 的时候，如果 Topic 不存在则会自动创建。所以，为防止 Topic 泛滥，通常关闭自动创建 Topic，而通过管理流 API 手动创建。

普通 Topic 和分区 Topic 无法互相转换，可以通过创建单分区的分区 Topic，方便后续扩展。

Topic 的种类

Topic 分为四种，分别为持久化分区 Topic、持久化非分区 Topic、非持久化分区 Topic 以及非持久化非分区 Topic。

持久化 Topic 和非持久化 Topic 的核心区别就是数据是持久化到 Bookie 中，还是存储于当前 Broker 的内存中。所以持久化 Topic 新建的时候，就会记录 Ledger 信息，记录这个 Partition 写入到哪些 Bookie 节点中。而分区 Topic 和非分区 Topic 的核心区别就是 Topic 的元数据信息是否需要同步。所以分区 Topic 在创建的时候，会同时把 Topic 元数据信息写入对应的元数据存储中(比如 Zookeeper、etcd 等)

Topic 核心

Pulsar 的 Topic 都需要和 Broker 绑定，非分区的 Topic 绑定单个 Broker，分区的 Topic 的每个 Partition 绑定单个 Broker。那么 Topic 和 Broker 是如何建立关系的？

众所周知，Pulsar 可以百万级 Topic，如果在元数据存储中存储每个 Topic 和 Broker 的关系，则数据量巨大。所以 Pulsar 并不是把 Topic 和 Broker 直接绑定的，而是抽象了 Bundle 的概念，并使用一致性 Hash 算法。Bundle 作为一致性哈希环中的虚拟节点，Topic 通过名称计算哈希值，并散列到哈希环中，找到对应的 Bundle，进而映射到对应的 Broker 上。

那 Topic 具体是如何映射的，源码是如何操作的呢。下节 Pulsar 详解进行详细说明。