加密货币HFT低延迟架构选型合理性及优化方案咨询

• ZMQ的PUB/SUB根本不适合纳秒/微秒级要求的低延迟场景：ZMQ为了兼容跨网络、跨语言、多通信模式的通用需求，内部堆了太多抽象层和协议封装，哪怕走本地inproc模式，也存在多余的内存拷贝、消息头封装开销。而且它原生的PUB/SUB模式对慢消费者的处理逻辑非常粗糙，要么丢消息要么阻塞发送端，你要做可靠的订单簿delta同步还得自己加序列号校验、缺口补传逻辑，平白增加额外开销。
• 你对“CPU亲和性锁”的认知有偏差：CPU亲和性本质是线程绑核的配置手段，和“锁”没有任何关系。另外你搭配的无锁环形缓冲区如果没做缓存行对齐，跨核读写的时候会触发严重的伪共享问题——读写索引落在同一个64字节缓存行上的话，MESI缓存一致性协议会频繁触发跨核缓存失效，尾延迟可能直接飙到几十微秒，根本达不到低延迟要求。
• 忙自旋的使用缺配套配置：如果只是单纯写个while死循环自旋，不给对应核心做操作系统级隔离，内核随时可能把你的业务线程踢出去跑系统中断、后台任务，照样会有毫秒级的上下文切换抖动。另外如果生产消费速率不匹配，无差别忙自旋会直接占满核心资源，很容易把同核心上的其他必要逻辑饿死。
• 无锁环形缓冲区选型容易踩冗余开销的坑：大部分开源无锁环形缓冲区默认是多生产者多消费者（MPMC）实现，如果你实际场景是单线程收行情写delta、单线程读delta做策略的单生产者单消费者（SPSC）模式，MPMC里多余的原子CAS操作会带来完全没必要的性能损耗，SPSC环形缓冲区的性能比MPMC高一个数量级都很正常。

• 通信层直接砍掉中间件：同机内线程/进程间的delta分发，直接用共享内存承载SPSC无锁环形缓冲区就行，完全跳过ZMQ这类消息组件的所有额外开销。如果需要跨机器传输行情，优先用UDP组播搭配DPDK这类用户态协议栈，跳过内核协议栈的内存拷贝和调度逻辑，别用TCP，也别碰任何通用消息队列。
• 绑核和自旋做全链路配套优化：
  • 改内核启动参数，用isolcpus、nohz_full、rcu_nocbs把跑核心业务的CPU核心从操作系统默认调度器里隔离出去，关掉这些核心上的定时中断，把网卡硬中断、磁盘IO中断全部绑到非业务核心上
  • 环形缓冲区的读写索引单独做64字节缓存行对齐，彻底避免伪共享；业务全程用大页（HugePages）分配内存，减少TLB miss带来的延迟波动
  • 核心路径上的自旋逻辑不要加任何sleep、sched_yield类的系统调用，给业务线程设置SCHED_FIFO最高实时调度优先级
• 数据通路做极致裁剪：订单簿delta事件不要用Protobuf、JSON这类通用序列化协议，直接用内存对齐的定长结构体传输，接收方直接读内存就能解析，做到零拷贝。所有需要的内存提前从内存池预分配好，业务运行过程中绝对不要做动态的malloc/free操作。
• 非核心逻辑全部移出关键路径：日志打印、监控上报、风控旁路计算这类不直接参与delta流转的逻辑，全部扔到非隔离的普通CPU核心上跑，绝对不要占用业务核心的资源，避免引入不必要的调度抖动。

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