|
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以办理你的问题。加群请联系 liuaustin3 ，（共2610人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6群均已爆满，新人进7群300+，8群，准备9群)
歉仄大家，昨天的0ceanBase的运动，太火爆了，早上帖子一发，6:30就有人答题过了60分，本来筹划搞3天，但是在打开运动后的8:37运动就只能制止了，人太多了，会OB源代码的客户都来了，银行的大佬也都来了，太卷了，还有答题六遍的，OB开源的真爱粉，搞得我昨天都要神经了。
最后辛劳OB 市场的老师了，一会找人家问，大家开心拿到礼物就好。
这边周五老师会总体统计，下周就有同学可以收到礼物了，感谢OB。
----------------------------------------------------------------
最近一直在学习OceanBase,对于分布式事务中的一些细节还是比较看重的，上一篇的白皮书中提到了，4.0在分布式事务中的改进，尤其2PC的部分。但个人因素，虽然看了多遍，但对于优化的点还是有一些必要再理解和深入的部分，同时对于分布式数据库的事务的稳定性，或者直白的说，丢不丢数这个事情，我也是比较在意的，所以也想通过研究白皮书中的理论来确认，在理论的部分OB在分布式事务中是严谨的。在征采中，发现这篇白皮书是针对我关心的部分进行叙述的，所以这篇文章应该能确定我的那些疑问。
OceanBase4.0 跟我学--分布式到底可靠不可靠，到底丢不丢数 ---- 什么是PALF
OceanBase4.0 跟我学--分布式到底可靠不可靠，到底丢不丢数 ---- 什么是PALF
这是这篇译文的第二部分
2 背景
本节简要描述了 OceanBase 数据库的架构，以便为 PALF 的设计提供背景。
2.1 OceanBase 数据库
OceanBase是一个基于shared noting架构的分布式关系型数据库体系。OceanBase 的主要设计目的包罗与传统关系型数据库管理体系 (RDBMS) 的兼容性、可扩展性和容错性。OceanBase 支持 ACID 事务、重做日志归档、备份与恢复、物理备用数据库等多种功能。为了进步数据写入效率，OceanBase 从零开始构建了基于日志结构的合并树 (LSM-tree)的存储引擎，并与事务引擎共同设计。
事务引擎通过使用悲观纪录级锁和多版本并发控制，确保 ACID 属性；它还针对shared nothing架构进行了高度优化。比方，通过改进的两阶段提交过程，分布式事务的提交耽误已经镌汰到几乎只有一次交互的程度。
OceanBase 依赖于基于 Paxos 的wal体系来容忍故障，这带来了分布式体系的优势，但同时也增长了日志复制的开销。
2.2 重新设计的架构
在 OceanBase 之前的版本（1.0-3.0）中，事务处理、日志纪录和数据存储的基本单元是表分区。随着越来越多的应用接纳 OceanBase，我们发现之前的架构更实用于大型公司的大规模集群，而不太适合中小型企业。此中一个问题是日志复制的开销。OceanBase 允许用户在每个服务器上创建成千上万的分区，而这些 Paxos 组的数量斲丧了大量资源，却没有现实意义，还提拔了部署和运维的难度。另一个挑战是大事务问题。这样的事务大概跨越成千上万个分区，这意味着在两阶段提交协议中有成千上万的到场者，这会导致体系不稳定并捐躯性能。
为了办理这些问题，OceanBase 数据库 4.0 版本的内部架构进行了重新设计 。提出了一个新的组件——Stream，它由多个数据分区、一个复制的WAL日志体系和一个事务引擎组成。Stream 的关键思想是，虽然数据库中的表仍然是分区的，但事务和日志的基本单元是 Stream 中的一组分区，而不是单个分区。表分区仅表示存储引擎中存储的数据的一部分。事务引擎天生redo log，纪录 Stream 内多个分区的修改，并将日志存储在该 Stream 的 WAL 中。Stream 会在差别的服务器上创建多个副本，此中只有一个副本会被选举为leader，负责处理数据写入请求。集群中的复制组数量可以镌汰到服务器的数量，从而消除由大量复制组带来的开销。
通过 Stream 的抽象，OceanBase 数据库 4.0 版本在独立模式下能达到与集中式数据库相媲美的性能（实用于中小型企业），同时可以通过增长机器轻松扩展到分布式集群（实用于大型企业）。在默认设置下，每个服务器上有一个 Stream，其leader会在该服务器上选举产生，因此，多个服务器中差别 Stream 的leader可以同时处理查询，实现了主动-主动架构。除了由leader提供的强一致性服务外，OceanBase 数据库的其他副本还可以在最终一致性保证下提供读取请求。
3 PALF 设计
PALF 的设计目的是提供一个复制的wal日志体系，该体系应能够为 OceanBase 数据库提供服务，同时又具有足够的通用性，可用于构建其他分布式体系。
PALF 的设计目的促成了其架构的形成：接纳分层架构来平衡数据库的特定性和日志体系的通用性。数据库特定的需求已被抽象为 PALF 原语，并在差别层次中集成。
本节首先描述 PALF 作为 OceanBase 数据库的复制 WAL 体系，然后介绍 PALF 提供的接口。最后，详细描述了共识协议的实现。
3.1 复制 WAL 模子
在 OceanBase 数据库中，复制日志体系被抽象为一个只追加的日志文件，事务引擎与 PALF 的交互类似于与本地文件的交互。如图 1 所示，事务直接修改内存存储引擎中的数据（步调 2-3）。因此，事务的大小上限大大扩展，仅受存储引擎容量的限定。然后，日志纪录被天生并追加到 PALF（步调 4）。领导者的事务引擎将 PALF 视为本地日志文件体系，并且只关心日志纪录是否已被刷新。PALF 的职责是将leader所做的修改复制到follower（步调 5）。如果日志已由 PALF 提交，leader将关照事务引擎提交效果（步调 6），follower将重放leader对本身所做的修改（步调 7-8）。
当大多数 PALF 副本将日志持久化后。与某些将leader选举和日志复制绑定在一起的 Paxos 变体差别，PALF 中的leader候选人由一个独立的选举模块选举产生，重新设置模块管理 PALF 组的成员资格（§5.3）。
在每台服务器上，会激活一个名为 PALFEnv 的 PALF 运行情况，提供远程过程调用（RPC）接口，并管理 PALF 副本的磁盘资源。详细来说，PALF 副本中的全部日志条目都作为多个固定大小的块存储在 LogStorage 中的唯一目录下。MetaStorage 存储元数据信息，如全部 PALF 副本的成员信息。BlockGC 负责修剪不再必要的日志块。全部由 PALF 副本发出的 I/O 请求都由 PALFEnv 中的统一 I/O 工作池处理。
我们将 PALF 与事务引擎之间的交互抽象为接口层。这一做法将数据库特性对 PALF 的影响隔离开，从而进步了 PALF 的通用性。leader中的日志关照器会关照事务引擎日志是否已提交。follower中的日志重放器会将日志条目中的纪录变更重放给事务引擎。如果 PALF 副本的脚色发生了切换（比方，从leader到follower，或从follower到leader），它会向脚色协调器发送脚色变更信号，脚色协调器再将信号转发到事务引擎，改变其脚色。
3.3 体系接口
图 3 表现了一组与数据相关的 API，省略了体系管理接口，如引导和重新设置。PALF 提供了两种写日志的方法：追加（append）和镜像（mirror）。追加方法将纪录 | 
