跟单系统性能优化

跟单系统（copy trading / social trading）的性能瓶颈，通常不在"下单本身"，而在**"信号分发 + 用户映射 + 批量下单链路"**这一整条链路的放大效应。

可以把它拆成三段来看：信号产生 → 跟单计算 → 执行下单。

核心性能瓶颈点在哪里？

主交易信号源（Leader Trade）分发瓶颈

当一个带单用户（leader）成交后，会触发：

复制给 N 个 follower
每个 follower 可能还要做比例计算、风控判断、仓位换算

瓶颈点：

单点广播（leader trade fanout）
同步调用风控/计算逻辑
消息堆积（Kafka / MQ lag）
热门带单员导致"爆炸式 fanout"

👉 本质问题：1笔成交 → N倍放大

用户映射（Follower Mapping）查询瓶颈

需要快速查：

这个 leader 有哪些 follower？

以及：

每个 follower 的配置（比例、杠杆、币种过滤）
是否开启跟单
风控限制

瓶颈点：

DB JOIN / SQL 查询
Redis 热 key（热门 leader）
缓存不一致导致频繁回源 DB

👉 本质问题：高频读 + 热点 key

跟单计算（Copy Logic）CPU瓶颈

每个 follower 都要做：

仓位比例计算
滑点/手续费估算
风控检查（最大仓位、风险等级）
下单拆分（部分成交）

瓶颈点：

单线程循环 follower（O(N)爆炸）
锁竞争（用户级资金/仓位锁）
GC 压力（大量临时对象）

👉 本质问题：计算被 follower 数量线性放大

订单执行层瓶颈（OMS / Execution）

跟单系统最终要打到 OMS：

瓶颈点：

RPC 调用过多（1个leader → 1000个订单请求）
同步阻塞调用 OMS
限流（broker / exchange rate limit）
TCP 连接池耗尽

👉 本质问题：下单风暴（order storm）

数据库写入瓶颈

常见写入：

跟单记录
成交记录
用户持仓更新
资金流水

瓶颈点：

写放大（fanout write）
行锁竞争（同用户持仓）
主库压力过高

如何提升性能

架构层优化：异步化 + 解耦（最重要）

❌ 错误做法

leader成交 → 同步计算 → 同步下单

✅ 正确做法

leader成交 → MQ → 异步 fanout → 批处理执行

推荐链路：

复制代码

Trade Event
   ↓
Kafka / MQ
   ↓
Follower Fanout Service
   ↓
Batch Copy Engine
   ↓
OMS Execution Service

👉 核心：所有步骤异步化 + 解耦

Fanout 优化：避免 1 → N 爆炸

方案A：预计算 follower 列表

leader → follower list 预展开
存 Redis / KV

方案B：分片 fanout

leaderId hash 分片
不同 worker 处理不同 leader

方案C：延迟 fanout（强推荐）

不是立即生成 N 个订单，而是：

👉 生成"跟单任务"

复制代码

leader trade
→ follower group task
→ worker 拉取批量执行

批量化下单（Batching）

❌ 错误

1 follower = 1 RPC

✅ 优化

100 ~ 1000 个订单批量发送 OMS
或 protobuf batch request

效果：

RPC 数减少 100x
网络开销显著下降

缓存优化（关键点：热点问题）

缓存结构设计：

follower mapping

复制代码

Redis:
leader:{id}:followers → list

follower config

复制代码

follower:{id}:config → hash

优化点：

本地 cache + Redis 双层缓存
TTL + push invalidation

计算优化：无锁 / 并行化

优化策略：

① 按 follower shard 并行

leader trade → 拆成多个 shard task
多线程 / 多实例处理

② 避免锁竞争

按 userId 分区
单 user 单线程处理（actor model）

订单执行优化（OMS层）

优化点：

① 异步下单

MQ → OMS consumer

② 限流与削峰

per-exchange rate limit
token bucket

③ 连接池优化

长连接 + keepalive
减少 TCP handshake

数据库优化

① 分库分表

followerId / userId hash

② 写入批处理

batch insert trade logs

③ 读写分离

follower 查询走 Redis / 只读库

热点问题

"大V带单员"是最大风险点

解决：

方案A：leader分片

一个 leader 拆多个 shard worker

方案B：限流 follower 数

单 leader 最大 follower cap

方案C：分层跟单

VIP follower 优先
普通 follower 延迟执行

跟单系统的性能瓶颈本质是 "fanout 放大效应 + 同步链路 + 热点 leader"

推荐的高性能架构

复制代码

          Leader Trade
                ↓
         Kafka / Event Bus
                ↓
     Fanout Service (stateless)
                ↓
   Batch Copy Execution Engine
                ↓
        OMS (async + batch)
                ↓
      Exchange / Matching