【问题标题】：LMAX Replicator Design - How to support high availability?LMAX Replicator Design - 如何支持高可用性？
【发布时间】：2014-06-25 11:44:42
【问题描述】：

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

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

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

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

有两种选择：

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

接收器将从网络读取并将事件推送到复制日志而不是环形缓冲区
单独的“阅读器”可以读取日志并将事件发布到环形缓冲区。
可以使用 RAFT 跨节点复制日志。我们不需要复制器和日志器，因为功能已经由 RAFT 的复制日志完成

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

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

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

【问题讨论】：

您最终是否使用 RAFT 开发 HA 和日记功能？如果是这样，您是自己推出的还是使用了几个预建库之一？
不，我还没有实现它。很高兴听到您的用例，您可以分享任何链接吗？

标签： replication high-availability disruptor-pattern lmax raft

【解决方案1】：

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

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

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

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

外部 Raft 复制

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

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

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

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

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

集成 Raft 复制

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

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

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

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

日志组件挂起输入环缓冲区；它只需要处理 Raft 规定的某些类型的消息。这可能是系统中最慢的部分。

当数据被认为是复制时，它会通过“真实业务逻辑”输入中断器移动到第二阶段。在那里对其进行处理，发送给 Client Outbound Disruptor，然后发送给您数百万满意的付费客户之一。

【讨论】：