以下文章来源于程序员 jinjunzhu，作者 jinjunzhu
程序员 jinjunzhu
程序员 jinjunzhu
资深后端开发，善于 java/golang，关注后端开发、分布式、云原生畛域
对于 Apache Pulsar
Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。
GitHub 地址：http://github.com/apache/pulsar/
本文转自公众号：程序员 jinjunzhu，作者：jinjunzhu
本期排版：StreamNative@Tango
Apache BookKeeper 是一款企业级存储系统，最后由雅虎研究院研发，在 2011 年作为 Apache ZooKeeper 的子项目进行孵化，在 2015 年 1 月成为 Apache 顶级我的项目。
起初，BookKeeper 是一个预写日志（WAL）零碎，通过几年的倒退，BookKeeper 的性能更加欠缺，比方为 Hadoop 分布式文件系统（HDFS）的 NameNode 提供高可用和多正本，为音讯零碎比 Pulsar 提供存储服务，为多个数据中心提供跨机器复制。https://github.com/apache/pul…
应用场景
BookKeeper 最后的一个应用场景是为 HDFS 的 NameNode 保留 edit log，
如下图：
ZKFC 是一个 ZooKeeper 的客户端，次要用来监测和治理 NameNode 状态，每个 NameNode 机器上都会运行一个 ZKFC，它的职责次要有三个：
•健康检查
•ZooKeeper 会话治理
•选举，当集群中一个 Active NameNode 宕机，ZooKeeper 会主动抉择一个节点作为新的 Active NameNode。
BookKeeper 记录 NameNode 的 edit log（edit log 寄存文件系统的操作日志），NameNode 的所有批改都会记录到 BookKeeper。这样 active NameNode 宕机后，BookKeeper 用保留的 edit log 去 standby NameNode 做回放，之后切换成 active NameNode。
BookKeeper 具备如下个性：
•一致性：因为 edit log 保留的是 HDFS 的元数据，对一致性要求很高
•低提早：为了不丢数据，须要低提早
•高吞吐：为了反对更多的 NameNode 节点，须要高吞吐
节点对等
Bookie 中保留的数据结构如下图：
writer 写数据时，把 entry 并发写入多 个 bookie 节点的 Ledger。这相似于文件系统写数据时首先会关上一个文件，如果文件不存在，则会创立文件元数据。
Ledger 也就是 Pulsar 中的 segment。
writer 写数据时，首先会关上一个新 Ledger，函数如下：
openLedger（组内节点数目、数据备份数目、期待刷盘节点数目）
比方（5,3,2）代表组内共有 5 个 Bookie 节点，写数据时须要写入 3 个节点，有 2 个节点返回胜利代表写入胜利。
这样写入的这 3 个节点数据齐全一样，关系是对等的，不存在主从关系。
数据读写
BookKeeper 数据读写如下图：
writer 以 roundrobin 的形式写入 bookie，比方在上图中，第一条数据写入 Bookie1、Bookie2 和 Bookie3，第二条数据写入 Bookie2、Bookie3、Bookie4，第三条数据写入 Bookie3、Bookie4、Bookie5，第四条数据写入 Bookie4、Bookie5 和 Bookie1。
在关上一个 Ledger 时，就传入了 bookie 数量，这样在写每个 entry 时，就用 entry 的 id 跟 bookie 数量取模，来确定写到哪几个 bookie 上。比方第 3 条音讯跟 5 取模是 3，就写到 Bookie3、Bookie4 和 Bookie5。
这样以轮询的形式将 Ledger 数据写入各个 bookie 节点，每个 bookie 节点的数据是平衡的，每个 bookie 节点的磁盘带宽和网卡带宽都能失去充分利用。
读高可用
Reader 在读取数据时，能够读取多份数据中的任意一份数据。BookKeeper 会设置一个读超时工夫，如果读取超时了，会给另外一个 bookie 节点（speculative read）发送读申请。
写高可用
如果某个 bookie 节点（比方 bookie5）产生故障不能写入了，BookKeeper 会做如下解决：
•记录出错的 entry id
•对故障节点的数据进行封装
•敞开以后的 Ledger，从新关上一个新的 Ledger，这个 Ledger 会从新抉择 bookie 节点，1、2、3、4、6。
•如果 bookie5 复原，就不再提供写服务了，只提供读服务。
•如果不能复原，就把 bookie5 的数据，从其余节点的备份中复原到新的节点上，这个过程须要依据 Ledger id 跟 5 取模来判断是否落到 bookie5 上，数据恢复过程并不影响 Reader，因为其余两份数据能够持续提供服务。
I/O 模型
BookKeeper 的 I/O 模型如下图，这个图是单个 bookie 的数据流转：
整个流程入下：
•Writer 写入的数据首先达到 Journal，Journal 将数据进行 group 后刷到到 Journal 盘，这个刷盘的数据程序跟 writer 写入程序统一。
Writer 写入 Journal Disk 是实时刷盘。
•Journal Disk 的数据会写入 memory table 进行数据整顿，把同一个 topic 的数据整顿到一起。
•把整顿好的数据刷盘。Index Disk 保留 entry 的 index，对应 entry 在 Logger Disks 的 offset。
读写拆散
读取数据时，首先从 Memory Cache 中读取数据，如果数据不存在，才会去 Index Disk 和 Logger Disk 读取数据。而写数据是实时落盘到 Journal Disk，这样实现了读写隔离。
强一致性
数据能够实时刷盘到 Journal Disk, 保障了数据的强一致性。
灵便 SLA
对于写性能要求高的业务场景，能够独自增强 Journal 盘性能，而对于读性能要求高的场景，能够增强 Ledger Disk 和 Index Disk 的性能。
Pulsar 中的应用
Pulsar 的架构图如下：
每次 Producer 生成的音讯实时落盘后，给 Producer 返回一个 ACK。
Consumer 生产音讯后，还会批改 Cursor 中保留的 offset，并且也会记录到 BookKeeper。这样保障了 Cursor 的一致性。