开头还是介绍一下群，如果感兴趣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群，8群，准备9群)
最近一直在学习OceanBase,大家实际上对于分布式事务中的一些细节还是比较看重的，上一篇的白皮书中提到了，4.0在分布式事务中的改进，尤其2PC的部分。但个人因素，虽然看了多遍，但对于优化的点还是有一些需要再理解和深入的部分，同时对于分布式数据库的事务的稳定性，或者直白的说，丢不丢数这个事情，我也是比较在意的，所以也想通过研究白皮书中的理论来确认，在理论的部分OB在分布式事务中是严谨的。在搜寻中，发现这篇白皮书是针对我关心的部分进行论述的，所以这篇文章应该能确定我的那些疑问。
摘要
近年来，由于其可伸缩性、可用性和一致性保证，分布式数据库得到了广泛的研究和发展，写前日志 (WAL) 系统是数据库中最关键的组件之一，设计一个具有 ACID 事务能力的分布式数据库仍然是一个难题。
本文提出了一种名为PALF的Paxos支持的追加日志文件系统，以应对这些挑战。PALF背后的基本思想是设计一个数据库共用的日志记录系统，以支持数据库特定功能，并将这些功能抽象为PALF基本操作，以支持分布式系统。基于PALF基本操作的数据库功能，包括事务处理、数据库恢复和物理备份数据库。经过测试和评估，完全能胜任分布式数据库负载。PALF已作为OceanBase 4.0数据库的一个组件部署，并与其一起开源。
分布式数据库的写前日志系统
Paxos-backed Append-only Log File System （PALF）
近年来，分布式数据库因其可扩展性、可用性和一致性保证而被广泛研究和开发。写前日志（WAL）系统是数据库中最关键的组件之一。设计一个能够支持ACID事务的分布式数据库的基础——复制日志系统仍然是不简单的问题。
本文提出了PALF，一个基于Paxos的追加式日志文件系统，以解决这些挑战。PALF的基本思想是将日志系统与整个数据库共同设计，以支持数据库特定的功能，并将这些功能抽象为PALF原语，以驱动其他分布式系统。许多数据库功能，包括事务处理、数据库恢复和物理备库，都是基于PALF原语构建的。
评估结果表明，PALF大大优于众所周知的共识协议实现，并且完全适用于分布式数据库工作负载。PALF已被部署为OceanBase 4.0数据库的组件，并已开源。
1 引言
写前日志（WAL）系统最初是为了在故障后将数据库恢复到其先前状态而引入的。除了最初的目的之外，分布式数据库逐渐出现了更多需求。日志系统应该能够将日志复制到多个副本，以实现持久性和故障容错，几个重要的数据库功能依赖于日志系统的设计，例如：事务处理，重做日志，数据备份与恢复等等。
为了数据库复制的一致性的概念，我们引入了复制状态机（RSM）的概念，与一致性协议集成。在典型的RSM模型中，客户端首先处理所有预期操作并生成日志，然后通过一致性协议将这些日志复制到所有副本。在大多数副本持久化操作日志后，每个副本将其应用于其RSM。
RSM模型对于修改小数据集的操作（例如，将键值设置为键值存储）运行并无问题。然而，RSM可能不适用于涉及大量数据的操作，例如分布式数据库中的事务。
首先，数据库通常需要配备额外的缓冲区来，缓存来自客户端的临时数据以生成日志，因此，数据库难以处理数据量大于其缓存的大型事务。一种折衷的方法是限制事务的大小并将大型事务分解为小的操作单元，但代价是丢失用户原始事务的原子性。其次，其他事务读取这个事务，可能无法看到事务中的先前写入的信息，因为写入可能尚未应用于数据库中。从缓存读取是一种可能的方法；但这将引入合并的工作，加大存储引擎和缓存的数据的开销，导致读取性能下降。
为解决以上问题，我们的设计选择是将一致性协议集成到写前日志模型中。在WAL模型中，数据库使用本地文件系统接口编写日志，相比RSM模型，日志记录和操作应用的顺序可以颠倒。写入直接应用于数据库的存储引擎，然后生成和刷新重做日志。这样事务大小的上限扩大了，读取请求只需访问存储引擎。然而，设计这样一个提供类似本地文件系统，来保证支持WAL模型的复制日志系统，仍然有以下挑战：
leader选举,在实际部署中，数据库leader通常与日志系统leader位于同一位置，以减少延迟。在选举日志系统leader时，应考虑数据库的要求，例如，与应用程序系统位于同一区域/IDC的副本,应该优先选举为leader。
然而，传统上一个副本是否可以被选举为leader取决于一致性协议本身。Raft中已经提出了leader转移扩展，但它依赖于外部协调器主动将领导权转移到指定副本，这损害了分布式数据库的可用性。
不确定的复制结果：在WAL模型中，事务是否应该提交或中止取决于其提交记录是否已被持久化。如果日志系统由于异常（例如leader转移）而向事务模型返回了错误的结果，则数据可能会变得不一致。本地文件系统确实返回显式的写入结果。然而，大多数一致性协议实现并没有在发生异常时返回显式的复制结果。例如，由于临时网络错误，以前的leader已被转换为跟随者。如果以前的leader在退休之前没有收到某些还在写入日志的确认，它就无法感知这些日志是否已被大多数副本提交。因此，事务处理可能会卡住，因为事务引擎无法确定其提交记录是否已被持久化。
数据变更同步问题：日志可以看做是一个数据库，物理日志同步是将数据变更从数据库导出到下游系统最常见的方法之一。例如，物理备库（例如Oracle Data Guard）通过传输和应用重做日志到备库来提供主数据库的相同副本，与直接复制日志文件不同，分布式数据库中的日志复制面临着从主数据库中的一个复制组同步日志到备库中的下游组的挑战，此外，这些组应该独立可用。一些复制协议将集群特定信息（例如成员资格）嵌入到日志中，这破坏了数据变更的连续性，并使下游复制组无法独立地重新配置集群。性能：对于许多日志复制系统，单个复制组的吞吐量是有限的。因此，他们通过并行写入多个组来提高整体吞吐量。然而，众多的复制组可能会带来额外的开销。数据库中的数据分区通常与复制组绑定；更多的复制组意味着更小的数据分区。这将导致更多的分布式事务并降低整个数据库的性能。
本文提出了PALF，一个基于Paxos的追加式日志文件系统。PALF与OceanBase数据库共同设计，以支持其WAL模型。它提供了典型的追加式日志接口，因此数据库可以与PALF交互的方式与本地文件交互的方式非常相似。PALF进一步将数据库特定的特性抽象为原语，例如显式复制结果和变更序列号，这为实际数据库系统带来了可维护性的好处，并使PALF成为构建更高层分布式系统的构建块。这些设计选择使我们能够通过平衡数据库的特殊的要求和日志系统的通用性来解决上述问题。
首先，PALF将leader选举与一致性协议解耦，以支持与数据库相关的选举优先级。例如，更接近上层应用程序的数据库副本可以通过配置其选举优先级来被选为领导者。作为独立选举的结果，PALF引入了一个日志重新确认阶段以确保正确性。
其次，PALF向日志写入者（数据库）返回显式复制结果，除非其leader崩溃，这使得PALF的行为类似于本地文件。日志写入者（数据库）将被通知日志是否已被PALF提交，即使以前的leader已经失去了其领导地位。为了实现这一点，在一致性协议中引入了一个新的角色转换阶段“待定跟随者”，以确定待处理日志的状态；以前的leader的角色在它从新领导者收到日志之前不会切换到follower。之后，事务的状态可以被推进。例如，如果以前的leader尚未由新leader持久化其提交记录，则它将回滚事务。
此外，为了同步分布式数据库之间的数据变更，下游Paxos组被抽象为主Paxos组的镜像。它只接受来自主组的日志，并且可以独立地重新配置。此功能已用于将重做日志从主数据库同步到OceanBase中的备库。据作者所知，这是第一个支持从一个Paxos组同步提案到另一个组的Paxos实现。
最后，为了减少分布式事务带来的开销，我们将日志复制组的数量限制为集群中服务器的数量。更少的复制组需要更高的单个组吞吐量，因为它处理来自多个分区的日志。我们通过系统优化，如管道复制、自适应组复制和无锁写入路径，最大化写入性能。
总之，本文的贡献如下：
PALF被提出作为OceanBase的复制写前日志系统。其高可用性、优异的性能和文件式接口适用于分布式数据库（§3章讲述）。
我们将数据库特定的需求抽象为PALF原语，例如显式复制结果和变更序列号，这大大有利于OceanBase数据库（§4章讲述）。
提出了从一个Paxos组同步日志到其他组的新方法，这为物理备库等功能提供了支持（§5章讲述）。
我们描述了构建高性能共识协议的设计，并在§7章讨论了PALF的设计考虑。
总结：本篇论文将详述OceanBase数据库产品在4.0中的数据一致性的实现过程，优化的过程，以及详细的细节。
以上为翻译的白皮书的1-2页 白皮书为14页
跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)
跟我学OceanBase4.0 --阅读白皮书 （4.0优化的核心点是什么）
跟我学OceanBase4.0 --阅读白皮书 （0.5-4.0的架构与之前架构特点）
跟我学OceanBase4.0 --阅读白皮书 （旧的概念害死人呀，更新知识和理念）
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤，来自杭州的Package（活动结束了）
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火星人
PolarDB-MySQL 并行技巧与内幕--（怎么薅羊毛）
PolarDB 并行黑科技--从百套MySQL撤下说起 （感谢8018个粉丝的支持）
PolarDB 杀疯了，Everywhere Everytime Everydatabase on Serverless
POLARDB 从一个使用者的角度来说说，POALRDB 怎么打败 MYSQL RDS
PolarDB 最近遇到加字段加不上的问题 与 使用PolarDB 三年感受与恳谈
PolarDB 从节点Down机后，引起的主从节点强一致的争论
PolarDB serverless 真敢搞，你出圈了你知道吗!!!!
PolarDB VS PostgreSQL "云上"性能与成本评测 -- PolarDB 比PostgreSQL 好？
临时工访谈：PolarDB Serverless 发现“大”问题了 之 灭妖记 续集
临时工访谈：庙小妖风大-PolarDB 组团镇妖 之 他们是第一
POLARDB -- Ausitndatabases 历年的文章集合
PolarDB for PostgreSQL 有意思吗？有意思呀
全世界都在“搞” PostgreSQL ，从Oracle 得到一个“馊主意”开始PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁
PostgreSQL “我怎么就连个数据库都不会建？” --- 你还真不会！
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 分组查询可以不进行全表扫描吗？速度提高上千倍？
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然，不是PG的锅
MongoDB 相关文章
MongoDB 合作考试报销活动 贴附属，MongoDB基础知识速通
MongoDB 使用网上妙招，直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
数据库 《三体》“二向箔” 思维限制 ！8个公众号联合抽奖送书 建立数据库设计新思维
MongoDB 是外星人，水瓶座，怎么和不按套路出牌的他沟通？
MySQL相关文章
阿里云系列
阿里云数据库产品权限设计缺陷 ，六个场景诠释问题，你可以做的更好？
阿里云数据库--市场营销聊胜于无--3年的使用感受与反馈系列
阿里云数据库产品 对内对外一样的卷 --3年阿里云数据库的使用感受与反馈系列
阿里云数据库使用感受--客户服务问题深入剖析与什么是廉价客户 --3年的使用感受与反馈系列
阿里云数据库使用感受--操作界面有点眼花缭乱 --3年的使用感受与反馈系列
