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

原作者：Sijie Guo
翻译: StreamNative——Sijia

在前一篇文章中，我介绍了 Apache BookKeeper 如何保证其持久性、一致性、高可用与低延迟。希望前一篇文章能够为你选择 BookKeeper 作为实时工作负载存储平台提供支持。在本文中，我将会介绍 Apache BookKeeper 一系列具有竞争力的功能，主要包括 I/O 隔离、数据分布、可扩展性与可操作性。

I/O 隔离

可预测的低延迟对实时应用程序而言十分重要，特别是关键在线服务（例如：核心业务服务、数据库等）。以消息系统为例，在大多数消息系统中，速度较慢的 consumer 可能会导致消息积压，这有可能会进一步导致总体性能下降。问题在于，较慢的 consumer 迫使存储系统从持久存储介质中读取数据，这会导致 I/O 抖动及页面缓存的换入换出。当存储 I/O 组件共享用于写入、追尾读、追赶读的单一路径时，就会发生这种情况。

在 BookKeeper 中，bookie（单个 BookKeeper 存储节点）旨在使用三条独立的 I/O 路径，分别用于写入、追尾读、追赶读。分离这三个路径很重要，因为写入和追尾读对可预测的低延迟有较高要求，而追赶读则对吞吐量的要求比较高。在这些工作负载之间提供物理隔离意味着 BookKeeper 能够充分利用以下几点：

• 写入时，网络入口带宽和顺序写入带宽
• 读取时，多个 ledger 磁盘上网络出口带宽和 IPOS（每秒输入/输出操作数）

I/O 隔离意味着 BookKeeper 能够在不妨碍其他优势的条件下，同时提供上述优势。更多信息，可参阅这里，此博客主要介绍了关于 bookie 存储的相关内容。

数据分布

建立在 BookKeeper 上的服务（比如：Apache Pulsar）将日志流作为分片 ledgers 存储在 BookKeeper 上。这些分片（ledgers）会被复制到多个 bookie。这样可以使数据存放有尽可能多的选择，从而实现高可用、流量负载均衡、运维简单等。我将从部署和运维的角度介绍一些优势。

首先，单个日志流的存储容量永远不会受到单个主机存储容量的限制。只要整个集群有足够的容量，就可以存储数据。

其次，在扩展 BookKeeper 集群时，不涉及日志流再平衡。管理员可以通过增加新设备来扩展 BookKeeper 集群。集群可以发现新的 bookie，并向其写入分片。BookKeeper 还提供了多种分布策略，包括机架感知、区域感知、基于重量的布局策略等，以实现尽可能多的布局方式。

再次，BookKeeper 能够在发生机器故障时更快、更高效地进行副本修复。当一个分片由于机器故障丢失或由于磁盘故障损坏时，BookKeeper 可以确定哪些分片需要修复（重新复制 entry 以满足副本要求），并从多个主机同时进行修复。

相比于 Apache Kafka 这样以分区为中心的系统，BookKeeper 可水平扩展的性能更具优势。在 Apache Kafka 中，日志流（又称 Kafka 分区）仅顺序存储在一部分机器上，并且扩展 Kafka 集群需要大量数据进行再平衡，而再平衡操作本身就很消耗资源、易出错，且运维复杂。另外，在以分区为中心的系统上，损坏的单个磁盘要求系统复制整个日志流到新磁盘，以满足多副本要求。

所有的日志分片跨 N 个可能的 bookie 复制到可配置数量的 bookie 上（图示中副本数为 3）。日志分片均匀分布，以在不重新平衡的条件下实现水平扩展。

可扩展

作为一个实时日志流存储平台，能够随着流量的增加或写入系统的数据增多而进行扩展是十分重要的。Apache BookKeeper 基于以下几点实现其可扩展性：

Ledger / 流的数量

流可扩展性能够支持大量日志流的存储，在 ledger 或流的数量从数百增为数百万时，其他性能不受影响。实现流可伸缩性的关键在于存储格式。如果 ledger 和流都存储在专用文件中，流伸缩性的实现就会出现问题，因为当这些文件定期从页面缓存刷新到磁盘时，I/O 会分散在磁盘上。BookKeeper 以交错存储格式存储 ledger 和流的数据，整合来自不同 ledger 和流的 entry，并存储在大文件中，然后进行索引。这既减少了文件数量，也减少了 I/O 争用，允许 BookKeeper 为大量 ledger 和流进行扩展。

Bookie 的数量

Bookie 可伸缩性，即日志流存储通过添加 bookie（BookKeeper 中的存储节点）来支持迅速增加的流量。在 BookKeeper 中，bookie 之间不直接交互。这使得 BookKeeper 只需添加新机器即可扩展集群。同样，由于 BookKeeper 在 bookie 上分发数据的方式，在扩展 BookKeeper 集群时，分区数据并不昂贵，也不会耗尽系统网络和 I/O 带宽。不管数据如何分配，这都可以增加集群的大小。雅虎（Yahoo!）和推特（Twitter）都在使用 BookKeeper，在单个集群上有成百上千个 bookie。

客户端的数量

客户端可伸展性，即日志流存储支持大量并发客户端并支持大量扇出的能力。BookKeeper 可在多处实现此功能：

• 客户端和服务器都完全使用 Netty 来实现异步网络 I/O。所有网络 I/O 使用单个 TCP 连接进行多路复用，并且都是异步的。以很少的资源消耗实现了非常高效的管道和极高的吞吐量。
• 复制数据到多个 bookie。在 bookie 副本间，数据是完全相同的。在 Apache Kafka 这样的系统中，客户端只能从 leader 节点读取数据。而 BookKeeper 的客户端可以从任一 bookie 副本中读取数据（这种读取可重复）。这不仅实现了较高的读可用性，还能平均分配读取流量。
• 由于客户端能够重复地从任一 bookie 副本读取数据，应用程序可以配置更多的副本来实现更高的读取扇出。

单流吞吐量

应用程序可以通过使用更多的流或增加 bookie 来提高吞吐量。另外，BookKeeper 还可以通过增加 ensemble 大小（ensemble 是用于存储给定 ledger 或流的 bookie 子集），并在 bookie 之间分段数据来调节单流吞吐量。对于那些需要对单个流进行数据排序的有状态应用程序而言，这是至关重要的。

运维简单

Apache BookKeeper 旨在运维简单。在系统运行时，可以通过添加 bookie 节点轻易扩展容量。如果一个 bookie 节点不再自动可用，此 bookie 中包含的所有 entry 将被标记为"已复制"，BookKeeper 自动恢复守护进程自动将其他可用副本中的数据再复制到新的 bookie 节点。在运行 bookie 节点时，BookKeeper 提供只读模式。在某些情况下，例如：磁盘已满、磁盘损坏，bookie 自动变为只读模式。只读模式下，bookie 不允许写入数据，但仍可以读取流量。这种自愈性减少了许多运维上的痛点问题。

另外，BookKeeper 提供了多种管理集群的方法，包括使用管理 CLI 工具、Java 管理库、HTTP REST API 等。REST API 具有编写外挂工具或在现有工具中使用某些操作的灵活性。

安全性

Apache BookKeeper 支持可插拔的身份验证机制，应用程序可以使用该机制进行自身身份验证。BookKeeper 也可以配置为支持多种身份验证机制。身份验证程序的目的在于建立客户端的身份，并为客户端分配一个标识符。该标识符可用来确定客户端被授权执行的操作。默认情况下，BookKeeper 支持两种身份验证程序：TLS 和 SASL（Kerberos）。

总结

如果你对 BookKeeper、其发展过程或用例感兴趣，欢迎观看我和 Matteo Merli 在 Strata 会议上的演讲，点击这里观看视频。

如果你对 BookKeeper 或 DistributedLog 感兴趣，可以通过 BookKeeper email list 或 BookKeeper Slack channel 加入我们的社区。还可以点击这里下载最新版本（4.5.0 版）的 BookKeeper。

想要了解更多关于 Apache BookKeeper 项目的信息，请访问官方网站：http://bookkeeper.apache.org。