zhh-4096
2019-12-16 00:00:00 发布
现在主流的与数据库复制相关的一致性算法(协议)在工程实现上分为两大派: Strong Leader 和 Leaderless。

Strong Leader: 只有一个节点可写，并且需要实现Leader选举。比较有代表性的论文是Leslie Lamport那几篇Paxos相关的论文以及Diego Ongaro 和 John Ousterhout的Raft。

Leaderless: 所有节点都可写，因为没有Leader，所以自然不需要实现Leader选举。这一派比较有份量的论文不多，比较出名的是CMU发表的EPaxos，论文在这里 网页链接 这个是正确性证明的论文: 网页链接

Leaderless 这个派系在工程实现上要比Strong Leader复杂一些，EPaxos就相当复杂，通过40多页的证明也能从一个侧面看出它的复杂性。Apache Cassandra 对EPaxos做了工程实现 网页链接 从2014年就开始做了，估计会合并到4.0(还未发布)，Cassandra 这种对等架构的系统的确适合Leaderless。除了 Cassandra 我还没有找到其他用 EPaxos 的数据库。

我的Lealone也属于Leaderless派系，但是跟EPaxos差别很大。

采用Strong Leader实现的数据库或相关产品比Leaderless更多。

MySQL Group Replication 实际上同时支持 Strong Leader 和 Leaderless 网页链接 它的Single-Primary部署模式就是Strong Leader，而Multi-Primary部署模式就是Leaderless。不过它的Multi-Primary模式跟Leaderless还是有点差别，客户端并不是并行写多个Primary的，看它的架构 网页链接 需要客户端先接入一个Primary，然后再由此Primary并行写到其他Primary，这种设计我想是为了兼容现有的客户端吧，如果在客户端实现并行写多个Primary，需要修改客户端协议，用不同语言实现的客户端需要做改动还是挺麻烦的。

但是我看到MySQL Connector/J 8.0 网页链接 又提供了Replication相关的功能，没去翻代码，不太确信它是否支持在客户端并行写多个Primary，我的Lealone就是并行写多个节点的，这样可以减少一次round trip。

用 MySQL Group Replication 有一个前提条件让我印象特别深刻，网页链接 就是每个表必须有主键或者不为null的唯一键。因为我最近在我的Lealone数据库中实现复制算法时刚好碰到没有主键的表当执行insert时会有问题。因为Lealone跟MySQL都类似，对于没有主键的表，insert新记录时，会为这条记录自动生成一个递增的逻辑rowId，这个rowId是用来关联索引的。

在Group Replication的场景下，如果每个节点对同一条记录生成不同的rowId是错误的，检测rowId的一致性需要另外的技巧(这时行锁是用不上的，因为是新记录，所以没法用行锁，行锁只用于已经存在的记录)。

如果已经有主键或者不为null的唯一键，就算不同客户端发起的insert操作在不同节点上的执行顺序全乱了，因为存在唯一性约束，所以总是能检测到冲突的，在哪个节点上都存在冲突，而rowId是否一致在单独的节点上是看不出来的，只能全局看。