批处理与实时链路的算力分配没有绝对最优解，核心原则是“按数据时效价值分层定价”交易场景中，实时链路拿高并发低延迟的算力，批处理则复用闲时资源，两者通过队列优先级和资源池隔离实现共存。
算力战争背后的交易场景差异
交易系统里，批处理和实时链路像性格迥异的两个员工，实时链路是负责盯盘的前台交易员，每秒要看几百次行情，延迟超过几十毫秒就可能导致滑点；批处理则是后台风控清算员，每天收盘后集中处理海量历史数据,跑几个小时也能接受。
两者的算力诉求天然冲突：实时链路要的是延迟稳定，算力必须随时待命；批处理要的是吞吐量大，但可以容忍排队等待，如果让批处理任务抢占实时链路的CPU资源，行情峰值时就会出现卡顿；反过来，实时链路占着资源不放，批处理窗口就被无限拉长，业内专家指出，解决冲突的关键不是让两者争抢同一份算力，而是从任务调度层面把两种链路拆开,让各自在专属资源池里运行。
以常见的交易系统架构为例，实时链路通常跑在基于内存计算的流处理框架上，批处理则落在离线计算集群中，两个集群物理隔离，再通过统一的资源管理平台分配算力比例，但物理隔离不等于效率最优如果白天批处理集群大量闲置，实时链路却因峰值扩容造成资源浪费，这种“各管各”的方式显然不划算。
批处理和实时计算怎么选？先看清数据时效的“价格”
不同交易数据的时效价值差异很大，逐笔成交、盘口变化这类数据，毫秒级延迟就能决定策略盈亏；而日终结算、历史回测这类数据，晚几分钟甚至几小时处理，对结果毫无影响。算力分配的优先级就该按数据时效价值排列,而不是按任务发起顺序。
实时链路占用的算力特征
实时链路通常包含行情接入、订单路由、风险预检三个环节，每个环节都是典型的低延迟高并发场景：行情推送需要微秒级响应，订单路由要处理每秒上千笔的请求，风险预检必须在几十毫秒内完成黑白名单筛查，这类任务对CPU缓存、内存带宽、网络中断的敏感度极高，算力配置需要预留50%以上的冗余应对瞬时峰值。
批处理任务的算力弹性空间
批处理任务包括对账、估值、报表生成、策略回测等，这类任务的计算特征是可拆分的一个小时的批量计算可以切成几百个小任务分散到多个节点并行执行，因此批处理天然适合利用实时链路的闲时资源，比如在收盘后、午间休市时段，实时集群的负载会明显下降，此时把批处理任务调度到这些节点上,就能做到算力复用。
实际决策路径参考
- 先列出所有交易任务，标注每个任务可接受的延迟上限（毫秒/秒/分钟/小时）。
- 延迟上限低于1秒的任务划入实时链路,其他全部划入批处理。
- 根据批处理任务的总计算量，估算需要多少算力；再用实时链路峰值负载减去常驻资源,得出可复用的闲时算力。
- 如果闲时算力不足，优先考虑延迟批处理任务的执行时段,而不是增加总资源。
金融交易系统算力分配中的资源池隔离与共享
资源池隔离是防止算力互相干扰的硬边界，但完全隔离又会造成浪费，金融交易系统常见的做法是“半隔离”模式：实时链路独占物理核心，批处理被允许使用实时链路集群的剩余算力,但受cgroup或容器配额限制。
分配比例怎么定？参考波动率而非平均值
大多数系统的算力分配习惯按平均负载设定，但交易场景的实时链路负载随行情波动极大，某只股票出现异常波动时，行情推送量可能瞬间翻三倍，如果按平均负载分配，峰值时必现资源争抢；按峰值负载分配，平时又会浪费大量算力，行业共识认为，更合理的做法是把实时链路的配额设为峰值的80%，批处理则使用剩下的20%加上动态借用的资源但借用必须设置“熔断机制”：当实时链路负载超过阈值时,批处理任务自动让出CPU。
实操步骤：用Kubernetes实现算力分配
- 创建两个Deployment：
realtime-trader与batch-processor，为实时链路设置requests等于峰值算力，limits等于峰值算力；批处理设置requests等于低配额，limits等于全部可用算力。 - 使用
PriorityClass：实时链路设为PriorityClass: critical，批处理设为low,保证资源不足时批处理Pod先被驱逐。 - 开启HPA（Horizontal Pod Autoscaler）：实时链路按CPU使用率自动扩容，批处理按队列深度自动扩容,两者共享同一节点池。
实时链路延迟优化方案：算力资源如何“让路”
即便做了资源池隔离，实时链路仍然可能因为系统调用、上下文切换、内存分配等问题产生延迟抖动，这些延迟往往与批处理任务无意中占用了共享资源有关，比如批处理任务频繁申请大内存导致实时链路的内存分配变慢,或者批处理任务的磁盘IO打断了实时链路的缓存预取。
从算力角度降低延迟的四个措施
- CPU绑核：给实时链路的每个核心绑定专属线程，批处理只能使用其他核心，Linux下使用
taskset或cpuset将实时线程固定到独立核心，同时设置sched_setaffinity
避免内核迁移线程。
- 内存锁定：实时链路的核心数据结构使用
mlockall锁定内存页，防止被swap到磁盘；批处理任务则禁止使用该内存区域。 - 网络中断隔离：使用
irqbalance绑定具体网卡队列到特定CPU，实时链路的网络包由高优先级核心处理,批处理任务的网络包走另一个队列。 - 关闭频率调节：将实时链路的CPU调至
performance调速器，关闭intel_pstate的省电模式,保证CPU频率稳定在最高档位。
一个可验证的优化案例
某期货公司交易系统曾出现实时链路每隔几分钟就出现2~3毫秒的延迟尖刺，排查发现是批处理任务在整点启动，同时向磁盘写入大量日志，导致实时链路的IO等待升高，解决方法是给批处理设置独立的磁盘路径，并在实时链路使用ionice -c1 -p标记高优先级IO，延迟尖刺从此消失，这个案例说明，算力分配不仅要看CPU,还要看IO和内存的隔离。
交易系统批处理实时混布时的故障隔离策略
算力分食最怕的是故障扩散，批处理任务内存泄漏可能影响实时链路，实时链路的突发流量也可能把共享节点CPU打满，进而拖垮批处理，除了资源配额,还需要在架构层面设置故障隔离。
故障隔离的三层防线
- 进程级隔离：实时链路和批处理使用独立的进程组，通过
systemd配设CPUQuota和MemoryMax，任何一方超限即被操作系统杀掉,而非影响对方。 - 容器级隔离：每个任务单独运行在Pod中，设置Pod的
terminationGracePeriodSeconds很短,批处理Pod在实时链路扩容时被优先驱逐。 - 集群级隔离：实时链路和批处理运行在独立的Kubernetes节点池中，节点池之间通过缩容和扩容实现算力互通,但默认不跨池调度。
关键操作命令参考
# 设置实时链路的CPU pinning echo 2 > /proc/irq/32/smp_affinity taskset -c 4-7 java -jar realtime-trader.jar # 限制批处理的CPU用量 systemctl set-property batch-service.service CPUQuota=2000% # 最多使用20个核心 # 动态调整实时链路的CPU权重 docker update --cpu-shares 2048 realtime-container
算力分食的长期趋势与绩效评估
未来交易系统的算力分配会越来越模糊化，随着实时计算框架的预处理能力提升，原本属于批处理的逻辑（比如特征计算）被下沉到实时链路，批处理的负担减小；批处理也开始使用实时链路产出的中间结果，减少重复计算，架构上出现了“Lambda架构”变体批处理层和实时层共享同一份Kafka数据源,算力复用度进一步提高。
怎样评估算力分配是否合理？
交易系统算力分配的效果不能只看CPU利用率，行业内部通常用三个指标：实时链路P99延迟（比如需低于50毫秒，超过即报警）、批处理完成时间（是否在系统设定的窗口内完成，比如每日6:00前跑完日终作业）、算力复用率（批处理使用闲时资源的比例），这三个指标互相制约，P99延迟高说明实时链路被批处理抢占；批处理完成时间不断延后说明闲时算力不足；复用率低则说明隔离过度。
近期不少系统开始使用“成本感知调度器”，给实时链路的算力标出更高的单价，批处理则使用折扣计价，通过价格信号驱动业务方合理申报任务优先级，虽然这套体系尚未普及，但方向已经清晰：算力分食的本质是成本分摊，谁对延迟更敏感,谁就该承担更高的算力成本。
回到最初的问题，批处理和实时链路分食交易的算力，不必用简单的“你多我少”来定义，实时链路需要的是稳定，批处理需要的是弹性，两者完全可以在统一资源池中共存，靠优先级、配额、熔断机制来平衡，最终的目标不是让双方各占多少比例，而是让每一笔交易在最恰当的时间，使用最恰当的算力,完成最恰当的计算。
批处理和实时计算算力分配的常见问题解答
Q1：批处理任务偶尔运行很慢，会不会影响实时链路的稳定性？
不会，前提是批处理任务被限制在独立的资源配额内，你只需要确认设置了两层保护：第一层按CPU核心数硬限制批处理的并发数；第二层设置实时链路的内存锁定和IO优先级，如果批处理真的拖慢了实时链路，优先检查是否共享了磁盘路径或内存页,而不是怀疑CPU配额没生效。
Q2：交易系统算力分配是先用实时还是先跑批处理？顺序怎么安排？
没有固定顺序，取决于交易时段，常规做法是交易时段实时链路优先级最高，批处理自动暂停或降级；日终时段批处理获得全部算力，实时链路只需保留最低响应能力，如果系统支持动态优先级，你可以设置实时链路在交易时段优先级为99，批处理优先级为10,日终自动切换角色。
Q3：怎样用有限的算力同时满足实时和批处理？预算不足时的折中方案。
把实时链路的核心逻辑拆成微服务，只对行情推送和订单路由保留高频算力；批处理任务拆成可断点续跑的细分步骤，放在闲时执行，当算力不够时，优先保实时链路的P99延迟，批处理允许延迟数小时完成，实际上多数中小交易系统都采用“白天实时、夜间批量”的粗粒度分时方案,成本最低。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%89%b9%e5%a4%84%e7%90%86%e4%b8%8e%e5%ae%9e%e6%97%b6%e9%93%be%e8%b7%af%e5%a6%82%e4%bd%95%e5%88%86%e9%85%8d%e4%ba%a4%e6%98%93%e7%ae%97%e5%8a%9b%ef%bc%8c%e6%9c%89%e4%bb%80%e4%b9%88%e5%8c%ba%e5%88%ab/
