———— 引言
前一阵子接触到 Pulsar 这么个新一代具有流原生特性的 MQ 中间件，当时因为项目需要，不得不深入了解一下 Pulsar 的一些特性以解决问题。至此，对 Pulsar 产生兴趣，从未停止过关注。所以最近逐渐意识到前一阵子对于 Pulsar 的某些特性理解过于简单，片面甚至是错误的。
1、Pulsar 与 云原生
云原生 ，这个词语在近几年的互联网领域很火热。以我目前的理解，对它的定义则是在云环境（ 私有、公有等 ）中可以部署运行可弹性扩展的应用。例如我们常用的微服务，那么 Pulsar 使用的也是云原生的架构，将 数据从 Borker ( 逻辑概念，下文介绍 ) 剥离，运用 Bookkeer 将消息存储在 Bookie 集群中 ( 持久层 )，而 Borker 则负责一些调度、管理、复制消息分发等服务。这也就是其“计算储存分离架构”了，据说也是目前非常流行的一种架构及趋势。其实 Pulsar 不光是存储模型的先进，消费模型的抽象也是很好的一种先进思想，后面会发个文章做出分析。那本篇就 Pulsar 是怎么做到分离架构这一点的呢 ？
2、Pulsar 之 Apache BookKeeper ( 下称 “BK” )
其实在这之前我都没听过 BookKeeper ，也是基于 Pulsar 对其有了了解 ，可以说 Pulsar 的分层储层特性也是 BookKeeper 的一大功劳。
官网： https://github.com/apache/bookkeeper
下面则对 Bookkeeper 一些重要的概念做下介绍 （ 主要和下文 Pulsar 有关 ）
- Entry：是储存到 Bookkeeper 中的一条记录，也是 BK 中最小的存储单元
- Ledger： 是用来存储 Entry 的，多个 Entry 组成一个 Ledger，在 Pulsar 中也叫日志段，另外一个叫日志流 Stream 下文介绍 。
- Bookie：在 BK 中其实就是一台存储节点，用来存储 Ledger ，但是 Ledger 可能会被划分为多段以分布式的方式存储在多个 Bookie 上 （ 应该是为了分布式存储在数据跨节点复制时考虑到其性能 ）。
- 元数据：用于储存 Bookie 相关的元数据。
3、Pulsar 储存模型
引用官网的一张典型的部署图。如下图所示， Pulsar 由 Borker 层 和 Bookie 层组成。另外在此处其实 Borker 只是一层逻辑的概念，下文会对其进行具体剖析。
- Borker 层 - 逻辑计算层 （ 个人理解 ）
在 Pulsar 中 Borker 是无状态的，因为 Borker 并不像 Kafka 那样会储存消息。而更多的则是负责消息的复制与分发 与计算有关的逻辑结构。每个主题的分区 （ Topic Partition ）都会分配到某个 Borker 上，而 Porducer 和 Consumer 则会连接到 Borker，从而向主题分区代理发送消息、消费消息。消息数据则是存放在 Bookkeeper 中，这样一来，当某个 Borker 挂了，或者说某个 Porducer、Consumer 所对应的分区改变了，不会有任何的数据复制发生，而只是一个代理 ( Borker ) 的变更 。
- 持久化层 -- Bookkeeper
在 Pulsar 中每个主题分区的日志都是存放在 BK 中的分布式日志，而每个分布式日志则又会被氛围 Segment 段。注意，Segment 其实就是 BK 中的 Ledger ，上文有提到，其实 Ledger 是分段分布式存储在多个 Bookie 上的。以此一来，就可以通过这种模式，主题分区的消息就可以均匀的分布在 Bookie 中，所以也就不会仅仅收到一个节点容量的限制，可以做到弹性的拓展，当然这取决于 Bookies 的数量。再借助于官网的一个图，我觉得基于图一，对其又进行一次更深层次的剖析。
其实我第一次看这个图还是比较困惑的，后来根据官网提供的一些参数，亲自配置试验了一下。那么与上面这两个图关联性最大的几个配置下面也说明下，以便于更好的理解，当然这几个配置也是 Bookkeeper Ledger 中的 （ 在Pulsar 中其实就是 基于 Segment 的 ）。如上图所示，Parition 被分为了多个 Segment，每个 Segment 会写入到4个 bookie 其中的3个中。比如 Segment 1 就写入到了 Bookie 1 , 2 , 4 中，Segment 2 写入到 Bookie 1 , 3 , 4 中 …
Ensemble Size ( Es )
Ensemble Size 决定了 Pulsar 写入 Ledger 可用的 Bookies 池的大小。在 Borker 创建 Segment时，会选择一组对应的 Bookies ， 每个 Segment / Ledger 都有着对应的 Bookies 列表，Write Quorum Size ( Qws )
该项配置决定了实际的 Bookies 的数量。Ack Quorum Size ( Qas )
该项配置是确认写入 Bookies 的数量，当 Producer 生产一条消息时，Borker 需要将消息发送给客户端，基于 BK 的强一致性， Qas 满足 >= (Qws + 1) / 2 的 ACK 确认时才算成功。所以在写入时是并行写入到多个 Bookies 中的。
4、为何 Pulsar 可以做到弹性的扩容
其实在第 3 点钟以及分析的很明确了。由于 Partition 中不同 Segment/Ledger 可以保存在 Bookeeper不同的 Bookies 上，当现有的集群 Bookie 存储满了时，可以快速的添加机器（ 添加 Bookie 节点 ）来解决问题，让新的 Segment 寻找到合适的 Bookie （ 哈哈，官网有说是可以通过一些策略去进行负载的，例如可以通过磁盘空间的剩余最多或者负载情况等，当然这个还得确认下 ），进行写入，从而实现弹性的扩展。
这其实还是得益于 Partition 以 Segment / Ledger 为粒度均匀的分布在 Bookies 的节点上，所以扩容其实也就是 调度 这么简单。又借鉴于官网找了一张图可以直观的表达 Pulsar 实现 即时扩容而无需进行复制的过程。
当然在 Broker 挂了，那么 Pulsar 又会进行怎样的一个 “数据转移”呢？（ 记住上文说到的 “ 调度 ” 二字 ），如下图
5、 Pulsar 如何保证数据的一致性的 （ 读取 & 写入分析 ）
基于上文第 3 点钟说到的配置项的最后一点，借用官网一图，画的也是非常的直观。
那么其实数据的可靠性已经得得到了保证，那么读取呢？其实既然数据一致性在写入时就已经维护得到了保证，所以在读取的时候就不必大费周章，就类似与 MySQL 在插入时区维护他的索引，而读取时直接用即可，不好意思.....偏题了。所以只需要从一个 Bookie 中读取， 当然这块涉及到一个 缓存机制，本编就不做介绍。大致也如下图 ：
具体的配置项可以参考官网的教程，非本篇文章的介绍重点。
———— 写在结尾
其实在了解 Pulsar 的过程中，层层剖析，对一些思想上还是有非常大的观念转变与进步的（ 特别是做架构的同学，哈哈 ~ ）。从而让我更加的关注到类似于该类架构的一些中间件的。例如最近有关注到 tidb 开源分布式关系型数据库也类似于这种架构体系。当然，回归到本质，一种技术手段深入的了解才会更好的运用到极致，也更好的规避一些问题。
参考文献
https://jack-vanlightly.com/blog/2018/10/2/understanding-how-apache-pulsar-works
