为了整理思路，文章采用模拟2人对话方式，如有误，欢迎留言。

Basic-Paxos协议回顾

一天下午，小王同学正在津津有味回顾：<<成为OB贡献者第四天：从单点到多节点 i++并发方案 >>

通过假设一个存储服务，2个客户端，3个存储节点 存储一个值方式 解决并发问题 引出 Basic Paxos

任何成员都可以提出议案，然后通过2轮 RPC 来确定只一个值。（这里没考虑持久化）

关于：任何成员都可以提出议案 然后写下自己理解

• Basic Paxos只负责批准一个提案，一旦批准之后，其他 proposer 再怎么重复的提交 更高的提案编号（proposal number ），都只会学习到已经达成一致的 提案(acceptedValue)，然后重复提交,，
• 学习这个表示很准确，如何学习呢？

Basic Paxos 是通过2次RPC确定一个值（假设的系统没考虑持久化）

在 phase 2a: Accept

如果 promise 里含有 (acceptedProposal, acceptedValue)，那么就 放弃自己原本的提案，从返回的这些 promise 里挑出  acceptedProposal 最大的 acceptedValue 作为本次的提案 value。

注意：这里说2轮RPC确定一个值，并不是说没有其他网络交互 ， 参考7：[Paxos三部曲之二] 使用Multi-Paxos协议的日志同步与恢复 参考8：[Paxos三部曲之一] 使用Basic-Paxos协议的日志同步与恢复 Basic-Paxos进行redolog同步的延迟包括了3次网络交互加2次写本地磁盘.

Multi-Paxos 协议将  Basic-Paxos3次网络交互（1.产生logID；2. Prepare阶段；3. Accept阶段），

简化为1次网络交互（accept阶段），省去的（1.产生logID；2. Prepare阶段）让leader代替，

leader提案时候省略准备（Prepare ）阶段提案编号获取过半同意， 直接进入接受阶段 写入 <提案编号，提案值> 根据Base Paxos 接受阶段 也可能失败情况。

这样leader可以一次提交多次提案，大大提升了效率。这样引发其他问题，

• 一次提交多个 可能失败情况 ，在索引位置出现 空日志情况 提示线索：Paxos 幽灵复现问题
• 需要明确的是Multi-Paxos协议并不假设全局必须只能有唯一的leader来生成日志， 它允许有多个“自认为是leader的server”来并发生成日志，这样的场景即退化为Basic-Paxo

这是raft本质区别,因为没看相应代码 这里不做注释， todo 当作遗留作业下次研究。

回顾小结：

从obce面试题开始

叮叮叮，群里 发一个消息，

中断 小王思考 一个/多个Leader一次提交多次提案引发新问题，机器可用多线程工作，但是小王不是。

先处理紧急事情。

obce面试题。 有套三地五中心的ob集群。a,b,c三个城市，a,b城市分别有两个全功能副本的zone，c城市有一份日志型副本的zone， 这时候a和b之间的网络断了，会发生脑裂吗，会有什么情况产生。

理解问题是什么？

小王是这样理解脑裂 这个概念的

脑裂 理解成------>2个leader ，为什么2个leader，
网络分区情况下，原来存在的leader，和新选举的leader，
---------> 这不对呀。不是多数派，不会产生2个leader，看采用协议，
Redis 就是异步 这个没有超时判断情况，不知道leader是否失效
参考[1]。这样更容易理解这个问题是什么

老王：请一句话描述问题是什么

小王：

Redis的集群方案哨兵模式 默认异步复制，在网络分区情况下，出现2个leader情况，同时接受客户端写入，导致数据不一致， Redis是无法处理这样情况的？增加2个参数避免这个情况 #健康的slave的个数小于N，mater就禁止写入 min-slaves-to-write 1 #延迟小于min-slaves-max-lag秒的slave才认为是健康的slave。 #数据复制和同步的延迟不能超过10秒 min-slaves-max-lag 10 下一步任务： 反向假设一下：Paxos 允许多个提议者存在 如何处理这个情况？ ob，目前还无法举例说明，：后面给出答案 成为OB贡献者第四天：从单点到多节点 i++并发方案 稍微提到解决方式

回到Redis3.0 是如何处理这个情况的

• 网络分区下的一致性

Redis2.8版开始正式提供名为Sentinel的主从切换方案。

假设 3节点组成的存储系统

T1 时刻 原始状态如下

• Redis instances.   Redis3 是 Leader， Redis2， Redis1 是follower
• Sentinel instances. 每个节点上都哨兵
• Clients. 2个客户端A B

T2 时刻 Redis3 节点发送网络分区，此时Redis1被Sentine提升Leader

• 此时客户端B依然写入 Redis3 ，
• 此时客户端A写入 Redis1

T3:时刻： 网络恢复，Redis3 变成Redis1 的follower，主从复制开始。

T1 时刻 客户端B写入数据被覆盖,主从复制这个方式 很暴力 不解决冲突 直接覆盖 针对这个情况Paxos怎么处理没有写过半情况？？

• 由于 Redis 是异步复制的，因此在这种情况下无法完全防止数据丢失，但是您可以使用以下 Redis 配置选项限制 Redis 3 和 Redis 1 之间的差异：

min-slaves-to-write 1
min-slaves-max-lag 10
要求至少有1个slave，数据复制和同步延迟不能超过10秒
如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么master就会拒绝接收任

• 根据配置 Redis 3 在10秒 后不可用。 RPO（Recovery Point Objective）会10秒数据丢失。
• 来源：33 脑裂：一次奇怪的数据丢失 络一个真实案例：

在使用主从集群时，我曾遇到过这样一个问题：我们的主从集群有1个主库、5个从库和3个哨兵实例，在使用的过程中，我们发现客户端发送的一些数据丢失了，这直接影响到了业务层的数据可靠性。

通过排查才知道，这其实是主从集群中脑裂问题导致的（不是异步同步导致的）

旁白 先不考虑内部实现，从用户角度考虑 ， Paxos 是如何解决 2个客户端 写入不同Leader情况？ 2个提议者 都提案情况？后面根据这个问题 看代码。

理解：三地五中心部署模式

• 物理部署

一个机柜上 一个交换机 ，下面几个物理机组网

• 逻辑部署

• 全功能型副本具备以下特点：

     可以构成 Paxos 成员组，并且要求 Paxos 成员组多数派必须为全功能型副本。

• 只读型副本主要具备以下特点：

        不可构成 Paxos 成员组，它不作为 Paxos 成员参与日志的投票，而是作为一个观察者实时追赶 Paxos 成员的日志，并在本地回放，        

• 三地五中心容灾场景  参考3

理解：C城市作用

如果C城市的节点失效，这将影响Paxos协议的多数派决策过程，因为C城市节点在投票过程中扮演重要角色

1. 无法达成多数派共识：由于C城市节点的失效，如果A和B城市的节点之间无法形成多数派，那么在没有额外机制的情况下，系统将无法选出新的领导节点，这可能导致无法进行新的数据写入操作。
2. 数据写入停滞：在Paxos协议中，新的数据写入需要多数派的同意。如果无法形成多数派，新的写入请求将无法执行，这可能导致业务中断

同类产品对比：

在Oracle ASM同城双活配置中，为了防止AB网络或机房中断导致的服务不可用，通常会引入第三方机房进行投票决策，这种配置也称为“仲裁”。

第三方机房的作用是在两个主要机房之间发生网络中断或其他故障时，提供决策支持，以确保系统的高可用性。

不是leader

小结

无法解决一个问题，至少明白这个问题是什么

本文主要描述，在实际物理部署情况下，在网络分区情况下，会出现

客户端同时写双主情况，这个和Paxos多个提议者情况下类似，

如何解决冲突，并不是说有了多数派就就"天然"避免者一切发生。

回到题目  ，不同厂商做不同优化，这里明确给出Redis3.0规避措施。其他产品并没有给出答案。

后续随着研究深入揭晓答案。

参考
[1] Consistency under partitions
[2] [Paxos三部曲之二] 使用Multi-Paxos协议的日志同步与恢复
[3] 【OceanBase 4.x DBA 进阶教程】容灾架构设计
[4] OceanBase 数据库中副本类型