章节摘要:本章把第 1 章启动的那堆容器拆开讲透。2.1 节给六进程边界:migration(数据库迁移)、backend(HTTP API)、trading-worker(交易长循环)、scheduler-worker(调度)、celery-worker 与 celery-beat(异步任务与节拍)各自的职责表,加上一张以 PostgreSQL 为事实源、Redis 为队列的通信图。2.2 节讲 v5 的设计哲学「HTTP API 不拥有长循环」:请求超时、进程回收、滚动重启、水平扩容都会杀死长循环状态,所以状态入库、循环进 worker、API 只读写数据库与队列——这也是本章对自研系统最有迁移价值的一课。2.3 节用三张图走通系统动态行为:一次下单从策略到交易所的路径、一段行情从交易所到数据库的路径、以及定时对账的回流。读完本章,日志里每一行都应该有归宿。
v5 进程分离全景(详细版见 2.1 节) ┌────────────── PostgreSQL 18(唯一事实源)──────────────┐ │ 状态 · 订单 · 行情 · 账户(一切持久事实) │ └───▲────────▲────────▲────────▲────────▲─────────────┘ │读写 │读写 │读写 │读写 │读写 backend(HTTP) ──┘ trading- ──┘ scheduler─┘ celery- ──┘ migration ──┘ 只读写库与队列 worker worker worker 首启建表迁移 交易长循环 调度循环 异步任务 ▲ ▲ ▲ └──── Redis 8(队列 / 缓存 / beat 节拍)────────┘
一句话金句:请求会死,循环必须活着——所以状态入库、循环进 worker、API 只做读写。
(文字流程图)migration 先行建表 ──▶ backend 与各 worker 并行启动 ──▶ 运行期一切协同经数据库与队列完成,进程之间互不直连。
三节按序读:先认静态边界(2.1),再懂设计动机(2.2),最后看动态流(2.3)。
┌──────────────┐ 「为什么这样拆」 ┌──────────────────┐ 「拆开后怎么动」 ┌──────────────┐ │ 2.1 六进程边界 │ ───────────────▶ │ 2.2 API 不拥有长循环 │ ──────────────▶ │ 2.3 消息流与 │ │ 静态:谁是谁 │ │ 动机:请求与循环冲突 │ │ 数据流 │ └──────┬───────┘ └────────┬─────────┘ └──────┬───────┘ │ ▼ │ │ 设计哲学落到下单/行情/对账三条路径 │ └───────────────────────────────────────────────────────────────────┘ ▼ 第 3 章 数据层(第一条路径的源头:行情从哪里来)
免责声明:本书仅供研究与教育用途,不构成任何投资建议;实盘交易风险自担,建议长期停留在 paper 模式。