多SPSC队列与单MPSC队列：HFT低延迟场景下哪种架构更优？

Great question—this is exactly the kind of tradeoff that makes HFT system design so tricky, where every nanosecond can make or break a strategy. Let’s break down your two options, focusing on the low-latency priorities you care about:

Option 1: Single MPSC Queue #

Key Pain Points for Low Latency #

• Cache Line Contention: Even with a well-implemented lock-free MPSC queue, your two producers will fight over the same atomic head/tail pointers. This leads to false sharing and constant cache invalidation between Producer1 and Producer2 every time they push an EventA. In HFT, cache contention is one of the biggest sources of unexpected latency spikes—you want to avoid hot shared state at all costs.
• Event Processing Overhead: Consumer1 will have to check every event’s type (A vs B) before processing it. While a single branch is cheap, at high throughput rates this adds up, and can throw off CPU branch prediction if the event types are mixed unpredictably.

Option 2: Multiple SPSC Queues (Per Producer, or Per Event Type) #

Clear Wins for Low Latency #

• Zero Producer Contention: Each producer writes to its own dedicated SPSC queue. No CAS battles, no cache line thrashing between producers—each producer’s writes only interact with the consumer’s cache line, which is a far lower overhead. This is a massive win for consistent low latency.
• Optimized Event Processing:
  • If you split Producer1’s events into two separate SPSC queues (one for EventA, one for EventB), Consumer1 can process batches of identical events without any type checking. Even if you keep Producer1’s events in a single queue, the consumer will still benefit from more predictable branch prediction since the event stream comes from a single source.
  • You can implement a batch polling strategy for the consumer: check each queue in turn, pulling as many events as possible in one go. This reduces the number of queue operations and lets the CPU leverage instruction-level parallelism more effectively.
• Scalability: If you add more producers later, you just spin up another SPSC queue—no impact on existing producers’ performance. With MPSC, adding more producers only makes the contention worse.

When Might Option 1 Be Better? #

• Ultra-Low Throughput: If your producers are pushing events very infrequently (e.g., hundreds per second instead of millions), the contention overhead in MPSC becomes negligible. In this case, the simpler single-queue architecture is easier to maintain.
• Strict Global Event Order: If Consumer1 must process events in the exact order they were generated across both producers (e.g., a Producer2 EventA needs to come before a Producer1 EventA generated 1ns later), MPSC naturally enforces this. With SPSC queues, you’d have to add timestamps and sort events on consumption, which introduces extra latency.

Quick Implementation Tips for Option 2 #

• Use a ring-buffer based SPSC queue (avoid any implementation that uses dynamic memory allocation—heap operations are poison for low latency).
• Align your queue structures to 64-byte cache lines (alignas(64)) to eliminate false sharing between the producer and consumer’s queue pointers.
• For the consumer’s polling loop: use a short busy-wait (e.g., 50-100 iterations) before falling back to a tiny sleep (like 1ns) if all queues are empty. This balances CPU usage with minimal latency.

内容的提问来源于stack exchange，提问作者xyzt