4

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

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

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

1 回答 1

2

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

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

总之：

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

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

于 2018-03-14T14:05:59.520 回答