sql - 使用 sql 主键进行主选举-这种方法有缺陷吗？

Question

假设我有这样的 SQL 模式-

create table master_lock(job_type int primary key, ip varchar);

现在每个节点都尝试像这样插入一个值-

insert into master_lock values(1,192.168.1.1);
insert into master_lock  values(1,192.168.1.2)

能够成功插入的节点现在可以被认为是主节点。我们可以向 sql 表添加一个新的列时间戳，以便可以删除陈旧的锁。

通过这个方案，我可以很容易地选出一个主节点。为什么我需要 Paxos/Raft 等？

Answer 1

谁说你需要 Paxos/Raft/等等？你所描述的本质上是一个分布式的、原子的比较和交换操作。您可以使用任意数量的机制来执行此操作，SQL 数据库就可以正常工作。添加一个必须不断刷新以保持主状态的额外时间戳的想法是这个领域的常见模式，它通常被称为“主租约”。

根据您的应用程序及其预期的操作环境，使用指定的第三方在对等点之间进行仲裁(这是 SQL 数据库在您的示例中扮演的角色)可能是您的最佳选择。它引入了单点故障，但它非常简单，并且周期性停机维护窗口可能是可以容忍的，同样取决于应用程序。 Raft 或 Multi-Paxos 之类的潜在优势在于没有单点故障。只要有一定数量的对等点可用，就可以选择和维护主对等点。前期实现可能要复杂一个数量级，但您可以通过删除指定的第 3 方的概念来消除单点故障并获得整体架构简单性的衡量标准。

最终，这取决于您要尝试做什么以及您需要的稳健性级别。 SPOF 的维护负担和潜在停机时间是否会破坏您的应用程序？如果是，请使用 Raft/Multi-Paxos。如果不是，请遵守 KISS 原则并走指定的第 3 方路线。