replication - LMAX Replicator Design - 如何支持高可用性？

Question

LMAX Disruptor 通常使用以下方法实现:


如本例所示，Replicator 负责将输入事件\命令复制到从节点。跨一组节点进行复制需要我们应用共识算法，以防我们希望系统在出现网络故障、主故障和从故障时可用。

我正在考虑将 RAFT 共识算法应用于这个问题。一项观察是:“RAFT 要求在复制期间将输入事件\命令存储到磁盘(持久存储)”(引用此链接)

这种观察本质上意味着我们无法执行内存复制。因此，我们可能必须结合复制器和日志器的功能才能成功地将 RAFT 算法应用于 LMAX。

有两种方法可以做到这一点:

选项 1:使用复制的日志作为输入事件队列

接收者将从网络读取并将事件推送到复制的日志而不是环形缓冲区

一个单独的“阅读器”可以从日志中读取并将事件发布到环形缓冲区。

可以使用 RAFT 跨节点复制日志。我们不需要复制器和日志器，因为功能已经由 RAFT 的复制日志

完成。

我认为这个选项的一个缺点是我们做了一个额外的数据复制步骤(接收器到事件队列而不是环形缓冲区)。

选项 2:使用 Replicator 将输入事件\命令推送到从属的输入日志文件


我想知道 Replicator 的设计是否还有其他解决方案？人们为复制器采用了哪些不同的设计选项？特别是任何可以支持内存复制的设计？

Answer 1

关于将复制和日志折叠到 Raft 组件中，您的直觉是正确的。但是，Raft 协议(protocol)准确地规定了何时需要将内容存储在磁盘上。

这里有两种不同的方式来看待它。

我假设在复制之前没有大量的计算，例如事务处理，因为您的图表中没有任何计算。

我个人会做第一个，因为它将关注点分成不同的流程。如果我自己实现 Raft，我会采用第二个场景的前半部分并将其放入自己的进程中。

外部 Raft 复制

其中 Raft 是由外部进程实现的。

复制组件将复制的业务外包给外部的 Raft 进程。一段时间后，Raft 响应复制组件，它实际上已被复制。复制组件更新环形缓冲区中的项目，并将其发布的光标向前移动。业务逻辑看到发布的游标(通过 waitFor )并使用新复制的数据。

在这种情况下，复制组件可能有很多正在进行的事件，因此它的读取游标远远领先于它发布到业务逻辑的游标。

在这种情况下不需要日志组件，因为外部 raft 系统会为您执行日志。

请注意，复制可能是系统中最慢的组件!

集成 Raft 复制

其中 raft 在与“Real Business Logic”相同的过程中实现。

在 Raft 中，复制是业务逻辑。实际上，您有多个级别的业务逻辑，或者等效地，业务逻辑的多个阶段。

为此，我将使用两个输入中断器和两个输出中断器来强调单独的业务逻辑。您可以根据自己的喜好组合、拆分或重新排列。或者你的分析器的内容。

正如我所提到的，第一阶段是 Raft 复制。客户端事件进入复制输入中断器。 Raft 逻辑可能会分批拾取它，然后发送到复制输出中断器上的跟随者。所有 Raft 消息也会进入 Replication Input Disruptor。 Raft 逻辑也拾取这些并将适当的响应发送到复制输出中断器上的适当追随者/主控者)。

Journaler 组件挂起 Input Ring Buffer；它只需要处理 Raft 规定的某些类型的消息。这可能是系统中最慢的部分。

当数据被认为是复制时，它通过“Real Business Logic”输入中断器移动到第二阶段。它在那里被处理，发送给客户出站干扰器，然后发送给您数百万满意的付费客户之一。