LMAX Replicator设计 - 如何支持高可用性？

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

我个人会做第一个,因为它将关注点分成不同的过程.如果我为自己实施Raft,我将采用第二个场景的前半部分并将其置于自己的过程中.

外部筏复制

其中Raft由外部过程实现.

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

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

在这种情况下不需要日志记录组件,因为外部筏系统会为您执行日志记录.

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

集成筏复制

其中筏在与"真实商业逻辑"相同的过程中实施.

就Raft而言,复制是业务逻辑.实际上,您有多个级别的业务逻辑,或者相当于业务逻辑的多个阶段.

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

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

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

当数据被认为是复制时,它将通过"Real Business Logic"输入干扰器移动到第二阶段.在那里它被处理,发送到客户出站干扰器,然后发送给您的数百万快乐付费客户之一.