中频交易系统的颠覆者与反应式架构

Posted 2023-04-12

【中文标题】中频交易系统的颠覆者与反应式架构

【英文标题】：Disruptor vs. Reactive architecture for middle-frequency trading system

【发布时间】：2018-08-12 11:52:14

【问题描述】：

我正在尝试为我正在开发的中频交易系统选择合适的架构。目前，我从 Web Socket 或 Rest 接收消息并在那里处理它们。有时它包括 IO 操作（即额外的休息请求），所以它工作得非常缓慢，我想所有其他消息都在 Web Socket 客户端的实现中得到缓冲。这种幼稚的方法看起来不太可扩展。

---

我一直在研究处理交易消息的成熟架构，目前，我的选择已缩小到 Disruptor 和 Reactive 编程。我想征求您的意见，哪个是更好的选择。具体来说，我担心两种情况：

消息处理程序之间的逻辑依赖关系。当我连接到特定交易所时，我需要接收余额和未结订单，然后才能处理交易消息并根据它们下订单。在我看来，响应式是处理这种需要流量控制的情况的更好方法。 Disruptor 有问题吗？ 长时间运行的消息处理程序。消息处理程序应该尽可能快（不要阻止以下消息），但是如果我需要发出一个休息请求来创建一个订单作为消息处理程序的一部分，那么正确的方法是什么？

【问题讨论】：

我强烈建议对两个原型进行模拟。纯粹从 *** 答案中驱动您的应用程序架构的风险很高：“可能肯定选择 X”。

【参考方案1】：

我认为你应该看看Apache's Kafka。它的设计与 Disruptor 非常相似，您可以将消息拆分为多个主题，并具有不同的配置。取决于您喜欢低延迟还是高吞吐量。它还支持动态压缩消息以减少带宽使用，或者允许您将一个主题内的消息拆分到多个分区中，每个分区都可能托管在不同的机器上。这对于负载平衡很有用。 当然支持复制，所以如果你的一台机器崩溃了，系统会继续正常工作。

要读取和处理 Kafka 消息，您可以使用多种模式。默认（至少在使用 C++ librdkafka 客户端时）是让您进行轮询，但您可以在此基础上轻松设置基于回调的系统。您也可以使用响应式系统，它非常自然地映射到 Kafka 拥有的主题/分区的概念。

总结：

为了处理您的 (1) 场景，您将根据紧急程度拆分不同主题的消息，并让更高优先级的线程处理更重要的消息（并设置 kafka 以减少这些主题的延迟）

为了处理您的 (2) 场景，librdkafka (C++) 提供了一种在您的应用程序赶上时临时暂停主题的方法。