raft 领导者选举算法可以在无服务器（lambda）上运行吗？

Question

是否可以在无服务器 lambda 而不是集群上运行 Raft？主要好处是无需维护集群或虚拟机。

Answer 1

（免责声明：虽然我几年前读过原始的 Raft 论文，并使用高级文章刷新了自己，但我不是这方面的专家，也从未实现过它。）

它也许是可能的，但你必须针对 Lambda 提供的框架进行工作。您将失去 Lambda 和 Raft 的许多好处。

首先，您需要弄清楚如何识别每个实例（以便您可以选择一个实例作为领导者），并让该实例在 Lambda 调用中保持不变。 Lambda 层 或许可以做到这一点，但它增加了复杂性。

然后，要选举领导者，你需要多数票。大多数...什么？它必须是 Lamdba 的最大并发数，每个 Lambda 都需要查询该并发数。好吧，没什么大不了的；但这确实意味着每次选举时，您至少需要

$MaxConcurrency / 2 + 1

实例。

然后，您需要弄清楚如何心跳。这并非“不可能”，但在 Lambda 中做起来相当尴尬；您可能需要类似 SQS 队列的东西，您可以在其中填充 $N 消息，每个消息都会触发一次心跳接收。您的每个关注者都需要这个 — 再次强调，至少

$MaxConcurrency / 2 + 1

— 这意味着您“始终”必须至少有那么多活跃的 Lambda。那时，您基本上是在使用 Lambda 来运行昂贵的集群。最后，您需要一种方法来与领导者一起实际做一些事情：如何让它处理请求？ Lambda 无法打开 HTTP 端口，因此您无法使用它；并且您不能使用 API Gateway，因为这会将请求轮询到任何 ol' 实例（而不仅仅是领导者）。您或许可以创建一个 Lambda 手动轮询的 SQS 队列（使用应用程序代码，而不是 AWS 的内置触发器），但这会很尴尬。这也没有帮助：如果您想要的是一个只有一个 Lambda 实例从中读取数据的 SQS 队列，您可以创建一个 FIFO 队列来触发最大并发数为 1 的 Lambda。

简而言之，虽然它在技术上可能是可行的，但您可能必须非常热地运行 Lambda（其中一半 24/7 运行），这基本上会将其变成一个非常昂贵的集群。作为回报，你将拥有一个最多也难以实际使用的领导者。

Raft 需要稳定的状态存储，因此如果您的 lambda 使用 ddb、s3 或任何其他持久存储，那么 raft 逻辑本身可能会在 lambda 中运行。

从设计的角度来看，代码将具有一个具有多种实现的存储抽象（接口）（例如，一种用于测试，一种用于本地，一种用于生产）。

附注 忘记提及 lambda 需要某种并发控制，因此如果 lambda X 代表一个 raft 节点，则该 lambda 的不超过一个实例可以修改状态

Answer 2

如果您的应用程序不是关键任务，并且 Raft 并不重要，那么 DK Lab 的注册表服务可能就是您所需要的。注册表服务是一种无服务器领导者选举服务和线性化键值存储，具有微秒级 p99（在许多情况下还有 p99.9）延迟和非常低的成本。

有关注册服务的更多详细信息：

https://www.dklab.us/registry-service

Answer 3

开源Python客户端可用：

https://github.com/DKLabPublic/RegistryClients