本地跑黄金 1 分钟级别回测时，我统计过一次参数扫描：单轮触发 1500 次历史 K 线请求，接口平均耗时 4.2 秒；加入缓存后总耗时降到 0.8 秒。这个数字背后是一个常见问题：历史 K 线被反复拉取。
需求场景
在量化策略开发中，黄金实时api主要提供最新行情，但回测和指标计算更依赖历史 K 线。无论是均线、布林带还是波动率突破，程序都要连续读取过去数日或数月的 1 分钟、5 分钟 K 线。参数寻优时，同一段历史数据会被不同参数组合反复访问，如果不做缓存，接口往返次数会成倍增加。
数据痛点
历史数据有一个显著特点：已经收盘的 K 线基本不变。昨天的黄金 1 分钟 K 线，今天不会改变。重复通过网络请求拉取这些固定数据，只会增加延迟。真正的耗时并非指标计算，而是网络 I/O、数据解析和等待响应。
因此，我调整了数据访问逻辑：先检查本地是否存在所需数据，如果缺失或不完整，再通过黄金实时api补齐。对于量化回测来说，这种“先查缓存、再补缺口”的方式非常有效。
缓存层设计
在实际项目中，我按数据变化频率使用两种缓存：
- 实时行情：变化快，适合内存缓存，只保留最近一段 tick 或最新价。
- 历史 K 线：更适合持久化保存，写入本地文件或数据库，下次启动直接加载。
持久化缓存会记录以下字段：
| 字段 | 作用 |
|---|---|
| symbol | 区分不同交易品种 |
| 周期 | 判断K线级别 |
| 开始和结束时间 | 匹配查询范围 |
| OHLC数据 | 用于指标计算和回测 |
判断缓存是否可用时，我通常按以下顺序：
- 解析当前请求的品种、周期和起止时间；
- 读取本地缓存，检查覆盖范围；
- 如果完全覆盖，直接返回；
- 如果部分缺失，只请求缺失区间；
- 合并数据并写回缓存。
这样查询前能快速判断缓存是否覆盖需求。如果只缺某几个小时的数据，就只补这一部分，避免重复拉取完整区间。
实时与历史衔接
实时行情和历史数据需要衔接，否则最新 K 线容易与历史部分断开。我的做法是让实时 tick 先进入内存缓存，再按时间周期合成 K 线；周期结束后，将完整 K 线持久化保存。以 AllTick API 的 tick 推送为例，我通过 websocket 接收实时数据并暂存：
import websocket
import json
from datetime import datetime
market_cache = {}
def on_message(ws, message):
data = json.loads(message)
symbol = data.get("symbol")
price = data.get("price")
timestamp = data.get("timestamp")
market_cache[symbol] = {
"price": price,
"timestamp": timestamp,
"update_time": datetime.now()
}
print(symbol, price)
ws = websocket.WebSocketApp(
"wss://api.alltick.co/ws",
on_message=on_message
)
ws.run_forever()
之后 K 线计算和行情展示直接读取缓存，不再依赖接口返回。对量化终端或本地 Python 环境都很容易集成。
维护与扩展
缓存需要持续维护。黄金交易时间长，实时数据缓存周期不能设置过长，否则价格展示会滞后；历史数据则可以长期保存。另一个容易忽略的坑是更新方式：发现历史 K 线缺失时，应只补缺失区间，而非重拉整个范围。
如果策略规模扩大，多个策略同时读取行情，我会把内存缓存升级为 Redis，让不同任务共享同一份数据，避免重复加载。未来还可以把缓存层独立成服务，方便多品种、多周期扩展。
实践总结
这次优化让我重新理解了行情系统的效率瓶颈。接口速度只是其中一个因素，数据流转方式同样重要。实时行情负责变化，缓存负责减少重复访问。对于需要频繁查询历史 K 线的量化策略，缓存不是可选项，而是基础组件。提前设计好缓存逻辑，后续增加品种和数据量时，系统会更稳定、更容易扩展。
