为了整理思路，文章采用模拟2人对话方式，文中比喻可能错误的，请注意区分。

本文主要内容

1. 通过对学习数据库下 定义聚焦学习内容

如果关心代码，直接去看代码，如果关心SQL，直接看SQL，先满足第一需求。

2. 通过OB定义一体化是什么 聚焦学习方向

一体化 在添加一个字： 像一体化，
多个网卡绑定一个虚拟网卡像一个网卡一样 ，
多个磁盘组成一个巨大磁盘，想一个磁盘一样，
多个节点像以一个节点一样。
来高并发和可扩展，不是说简单添加更多机器就可以满足的。
换个马甲也要认识。

3. 采取对照组实验方式学习， 请说出他们相同点 和不同点,确定关键部分。

对照组：
从一个最简单例子开始，这个自己很清楚，大家都知道
版本1.0: 采用Go语言 完全按照lamport的论文paxos-simple.pdf中的描述流程，没有任何优化实现 去网络上搜索到。

一个是踩过无数坑，经过无数考验，自己不知道，别人知道 。
版本4.0 ：采用c++实现的工业级实现的 multi-paxos
Palf 基础组件：Paxos-backed Append-only Log File System
PALF: Replicated Write-Ahead Logging for Distributed Databases

4  选举算法与Paxos 日志同步之间 的关系

本来计划写领导选举要点，输出 2个表格。不是容易写的，国庆几天没整理出来，上班赶项目，延后几天。看到这里可以结束了，下面是详细分析过程。

一、对学习下个定义：简化，简化，简化

风和日丽下午，小王与老王在咖啡馆相遇了，

小王：我想学习数据库，但是笔记本配置低，最新的4.x至少8G内存，不方便安装了，即装 了也无法长时间运行？更别说编译了,该如何开始呢

老王：咱们对学习下个定义

• 如果业务开发人员，关心的是怎么写sql，可用使用OB Cloud 云数据库 30 天免费试用，先别考虑30是否太短。用完30天在说，不需要关心部署问题。
• 如果源码爱好者，关心的是设计方案，代码流程 ，代码规范，如果提交代码，可用gitpod简单编译，不用担心没有经过充分测试  github提供大部分自动化测试用例。
• 如果万能DBA 考虑更多。。。

资源有限情况下，做出取舍，这样更加集中精力，咱们主要学习ob 并发情况下如何保证数据的一致性

• 对ob下个定义：自研的一体化架构，兼顾分布式架构的扩展性与集中式架构的性能优势，

小王疑问：

一体化 是不是把全部功能放在一块，这有点违反直觉，软件为了代码可读性和可维护性采用，“高内聚、松耦合” 设计，代码目录划分是不是回混乱？

在存储领域 海量非结构化存储的 有一体机说，软硬件一体化的设计。这个意思吗？

老王：OceanBase 为什么走向一体化 看一下这个文章 https://open.oceanbase.com/blog/5022262784

下面是我的另外一个理解

对比熟悉产品他们没有一体化这个概念，他们是怎么解决这个高可用这样问题的？

Ceph：统一存储解决方案，三部分组
Ceph 对象存储设备服务进程，简称 OSD。一个 OSD 守护进程与集群中的一个物理磁盘绑定
Ceph 元数据服务器服务进程，简称 MDS
Ceph 监视器服务进程，简称 MON。

Ceph monitor 通过保存一份集群状态映射来维护整个集群的健康状态。它分别为每个组件维护映射信息，包括OSD map、MONmap、PG map和CRUSH map。
所有群集节点都向MON节点汇报状态信息，并分享它们状态中的任何变化
Ceph monitor中实现了paxos算法，来选举一个leader负责监控集群的监控状态

Redis Sentinel 模式 Sentinel（哨兵）是一个独立运行的进程，三个节点（box）启动三个 Sentinel组成进程一个分布式系统。但是只有一个leader,leader来管理Redis 主从切换。

一体化 概念不理解 就是抽象：是多个进程，抽象一个进程，每个进程里 可能不同功能线程组成。

旁白：这样比喻可能不正确，用一个概念 解释另外一个概念，别人会问 Ceph，Redis 有什么关系？
其实就是 就是辅助理解
一体化，总控服务RootService，ObServer等，这些概念
如同金箍棒 一样 变小 变小再变小 用其他产品组建对比。

别看这么粗暴介绍OceanBase整体结构， 至少目的了，方法有了，就展开看行动吧，

至少1个月内完内✅ 2024-10-01--2024-11-01

OceanBase 数据库的那些线程,分别是做什么的？

• election worker：选举线程。

因此看代码时候  直接main 函数从头到尾不合适了，这是大型工程，不是简单的例子，

越是大型工程，必然内部必然清晰模划分，每个独立部分都是单独封装起来。甚至是Paxos 协议与选举协议为什么分开独立实现的？

OceanBase 数据库的 Paxos 实现和选举协议一起构成了一致性协议（日志服务）的实现。 两者有一定的相关性，但在实现上又尽量做到减少耦合。

项目：必然符合，“高内聚、松耦合” 设计思想，这样保证代码的可读性和可维护性。

可能是通过进程（不同项目），线程（不同模块 ），函数调用（一个独立逻辑）来区分。

换个马甲认识，主要帮助快速理解。

tree -L 1 -d
    ├── logservice //？？？？？？ 这个是需要探索部分 
         OceanBase 4.0 分布式日志系统 PALF (Paxos-backed Append-only Log File System) 的架构设计，及其在有效支撑 OceanBase 高可用、高可靠
    
    ├── observer 所有组件的“总装车间“ //当作无状态执行节点，负责接受客户端的连接，执行 SQL
    
    ├── rootserver OB集群总控服务Rs，集群管理、数据分布以及副本管理 
      //就是元数据管理节点,每个zone上只有1个Rs，但是只有其中一个leader，其他fo l lfoll
    
    ├── sql sql引擎 // 至少支持sql解析
    
    └── storage  存储引擎 //当作存储kv集群，至少支持put get存储一个值 `rootservice.log`、 ----RS 日志 
`election.log` -----选举日志

题外话： 用多个进程，多个线程能实现一个数据库，协程呢，为什么大家都不用协程实现一个数据库。协程的特点不是更加高效，更异步？

这里重点解释几个概念

• Redis 主从模式 节点为单位存储数据（上面数据全部是leader的存储），一个节点故障了，另外一个节点上数据代替。 单节点 性能有限？如果提高性能，直接添加机器固然可用，理论依据是什么

看看硬件：

• 网卡绑定，多个网卡像一个网卡一样使用。

网卡绑定是将多块物理网卡虚拟成一块逻辑网卡的过程。

多块物理网卡被视为一个整体，共同完成网络数据的传输任务。同时，当其中一块网卡出现故障时，其他网卡可以继续提供网络服务，增强了网络的稳定性。

• 硬RAID和软RAID 多个磁盘像一个磁盘一样

RAID 全称叫廉价冗余磁盘阵列（Redundant Array of Inexpensive Disks) 其设计初衷是为了将多个容量较小、相对廉价的磁盘进行有机组合，

在实际应用领域中使用最多的 RAID 等级是 RAID0 、 RAID1 、 RAID4 、 RAID5 、RAID10 、JBOD 软raid是通过操作系统和软件来实现raid功能，

而硬raid则是使用专门的raid控制器来实现raid功能。硬Raid 通过raid 卡进行数据交换，占用系统I/O 极小，数据的交换与运算都是通过RAID 卡来完成的

• CEPH PG全称是placement groups，ceph的逻辑存储单元

简单是一个存储节点上 10个磁盘，一个磁盘对应一个osd服务。 通过服务把三个节点上30个磁盘组成像一个磁盘一样，

PG全称是placement groups，它是ceph的逻辑存储单元，可以把PG想象成存储了多个对象的逻辑容器，这个容器映射到多个具体的OSD

如果没有PG，就难以管理和跟踪数以亿计的对象，它们分布在数百个OSD上。对ceph来说，管理PG比直接管理每个对象要简单得多。

每个PG需要消耗一定的系统资源包括CPU、内存等

• 说到这里CEPH PG 与ob 有点类似 ，多个节点能组成一个组？？

• 分区与副本 由于 OceanBase 数据库的数据副本是以分区为单位的，所以同一个分区的数据会分布在多个 Zone 上。

   每个分区的主副本所在服务器被称为 Leader，所在的 Zone 被称为 Primary Zone

• 可用区/区（Zone）

Zone 是 Availability Zone 的简称。一个 OceanBase 集群，由若干个可用区（Zone）组成。通常由一个机房内的若干服务器组成一个 Zone。为了数据安全性和高可用性，一般会把数据的多个副本分布在不同的 Zone 上，可以实现单个 Zone 故障不影响数据库服务。

每个 Zone 会提供两种服务：总控服务（RootService）和分区服务（PartitionService）

其中，每个 Zone 有一台 OBServer 会同时运行总控服务（RootService），用于执行集群管理、服务器管理、自动负载均衡等操作

二、如何学习：对照，对照，在对照

小王：我准备好阅读代码工具 和和找到相关代码模块，如下 ，该如何下手呢？

阅读代码工具选择 （只阅读不编译代码）

• In Windows, we recommend  Souce Insight can be used
• in Mac or Linux, we recommend that  VSCode + ccls

代码路径：

其中 Palf 不是随便命名的，全名 “Paxos-backed Append-only Log File System”这个是对日志服务一个抽象，

这里你发现：这里只有领导选举代码，并没有日志复制代码（和期望一样全部在一个模块不一样，别慌，你发现的绝对没问题

小疑问 ：PALF 为什么领导者选举与共识协议分离开来？---------
开始 原文1：PALF decouples leader election from the consensus protocol to manipulate the location of the database leader without sacrificing availabilit

PALF 将领导者选举与共识协议分离开来---选择距离最近的。

小王猜测可能从用户角度考虑，为了降低业务延迟，在业务部署时候，尽可能部署到Primary Zone。这样用户需就可以灵活指定领导者优先级 ，不仅仅根据谁日志编号大就是选择谁。回顾：配置2 领导者选举时候保证zone1  > zone2 > zong3 ，zone1故障恢复后，流量切换zone1

Primary Zone 描述了 Leader 副本的偏好位置，而 Leader 副本承载了业务的强一致读写流量，即 Primary Zone 决定了 OceanBase 数据库的流量分布。

假设某张表  t1 的  primary_zone="Zone1"，则  RootService 会尽量将  t1 表的 Leader 调度到 Zone1 上来。在补充概念

小疑问 ：PALF 为什么领导者选举与共识协议分离开来？------------结束
原文2：For example, in cross-region deployment, users tend to make the upper application and the database leader in the same region to reduce latency，
If the previous leader recovers from failure and its priority is still higher than current leader’s, leadership can be automatically transferred back to the recovered replica.

• OceanBase 的 2 篇论文《Replicated Write-Ahead Logging for Distributed Databases》和《Native Distributed Databases: Problems, Challenges and Opportunities》入选，获得了国际学术界的高度认可。
• https://www.vldb.org/pvldb/vol17/p3745-xu.pdf

Palf 是数据库的一个基础组件，它需要完成两大核心功能：

• 对于事务系统，具备以下特性： 满足事务系统 Write-Ahead Logging 的功能需求，实现事务的原子性和持久性。 支持返回特定语义的时间戳，满足读写事务、备机弱读等生成事务版本号的需求。 实现事务的高性能，同时做到多核下的可扩展。
• 对于分布式，具备以下特性： 基于 Paxos 协议，保证数据在多数派副本持久化成功；同时通过成员变更提供容灾能力，实现高可用和高可靠。 提供异步复制的能力。 提供完善的诊断监控能力，实现可诊断、可运维。

老王：自然对照组方式，一个最 简单demo方式实现 这个你清楚了解的，一个是踩过无数坑，经过无数考验实现 这个是你不清楚的，请说出他们相同点 和不同点。

• 版本1.0: 采用Go语言 完全按照lamport的论文paxos-simple.pdf中的描述流程，没有任何优化实现
• 版本4.0 ：采用c++实现的工业级实现的 multi-paxos
• Raft vs Paxos 方式

国庆7天准备 整理一个表格证明

三、Master 选举算法与Paxos协议 的关系

• 为什么需要Leader

Multi-Paxos允许并行提交，最坏情况要退化到Base Paxos

1. 如 活锁问题：

多个 proposor，轮流用更高的 proposal ID 运行 phase1，导致两者都没法进入 phase2，无法确定谁可以写入，形成活锁

• 如何选举唯一的Master

Base Paxos 是通过2次RPC达成一个值，

Master选举也是达成一致，是不是可以用Base Paxos ？

或者

是不是可以用选择一个编号最大的一个，ID最大一个？

都 可以。既然都可以没有统一的说明，这就是百花齐放，

PALF: Replicated Write-Ahead Logging for Distributed Databases

提到：重点介绍复制日志系统的设计，

因此，我们将选举算法的实现细节留给另一篇论文也没有具体给出说明

This paper focuses the design of the replicated logging system, therefore, we leave implementation details of the election algorithm for another paper

在万字解析：从 OceanBase 源码剖析 paxos 选举原理 ob作者提到

题外话：

Paxos算法强调达成一致，但是没有告诉如何选举，

或者认为选举就是很随意一个事情。这就是框架的灵活性，就c++一样，

Master选举算法可以采用其他通用性的算法，它可以与任何强一致性算法搭配来完成，而无需要求一定是Paxos是算法。

选举算法和Paxos日志同步可以分开来实现。

题外话：

在选举中哪个副本会被选为主？OceanBase 数据库的选举模如何保证选举到的 Leader 副本是更好的选择？ 这个是帮助理解，不需要记住

后记：

国庆7天准备按照这个方式整个表格，结果遇到工作问题，延迟整理，后面拿出一个一篇来整理

简单整理ob 选举用到类

• election proposer： proposer  是  paxos  中的提案发起者， proposer  会提议开始一次选举，并尝试竞选成为  Leader  。
• election acceptor： acceptor  是  paxos  中的提案审议者， acceptor  会根据基本原则判断是否要接受一项提案（在选举中提案就是租约），并确保任意时刻集群中只有一个  Leader

对比：

paxos-simple.pdf 用到到2个类

• proposer
• acceptor

6-4 OceanBase 事务流程与两阶段提交 优化地方 还不明白

OceanBase 数据库知识导图

https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000324072

参考

• [1]万字解析：从 OceanBase 源码剖析 paxos 选举原理
• [2] 开源数据库OceanBase代码导读
• [3] PALF: Replicated Write-Ahead Logging for Distributed Databases
• [4]OceanBase 数据库选举

  Paxos理论介绍(3): Master选举

• [5]OceanBase 两阶段提交

https://www.oceanbase.com/video/9000857