LMAX 架构

整体结构

图 1：LMAX 的架构，分为三个部分

在顶层，架构有三个部分

• 业务逻辑处理器[5]
• 输入中断器
• 输出中断器

顾名思义，业务逻辑处理器处理应用程序中的所有业务逻辑。正如我上面提到的，它作为一个单线程 Java 程序执行此操作，该程序对方法调用做出反应并生成输出事件。因此，它是一个简单的 Java 程序，不需要任何其他平台框架来运行，除了 JVM 本身，这使得它可以轻松地在测试环境中运行。

虽然业务逻辑处理器可以在简单的环境中运行以进行测试，但要使其在生产环境中运行，还需要更多复杂的编排。输入消息需要从网络网关中取出并取消序列化、复制和记录。输出消息需要为网络序列化。这些任务由输入和输出中断器处理。与业务逻辑处理器不同，这些是并发组件，因为它们涉及既慢又独立的 IO 操作。它们是专门为 LMAX 设计和构建的，但它们（与整体架构一样）适用于其他地方。

业务逻辑处理器

输入和输出中断器

虽然业务逻辑发生在一个线程中，但在调用业务对象方法之前，还有很多任务需要完成。处理的原始输入以消息的形式从网络中获取，此消息需要被反序列化为业务逻辑处理器方便使用的形式。事件溯源依赖于保存所有输入事件的持久日志，因此每个输入消息都需要被记录到持久存储中。最后，该架构依赖于业务逻辑处理器的集群，因此我们必须将输入消息复制到整个集群中。类似地，在输出端，输出事件需要被序列化以通过网络传输。

图 2：输入中断器执行的活动（使用 UML 活动图符号）

复制器和日志记录器涉及 IO，因此速度相对较慢。毕竟，业务逻辑处理器的核心思想是避免进行任何 IO。此外，这三个任务相对独立，它们都需要在业务逻辑处理器处理消息之前完成，但它们可以按任何顺序完成。因此，与业务逻辑处理器不同，每个交易都会改变后续交易的市场，这里自然适合并发。

为了处理这种并发，LMAX 团队开发了一个特殊的并发组件，他们称之为 **中断器**[11]。

在粗略的层面上，您可以将中断器视为队列的多播图，生产者将对象放入其中，这些对象被发送到所有消费者，以便通过单独的下游队列并行消费。当您查看内部时，您会发现这个队列网络实际上是一个单一的数据结构——环形缓冲区。每个生产者和消费者都有一个序列计数器，用于指示它当前正在处理的缓冲区中的哪个槽。每个生产者/消费者都写入自己的序列计数器，但可以读取其他计数器。这样，生产者可以读取消费者的计数器，以确保它想要写入的槽可用，而无需对计数器进行任何锁定。类似地，消费者可以通过观察计数器来确保它只处理其他消费者完成的消息。

图 3：输入中断器协调一个生产者和四个消费者

输出中断器类似，但它们只有两个顺序消费者用于序列化和输出。[12] 输出事件被组织成多个主题，以便消息可以仅发送给对它们感兴趣的接收者。每个主题都有自己的中断器。

我描述的中断器以一个生产者和多个消费者的方式使用，但这并不是中断器设计上的限制。中断器也可以与多个生产者一起工作，在这种情况下，它仍然不需要锁定。[13]

中断器设计的一个好处是，如果消费者遇到问题而落后，它更容易快速赶上。如果反序列化器在处理槽 15 时遇到问题，并在接收器位于槽 31 时返回，它可以一次性读取槽 16-30 中的数据以赶上。这种从中断器中批量读取数据的方式使落后的消费者更容易快速赶上，从而减少了总体延迟。

我在这里描述了日志记录器、复制器和反序列化器各一个——这确实是 LMAX 所做的。但该设计允许这些组件中的多个运行。如果您运行两个日志记录器，那么一个将占用偶数槽，另一个日志记录器将占用奇数槽。如果需要，这将允许这些 IO 操作进一步并发。

环形缓冲区很大：输入缓冲区为 2000 万个槽，每个输出缓冲区为 400 万个槽。序列计数器是 64 位长整数，即使环形槽包裹，它们也会单调递增。[14] 缓冲区的大小设置为 2 的幂，因此编译器可以执行有效的模运算，以将序列计数器编号映射到槽编号。与系统其他部分一样，中断器在夜间被重启。这种重启主要是为了清除内存，以便在交易期间减少昂贵的垃圾回收事件的可能性。（我也认为定期重启是一个好习惯，这样您就可以练习如何在紧急情况下进行重启。）

日志记录器的任务是将所有事件存储在持久形式中，以便在出现任何问题时可以重播它们。LMAX 不使用数据库来完成此操作，只使用文件系统。他们将事件流式传输到磁盘。用现代术语来说，机械磁盘对于随机访问来说速度非常慢，但对于流式传输来说速度非常快——因此有了“磁盘是新的磁带”的口号。[15]

之前我提到过 LMAX 在集群中运行其系统的多个副本，以支持快速故障转移。复制器使这些节点保持同步。LMAX 中的所有通信都使用 IP 多播，因此客户端不需要知道哪个 IP 地址是领导节点。只有领导节点直接监听输入事件并运行复制器。复制器将输入事件广播到跟随节点。如果领导节点出现故障，它将无法发送心跳，另一个节点将成为领导节点，开始处理输入事件，并启动其复制器。每个节点都有自己的输入中断器，因此有自己的日志并执行自己的反序列化。

即使使用 IP 多播，仍然需要复制，因为 IP 消息可能在不同节点上以不同的顺序到达。领导节点为其余处理提供确定性序列。

反序列化器将来自网络的事件数据转换为可以用于在业务逻辑处理器上调用行为的 Java 对象。因此，与其他消费者不同，它需要修改环形缓冲区中的数据，以便它可以存储此反序列化的对象。这里的规则是，消费者被允许写入环形缓冲区，但每个可写字段只能有一个并行消费者被允许写入它。这保留了只有一个写入者的原则。[16]

图 4：扩展了中断器的 LMAX 架构

中断器是一个通用组件，可以在 LMAX 系统之外使用。通常，金融公司对自己的系统非常保密，即使对于与业务无关的项目也保持沉默。LMAX 不仅公开其整体架构，还开源了中断器代码——这让我非常高兴。这不仅将允许其他组织使用中断器，还将允许对它的并发特性进行更多测试。

队列及其缺乏机械同情

LMAX 架构引起了人们的注意，因为它是一种与大多数人正在考虑的高性能系统截然不同的方法。到目前为止，我已经讨论了它的工作原理，但没有深入探讨为什么以这种方式开发它。这个故事本身很有趣，因为这种架构并非凭空出现。在团队确定使用这种架构之前，他们花了很长时间尝试了更传统的替代方案，并认识到它们的缺陷。

如今，大多数业务系统都具有一个核心架构，该架构依赖于通过事务性数据库协调的多个活动会话。LMAX 团队熟悉这种方法，并确信它不适用于 LMAX。这种评估是基于 Betfair 的经验——Betfair 是创建 LMAX 的母公司。Betfair 是一个博彩网站，允许人们对体育赛事进行下注。它处理非常高的流量，并且存在大量争用——体育博彩往往会在特定事件周围爆发。为了使它正常工作，他们拥有最热门的数据库安装之一，并且不得不做很多不自然的事情才能使其正常工作。基于这种经验，他们知道维护 Betfair 的性能有多困难，并且确信这种架构不适合交易网站所需的极低延迟。因此，他们不得不寻找不同的方法。

他们最初的方法是遵循如今许多人都在说的话——要获得高性能，您需要使用显式并发。对于这种情况，这意味着允许订单由多个线程并行处理。但是，正如并发中经常出现的情况一样，困难在于这些线程必须相互通信。处理订单会改变市场状况，而这些状况需要被传达。

他们早期探索的方法是 Actor 模型及其近亲 SEDA。Actor 模型依赖于独立的、活动的、拥有自己线程的对象，它们通过队列相互通信。许多人发现这种并发模型比尝试基于锁定原语做一些事情更容易处理。

该团队使用 Actor 模型构建了一个原型交易所，并对其进行了性能测试。他们发现，处理器花费更多的时间来管理队列，而不是执行应用程序的实际逻辑。队列访问是一个瓶颈。

当像这样推动性能时，开始变得重要，要考虑现代硬件的构建方式。马丁·汤普森喜欢使用的短语是“机械同情”。这个词来自赛车，它反映了车手对汽车的本能感觉，因此他们能够感觉到如何充分发挥汽车的潜力。许多程序员，我承认我属于这个阵营，对编程如何与硬件交互没有多少机械同情。更糟糕的是，许多程序员认为他们有机械同情，但它建立在关于硬件过去如何工作的观念之上，而这些观念现在已经过时很多年了。

现代 CPU 影响延迟的主要因素之一是 CPU 如何与内存交互。如今，访问主内存对于 CPU 来说是一个非常慢的操作。CPU 有多个级别的缓存，每个缓存都比前一个快得多。因此，为了提高速度，您希望将代码和数据放入这些缓存中。

在某种程度上，Actor 模型在这里有所帮助。您可以将 Actor 视为一个独立的对象，它将代码和数据聚集成一个集群，这是一个自然的缓存单元。但 Actor 需要通信，它们通过队列进行通信——而 LMAX 团队观察到，正是队列干扰了缓存。

解释如下：为了将一些数据放入队列，您需要写入该队列。类似地，要从队列中取出数据，您需要写入队列以执行删除操作。这就是写入争用——多个客户端可能需要写入相同的数据结构。为了处理写入争用，队列通常使用锁。但是，如果使用锁，则会导致上下文切换到内核。发生这种情况时，涉及的处理器可能会丢失其缓存中的数据。

他们得出的结论是，为了获得最佳的缓存行为，你需要一个设计，该设计只有一个核心写入任何内存位置[17]。多个读取器是可以的，处理器通常在它们的缓存之间使用特殊的高速链接。但是队列不符合单写入原则。

这项分析让 LMAX 团队得出了一些结论。首先，它导致了 disruptor 的设计，该设计坚定地遵循单写入约束。其次，它导致了探索单线程业务逻辑方法的想法，并提出了一个问题：如果一个线程摆脱了并发管理，它能有多快？

在单线程上工作的本质是确保你有一个线程在一个核心上运行，缓存预热，并且尽可能多的内存访问都去缓存而不是主内存。这意味着代码和工作集数据都需要尽可能一致地访问。此外，将小对象与代码和数据放在一起，可以使它们作为一个单元在缓存之间交换，简化缓存管理，并再次提高性能。

通往 LMAX 架构的关键部分是使用性能测试。对基于 Actor 的方法的考虑和放弃来自构建和性能测试原型。同样，改进各种组件性能的许多步骤都是由性能测试实现的。机械同情非常有价值——它有助于形成关于你可以进行哪些改进的假设，并引导你向前迈进而不是后退——但最终，测试会给你令人信服的证据。

然而，这种风格的性能测试并不是一个被很好理解的话题。LMAX 团队经常强调，想出有意义的性能测试通常比开发生产代码更难。同样，机械同情对于开发正确的测试很重要。除非你考虑了 CPU 的缓存行为，否则测试低级并发组件是没有意义的。

一个特别的教训是，编写针对空组件的测试的重要性，以确保性能测试足够快，能够真正衡量真实组件的行为。编写快速的测试代码并不比编写快速的生产代码容易，而且很容易得到错误的结果，因为测试没有组件快，它试图衡量。

你应该使用这种架构吗？

乍一看，这种架构似乎只适用于一个非常小的利基市场。毕竟，导致它的驱动因素是能够以非常低的延迟运行大量复杂的事务——大多数应用程序不需要以 600 万 TPS 的速度运行。

但让我着迷的是这个应用程序，他们最终设计了一个架构，它消除了困扰许多软件项目的许多编程复杂性。围绕事务数据库的传统并发会话模型并非没有麻烦。通常，与数据库的关系需要付出相当大的努力。对象/关系映射工具可以帮助解决处理数据库的大部分痛苦，但它并不能解决所有问题。大多数企业应用程序的性能调整都涉及围绕 SQL 调整。

如今，你可以在你的服务器中获得比我们这些老家伙所能获得的磁盘空间更多的主内存。越来越多的应用程序能够将它们的所有工作集放在主内存中——从而消除了复杂性和迟缓的来源。事件溯源提供了一种为内存系统解决持久性问题的方法，在单线程中运行所有内容解决了并发问题。LMAX 的经验表明，只要你的 TPS 不超过几百万，你将拥有足够的性能空间。

这里与人们对 CQRS 的兴趣日益增长有相当大的重叠。基于事件的内存处理器是 CQRS 系统命令端的自然选择。（尽管 LMAX 团队目前没有使用 CQRS。）

那么，什么表明你不应该走这条路呢？对于像这样的鲜为人知的技术来说，这始终是一个棘手的问题，因为该行业需要更多时间来探索其边界。然而，一个起点是考虑鼓励这种架构的特征。

一个特征是，这是一个连接的领域，其中处理一个事务总是可能改变后续事务的处理方式。对于彼此更加独立的事务，协调的必要性较小，因此使用并行运行的独立处理器变得更有吸引力。

LMAX 专注于弄清楚事件如何改变世界的后果。许多网站更多的是关于获取现有的信息存储并将其各种组合呈现给尽可能多的眼球——例如，想想任何媒体网站。在这里，架构挑战通常集中在正确地获取缓存。

LMAX 的另一个特征是，这是一个后端系统，因此考虑它是否适用于以交互模式运行的系统是合理的。越来越多的 Web 应用程序帮助我们习惯了对请求做出反应的服务器系统，这方面与这种架构非常吻合。这种架构比大多数此类系统更进一步的是它绝对使用异步通信，导致我之前概述的编程模型的更改。

对于大多数团队来说，这些变化需要一些时间来适应。大多数人倾向于以同步的方式思考编程，并且不习惯处理异步。然而，长期以来，异步通信一直是响应能力的必不可少的工具。有趣的是，看看 JavaScript 世界中异步通信的更广泛使用，包括 AJAX 和 node.js，是否会鼓励更多人研究这种风格。LMAX 团队发现，虽然适应异步风格需要一些时间，但它很快变得自然，而且通常更容易。特别是，在这种方法下，错误处理更容易处理。

LMAX 团队肯定认为，协调事务数据库的时代已经屈指可数。能够使用这种架构更轻松地编写软件，并且它运行得更快，消除了对传统中央数据库的大部分理由。

就我而言，我发现这是一个非常激动人心的故事。我的许多目标都是专注于对复杂领域进行建模的软件。像这样的架构提供了良好的关注点分离，允许人们专注于领域驱动设计，并将大部分平台复杂性很好地分离。领域对象和数据库之间的紧密耦合一直是一个令人恼火的问题——像这样的方法提供了一种摆脱困境的方法。