【量化系统从0到1】回测引擎:性能不是难点,语义才是
回测引擎的主线不是"跑得快"而是"把 A 股语义做对":自研 142 行撮合核心、价格口径必须自洽(后复权修掉除权日假跳变)、费用用 Decimal 精确到一分钱、验证逼出三个 bug——以及 Rust 为什么最终没有写(50 票实测 0.3 秒,全市场按线性外推约 30 秒)。
回测引擎的主线不是"跑得快"而是"把 A 股语义做对":自研 142 行撮合核心、价格口径必须自洽(后复权修掉除权日假跳变)、费用用 Decimal 精确到一分钱、验证逼出三个 bug——以及 Rust 为什么最终没有写(50 票实测 0.3 秒,全市场按线性外推约 30 秒)。
个人量化系统的存储选型:先刻画数据特征,再推导方案——行情/因子用 parquet、财务/任务用 SQLite、元数据用 JSON。不选择什么比选择什么更重要:DuckDB、PostgreSQL 被排除的理由,以及它们的触发条件。
调用一个外部服务失败了,第一反应是再试一次。这个直觉没错,但「再试一次」从一句代码到生产可用的重试策略,中间隔着好几层坑——每一层都是被上一层的代价逼出来的。 起点:固定次数重试 最直觉的做法:失败就重试,重试 N 次,还不行就放弃。 for i in range(3): try: return c
限流是个听起来很简单的问题:请求太多,挡一挡就行。但真到实现的时候,你会发现「怎么挡」的答案一直在变——被业务规模一层层逼着升级。 起点:固定窗口计数器 最直觉的方案:在内存里记一个计数器,当前这一秒来了多少请求,超过阈值就拒。 伪代码,不是让你抄 counter = 0 windowstart =
最近碰到一个问题,事后想想,很适合拿来讲分布式系统里一个很普遍的现象:一个在单节点上简单到不用过脑子的事,放到多节点环境下,复杂度会一层一层地叠上去,每加一层,就多一类你绕不开的问题。 单节点:两个 if 的事 需求是这样的:用户请求来了,需要从 S3 拉一份代码到本地,解压,然后执行。 为了避免同
仓位管理(position sizing):每只股票买多少钱。等权最简单,波动配最保守,信号配最直接。三个不选比一个要选更值钱:不全仓一只、不配一堆相关的、不设单票上限。策略的 alpha 靠因子,存活靠仓位。
设计分布式系统,最难的不是学概念,是拿到需求知道从哪下手。不是找最优解——最优解不存在。
多节点下,谁说了算?锁和选主都是排他性地让一个节点说了算,只是生命周期不同。
一个操作跨多个数据库、多个服务,没有谁替你兜底。分布式事务就是让多个独立操作原子完成。
数据分散在多个节点,消息不可靠,机器随时挂。现在需要这些节点就一个值达成一致——这就是共识。