用於中頻交易系統的Disruptor vs. Reactive架構

Question

我正在嘗試為我正在研究的中頻交易系統選擇合適的架構。 目前，我從Web Socket或Rest接收消息並在那里處理它們。 有時它包含IO操作（即額外的休息請求），因此它的工作速度非常慢，我想，所有其他消息都在Web Socket客戶端的實現中得到緩沖。 這種天真的方法看起來不太可擴展。

---

我一直在閱讀成熟的架構來處理交易信息，目前，我的選擇已經縮小到Disruptor和Reactive編程。 我想問你的建議哪一個是更好的選擇。 具體來說，我關注兩種情況：

1. 消息處理程序之間的邏輯依賴關系。 當我連接到特定的交易所時，我需要先收到余額和未結訂單才能處理交易消息並根據它們發出訂單。 在我看來，Reactive是一種更好的方法來處理需要流量控制的這種情況。 干擾器是一個問題嗎？
2. 長時間運行的消息處理程序。 消息處理程序應盡可能快（不要阻止以下消息）但是，如果我需要制作一個休息請求來創建一個訂單作為消息處理程序的一部分，那么正確的方法是什么？

Answer 1

我想你應該看一下Apache的Kafka 。 它的設計與Disruptor非常相似，您可以使用不同的配置在幾個主題之間拆分消息。 取決於您是喜歡低延遲還是高吞吐量。 它還可以動態支持壓縮消息以減少帶寬使用，或者允許您在一個主題中將消息拆分到多個分區中，每個分區都可以托管在不同的計算機上。 這對負載平衡很有用。 當然，支持復制，因此如果您的某台計算機崩潰，系統將繼續合理運行。

要讀取和處理Kafka消息，您可以使用多個模式。 默認情況下（至少在使用C ++ librdkafka客戶端時）是允許您進行輪詢，但您可以輕松地設置基於回調的系統。 您也可以使用反應系統，它很自然地映射到Kafka所擁有的主題/分區的概念。

綜上所述：

要處理您的（1）場景，您將根據其緊急程度拆分不同主題的消息，並使用更高優先級的線程處理更重要的消息（並設置kafka以減少這些主題的延遲）

為了處理您的（2）場景，librdkafka（C ++）提供了一種在應用程序趕上時臨時暫停主題的方法。