为什么选择 Apache BookKeeper？（第 1 部分）

原作者：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 集成中的多副本。

在上图中：

1. 从 BookKeeper 集群中（自动）选择一组 bookies（图例中为 bookies 1-5）。这一组 bookies 即为给定 ledger 上用于存储数据记录的ensemble。
2. Ledger 中的数据分布在 bookies 的 ensemble 中。也就是说，每条记录都存有多个副本。用户可以在客户端级别配置副本数，即写入 quorum 大小。在上图中，写入 quorum 大小为 3，即记录写入到 bookie 2、bookie 3 与 bookie 4。
3. 客户端向 ensemble 中写入数据记录时，需要等待直至有指定数量的副本发送确认（ack）。副本数即为 ack quorum 大小。接收到指定数量的 ack 后，客户端默认写入成功。在上图中，ack quorum 大小为 2，也就是说，比如 bookie 3 和 bookie 4 存储数据记录，则向客户端发送一条确认。
4. 当 bookie 发生故障时，ensemble 的组成会发生变化。正常的 bookies 会取代终止的 bookies，这种取代可能只是暂时的。例如：如果 Bookie 5 终止，Bookie x 可能会取代它。

多副本：核心理念

BookKeeper 多副本基于以下核心理念：

1. 日志流面向记录而不是面向字节。这意味着，数据总是存储为不可分割的记录（包括元数据），而不是存储为单个字节数组。
2. 日志（流）中记录的顺序与记录副本的实际存储顺序分离。

这两个核心理念确保 BookKeeper 多副本能够实现以下几项功能：

• 为向 bookies 写入记录提供多种选择，从而确保即使集群中多个 bookies 终止或运行缓慢，写入操作仍然可以完成（只要有足够的容量来处理负载）。可以通过改变 ensemble 来实现。
• 通过增加 ensemble 大小来最大化单个日志（流）的带宽，以使单个日志不受一台或一小组机器的限制。可以通过将 ensemble 大小配置为大于写入 quorum 大小来实现。
• 通过调整 ack quorum 大小来改善追加时的延迟。这对于确保 BookKeeper 的低延迟十分重要，同时还可以提供一致性与持久性保证。
• 通过多对多副本恢复提供快速再复制（再复制为复制不足的记录创建更多副本，例如：副本数小于写入 quorum 大小）。所有的 bookies 都可以作为记录副本的提供者与接受者。

持久性

保证复制每条写入 BookKeeper 的数据记录，并持久化到指定数量的 bookies 中。可以通过使用磁盘 fsync 和写入确认来实现。

1. 在单个 bookie 上，将确认发送给客户端之前，数据记录已明确写入（启用 fsync）磁盘，以便在发生故障时能够持久保存数据。这样可以保证数据写入到持久化存储中不依赖电源，可以被重新读取使用。
2. 在单个集群内，复制数据记录到多个 bookies，以实现容错。
3. 仅当客户端收到指定数量（通过 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。

想要了解更多关于 Apache BookKeeper 项目的信息，请访问官方网站：http://bookkeeper.apache.org，或在 Twitter 上关注 @asfbookkeeper 和 @distributedlog。