disruptor 使用LMAX/Disruptor构建高扩展性的交易引擎的经验分享

Koinex的交易引擎是使用LMAX架构的很多原理设计的。这使我们能够在高峰时间承受很大的负荷。在快速增长的金融系统中，干净和可扩展的架构对于更好的可扩展性和更快的执行非常重要。LMAX架构帮助我在Koinex中设计多个实时应用程序，这些应用程序不具有显著的事务性。虽然不可能对整个架构进行深入总结，但我列出了一些可以提高我们为产品设计的可扩展架构质量的关键知识。开始吧！LMAX架构的组件:

输入Disruptor：负责网络的I / O操作，解组，复制和日志记录。输出Disruptor：帮助编组处理后收到的消息和响应。业务逻辑处理器：处理应用程序中的所有业务逻辑。如何设计业务逻辑处理器？业务逻辑处理器是来自输入Disruptor的事件的状态机。它们有助于处理输入和产生输出。 内存中逻辑处理：从输入中断器读取后的处理数据应存储在内存数据结构中。这减少了输出中断器执行的I / O操作的延迟。没有数据库，不需要持久存储。 顺序输入流：从输入中断器读取的输入必须遵循顺序路径，例如，它应该是FIFO，LIFO或其他一些序列。 集群业务处理器：由于系统内存很多，因此应将输入数据流馈送到多个业务处理器中，这样，如果任何处理器出现故障或不一致，则可以将流量切换到其他工作流量。但是，在任何给定的时间点，只有一个处理器链接到输出中断器。 输入源数据库：输入流事件应存储在事件系统中，如Kafka，ActiveMQ，它有助于恢复故障处理器并降低系统停机风险。 更好的编程模型：更好的错误处理和异步定义与外部服务的更好交互是在设计这样的实时架构时应该遵循的关键编程模型。 设计输出和输入Disruptor的关键点输入和输出Disruptor会处理消息，因此需要以持久的方式存储它们并按照集群业务处理器进行复制。由于数据由业务处理器独立存储，复制和使用，这导致分布式系统中的生产者 - 消费者问题，因为业务处理器不应该读取正在复制的数据。 例如，如果数据复制失败并且同时业务处理器处理了数据，那么这将导致集群业务处理器之间的不一致。 并行数据结构来拯救Martin提出了“环形缓冲区”的概念，这是一种并发数据结构。环形缓冲区的设计基于共享序列计数器，生产者和使用者使用它来处理并发。对于您的体系结构，您可以使用或设计任何此类并发数据结构来处理生产者 - 消费者问题。 什么是Concurrent Ring Buffer及其工作原理？Ring Buffer是队列数据结构的组播网络。它被称为多播网络，因为每当生产者放置一个对象时，所有消费者都会在下游队列的帮助下被通知并行消费。 生产者和消费者都在序列计数器的帮助下处理并发。每个生产者会编写自己的序列计数器，但在写入之前，它会读取消费者和生产者的所有其他序列计数器，以避免并行写入并保持一致性。序列计数器可以被视为锁定变量。类似地，消费者在消费之前也会在序列计数器上观察，以确保他们读取一致的数据。

在上面的场景中，日志器日志、复制器复制器和业务逻辑处理器充当消费者，而解组器充当生产者。日志记录:为了恢复故障的业务处理器，必须存储数据事件。日志有助于将数据存储在实时流式内存数据磁盘中，同时保留数据序列。灾难恢复在考虑充分利用任何体系结构时，我们还必须分析系统如何能够轻松快速地从灾难中恢复。LMAX架构可以帮助我们降低其独立组件带来的风险。有哪些风险？

如果运行业务处理器的数据由于与输入中断器的通信问题而损坏。如果流数据的日记记录操作失败并影响数据复制。使用LMAX进行风险缓解如上所述，Ring Buffer是一种并发数据结构，通过解决生产者 - 消费者问题，确保减少业务处理器之间数据损坏的风险。 正在运行的业务处理器是集群的，因此多个处理器与输入数据保持同步，如果任何业务处理器发生故障，另一个可以被视为主服务器，停机时间为零。 日志数据通过流式传输已记录的事件来帮助恢复损坏的处理器，并且还复制导致处理器故障的情况。 你何时应该使用这种架构？总结以上几点，您可以在架构中使用LMAX模式来设计可扩展且快速的系统，在下面情况满足的条件下： 围绕事务数据库的传统并发会话模型变得难以管理。您正在解决的业务问题并非严重的事务性问题。由于事务彼此更加独立，因此协调的需求较少，因此使用并行运行的单独处理器变得更具吸引力。后端系统不与用户交互，并且可以使用如上所述的异步通信和编程模型。您需要很好地分离关注点，允许人们专注于领域驱动设计，并且还希望将大部分平台复杂性完全分开。 PS：Koinex的贸易引擎使用上面提到的许多原则设计。这使我们能够在高峰时段承受大量负荷。 Koinex和LMAX的贸易引擎如前所述，LMAX架构帮助我们为Koinex设计稳定且高吞吐量的Trade Engine。我们通过在内存中开发业务处理器来实现LMAX的一些原则，从而将输入和输出流的设计问题分开。但是，我们没有遵循集群业务处理器的基础，这限制了我们在恢复过程中没有停机时间。虽然引擎的事件流性质帮助我们以更快的方式恢复系统。