[TOC]

绪论

介绍 openGauss 数据库，以及作为分布式系统的特性。本工作的目标。

本节内容。

研究背景

介绍分布式数据库、openGauss 和要解决的问题。

研究工作

简要介绍本文探索了哪些优化，得到了什么样的结果。

相关工作

TiKV 优化的 Raft

TiKV 是一款开源的分布式事务型键-值数据库，采用 Raft 共识协议以保证强数据一致性和高可用性。Raft 与 Paxos 在容错和性能实现方面有很多共同点，但易于理解和实现。

在分布式系统中，“脑裂”是一个常见的问题。如果在一个 Raft 集群中发生脑裂问题，旧的 Raft Leader 节点不知道新的 Leader 已经被选出，如果此时有客户端的读取请求，则可能会读取到旧值。原版 Raft 的解决办法是让读请求前将全部 Log 按序应用到状态机，再去进行读操作，则可以保证读到的数据满足强一致性。这种方法的缺点在于每一次读请求都需要依次应用所有的 Log，引发严重的性能问题，因此实际上少有实际项目采用这种方法。Raft 协议的作者后来又在 Raft 的教学材料中提出了针对只读请求的优化方法，为 TiKV 所实现。

论文组织

这部分讲论文的结构。

准备知识

openGauss

paxos 共识协议

DCF

openGauss-DCF 分布式共识框架是基于 Paxos 共识算法实现的一致性数据复制组件。传统的主备+集群管理采用的是主从模式，有容易触发日志分叉而重建数据、选主错误、不支持动态增删节点等缺陷。在这样的需求背景下，采用了基于一致性协议的自仲裁管理方法。

DCF 基于 Paxos 协议，扩展了多样化的节点角色：Leader 负责将日志复制到其他节点，并维持心跳；Follower 复制来自 Leader 的日志，心跳超时时转换为 Candidate，给其他 Candidate 投票；Pre-Candidate 发起新任期投票，收集来自其他节点的投票；Passive 复制来自 Leader 的日志；Logger 复制日志及给其他 Candidate 投票。

对比基本的 Paxos 协议，DCF 的实现采取了两个优化：一是 preVote 优化，通过加入 Pre-Candidate 状态，发起任期不变的预选举，成功后才进行正式选举，以避免网络断连导致节点频繁发起选主使任期持续增加。二是 Lease 优化，在 Leader 网络故障与多数派断连后主动降为 Follower，防止事实上存在两个 Leader。

优化设计