cckkbb
60 posts
我看到X上很多文章又是讲定价模型又是讲概率论，很多复杂的数学让人望而却步，搞的很复杂，实际上有时候只需要很简单的alpha就能赚钱，比如我这个号，虽然远远比不上卷5min/15min的大佬，但是收益对于我来说也很不错了。对于普通散户来说，核心还是找到一个小众不卷的领域，而不是去人多的地方卷。
中文
@gch_enbsbxbs 不行的，我已经按照这个思路做出来了，币安给出来行情，我这边决策完到下单，pm就已经跟上来了，速度永远拼不过。即使换了离服务器最近的ip也不行。很难拼得过专业机器人
中文
再给大家分享一波：高频量化套利架构与低延迟开发指南.md （我的脚本就是按照这个指南写的，这也是我跟ai沟通了很久采取的方案）
# 高频量化套利架构与低延迟开发指南（行业通用版）
> 目标读者：要做“高频、低延迟、延迟敏感”的量化套利系统的开发团队。
> 文档定位：不写具体代码，只讲设计方案、架构原则、性能策略和落地注意事项。
> 说明：本文是通用行业方法，不依赖你当前仓库实现。
---
## 1. 先说结论（最重要的 8 条）
1. 高频套利系统的核心不是“策略公式有多复杂”，而是**能否稳定地更快下单**。
2. 架构必须拆成两层：**交易主链路（热路径）** + **旁路系统（监控/报表/分析）**。
3. 热路径必须“极简”：不做磁盘写入、不做慢网络调用、不做重日志。
4. 优先做**延迟预算**（每一段允许花多少微秒/毫秒），再做编码。
5. 风控必须在线且轻量，不能关；但风控逻辑也要做成常数级开销。
6. 先保证“稳定低延迟”，再追求“极限低延迟”。抖动（延迟忽高忽低）比平均值更危险。
7. 生产系统必须支持降级：旁路坏了不影响交易，单个交易所异常要可隔离。
8. 不要上来全量重写；先性能画像（profiling，白话：先测哪里慢）再动大手术。
---
## 2. 业务目标如何转成工程指标
高频系统必须把“赚钱目标”翻译成“机器指标”。
### 2.1 必要指标（建议）
- **行情到决策延迟**（Market-to-Decision）：行情到策略出信号的时间。
- **决策到下单延迟**（Decision-to-Order）：信号到请求发出的时间。
- **端到端延迟**（E2E）：行情到交易所确认的总时间。
- **P99 延迟**：99% 请求都不超过这个时间（比平均值更重要）。
- **丢信号率**：有效机会被系统漏掉的比例。
- **撤单失败率 / 拒单率**：执行可靠性关键指标。
- **风控拦截命中率**：风险是否真的被挡住。
### 2.2 延迟预算（示例）
> 下面是“设计预算”的例子，不是固定标准。
- 行情解码：0.2ms
- 盘口更新：0.2ms
- 信号计算：0.3ms
- 风控检查：0.2ms
- 下单组包与签名：0.4ms
- 网关发送：0.2ms
- **主链路总预算：1.5ms（不含外部网络 RTT）**
白话：先给每段“定额”，谁超额就优化谁，不要靠感觉调优。
---
## 3. 推荐总架构：双平面 + 模块隔离
## 3.1 双平面架构
1. **交易平面（热路径）**
只包含：行情接入 -> 状态更新 -> 信号计算 -> 风控 -> 执行网关。
2. **旁路平面（冷路径）**
只包含：监控、日志聚合、报表、回放、策略研究、UI、告警。
白话：交易平面只做“抢机会”，旁路平面做“看和管”。
## 3.2 逻辑数据流（推荐）
`行情源 -> 归一化层 -> 内存订单簿 -> 策略引擎 -> 风控引擎 -> 执行引擎 -> 交易所`
旁路订阅：
`交易平面事件 -> 消息队列/共享内存 -> 监控与分析系统`
---
## 4. 热路径设计原则（必须严格执行）
### 4.1 单一职责
- 每个模块只干一件事。
- 例如“风控模块不做日志落盘”，“执行模块不做统计报表”。
### 4.2 无阻塞优先
- 禁止在热路径做：
- 同步磁盘 I/O（白话：边交易边写文件）
- 慢 HTTP 请求
- 数据库查询
- 外部 RPC 重试循环
### 4.3 数据结构优先级高于算法花活
- 低延迟系统更看重数据搬运成本。
- 优先选择：连续内存、少拷贝、固定结构。
- 避免：频繁动态分配、大对象序列化、深拷贝。
### 4.4 线程模型要可控
- 典型模式：`1~N 行情线程 + 1 策略线程 + 1 执行线程`。
- 尽量减少跨线程共享写，降低锁竞争。
- 能用单写多读（白话：一个线程写，多个线程读）就不要多写抢锁。
### 4.5 日志策略
- 热路径只记关键事件（错误、风控、成交摘要）。
- 明细日志异步输出到旁路。
- 日志要节流，避免高频字符串拼接吃 CPU。
---
## 5. 行情系统设计（延迟和正确性的根）
## 5.1 多源输入与优先级
- 主行情：WebSocket（白话：实时推送）。
- 兜底行情：REST 轮询。
- 要定义清楚“谁是主、谁是备、切换条件是什么”。
## 5.2 归一化层
- 把不同交易所字段转成统一内部模型。
- 单位统一：价格、数量、时间戳、币种精度。
- 明确“交易所原始时间”和“本地接收时间”。
## 5.3 新鲜度控制
- 每条行情都要判定 staleness（白话：是否过期）。
- 过期行情禁止触发下单。
- 断流时快速告警并降级。
## 5.4 订单簿维护
- 只维护策略真正需要的层级，不要全量重建。
- 增量更新优先，快照定时校准。
- 检测序列号跳变，必要时重拉快照。
---
## 6. 策略引擎设计（快、稳、可解释）
### 6.1 信号计算要常数级
- 高频策略尽量 O(1) 或接近 O(1)。
- 单次决策只读当前必要状态。
- 不做全局扫描，不跑重统计。
### 6.2 机会去重与节流
- 同类机会去重，避免重复触发。
- 设置最小触发间隔，防止抖动过度下单。
- 拥塞时允许丢“过时机会”，优先最新机会。
### 6.3 可解释输出
- 每次触发都能回答三件事：
1) 为什么触发
2) 价格依据是什么
3) 风险边界是什么
---
## 7. 风控引擎设计（必须在线，不可旁路）
## 7.1 热路径风控（必须同步）
- 单笔最大数量
- 单市场最大暴露
- 单交易所可用余额阈值
- 当日亏损阈值
- 下单频率上限
白话：这些必须在下单前立刻检查，不能“事后再看”。
## 7.2 风控要轻量
- 风控规则尽量表驱动（配置化），不要写复杂脚本解释器。
- 结果二值化：通过 / 拦截，减少分支复杂度。
- 风控日志只输出关键字段。
## 7.3 失败策略
- 风控模块异常时默认“保守”而不是“放行”。
- 可以按策略设置 fail-close（白话：出错就停）或 fail-open（白话：出错仍放行），但生产建议关键风控 fail-close。
---
## 8. 执行网关设计（决定实盘成败）
## 8.1 统一下单抽象
- 内部用统一订单模型，再映射到各交易所。
- 明确区分：限价单、市价单、FOK/IOC/GTC（白话：不同成交约束）。
## 8.2 并发执行与回报确认
- 双腿套利通常并发发单，但必须设计单腿失败回补流程。
- 回报优先走私有 WS，REST 仅兜底。
- 设定确认超时，防止执行线程卡死。
## 8.3 幂等与去重
- 每个订单必须有唯一客户端 ID。
- 网络重试不能造成重复下单。
- 所有重试动作都要可追踪。
## 8.4 失败恢复
- 交易所超时：分级重试（快速一次 + 慢速一次）。
- 单腿成交：立即进入应急对冲流程。
- 交易所异常：快速熔断（circuit breaker，白话：临时停用这个通道）。
---
## 9. 状态与存储设计（热冷分层）
## 9.1 热状态（内存）
- 最新盘口、最新持仓、可用余额、风险计数器。
- 强一致要求高，更新必须快。
## 9.2 冷存储（异步）
- 订单明细、成交回报、回放日志、审计记录。
- 通过异步队列批量落盘，不阻塞交易线程。
## 9.3 事件回放能力
- 关键事件要可回放，用于复盘和问题定位。
- 回放系统与实盘系统物理隔离，防误操作。
---
## 10. 监控与告警（没有监控就没有生产）
## 10.1 必看监控面板
- 延迟：P50/P95/P99、抖动、峰值。
- 执行：下单成功率、拒单率、撤单成功率、超时率。
- 策略：触发次数、命中率、盈亏曲线。
- 风控：拦截次数、原因分布、阈值触发。
- 系统：CPU、内存、GC（垃圾回收，白话：自动回收内存行为）、网络丢包。
## 10.2 告警分级（建议）
- P0：无法下单、订单状态不一致、风控失效。
- P1：延迟突增、拒单率突增、行情断流。
- P2：旁路服务异常、报表延迟。
---
## 11. 语言与技术栈（实用建议）
## 11.1 常见组合
- **C++/Rust**：热路径、执行网关、订单簿维护。
- **Python**：策略研究、编排、离线分析、旁路服务。
- **Go/Java**：中间服务与后台系统（视团队能力）。
白话：不是“只用一种语言”，而是“让合适语言做合适环节”。
## 11.2 Rust 的典型使用场景
- 低延迟行情处理
- 高并发执行网关
- 风控核心模块
不建议一开始全量重写，建议先迁最热 20% 链路。
---
## 12. 部署与网络策略（延迟敏感系统的硬条件）
## 12.1 机房策略
- 尽量靠近交易所服务器（同城/同机房）。
- 固定低抖动网络路径。
- 主备线路独立，避免单点网络故障。
## 12.2 系统调优（方向）
- CPU 固定核绑定（pinning，白话：把关键线程固定在指定核心）。
- 减少上下文切换（白话：线程来回切换）。
- 控制后台任务抢占。
- 时间同步（NTP/PTP，白话：系统时钟尽量准确一致）。
## 12.3 容灾
- 多实例主备，故障自动切换。
- 交易所级别熔断与隔离。
- 限定“最大事故半径”（白话：一次故障最多影响多大范围）。
---
## 13. 测试与上线流程（没有这部分，实盘风险很高）
## 13.1 测试层次
1. 单元测试：规则与边界条件。
2. 集成测试：交易所适配与回报流。
3. 回放测试：用历史行情重放，验证稳定性。
4. 压测：峰值行情下延迟与丢包表现。
5. 故障注入：模拟断网、超时、拒单、延迟抖动。
## 13.2 上线节奏
- 先 shadow（影子模式，白话：只算不下单）
- 再小资金灰度
- 最后逐步扩容
每一步都要有“自动回退开关”。
---
## 14. 常见反模式（务必避免）
1. 在热路径同步写数据库。
2. 在回调里做慢 HTTP。
3. 大量 debug 日志直接打在交易线程。
4. 没有唯一订单 ID，重试后重复下单。
5. 风控放在旁路，导致“先下单后告警”。
6. 把所有功能塞进一个进程，故障不可隔离。
7. 只看平均延迟，不看 P99 和抖动。
8. 没有演练过“单腿成交失败回补”。
---
## 15. 研发协作建议（保证长期可维护）
- 每个新功能都要回答：
1) 是热路径还是旁路？
2) 会增加多少延迟预算？
3) 故障时怎么降级？
- PR（代码变更）必须附带：
- 延迟影响说明
- 风险点
- 回滚方案
白话：高频系统不是“能跑就行”，而是“快、稳、可回退”。
---
## 16. 一页式落地清单（可直接执行）
1. 先画出交易主链路，删掉所有非必要逻辑。
2. 给每段定义延迟预算和 P99 目标。
3. 建立在线风控最小集（余额、暴露、频率、亏损）。
4. 做旁路监控与告警，确保旁路故障不影响交易。
5. 建立单腿风险回补和熔断机制。
6. 上线前做回放 + 压测 + 故障注入。
7. 先影子模式，再灰度，再扩容。
---
## 17. 最后一句话
高频套利系统的工程本质是：**把“时间”当成最稀缺资源管理**。
你每减少一次不必要拷贝、一次阻塞调用、一次线程争锁，都是在直接提升真实交易竞争力。
C J@gch_enbsbxbs
说下我的工作流，我是怎么做预测市场的流程。 暂时没办法 分享具体的的策略。 因为第一 没有得到长时间的验证。虽然是15分钟很短。 但是仍然需要长时间验证。 第二就是策略如果直接公开 很可能失效。 希望大家体谅。 我不是搞量化的， 也是摸着石头过河， 1/ 先搓个简单的脚本，抓数据，然后写入到csv。 2/写个模拟盘，别实盘。策略都还没定好 就别实盘 必亏钱。 3/一边看数据，一边想几个简单的策略，进行模拟测试， 从结果反推过程， 为什么这里下单，为什么下单之后输了。 找原因。 4/根据问题 找关键指标，或者叫挖掘因子。 挨个的测试。 15分钟一轮 结果肯定可以很快提现出来。开始上实盘。 5/如果挖掘的因子，能有效改善，说明方向是对的。要分析背后原因，再找相关的因子组合测试， 重复上述步骤。 在我的脚本里，我搜集了币安的k线数据，开盘收盘 成交量 振幅 等所有数据，历史7-30天。 也搜集了期权数据，也搜集了 预测市场自身的数据 包含开盘价格 实时价 和成交量等（一边测试 一边采集写入本地） 由于预测市场 没有历史数据，所以很难做回测。 只能写了一个方案 直接运行测试。 效率不高 很磨人。 最终 实际就是在这堆数据里， 找到最能影响你结果的那个。 不管是多少分钟的， 肯定是没办法 做到百分百胜率 不带一丁点回撤的。 所以 要过滤机会， 只对把握大，趋势明显的订单下手。不要每一轮都玩。 因为手续费太贵。目前来看即便有些事件 暂时没收手续费，未来肯定也会收。高频的事件 收费是必然的。 事件一轮时间越短。提供给你捕捉的机会越多。 但是不能因为机会多，而进行无脑的高频下单。 所以要提取确定性最高的机会。 很多人觉得15分钟难度比较大。是因为玩的人多，但是频率越高 代表机会概率越多。 （5分钟时我写脚本中途出现的 所以我暂时就没弄5分钟） 如果思路卡壳，就跳出来，换换思路。比如 抓下别人的下单记录，从他的下单点位反推策略过程。 从策略延伸策略，当一个策略 哪怕一个因子有效， 应该对他进行放大，多事件进行测试。 好处是 可以提高资金体量。也能pnl 曲线更平滑。（这是我接下来要做的事情） 如果以后有合适的机会的话， 我再给老铁们分享 我挖掘到的关键因子 目前还需要时间验证
中文
这两天 触发的频率有点低。导致收益率 有点低。
不过 我每次下单 金额 也很小。
但是已经没有像最初的脚本那样回撤了。
过几天 开始提高金额。
C J@gch_enbsbxbs
策略应该已经跑通了 一共花了差不多半个月。（实现功能仅仅3天就写完了） 从最初的 实现功能。然后开始逐步边写策略 边思考 边测试。 直到最近几天，开始开始稳定了。 先小资金跑一个月看看吧。 脚本已经偏离了我最初的设想。 原本预期是写套利，结果开始往量化的方向发展了。 不过这些也不重要。预测市场的策略 实在太多了。 我想说的是 只要你沉下心来干。 别人过年，你搓代码。有这个决心。肯定能干成。
中文
@cckkbubu @0xnetuser 确实越来越卷了，最近我的下单失败率从10%飙到20%多了，一看发现了至少两个相同策略的bot，想滚回去上班了，难顶哈哈
中文
看到 @0xnetuser 写了一条如何降低Polymarket延迟的帖子
x.com/0xnetuser/stat…，其中第4点，如果你是做延迟套利，有几种方法可以绕过CF的geo block，可以让你在服务器同城甚至机房旁边下单，但是代价不小，甚至有封号的风险，不过风险与收益并存，如果你一天就能赚很多，那么成本则完全可以接受：
0xNetuser@0xnetuser
很多私信是问PM延迟高频怎么优化什么的... 首先想清楚你是不是真的需要高频: 1.如果你目前是亏钱的，优化也绝对不会赚钱 2.如果是目前不亏不赚，优化也绝对不会很赚钱 3.只有你现在小赚的时候，才需要在这方面下功夫 一个推文放不下，评论区见
中文
@rorschachluc @0xnetuser 最近一段时间crypto预测市场也很卷，延迟挺重要的，前提是策略层面也得说的过去，我感觉策略和速度都挺重要的，55开吧（仅高频套利
中文
@0xnetuser 最后我个人认为精力花在IP对抗绕过geoblock，不如多花时间在策略研究和具体的套利策略工程实现上面，我也是研究了一段时间然后放弃了，因为对我当前的策略来说花大量精力在这上面不太划算。
中文
@0xnetuser 感觉是延迟套利的一部分，现在15m很卷了。有大订单cex的订单薄几乎也是同时变化吧，之前我的bot算第二梯队吧，现在卷的不赚了都
中文
@haloowhite 之前搞过，这些不是重点，用一些支持模拟浏览器指纹的库就可以过，重点在于过aws的缓存，通过随机一些header或者参数绕过缓存，但是也白费，当时花了很大力气，很大概率能进前几秒，但是去拉逐笔成交数据基本盘利润都被第一梯队吃完了
中文
🎃选个数字测好运！
在1-50之间挑一个你最喜欢的数字🔢
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
只有一个数字能召唤出礼物🎁
💬评论区留下你的数字，24小时后揭晓！
中文
