LMAX Disruptor通常使用以下方法实现： enter image description here

在此示例中，Replicator负责将输入事件\命令复制到从属节点。复制一组节点需要我们应用一致性算法，以防我们希望系统在出现网络故障，主故障和从站故障时可用。

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

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

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

选项1：使用复制日志作为输入事件队列 enter image description here

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

选项2：使用Replicator将输入事件\命令推送到从属的输入日志文件 enter image description here

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

关于将复制和日记折叠到Raft组件中，您的直觉是正确的。但是，Raft协议确定了什么时候需要存储在磁盘上。

以下是两种不同的方式来看待它。

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

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

外部筏复制

其中Raft由外部进程实现。

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

在这种情况下，复制组件可能有很多飞行事件，因此它的读取光标远远超过它发布到业务逻辑的光标。

在此方案中不需要日记组件，因为外部筏系统会为您执行日志记录。

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

集成筏复制

在与“真实商业逻辑”相同的过程中实施哪种木筏。

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

我将使用两个输入中断器和两个输出中断器来强调单独的业务逻辑。您可以将心脏的内容组合，分割或重新排列。或者你的探查者的内容。

正如我所提到的，第一阶段是筏复制。客户端事件进入复制输入干扰器。 Raft逻辑可能会批量处理它，然后发送给复制输出干扰器上的追随者。所有Raft消息也会进入复制输入干扰器。 Raft逻辑也会选择这些并将相应的响应发送到复制输出干扰器上的相应的Followers / Master。）

一个记录器组件挂起输入环缓冲区;它只需处理Raft规定的某些类型的消息。这可能是系统中最慢的部分。

当数据被视为已复制时，它将通过“Real Business Logic”输入干扰器移至第二阶段。在那里它被处理，发送到客户出站干扰器，然后发送给您的数百万快乐付费客户之一。