原作者：Sijie Guo
翻译：StreamNative-Sijia
Apache BookKeeper 针对实时工作负载进行了优化，是可扩展、可容错、低延迟的日志存储服务。BookKeeper 最初由雅虎研究院（Yahoo! Research）开发，而后于 2011 年作为 Apache ZooKeeper 的子项目孵化，最终在 2015 年 1 月作为 Apache 的顶级项目问世。自最初引入以来，诸如 Twitter、Yahoo!、Salesforce 等公司广泛使用 BookKeeper 在多种用例中存储、服务重要数据。在本文中，我将介绍 BookKeeper 如何确保持久性、一致性与低延迟，还会重点介绍 BookKeeper 的保证和关键特性，这些内容都是开源的。
在上一篇文章中，我对 Apache BookKeeper 进行了技术层面的概述，并介绍了一些相关的概念和术语。一个 BookKeeper 集群包括：
- Bookies：一组独立的存储服务器
- 元数据存储系统：用于服务发现和元数据管理
BookKeeper 客户端可以使用较高级别的 DistributedLog API（也称为日志流 API）或较低级别的 ledger API。Ledger API 允许用户直接与 bookies 交互。下图即为 BookKeeper 安装的典型示例。
流存储要求
在 Apache BookKeeper 简介一文中已经提到，实时存储平台应该同时满足以下要求：
- 即使在强持久性条件下，客户端也能够以极低的延迟（小于 5 毫秒）读写 entry 流
- 能够持久、一致、容错地存储数据
- 在写入时，客户端能够进行流式传输或追尾传输
- 有效存储数据，支持访问历史数据与实时数据
BookKeeper 通过提供以下保证来同时满足上述各项要求：
| 保证 | 说明 |
|---|---|
| 多副本 | 复制数据并将其持久存储在多台机器上，或存储在多个数据中心以保证容错。 |
| 持久性 | 复制成功后，可以实现持久存储数据。在向客户端发送确认前，强制启用 fsync。 |
| 一致性 | 通过简单、可重复读取的一致性模型保证不同读者之间的一致性。 |
| 可用性 | 通过 ensemble 更改和推测读取提高读写可用性，同时增强一致性和持久性。 |
| 低延迟 | 通过 I/O 隔离来保护读写延迟，同时保持一致性和持久性。 |
多副本
BookKeeper 在一个数据中心内的多个机器上，或是多个数据中心之间，复制每条数据记录并存储多个副本（通常是 3 个或 5 个副本）。一些分布式系统使用主/从或管道复制算法在副本之间复制数据（例如，Apache HDFS、Ceph、Kafka 等），BookKeeper 的不同之处在于使用 quorum-vote 并行复制算法来复制数据，以确保可预测的低延迟。图 2 即为 BookKeeper 集成中的多副本。
在上图中：
- 从 BookKeeper 集群中（自动）选择一组 bookies（图例中为 bookies 1-5）。这一组 bookies 即为给定 ledger 上用于存储数据记录的ensemble。
- Ledger 中的数据分布在 bookies 的 ensemble 中。也就是说，每条记录都存有多个副本。用户可以在客户端级别配置副本数，即写入 quorum 大小。在上图中，写入 quorum 大小为 3，即记录写入到 bookie 2、bookie 3 与 bookie 4。
- 客户端向 ensemble 中写入数据记录时，需要等待直至有指定数量的副本发送确认（ack）。副本数即为 ack quorum 大小。接收到指定数量的 ack 后，客户端默认写入成功。在上图中，ack quorum 大小为 2，也就是说，比如 bookie 3 和 bookie 4 存储数据记录，则向客户端发送一条确认。
- 当 bookie 发生故障时，ensemble 的组成会发生变化。正常的 bookies 会取代终止的 bookies，这种取代可能只是暂时的。例如：如果 Bookie 5 终止，Bookie x 可能会取代它。
多副本：核心理念
BookKeeper 多副本基于以下核心理念：
- 日志流面向记录而不是面向字节。这意味着，数据总是存储为不可分割的记录（包括元数据），而不是存储为单个字节数组。
- 日志（流）中记录的顺序与记录副本的实际存储顺序分离。
这两个核心理念确保 BookKeeper 多副本能够实现以下几项功能：
- 为向 bookies 写入记录提供多种选择，从而确保即使集群中多个 bookies 终止或运行缓慢，写入操作仍然可以完成（只要有足够的容量来处理负载）。可以通过改变 ensemble 来实现。
- 通过增加 ensemble 大小来最大化单个日志（流）的带宽，以使单个日志不受一台或一小组机器的限制。可以通过将 ensemble 大小配置为大于写入 quorum 大小来实现。
- 通过调整 ack quorum 大小来改善追加时的延迟。这对于确保 BookKeeper 的低延迟十分重要，同时还可以提供一致性与持久性保证。
- 通过多对多副本恢复提供快速再复制（再复制为复制不足的记录创建更多副本，例如：副本数小于写入 quorum 大小）。所有的 bookies 都可以作为记录副本的提供者与接受者。
持久性
保证复制每条写入 BookKeeper 的数据记录，并持久化到指定数量的 bookies 中。可以通过使用磁盘 fsync 和写入确认来实现。
- 在单个 bookie 上，将确认发送给客户端之前，数据记录已明确写入（启用 fsync）磁盘，以便在发生故障时能够持久保存数据。这样可以保证数据写入到持久化存储中不依赖电源，可以被重新读取使用。
- 在单个集群内，复制数据记录到多个 bookies，以实现容错。
- 仅当客户端收到指定数量（通过 ack quorum 大小指定）的 bookies 响应时，才 ack 数据记录。
最新的 NoSQL 类型数据库、分布式文件系统和消息系统（例如：Apache Kafka）都假定：保证最佳持久化的有效方式是将数据复制到多个节点的内存中。但问题是，这些系统允许潜在的数据丢失。BookKeeper 旨在提供更强的持久性保证，完全防止数据丢失，从而满足企业的严格要求。
一致性
保证一致性是分布式系统中的常见问题，尤其是在引入多副本以确保持久性和高可用时。BookKeeper 为存储在日志中的数据提供了简单而强大的一致性保证（可重复读取的一致性）：
- 如果记录已被引用程序 ack，则必须立即可读。
- 如果记录被读取一次，则必须始终可读。
- 如果记录 R 成功写入，则在 R之前的所有记录都已成功提交/保存，并且将始终可读。
- 在不同读者之间，存储记录的顺序必须完全相同且可重复。
这种可重复读取的一致性由 BookKeeper 中的 LastAddConfirmed（LAC）协议实现。
高可用
在 CAP（Consistency：一致性、Availability：高可用、Partition tolerance：分区容错）条件下，BookKeeper 是一个 CP 系统。但实际上，即使存在硬件、网络或其他故障，Apache BookKeeper 仍然可以提供高可用性。为保证写入与读取的高可用性能，BookKeeper 采用了以下机制：
| 高可用类型 | 机制 | 说明 |
|---|---|---|
| 写入高可用 | Ensemble 变化 | 当正在写入数据的 bookie 发生故障时，客户端会重新选择数据的放置）。这样可以确保：在集群中剩余的 bookie 数量充足时，写入操作总可以实现。 |
| 读取高可用 | 随机读 | 一些系统仅从一个指定为 leader 的存储节点读取数据，例如：Apache Kafka。BookKeeper 的不同之处在于可以使客户端从ensemble 中的任一 bookie 读取记录。这有助于将读取流量分散到各个 bookie，同时还能减少追尾读的延迟。 |
低延迟
强持久性和一致性是分布式系统的复杂问题，特别是当分布式系统还需要满足企业级低延迟时。BookKeeper 通过以下方式满足这些要求：
- 在单个 bookie 上，bookie 服务器旨在用于不同工作负载（写入、追尾读、追赶读/随机读）之间的 I/O 隔离。在 journal 上部署 group-committing 机制以平衡延迟与吞吐量。
- 采用 quorum-vote 并行复制 schema 缓解由于网络故障、JVM 垃圾回收暂停和磁盘运行缓慢引起的延迟损失。这样不仅可以改善追尾延迟，还能保证可预测的 p99 低延迟。
- 采用长轮询机制在 ack 并确认新记录后，立刻向追尾的写入者发出通知并发送记录。
最后，值得一提的是，明确 fsync 和写入确认的持久性与可重复的读取一致性对于状态处理（尤其是流应用程序的 effectively-once 处理）非常重要。
总结
本文解释了 BookKeeper 如何保证其持久性、一致性、高可用与低延迟。希望本文为你选择 BookKeeper 作为实时工作负载存储平台提供了强有力的支持。在后续文章中，我会深入介绍 BookKeeper 如何复制数据，以及它采用了怎样的机制能够在保证低延迟时，同样保证一致性与持久性。
如果你对 BookKeeper 或 DistributedLog 感兴趣，可以通过 BookKeeper email list 或 BookKeeper Slack channel 加入我们的社区。还可以点击这里下载最新版本（4.5.0 版）的 BookKeeper。
