5

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

每次收到下一个订单时，我都需要执行以下操作：

  • 更新相应工具的订单簿
  • 更新依赖于该顺序的索引和指标
  • 如果需要，更新策略并安排一些行动（买/卖东西等）

为了实现同步，我需要大约 200-300 µs（每秒能够处理 3000 个订单）。我想这应该足够了。

只是为了安排异步任务我花了我想~30 µs

优点和缺点：

同步：

  • ++ 不需要同步东西！
  • ++“收到订单”和“采取行动”之间的延迟较少，因为不需要安排任务或将数据/工作传递给另一个进程（在 hft 中非常重要！）。
  • -- 但是“订单已收到”操作可能会延迟，因为我们可以在套接字缓冲区中等待上一个订单处理

异步：

  • ++ 能够使用现代服务器的强大功能（例如，我的服务器有 24 个内核）
  • ++ 在某些情况下更快，因为在处理先前的消息时不要等待。
  • ++ 可以处理更多消息，或者每条消息可以做更多“复杂”的事情
  • -- 需要同步很多东西可以减慢程序的速度

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

所以问题是我应该同步还是异步处理订单更新。到目前为止，我对它们进行异步处理，并且每个仪器都有专用线程。因为我可以为不同的仪器（MSFT 和 INTC）处理异步更新的两个更新，但一个仪器（MSFT）的两个更新应该同步处理。

4

1 回答 1

4

I receive orders from FAST and process them. I receive about 2-3 thousands orders per second

Really? You work at an exchange? Becuase seriously, I get data from 5 exchanges, but those aren ot orders ;) I suggest you get your term in line - you get 2-3 thousand EVENTS, but I really doubt you get ORDERS.

Have you ever thought of doing a multi stage processing setup? I.e. you get data in 2 thread, hand it over to another thread to find the instrument (id instead strings), hand it over to another thread to update order book, hand it over to another thread to do indicators, hand irt over to X threads to do strategies?

No need to schedule tasks al lthe time, just synced queues with one tas processing messages on each of them. Can be super fficient with a no-lock approach.

Brutally speaking: I am all for multi threaded, but all in core processing must maintain cardinality, so classical multi threading is out. Why? I need fully repeatable processing, so that unit tests get determined output.

So far I process them asynchronous and I have dedicated thread per instrument

You do not trade a LOT, right? I mean, I track about 200.000 instruments (5 complete exchanges). Allocating 200.000 threads would be - ah - prohibitive ;)

GO staged pipeline - that means that the core loops can be small and you can distribute them to enough cores that you are a lot more scalable. THen properly optimize - for example it is quite common for updates of one instrument to come followed by another update for the SAME instrument (for example multiple executions while a large order executes). Take advantage of that.

于 2012-07-03T07:26:59.300 回答