在量化交易设计的过程中,行情分发中心构架的必要性

_do_ai_decision()  ├─ _refresh_market_snapshot()     ← 直接调 TQ，导入失败导致数据 0:0 ❌  ├─ _refresh_trading_snapshots()   ← 逐股调 TQ，无批量化 ❌  └─ _build_market_env_text()       ← 读到的是过期或 0 数据 ❌

_do_ai_decision()  ├─ _refresh_market_snapshot()  │   └─ center.get_market_dashboard(force_fresh=True)  │        └─ 检查缓存年龄 > 3s → 加锁刷新 880005/880006/指数  │        └─ 注入 _last_market_env ✅  ├─ _refresh_trading_snapshots()  │   └─ center.get_stock_batch(codes)  │        └─ get_pricevol 批量获取 ✅  └─ _build_market_env_text()       └─ 读 _last_market_env → 涨跌数据正确 ✅

Timer 3秒循环:  refresh()    ├─ _refresh_indices()     ← 8 个指数缓存    ├─ _refresh_breadth()     ← 880005.SH 涨跌家数    └─ _refresh_limit_stocks() ← 880006.SH 涨跌停

1. 只有行情中心才可以跟 API 对接✅ 已实现。market_data_center.py 中的 _tq_lock 是全局唯一锁，所有 TQ 调用（get_market_snapshot、get_more_info、get_pricevol、get_stock_list 等）都必须通过行情中心的方法，内部统一持有锁。已把 7 个文件中原有的 tq.xxx() 调用全部替换为 center.xxx()。2. 着急需求的调用可以直接放行，比如交易盘口你之前说"除了 LLM 需要交易盘口行情的那个级别之外"，意思是：LLM 决策用的交易盘口数据（五档买卖 Buyp/Buyv/Sellp/Sellv、实时 Now、Volume 等）→ 直接调 TQ，不走行情中心缓存其他所有数据 → 走行情中心当前 _refresh_trading_snapshots 已经改为走行情中心的 get_stock_batch()，它内部用的是 get_pricevol（只返回 Now/LastClose/Volume，没有五档盘口）。需要确认：LLM 决策时是否需要五档盘口数据（买卖盘口深度）？如果需要，这部分应该保留直接调 TQ 的通道，不经过行情中心的缓存层。目前持仓快照走的是 get_pricevol，只有价量没有盘口。如果需要盘口，我可以给行情中心加一个 get_stock_depth(code) 方法，设 Priority.CRITICAL 直接穿透缓存。3. 不着急的，去缓存拿✅ 已实现。大盘指数、880005 涨跌家数、880006 涨跌停、成交额等，行情中心后台 3 秒一次自动刷新到缓存，所有读取方（market_env_analyzer、_build_market_env_text 等）直接读缓存，不需要再向 TQ 发请求。Python# 指数/涨跌家数 → 缓存读取（3秒刷新）indices = center.get_indices()breadth = center.get_market_breadth()# 个股快照 → 缓存读取（5秒 TTL）snap = center.get_stock_snapshot(code)4. 其他缓存数据也到行情中心申请✅ 已实现。get_stock_name()（600秒缓存）、get_stock_more_info()（30秒缓存）、get_relation()、get_kline_data() 等方法都带缓存，调用方不需要知道底层是 TQ 还是缓存。关于"既准确又不会给 API 施压"这正是行情中心的核心价值。改造前后对比：改造前改造后880005 调用次数7 个地方各自调，每分钟 N 次行情中心后台 3 秒 1 次TQ 并发多线程无锁竞争，导致断开重连_tq_lock 全局串行化LLM 决策数据_refresh_market_snapshot 因导入失败直接崩get_market_dashboard(force_fresh=True) 保证新鲜度数据一致性各模块看到的数据时间戳不一致同一份缓存，所有人看到的是同一时刻的数据