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

[yamasa]

@xiyy02 想强一致就 follower 转发 leader ，想一定程度牺牲一致性来换取性能和可用性就 follower read ，总是有取舍的。

[yamasa]

@liuhan907 你搞错了，Raft 读数据走 leader 即提供全局 linearizable read ，怎么可能不解决 data consistency ？只是想要线性一致性读必须走 leader ，这对于分布式系统的服务可用性和性能是个头疼的问题，所以即便是采用了 Raft 作为 data replication 共识算法的分布式数据系统一样要提供 follower read 提供给用户，典型如 CRDB 和 yugabyteDB

[yamasa]

MySQL 的这种做法不就是典型的 2PC ？ 2PC 的缺陷不想在这里赘述了，几个知名的分布式数据系统（ Spanner ，CRDB ，yugaByteDB ）都采用了 paxos 或者 multi paxos 的方式来尽量解决 2PC 的缺陷，比如改进后的 2PC 不需要全局共识了而只需要 quorum 共识，以及 coordinator 可以根据 paxos 算法自动 failover ，这都是很大的改进了。

[liuhan907]

@yamasa 但是 raft 读数据也可以不走 leader 不是么

[happyxhw101]

C A P 你是一点都不看啊

[yamasa]

@liuhan907 Raft source paper 可没让走 follower ，论文里就是让走 leader 可提供线性一致性读，后续的各类系统实现的时候走 follower 显然是为了性能的妥协，不能怪到 Raft 算法本身上去

[akira]

现在存算分离的数据库方案成熟了么，感觉可以直接规避掉这一大堆麻烦事情

[xiyy02]

@happyxhw101 我理解 CAP 指的是在实现分布式一致性遇到网络分区（ P ）时的取舍方案（ C or A ），而 Raft 协议是一种保证多副本共识而最终达到多副本强一致的策略，它们都是单独的理论，但在做工程实现时需要一起考虑：比如我有一个分布式系统通过 Raft 实现节点间的强一致，正常情况下，它确实是强一致的，而且运行的很好，但当发生网络分区时我需要结合 CAP 理论在可用性和一致性之间作取舍，如果要舍弃可用性，那就分区期间为了保证一致性让整个系统不可用（具体表现为客户端无法读或写），如果要舍弃强一致性，那就在分区期间也允许读写操作，但后果就是多节点间因为分区导致多 leader 写或单 leader 写的内容无法同步到没有 leader 的分区节点，导致各分区间的数据不一致。
额。。只是个人理解，不知道对不对，CAP 和 Raft 都是我最近在研究的东西，感觉都很抽象😭

[lifanxi]

@akira 成熟。但是分离以后存储也得是分布式的吧？分布式存储一样需要解决一致性的问题。没有规避掉这些麻烦事情，只是这些麻烦的事情交给了更底层去做。

[beneo]

Mysql 依赖于单个主库来处理所有写操作，如果主库宕机，切换到从库作为新的主库，这个过程中可能会面临短暂的服务不可用，或者数据延迟问题。而 Paxos 和 Raft 就提供了对分布式而言更通用、更强大的算法，能够帮助设计和实现高可用、高一致性的分布式系统。

[mightybruce]

2PC 几个回复写得有点问题，
mysql 实现 2pc 不是 binlog 和 relog 达成共识，而是 XA 事务。XA 事务在很多数据库中是有实现。

[chenzw2]

raft 算法演示，非常清晰了
https://code.bqrdh.com/alg/raft/

[kuro1]

6.824
https://pdos.csail.mit.edu/6.824/schedule.html

[vczyh]

@mightybruce 谢谢提醒，我理解确实有点问题，把 XA 和崩溃恢复混在一起理解了。

[ywutiao]

@xiyy02 CAP 理论不用太纠结现在很多人批斗这篇论文，因为说的太绝对了。况且分布式的东西你能舍弃 A 吗，共识算法算是保证了部分 A 半数可用，在这种情况下保证一致性。而你一开始提到 Mysql 同步机制，这哪里算是一致性，你这不就是勉强搞了个复制算法吗，同步、半同步、全同步这些东西（个人感觉共识协议是半同步的进化版本）。只能算是做了共识算法的一部分

[ywutiao]

@akira 存算分离和共识完全是不同维度上的事

[shalk]

1. mysql 副本同步机制，也就是复制机制。

2. 比如有 1 主 3 从（ A ，B ，C ，D ），如果 mysql 挂了切主，谁当主谁当从，都要达成共识，这是共识算法。

3. 最后 A ，B ，C ，D 数据是不是相同，延迟多少，一致成什么效果，才叫一致性。

[iminto]

不要编造名词，或者虚构理论。

“既然 mysql 可以靠 binlog 达成多副本共识”，这是谁告诉你的呢。。。

[liuhan907]

@yamasa 这倒是没错，不过现在的实现倒是都提供了非 leader 读。反正也没人按照原始论文来实现算法，都是改了又改的。

[Jasonhhh]

因为数据库不仅有 MySQL ，还有 Redis 等其他数据库。Redis 的主从切换就使用了 Raft 共识算法。