我正在尝试为我正在开发的中频交易系统选择合适的架构。目前，我从 Web 套接字或 Rest 接收消息并在那里处理它们。有时它包括 IO 操作(即额外的 rest 请求)，因此它的工作非常缓慢，我想所有其他消息都在 Web Socket 客户端的实现中缓冲。这种幼稚的方法看起来不是很可扩展。
我一直在阅读处理交易消息的成熟架构，目前，我的选择范围已缩小到中断器和响应式编程。我想征求您的意见，哪一个是更好的选择。具体来说，我担心两种情况：
- 消息处理程序之间的逻辑依赖关系。当我连接到特定交易所时，我需要接收余额并打开订单，然后才能处理交易消息并根据它们下订单。在我看来，反应式是处理这种需要流量控制的情况的更好方法。这对颠覆者来说是个问题吗？
- 长时间运行的消息处理程序。消息处理程序应该尽可能快(不要阻止以下消息)，但是如果我需要发出 rest 请求来创建订单作为消息处理程序的一部分，正确的方法是什么？
我认为你应该看看Apache的Kafka。它的设计与Disruptor非常相似，您可以使用不同的配置将消息拆分到多个主题中。具体取决于您是喜欢低延迟还是高吞吐量。它还提供对动态压缩消息的支持以减少带宽使用，或者允许您将一个主题中的消息拆分到多个分区中，每个分区都可能托管在不同的计算机上。这对于负载平衡很有用。 当然，支持复制，因此如果您的一台机器崩溃，系统将继续正常工作。
要读取和处理 Kafka 消息，可以使用多种模式。默认值(至少在使用 C++librdkafka 客户端时)是让你进行轮询，但你可以轻松地在此基础上设置一个基于回调的系统。你也可以有一个反应式系统，它很自然地映射到 Kafka 拥有的主题/分区的概念。
总结：
为了处理您的 (1) 场景，您可以根据消息的紧急程度拆分不同主题上的消息，并让更高优先级的线程处理更重要的消息(并且还设置 kafka 以减少这些主题的延迟)
为了处理您的 (2) 场景，librdkafka (C++) 提供了一种在应用程序赶上时暂时暂停主题的方法。