OceanBase4.0 跟我学--分布式到底可靠不可靠，到底丢不丢数--终于学完了

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2680人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6群均已爆满，新人进7群近400，8群，7群满400开9群)
最近一直在学习OceanBase,对于分布式事务中的一些细节还是比较看重的，上一篇的白皮书中提到了，4.0在分布式事务中的改进，尤其2PC的部分。但个人因素，虽然看了多遍，但对于优化的点还是有一些需要再理解和深入的部分，同时对于分布式数据库的事务的稳定性，或者直白的说，丢不丢数这个事情，我也是比较在意的，所以也想通过研究白皮书中的理论来确认，在理论的部分OB在分布式事务中是严谨的。在搜寻中，发现这篇白皮书是针对我关心的部分进行论述的，所以这篇文章应该能确定我的那些疑问，此篇为这个系列的最后一篇。

OceanBase4.0 跟我学--分布式到底可靠不可靠，到底丢不丢数-- 核心实现

OceanBase4.0 跟我学--分布式到底可靠不可靠，到底丢不丢数 ---- 什么是PALF

4 和事务引擎的交互

本节介绍 PALF 的特性，这些特性是基于共识协议的实现，专为 OceanBase 数据库的事务引擎设计的。

4.1 显式复制结果

如果网络故障导致leader发生切换，则先前的leader可能不清楚追加的日志条目是否已提交，这些日志被称为待定日志。待定日志可能会给事务引擎带来复杂性。

例如，事务引擎生成一个事务的提交记录并将其追加到 PALF。如果leader意外丢失其领导地位，则事务引擎必须根据提交记录判断持久化来决定是提交还是回滚事务。

PALF 保证，除非leader崩溃或网络永久中断，否则事务引擎将显式地收到复制结果的通知，leader负责提交日志并通知结果。如果领导权已转移到另一个副本，则先前的leader会将自身切换为待定跟随者。当待定follower从新leader那里收到日志时，待定日志的复制结果将变得明确（已提交或已截断）。已提交日志的复制结果将通过调用成功函数来通知，被截断的日志将通过调用失败函数来通知为复制失败。这就是为什么先前的leader必须切换为待定跟随者并等待来自新leader的日志，然后才能成为跟随者。

这段的小结：设计的思路为什么失败的Leader 要转换为待定跟随者。

对于每条记录，只会调用回调函数中的一个，并且最多调用一次。

如图 6a 所示，先前的 A 提交了 log1、log2 和 log3，它们已被追加到副本 A，但尚未复制。然后 A 暂时与 B 和 C 分区隔离，C 被选为leader并从 B 重新确认了 log2（图 6b）。网络恢复后（图 6c），副本 A 由于其选举租约已过期而转换为待定跟随者。它接收来自新leader C 的日志，A 中的 log2 将被接受，因为它已被新leader提交。因此，副本 A 通过调用函数将 log2 的复制结果通知给数据库。相比之下，A 中的 log3 将被截断，因为来自 C 的另一个 log3 包含更大的 ProposalID。先前leader A 复制的 log3 未能达成共识，因此副本 A 调用失败函数来通知数据库。

请注意，如果leader A 在图 6a 中崩溃，PALF 不需要直接将复制结果通知给数据库，因为内存中的所有状态都将丢失。当它开始恢复时，事务引擎切换到follower，接收来自新leader的日志，并重放本地日志以恢复事务。如果先前leader的网络中断，则它无法提供复制结果，因为新leader无法访问它。如果网络恢复，则先前leader可以接收日志并确定正在处理的日志是否已提交。

共识协议的状态机安全属性由显式复制结果来保证。如果一个日志已被提交，则它必须应用在leader并将被重放到follower。如果 PALF 未能就该日志达成共识，则先前leader的状态机将通过调用失败函数来回滚。

4.2 变更序列号数据同步工具（例如变更数据捕获）

通常按日志顺序消费事务；然而，LSN 不足以跟踪事务的顺序，因为它是在单个 PALF 组内本地排序的。为了实现可扩展性，数据分区通常分布在多个流中。如果不同的事务修改不同流中的数据分区，则其日志的 LSN 是不可比较的。为了使用跨 PALF 组的日志跟踪事务的顺序，一种自然的方法是在日志条目的有效负载中记录事务的提交版本，正如一些系统所做的那样 [18, 42]。这种方法确实有效，但它也有缺点。例如，由于事务的并行执行（即，将较小的 LSN 分配给具有较大提交版本的事务的日志），提交版本可能不会随着 LSN 严格递增。这种方法会产生日志消费者解析日志的有效负载，这会产生额外的开销。

PALF 提供了另一个日志条目标识符------变更序列号 (CSN)，它与 LSN 保持一致性，并反映了跨多个 PALF 组的事务顺序。CSN 是一个 64 位整数，存储在每个日志条头的头部。PALF 不推断 CSN 的含义，这意味着维护和识别 CSN 的开销非常小。leader中的日志排序器在调用追加方法时为日志分配 LSN 和 CSN。PALF 维护 CSN 的一个不变量：在 PALF 组内单调递增。在每个 PALF 组内，对于任意两个日志 α 和 β，如果 α 的 LSN 大于或等于 β 的 LSN，则 α 的 CSN 必须大于或等于 β 的 CSN。正式地：

𝐿𝑆𝑁𝛼 ≥ 𝐿𝑆𝑁𝛽 → 𝐶𝑆𝑁𝛼 ≥ 𝐶𝑆𝑁𝛽, ∀𝛼, 𝛽.

该不变量保证了 CSN 在 PALF 组内单调递增，从而与 LSN 的顺序保持一致。图 5 显示了日志的 LSN 和 CSN 之间关系的可视化。𝐶𝑆𝑁 与日志条目一起持久化。因此，即使leader崩溃，上述不变量也始终有效。

PALF 提供了另一个关键保证：对于追加方法，其输入参数 RefCSN 和其输出参数 CSN 始终遵循 CSN >= RefCSN。RefCSN 用作因果参考；该保证表明日志条目必须在 RefCSN 发生的事件之后追加。因此，如果 RefCSN 是一个全局有意义的值，则日志的 CSN 可以反映系统范围的顺序。

OceanBase 数据库使用 CSN 为事务提供全局有意义的提交版本。当一个事务即将提交时，事务引擎从全局时间戳的获取一个时间戳，并将提交记录附加到该时间戳作为 RefCSN。追加方法返回的 CSN 跟踪 RefCSN 指示的顺序，并充当事务的提交版本。请注意，CSN 不是由全局时间戳预言机生成的，其值可能大于当前全局时间戳。因此，对于从全局时间戳产生的主机获取较小可读版本的未来读取请求，该事务可能是不可见的。为了避免这种情况，事务引擎在全局时间戳大于 CSN 之前不会响应客户端。通过事务引擎和 PALF 之间的协作，CSN 成功地跟踪了跨 PALF 组的事务顺序。

另一个受益于 CSN 的数据库特性是follower读取。follower读取使follwer副本能够以最终一致性保证来服务只读请求，从而减少延迟。具有 T 的读取请求，可以在follower中读取完整数据，要求所有 CSN 小于 T 的日志都已在follower中重放，并且任何未来写入的提交版本都应大于 T。CSN 的单调递增特性自然地提供了这种保证。日志以 LSN 的顺序复制并重放到follwer，这与 CSN 的顺序一致。如果 CSN 为 T 的日志已在follower中重放，则后续日志的 CSN 必须大于 T。与其他通过定期广播特殊命令（例如，封闭时间戳 [43]）来推进follower中可读时间戳的分布式数据库相比，OceanBase 数据库的follower读取功能不需要额外的机制。

5 数据变更同步

除了服务事务之外，分布式数据库还充当数据流的来源。可以部署下游应用程序，通过同步物理日志中记录的数据更改来提供各种服务。本节介绍 OceanBase 中两种典型的物理日志同步场景，描述它们给 PALF 带来的挑战，并阐述如何利用 PALF 的特性来应对这些挑战。

5.1 概述

当客户端将数据写入数据库时，修改记录会被追加到 PALF 组的leader，并复制到follower。除了在数据库内部复制日志之外，还可以将数据更改同步到数据库外部以实现更丰富的功能。OceanBase 数据库中有两种典型的场景：物理备库和数据库恢复。

如图 7 所示，物理备库是一个独立的数据库，其中的数据与主库完全相同。它可以服务一部分读取请求，以减轻主库的压力。与传统的primary-backup架构相比，它提供了更高的可用性，因为每个数据库集群都可以提高抵御故障的能力。物理备库最重要的特性之一是数据库级别的数据保护和灾难恢复，如果原始主库变得不可用，可以通过故障转移操作将物理备库切换为主库，这使其区别于副本级别的保护，例如 Paxos learners [7]。在生产数据库中，数据库恢复是高可靠性功能的核心组成部分。如果由于存储介质损坏或人为错误导致数据丢失，则可以使用存储在离线存储（例如 NFS 或云对象存储）中的归档日志来恢复相同的数据库。

物理备库或数据库恢复背后的基本思想是相似的：将物理日志中记录的数据更改从主库或外部存储同步到备库或恢复中的数据库。对于 OceanBase 数据库，实现这些功能的挑战之一是将日志从一个 PALF 组（或外部存储）同步到另一个 PALF 组。此外，这些 PALF 组应该是独立可用的。一种简单的方法是从主库中的 PALF 组读取日志条目，并将日志作为记录追加到备库中相应的 PALF 组（图 3）。但是，共识协议会将一个日志头附加到追加的记录以进行复制，这会导致主库的日志格式与备库的日志格式不一致。

5.2 PALF 组镜像

我们将跨 PALF 组同步数据更改的需求抽象为一个原语：PALF 组镜像，它是一个独立的 PALF 组，执行与 §3.4 中描述的相同的共识协议。它维护数据更改前缀的镜像，这些前缀存储在主 PALF 组或外部存储中。PALF 组镜像可以独立重新配置，并根据需要切换为主组。

主 PALF 组和 PALF 组镜像之间最重要的区别之一是写入日志记录的模式。在主 PALF 组中，一个日志记录被追加到 PALF 组，附加一个日志头，并通过共识协议复制到副本。对于 PALF 组镜像，它只接受主 PALF 组提交的日志。当一个已提交的日志镜像到leader时，日志头的某些字段（例如 ProposalID）将被替换为leader自己的值。leader重用原始日志条目的 LSN 和 CSN，将日志存储到 LSN，并将日志复制到follower。

提出了两种访问模式：Primary 和 Mirror，以区分主 PALF 组及其镜像。可以通过故障转移或切换操作来切换 PALF 组的访问模式。问题是如何以原子方式将新的访问模式广播到所有副本。显然，访问模式的原子广播等同于共识问题 [12]。因此，实现了一个基本的 Paxos 来切换 PALF 组的访问模式，并将每个副本的访问模式存储到 MetaStorage。

有了 PALF 组镜像原语，为 OceanBase 数据库构建数据更改同步架构就变得很自然了。如图 7 所示，物理备库中的所有 PALF 组都是主库中 PALF 组的镜像，恢复中的数据库中的所有 PALF 组都是存储在外部存储中的数据更改的镜像。在事务日志被主 PALF 组提交后，日志归档器从每个 PALF 组读取日志，然后将它们存储在外部存储中或传输到备库。在物理备库中，恢复器从归档器接收日志（从外部存储获取日志）并将日志镜像到 PALF 组镜像的领导者。在日志被领导者提交后，它们将被重放到所有副本（包括领导者）中的事务引擎。因此，在主库中执行的事务将被同步到物理备库；数据库恢复执行类似的过程。

值得注意的是，备库中事务引擎和 PALF 组之间的交互与主库中的不同。在备库中，事务引擎执行标准的 RSM 模型，所有副本都只是从 PALF 副本读取日志记录并将数据更改重放到数据分区。因此，即使 PALF 副本的角色可能是领导者，事务引擎的角色也始终是跟随者。

5.3 独立重配置

许多共识协议的实现 [2, 15] 将重配置命令作为普通的日志条目存储和复制；然而，这种嵌入式方法可能对 PALF 组镜像的可用性有害。首先，事务引擎必须过滤无用的重配置命令，因为它们只关系到它们写入的数据更改。其次，PALF 组镜像的成员与主 PALF 组的成员不同，它应该能够独立地进行重配置。但是，PALF 组镜像只能接受来自其主组的日志。因此，无法通过将重配置命令作为普通日志记录写入来重配置物理备库。

PALF 的重配置类似于 Raft [33] 中描述的单服务器方法，一次只能添加或删除一个副本。领导者复制一个记录新成员关系的重配置日志，并使用新成员关系的确认来提交它。每个副本在收到较新的重配置日志后都会更新其自身的成员关系。为了使 PALF 组镜像能够独立重配置，PALF 将重配置日志存储在与 LogStorage 分离的 MetaStorage 中。

独立的元数据存储并不像看起来那么简单，它可能会损害共识协议的安全性，以下示例演示了由独立的元数据存储引起的一些棘手问题。如图 8a 所示，LSN 小于或等于 5 的所有日志都已由领导者 A 提交，其中 A、D 和 E 拥有最新的日志，但 B 和 C 落后。领导者 A 希望通过将新成员关系复制到新成员关系中的副本，将副本 D 和 E 从组中删除；可能会发生已提交日志丢失的安全风险。具体来说，一些已提交的日志（3、4、5）尚未被任何新成员关系（A、B、C）的大多数刷新。如果副本 A 在 D 和 E 被删除后崩溃，这些日志将丢失。图 8b 说明了连续重配置集群时可能出现脑裂 [11] 的情况。在通过删除副本 E 并添加副本 F 将副本 E 替换为副本 F 之后，副本 B 和 F 可以投票给 A，但副本 C 和 E 投票给 D。结果，将选出两个领导者 A 和 D。

PALF 对重配置和领导者选举引入了约束，以解决这些异常情况。对于重配置，领导者会连同一个日志屏障一起向跟随者发布新的配置。该屏障是领导者发布配置时日志的尾部。每个跟随者都拒绝接受配置，直到其在屏障之前刷新的日志为止。因此，副本 B 或 C 在接受屏障之前的所有日志（3、4 和 5）之前不会接受新的配置（图 8a）。对于领导者选举，PALF 维护配置版本以指示成员关系的版本；重配置操作将递增它。配置版本充当主要的选举优先级，因此副本 D 不会被选为领导者，因为其配置版本低于副本 C 的配置版本（图 8b）。

这里认为，即使独立的元数据存储给共识协议带来了额外的复杂性，但它仍然是有利的，因为它使元信息对日志消费者不可见，并使 PALF 组镜像能够独立地重新配置集群。

6 性能优化

如 §2.2 所述，事务引擎在单个 PALF 组上施加了大量多个数据分区的重做日志，这可能使 PALF 成为瓶颈。本节介绍如何系统地设计 PALF 以最大限度地提高 PALF 的性能。

流水线复制

为了提高吞吐量，PALF 利用现代多核处理器并发地处理和复制日志。多个日志的共识相关状态缓存在内存中的滑动窗口中，以避免 CPU 缓存未命中。因此，可以重叠多个日志的复制阶段。

自适应组复制

共识协议给数据库带来了额外的开销，其中至少包含两个网络消息（日志复制和确认）和一些 CPU 周期。在一个实例中批量处理多个日志条目是减少共识带来的开销的常用方法。批量处理日志的核心是如何确定合适的批处理大小。定期批量处理日志或在 I/O 工作器空闲时立即批量处理日志（反馈）是两种常用的方法。但是，前者可能会在低并发下导致额外的延迟。后者可能会损害吞吐量，因为大量的小请求可能会在高并发下使 I/O 设备不堪重负。

PALF 使用自适应组大小复制日志，以平衡延迟和吞吐量。领导者将追加的日志缓存在一个组缓冲区中。"冻结"操作会将缓存的日志打包到一个组日志条目中，然后将其复制到跟随者。组日志条目中日志条目的数量（组因子）取决于执行"冻结"操作的频率。自适应组复制的关键思想是在低并发下定期冻结日志，在高并发下根据 I/O 工作器反馈冻结日志，但客户端的并发度很难直接衡量。假设 n 个客户端并发地将记录 r 追加到 PALF。如果所有客户端的日志都已追加，但尚未提交，则应立即将这些缓存的日志冻结为一个组日志 g~l~，而无需等待固定的时间间隔。因此，并发度 (n) 与组因子 (g~f~，缓存的日志数) 相关，这可以通过计数日志来轻松衡量。该关系可以形式化为：

g~f~ = size( g~l~ ) / size( r ) ∝ (n * size( r )) / size( r ) = n ∝ CPUCores.

通过实验，并发度与 PALF 占用的 CPU 核心数成正比，因此组因子阈值可以由硬件资源决定，而无需手动调整批处理大小。如果组因子小于阈值，则意味着并发性较低，如果 I/O 工作器空闲，PALF 将冻结日志，否则，PALF 将以固定的时间间隔（默认为 1 毫秒）冻结日志。与现有的批处理算法 [20] 相比，自适应组复制简单且足够可预测，并且适用于生产部署。

无锁写入路径

如果发生严重的争用，高并发不仅不能提高吞吐量，反而会降低性能。因此，PALF 设计了一条无锁写入路径，以避免线程之间的争用。写入路径中的主要组件是日志排序器和组缓冲区。日志排序器按顺序为日志条目分配 LSN。我们实现了一个无锁日志排序器，以避免其成为瓶颈。当一个线程将日志追加到 PALF 时，它以原子方式将 LSN 尾部的值加载到一个临时变量，更新该临时值，并使用原子比较和交换操作将其存储到 LSN 尾部。如果由于并发追加导致比较和交换操作失败，则该线程将重新加载 LSN 尾部并循环以再次获取 LSN [21]。

在获取 LSN 后，多个线程并发地将日志条目填充到组缓冲区。LSN 不仅充当磁盘上日志条目的地址，还充当组缓冲区中日志条目的偏移量，这意味着为日志条目保留的缓冲区永远不会与其他日志条目重叠。因此，组缓冲区不是竞争资源，多个线程可以并发地将日志条目填充到不同的偏移量，而没有任何锁开销。

7 设计选择与讨论Raft 与 PALF

Raft 和 PALF 本质上都是 Paxos 协议 [27] 的实现。PALF 为了简单起见采用了 Raft 的日志复制，以下是一些值得讨论的差异。

状态机模型

PALF 采用复制的 WAL 模型来服务 OceanBase 数据库 (§3.1)，而 Raft 是在 RSM 模型的设置下构建的。领导者选举。 在 Raft 中，领导者的日志必须至少与大多数副本中的任何副本的日志一样新。在 PALF 中，选举优先级控制哪个副本可以被选为领导者，配置版本充当主要的选举优先级 (§5.3)。为了正确性，引入了日志重新确认 (§3.4)，以确保候选者在接任领导者之前拥有大多数中最长的日志。待定跟随者。 PALF 为从领导者到跟随者的转换添加了一个新阶段，以在发生某些故障时确定日志的复制结果 (§3.4)。重配置。 Raft 的重配置命令是一个普通的日志条目，但 PALF 将其解耦为元条目，用于独立的 PALF 组镜像 (§5.3)。日志索引。 Raft 采用连续的数字日志索引进行日志复制。PALF 采用两个日志条目标识符：LSN 和 CSN。连续的 LSN 用于复制和存储日志，CSN 用于跟踪跨多个 PALF 组的操作顺序。**PALF 组镜像与 Paxos Learners。**一个直观的问题可能是，为什么我们选择通过在 PALF 组之间流式传输来构建物理备库，而不是像 Paxos learners 那样将日志同步到物理备库。实际上，两个主要原因促使了 PALF 组镜像的设计。

第一个原因是故障转移。如果主库崩溃，备库应该能够切换为新的主库并开始服务用户请求。但是，对于 Paxos learners 来说，被选为新主库的领导者是很复杂的，因为 learners 不是 Paxos 成员的一部分。相比之下，PALF 组镜像是一个独立的 Paxos 组，可以通过更改其访问模式轻松切换到主 PALF 组。第二个原因是可维护性。共识协议中的大多数重配置算法都由领导者执行。如果备库依赖于 Paxos learners，则重新配置备库必须要求它与主库联系，当它们之间的网络中断时，这是不可接受的。对于 PALF 组镜像，即使主库崩溃，独立的重配置也使管理员能够重新配置备库。

8 评估在本节中，我们通过实验评估 PALF 的性能。更具体地说，我们试图回答以下问题：

PALF 可以达到什么级别的性能？ PALF 中的优化如何影响其性能？日志重新确认是否会影响故障恢复？ PALF 是否胜任作为 OceanBase 数据库的 WAL？ 8.1 整体性能**测试平台。**所有实验（§8.4 除外）都在一个由三台商用服务器组成的集群上进行。每台服务器都配备了一个 32 核 2.5GHz Intel Xeon CPU、256 GB 内存和四个 SSD 磁盘，所有服务器都通过平均延迟为 0.2 毫秒的 10 千兆以太网连接。三个副本放置在不同的服务器上。

**基线。**我们将 PALF 与 etcd-raft [15] 和 braft [2] 进行了比较，它们是 Raft [33] 的两个开源实现，一些工业分布式系统 [14, 42] 已经基于它们构建。系统设计的主要区别在于多核可扩展性和组复制。例如，在 etcd-raft 中，客户端通过 Go 通道向 raft 节点提出日志，这方便了它的使用，但限制了高并发下的吞吐量。即使 etcd-raft 和 braft 都实现了一些批处理优化，例如批量处理磁盘 I/O 请求和减少网络数据包的数量，它们仍然在共识协议中逐个处理日志条目，这限制了吞吐量。

**客户端模型。**我们为 PALF、etcd-raft 和 braft 构建了闭环客户端。每个客户端在其先前追加的日志提交之前不会向领导者追加新的日志。为了模拟预写日志系统的常见用例（作为分布式数据库的内部组件），客户端与领导者位于同一位置并直接向领导者追加日志。

**吞吐量。**随着客户端数量的增加，PALF 的吞吐量大大提高。如图 9a 所示，PALF 在 1500 个客户端下每秒处理 478K 个追加请求，在 8000 个客户端下每秒处理 1480K 个请求。这些吞吐量数字远高于基线。当客户端数量从 500 增加到 8000 时，PALF 的加速比为 5.98，而 etcd-raft 和 braft 的加速比分别为 1.386 和 1.8。这意味着 PALF 可以充分利用现代多核硬件。造成这种情况的原因有几个。首先，PALF 的无锁写入路径最大限度地减少了锁争用造成的开销。其次，可以并发地填充组缓冲区，并且可以在一个共识实例中复制大量缓存的日志。

我们进一步评估了日志大小对 I/O 带宽和吞吐量的影响。如图 9b 所示，etcd-raft 实现了与 braft 和 PALF 相当的 I/O 带宽，尤其是对于小日志大小。这似乎与图 9a 中描述的结果不一致。为了找出原因，我们进一步绘制了图 9c 中吞吐量和日志大小之间的关系。结果表明，braft 的有效吞吐量远高于 etcd-raft，但它们的 I/O 带宽是同一数量级的。这意味着每个日志的实际 I/O 大小可能被 etcd-raft 放大。图 9d 中描述的写入放大验证了之前的推理。还发现，当日志大小小于 128 字节时，PALF 中每个日志的实际 I/O 大小大于 braft 中每个日志的实际 I/O 大小。原因是组复制。除了日志头（图 5）之外，每个组日志还将附加一个额外的组日志头，这会放大日志的实际 I/O 大小。

延迟如图 9e 所示，当客户端数量少于 1500 时，PALF 的延迟约为 2 毫秒。虽然 PALF 经评估对高并发友好，但延迟仍然随着客户端数量的增加而略有增加，在 8000 个客户端下达到 4.8 毫秒。在 PALF 的写入路径中，LSN 和 CSN 分配是一个必须按顺序执行的过程。如果一个线程由于并发请求而无法分配 LSN，则重试操作将导致额外的延迟。我们进行了一项评估，以确定在高并发下日志排序器是否是瓶颈。我们的评估表明，日志排序器在 1000 个线程下每秒可以处理 588 万个请求。因此，LSN 分配器远未成为瓶颈。

复制延迟包括内存复制、磁盘刷新和网络传输；这些开销都与日志大小相关。因此，较大的日志导致较高的延迟是合理的（图 9f）。

8.2 自适应组复制

我们评估了不同并发级别下自适应组复制的效果。组因子的阈值设置为 10，因为有 10 个工作器在处理客户端的请求。在图 10a 中，较少的共识实例意味着较少的开销。当禁用组复制时，PALF 会提出更多的共识实例；它必须比组复制消耗更多的计算资源。随着客户端数量的增加，自适应组复制显着减少了共识实例的数量。图 10b 直观地描述了性能的提高。当吞吐量较低时，自适应组复制跟踪反馈组复制的低延迟特性。随着并发度的增加，PALF 切换到定期组复制并实现了显着的吞吐量。总之，自适应组复制结合了两种聚合策略的优点，这使 PALF 能够在不同的并发级别下表现良好。

8.3 故障恢复

除了峰值性能之外，我们还测量了领导者崩溃时的性能跟踪和恢复时间，这对于数据库的可用性至关重要。图 11a 表明，PALF 可以在短时间内从领导者故障中恢复，并且新领导者实现了与前任领导者相当的吞吐量。PALF 恢复包括两个阶段：领导者选举和日志重新确认。领导者选举的持续时间主要取决于租约（默认为 4 秒）；与 Raft 相比，日志重新确认需要花费额外的时间。图 11b 说明了重新确认时间的累积分布函数 (CDF)。中位数和 90 分位数分别为 32.2 毫秒和 32.5 毫秒。即使重新确认时间与新领导者和拥有最多日志的副本之间的日志大小差距有关，选举限制（在 §5.3 中）也保证了新领导者的日志不会远远落后。此外，PALF 高效的写入路径进一步缩短了恢复时间。这些优化使日志重新确认的开销可以忽略不计。

8.4 在 OceanBase 中评估 PALF 为了验证日志复制如何影响数据库性能，我们在基准测试工具和生产环境下都测量了 OceanBase 4.0。为了给 PALF 施加足够的压力，我们选择了两个 Sysbench [25] 用例（插入和更新）和 TPC-C [10]（200 个仓库）作为工作负载，使用 YCSB 批量插入工作负载评估了 OceanBase 在键值模式下的 PALF，并在生产集群中测量了 PALF 性能。基准测试实验在一个由三台商用服务器组成的集群上进行，这些服务器配备了 96 核 2.5GHz Intel Xeon CPU 和与早期实验中相同的硬件；生产集群由 46 个阿里云 ECS r5.16xlarge 实例组成。

事务性能的结果如图 12a 和图 12b 所示。与独立性能相比，日志复制使三副本 OceanBase 的性能平均降低了 8.8%（为了公平起见，只有数据库的一个副本可以处理事务）。该结果证明了 PALF 的效率。请注意，OceanBase 的性能在 Sysbench 下随着客户端数量的增加而扩展，但在 TPC-C 下略有下降。原因是写事务的比例。日志记录系统极大地影响了写事务的性能，但对读事务的影响很小。因此，由于 PALF 的可扩展性，Sysbench 中写密集型工作负载的性能扩展良好。相比之下，TPC-C 中混合工作负载的性能受到数据库本身的限制。该结果表明日志复制不是 OceanBase 的瓶颈。

在基准测试实验（三副本）和生产工作负载期间，OceanBase 中 PALF 的性能分析如表 1、图 12c 和图 12d 所示。结果远低于 §8.1 中描述的 PALF 峰值性能，后者在使用 512 字节有效负载的情况下每秒可以达到 140 万次追加操作。因此，PALF 的性能对于 OceanBase 服务密集型写入来说绰绰有余。

9 相关工作在本节中，我们讨论其他贡献以及它们与 PALF 特性的关系。

**分布式数据库中的 WAL。**许多分布式数据库都是基于复制日志构建的，以实现容错和可用性。Raft 协议 [33, 34] 广泛用于在副本之间同步日志，例如 CockRoachDB [42] 和 YugabyteDB [48]。Spanner [9] 在每个 tablet 之上使用 Paxos 实现了复制状态机。它们的事务引擎通过复制状态机模型 [39] 与日志记录系统交互。PALF 所做的选择是提供类似文件的接口，这使得共识协议与典型的集成变得更加容易。

使 WAL 模型成为可能。Aurora [44] 是一种共享存储数据库，数据库引擎负责日志复制并将日志处理卸载到日志存储，相比之下，PALF 适用于共享无架构，数据库通过类似文件的 API 将日志追加到 PALF，并且不知道共识协议。

这些分布式数据库采用将日志复制与数据分区（Spanner 中的 tablet，CockRoachDB 中的 range 等）捆绑的方法，通过并行化多个分区来实现高吞吐量，但会导致更多的分布式事务。PALF 的单个复制组提供了出色的性能，它可以并发地复制多个数据分区的日志，从而间接减少了分布式事务的数量。

Socrates [1] 使用基于 Azure 存储服务构建的未绑定日志服务 XLOG 来支持上层数据库层。FoundationDB [50] 采用了另一种未绑定架构，其中日志服务器与事务处理分离，日志在事务系统中代理的控制下跨日志服务器复制。PALF 为绑定架构提供类似文件的接口。在绑定架构中，即使通过将 WAL 与数据库紧密耦合（例如，使 WAL 事务感知以提交缓冲日志 [29]，分布式事务优化 [17, 19]）可以获得额外的性能提升，PALF 仍然将特定于数据库的功能抽象为类似文件系统的 API，以保持日志和数据库之间清晰的界限，这将为实际的数据库系统带来可维护性和稳定性优势。

YugabyteDB 的 xCluster [49] 通过使用变更数据捕获工具传输逻辑日志来支持数据库之间的异步复制，但施加了许多约束；例如，它不支持同步 DDL 语句。CockroachDB [42] 仅支持通过非投票副本进行副本级异步复制。这些方案不适用于物理备库，物理备库提供主库的相同副本，并且应该是独立可用的。PALF 提供 PALF 组镜像以自然地构建备库。

复制日志系统复制日志系统广泛用于在分布式系统中持久化和排序更新。许多复制日志协议通过一个杰出的领导者来排序记录 [9, 18, 22, 30, 34]。已经提出了一种共享日志抽象，以通过全局排序层来传递所有更新，例如 CORFU [4] 和 Scalog [13]。对于分布式数据库，日志的顺序本质上是由事务引擎而不是日志记录系统决定的。一些日志记录系统 [18, 42] 将事务标识符打包到日志记录中，这可能会导致事务顺序和日志记录顺序不一致。PALF 提供了一个变更序列号原语，该原语使用日志记录顺序跟踪事务顺序。

至于独立重配置，另一个有希望的解决方案是将配置管理与日志复制分离，就像在 Vertical Paxos [28] 和 Delos [3] 中一样。这些研究中的大多数都将重新配置集群的责任交给另一个服务；该方法可能会给系统带来额外的可用性风险 [16]。这些系统通常是大公司的内部服务，而不是像 OceanBase 数据库这样的通用软件产品。PALF 方法实现了重配置的独立性和通用性。MongoRaftReconfig [40] 也像 PALF 一样单独存储重配置日志，但其动机是从大多数故障中恢复共识组。在这种情况下，Raft 重配置的安全性可能无法得到保证；MongoRaftReconfig 提出了一个扩展的重配置协议并证明了其安全性。

10 结论

本文介绍了 PALF，它充当 OceanBase 的复制预写日志系统，并有望成为许多其他分布式系统的构建块。关键思想是将特定于数据库的需求抽象为 PALF 原语。具体来说，PALF 在共识级别提供典型的文件系统接口和显式复制结果，这有助于事务系统和 WAL 之间的集成。CSN 原语有助于通过日志顺序跟踪事务顺序。数据更改同步已被抽象为 PALF 组镜像；下游应用程序将从中受益。在典型的 OLTP 工作负载下，PALF 以舒适的方式服务于 OceanBase 数据库，并为未来的发展提供了空间。

个人总结：在学习了OceanBase4.0关于日志部分的优化，我们这里称之为PALF，了解的OB4.0在这里的设计的几个特点

1 更细致，将分布式的细节和各种出现的状况都研究了，并且拿出了措施

2 将原有的日志性能部分进行更深层次的研究和提高

3 一些设计细节进行了说明，日志是单调递增，保证的事务的原子性的原理

4 最后通过测试对比了不使用此优化的情况下的性能差距

OceanBase 相关文章

OceanBase 送祝福活动，礼物和幸运带给您

跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)

跟我学OceanBase4.0 --阅读白皮书（4.0优化的核心点是什么）

跟我学OceanBase4.0 --阅读白皮书（0.5-4.0的架构与之前架构特点）

跟我学OceanBase4.0 --阅读白皮书（旧的概念害死人呀，更新知识和理念）

聚焦SaaS类企业数据库选型（技术、成本、合规、地缘政治）