在HFT中尝试并行订单处理是否有意义?

jav*_*red 5 c# fix-protocol hft

我认为对于那些熟悉hft的人来说,这是一个更理论性的问题.我收到FAST的订单并处理它们.我每秒收到大约2-3千个订单.问题是我是否应该尝试同步或异步处理它们.

每次收到下一个订单时,我都需要做以下事情:

  • 更新相应仪器的订单
  • 更新依赖于该订单的索引和指标
  • 更新策略并根据需要安排一些操作(买/卖东西等)

要做同步,我有大约200-300μs(能够每秒处理3000个订单).我认为这应该足够了.

只是计划异步任务我花了大约30μs

利弊:

同步:

  • ++不需要同步事物!
  • "收到订单"和"采取行动"之间的延迟较少,因为不需要安排任务或将数据/工作传递给另一个进程(在hft中非常重要!).
  • - 但是"接收到订单"操作可能会延迟,因为我们可以在套接字缓冲区中等待等待先前的订单处理

异步:

  • ++使用现代服务器的能力(例如我的服务器有24个核心)
  • ++在某些情况下更快,因为在处理上一条消息时不要等待.
  • ++可以处理更多消息,或者可以为每条消息执行更复杂的操作
  • - 需要同步很多可以减慢程序的东西

同步示例:我们收到更新的MSFT订单,然后更新INTC订单并在不同的线程中处理它们.在这两种情况下,我们都会触发NASDAQ指数重新计算.因此纳斯达克指数的计算应该是同步的.然而,这个特殊问题可以解决以避免同步......这只是可能同步的一个例子.

所以问题是我应该处理同步或异步的订单更新.到目前为止,我处理它们异步,我有每个仪器的专用线程.因为我可以处理针对不同仪器更新的异步两个(MSFT和INTC),但是应该同步处理一个仪器(MSFT)的两个更新.

小智 4

我收到来自 FAST 的订单并进行处理。我每秒收到大约 2-3 千个订单

真的吗?你在交易所工作吗?因为说真的,我从 5 个交易所获取数据,但这些不是订单;)我建议你让你的术语一致 - 你会得到 2-3 千个事件,但我真的怀疑你是否得到了订单。

您是否想过进行多阶段处理设置?即,您在2个线程中获取数据,将其交给另一个线程来查找工具(id而不是字符串),将其交给另一个线程来更新订单簿,将其交给另一个线程来做指标,将irt交给X线程做策略?

无需一直安排任务,只需将队列与每个任务上的一个任务处理消息进行同步即可。使用无锁方法可以非常高效。

残酷地说:我完全赞成多线程,但所有核心处理都必须保持基数,所以经典的多线程已经过时了。为什么?我需要完全可重复的处理,以便单元测试获得确定的输出。

到目前为止,我异步处理它们,并且每个仪器都有专用线程

你的交易量并不大,对吧?我的意思是,我跟踪了大约 200.000 个工具(5 个完整的交易所)。分配 200.000 个线程会 - 啊 - 令人望而却步;)

GO 分阶段管道 - 这意味着核心循环可以很小,您可以将它们分配到足够的核心,从而更具可扩展性。然后适当优化 - 例如,更新一个工具后紧接着同一工具的另一个更新是很常见的(例如,在执行大订单时多次执行)。利用这一点。