既然 mysql 可以靠 binlog 达成多副本共识，那为什么还需要 Paxos、Raft 等共识算法？

[xiyy02]

RT ，最近在看 Paxos 、Raft 等共识算法，Paxos 没怎么看明白，Raft 看了整个流程，相较于 Paxos 好理解许多；
有些疑问想要请教下 V 友们：
我了解过 mysql 的副本同步机制，mysql 通过 binlog 来完成副本同步，为了保证 redolog 和 binlog 不发生一致性问题，还专门做了两段式提交：
阶段一：主库写 redolog 但不提交；
阶段二：主库写 binlog ，然后标记相关 redolog 为提交状态
当且仅当 binlog 写成功时，redolog 里相关改动才算提交，这样可以保证多副本最终一定会按照 binlog 可靠的达成共识（一致？）

在这个过程中，mysql 既没有实现 Paxos ，也没有依赖 Raft ，最终还是达成了多副本的共识（一致？），那为什么还专门提出来 Paxos 这类复杂的共识算法来完成多副本一致性呢？

PS：在此期间还看到有人纠正：共识和一致不是一回事；但我理解共识算法的目的也是为了多副本就一份数据达成一致吧？所以一致性还是最终的目的，总之我被绕晕了😭

[verrickt]

我只看过 raft ，mysql 不太了解。
我觉得可能比较关键的点是，提供了什么样的一致性。
比如 raft 提供了线性一致性保证（ linearizability ），mysql 是否提供了相同的一致性，或是说只是提供了一个很模糊的最终一致性（ eventual consistency ）？
另外提一点，这里的一致性指多个 replica 之间读写的一些保证，与事务（ ACID ）里的一致性是不同的概念

[verrickt]

共识和一致确实不是同一回事。lz 可以看看 design data intensive application 这本书，里面有专门的章节介绍一致性（ consistency ）和共识（ consensus ）
https://dataintensive.net/

[liprais]

binlog 达成不了强一致性

[billlee]

1. Paxos 和 Raft 不是唯二的共识算法
2. Paxos 性能太低了，一般只用来管理 group membership, 然后根据 group membership 退化到主从复制来处理数据。zookeeper 就是这样做的。
3. MySQL 能保证一致性的是 group replication, 它的 group membership 确实依赖共识算法来管理： https://dev.mysql.com/blog-archive/the-king-is-dead-long-live-the-king-our-homegrown-paxos-based-consensus/

[tool2d]

我个人不太喜欢 binlog 同步，任何对数据库的小变动，都往这文件里写。我们服务器是老式硬盘，一直高强度写，有很大损耗的。

任何方法都有一定局限性，写个同步算法，也可以有 3 ～ 4 种完全不同的思路。

[lazyfighter]

mysql 没法选主啊 ， 主就是固定的

[rqzrqh]

paxos 和 raft 算法可以实现强一致性，容易理解就是复制状态机，所有的节点有相同的输入和输入顺序，只要大多数节点存活就能正常工作（更严谨是说法要满足共识算法的大多数节点以及大多数节点的状态），最原始的 paxos 算法里任何节点都可以提交 log ，但是这样效率太低，后来的共识算法都改为只有一个节点提交 log ，这个节点是可以通过算法选举出来的。
binlog 是预先配置好的主+多个备，一旦主故障后，备是不能写入的，否则会导致数据和主不一致。

[jimrok]

双向复制的时候，怎么保证 binlog 的一致？应该听谁的？

[mightybruce]

binlog 那是依赖一个主多个从， 当你集群有多个主和多个从节点， 要想达到一致性就不能靠这个了。
mysql 集群 如果要允许多个主多个从 可以写入并达到一致性，就要依赖 paxos ，raft 。不同的公司都有一些实现，比如 facebook 的论文中就有通过 raft 来做一致性

[mightybruce]

https://engineering.fb.com/2023/05/16/data-infrastructure/mysql-raft-meta/
可以看看这篇文章

[cheng6563]

你想想，主库挂了会怎样

[vczyh]

存在 Leader 选举，才会用 Raft Paxos 这些东西。比如一开始有三个内容一样的副本（其中一个为 Leader ），修改内容的时候去 Leader 修改，然后同步到其他副本，如果 Leader 挂了，Raft 这时候就可以重新选举了，说白了他就是选举话事人的。

MySQL 通过二阶段提交保证 binlog 和 redolog 的一致性，我觉得单靠这个也不能保证，比如阶段二中 binlog 刷盘之后，标记 redolog 提交状态之前挂了，这个时候 binlog 事务是提交的，redolog 中事务状态是未提交的，这个时候需要 mysql 启动的时候进行崩溃恢复，可以通过 binlog 判断出事务已经提交了，然后把 redolog 的事务标记为提交，这样就保证一致了。

所以我觉得他们都属于共识算法，binlog 和 redlog 通过崩溃恢复达成了某个事务是否提交的共识，这个实现我觉得没有 Raft 这种更具有通用性，他只负责当前多副本只有一个老大，其他全部老老实实同步数据就行。

[qieqie]

保证了主库 binlog 和 redo 一致不代表可以保证集群的状态一致性，
同步 binlog 最多只能保证最终一致性，强一致性需要分布式事务去支持。

[momocraft]

binlog 能用的前提是 MySQL 一直在跑，master 能一直活着负责做决定，其他节点只管跟随
这不叫“分布式共识”

[lvlongxiang199]

如果向 master 内写了 x=1, 写成功之后 master 挂了(其它节点, 拿不到最新的 binlog). 这时候从其它节点读 x, 能读到 1 还是之前的值 ?

raft 能提供这种线性一致性的保证

[xiyy02]

@momocraft 可是共识算法中不也是 leader 负责做决定，Follower 跟随吗？唯一的区别是 leader 身份可切换

[mightybruce]

共识算法是为了可用性， 服务器节点存在三个角色 ：leader 、follower 、candidate
主从模式中是只有主节点可以写入的。

[xiyy02]

@liprais 可是 raft 也保证不了完全的强一致吧？比如：leader 写了一个数据，此时同步到 Follower ，「多半」 Follower 响应 leader 后 leader 将此信息传给客户端，告知客户端已经写成功，但如果此时客户端读这个数据的时候正好读到了还未将此数据标记为 commited 状态的那个 Follower 节点（「多半」意味着总会有落后的 Follower ），这不就造成读写不一致了吗？
我看过 Quorum 规则，说客户端每次可以读半数以上的节点，以确保至少有一个节点可以读到最新的值，但这对于一个客户端来说操作似乎又太重了（一次请求那么多个节点显然不合适），就很晕😓

[liuhan907]

@xiyy02 raft 协议只解决共识，不解决一致。而你的这个问题是一致问题，而不是共识问题。

[JasonLaw]

@xiyy02 #18 据我了解，在 Raft 协议中，client 的读写都是发生在 leader 的，不像 ZooKeeper 。MIT 6.824 课程有讲。