zlt
|
bccc2e5970
|
计划接口按请求实时补个股深度评析：评析什么时候跑完都算数
用户问：今天要计划的股票理论上应该优先做买方评析，为什么没有。查下来是三层
原因叠在一起，前一层今天已经解掉，这里解掉后两层。
第一层（今天已解）。评析原先每天凌晨 00:45 跑一批二十家，而当天的计划要
07:10 才出，所以它读到的永远是前一天的名单。今天改成全天每小时一批之后，
07:10 之后的批次能读到当天名单了。
第二层。计划一天只装配一次。07:10 出计划时读一次评析库，之后新产出的报告
再也进不了那份快照。
第三层。计划接口带十二小时缓存（今天早上为修页面超时从十分钟改上去的），
于是连「重新装配一次」这条路也堵上了 —— 原先十分钟过期重算，新报告十分钟内
能进；现在要等十二小时。这一层是今天早上那笔改动的副作用。
实测证据。今天早上七点十分那份计划里 154 行只有 7 只带评析。中午十二点二十三
到三十五分之间新跑出五份报告，而这五只（688556.SH 名单第 2、605598.SH 第 7、
300118.SZ 第 8、688698.SH 第 11、300638.SZ 第 13）正是持仓管理系统当天出提议的
票 —— 它当天一份都看不到，卡片上写的全是「数据基座还没出这家的报告」。
为什么不靠排期解决。查过两天名单的重合度：09-08 与 09-09 只重合 66 只 = 55%，
前 40 名里只有 46% 重合，每天有 54 只是新进名单的。也就是说「凌晨提前跑前一天
的名单」最多覆盖一半，剩下一半当天无论如何都赶不上 —— 名单本身就是计划的产物，
不出计划就不知道要跑谁。
修法。在 /plan 返回时实时补一次，与 regime、market 两个键同一个路子：按请求补、
不进缓存。这样评析什么时候跑完都行，跑完下一次请求就带上；计划缓存多久、走快照
还是现算，都不再影响它。代价是每次请求多一条批量数据库查询。
最要小心的是浅拷贝：get_plan 里的 dict(data) 只拷了顶层，main / observe 里的行
对象与缓存里那一份是同一批，不先拷贝就改等于把当次请求的结果写进缓存、污染全天。
新增的 test_plan_reviews_live.py 六组用例里，第二组专门钉这一条。
访问日志加了「评析补 N 只」，事后能核对。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-09-10 13:17:22 +08:00 |