PanWatch 行情缓存与节流设计4道防线让你的免费数据源永不限流【免费下载链接】PanWatchPanWatch — AI stock monitoring for A-shares, HK US markets, powered by TradingAgents. Portfolio insights, real-time alerts automated reports.盯盘侠覆盖 A股/港股/美股的 AI 盯盘、持仓分析、实时提醒与自动报告。项目地址: https://gitcode.com/GitHub_Trending/pa/PanWatchPanWatch盯盘侠是一款覆盖 A股、港股、美股的 AI 盯盘工具它的实时提醒与自动报告背后是一套精心设计的行情缓存与节流体系。免费行情接口腾讯、新浪、东财随时可能因为请求过猛而限流本文用通俗的方式拆解 PanWatch 如何用TTL 缓存、并发合并、负缓存、按 host 节流四道防线把打爆数据源这件事变成历史。为什么免费行情接口容易被限流先说痛点。PanWatch 的后台任务比想象中密集定时行情轮询每个持仓/自选股都要拉报价批量分析任务入场候选扫描、策略回测、组合归因会在同一时刻对同一批股票并发拉取 K 线多数据源故障转移主源挂了立刻切备源请求量不减反增。如果不做任何防护一次调度轮转就是几百次 HTTP 请求的突发免费接口的风控系统很快会给你的 IP 上枷锁。PanWatch 的解法可以概括为一句话能不发就不发必须发就慢慢发具体分成四道防线。第一道防线TTL 缓存——同样的请求只发一次核心实现在 packages/marketdata/src/marketdata/cache.py一个不到 60 行的线程安全内存缓存TTLCache每个数据带一个过期时间戳过期后自动失效再请求才会真正联网。PanWatch 为不同数据类型设置了不同的 TTL配置集中在 packages/marketdata/src/marketdata/client.py设计思路非常朴素——数据更新越慢缓存时间越长数据类型默认 TTL设计理由实时报价quotes5 秒价格敏感短 TTL 防抖快讯flash_news30 秒7×24 滚动但同一分钟内重复看没意义北向资金northbound60 秒盘中分钟级递增比 5 分钟更贴合基本面/龙虎榜/融资融券等300 秒日频/期频数据5 分钟内几乎不变更巧妙的是TTLCache的两个细节见 cache.py被动剔除不在定时器里主动清理而是下次 get 时发现过期就删零后台开销容量保护缓存条数超过max_size时优先淘汰最早过期的条目保证内存不无限增长。第二道防线K线市场态感知缓存——盘中短 TTL、收盘长 TTLK 线是批量任务的大户。日 K 一天只定稿一次收盘后但调度任务每轮都逐只重新联网拉取正是触发限流的元凶。采集层在 src/platform/marketdata/collectors/kline_collector.py 做了一个看市场状态决定缓存多久的策略交易时段缓存 180 秒3 分钟——最后一根 K 线盘中还在动太长的缓存会拿到旧数据收盘之后缓存 1800 秒30 分钟——数据已定稿再拉就是浪费。同样一份 K 线收盘前被缓存 3 分钟、收盘后被缓存 30 分钟联网次数直接下降一个数量级而且用户完全无感。第三道防线并发合并 失败负缓存——突发请求只出门一次缓存解决的是时间上重复还有另一种更隐蔽的重复同一时刻的并发重复。设想收盘后 5 个批量任务同时拉取贵州茅台的日 K如果没有合并就是 5 次请求。PanWatch 给每个市场:代码组合挂了一把锁kline_collector.py第一个线程真正联网其余 4 个排队等待拿到结果后直接复用——5 次并发合并为 1 次联网且不同股票各用各的锁互不阻塞。这个行为有专门的测试固化tests/test_kline_fetch_coalesce.py。更狠的是失败负缓存数据源短暂故障限流、断连时PanWatch 会把这个标的标记为冷却中——交易时段冷却 60 秒收盘后冷却 15 分钟。冷却窗口内所有请求直接返回缓存里的旧数据哪怕是空数据绝不重复联网。这解决了最难缠的一类刷屏如果源返回的数据条数不足正缓存永远不会命中没有负缓存的话每个消费者每轮都会重新打一遍补全源。第四道防线按 host 节流 退避重试——必须发就慢慢发前三道防线都在减少请求量最后一道防线兜底真正发出的请求也要文明。统一的 HTTP 出口 packages/marketdata/src/marketdata/http.py宿主侧对应 src/platform/marketdata/collectors/market_http.py内置了throttle()按域名节流对同一个 host两次请求之间强制保持最小间隔把并发突发拉平成匀速流水退避 抖动重试请求失败后按 0.4s、0.8s 递增等待再叠加 0~0.25s 随机抖动——随机性避免了所有重试齐步走再次撞墙失败来源标记每次取数都打上[srcxxx]日志标签限流发生时能立刻定位是哪个调度任务触发的。配合 Engine 层的主备故障转移按priority依次试数据源详见 packages/marketdata/src/marketdata/engine.py单次请求失败会自动切源而不是原地死磕健康度指标还会实时展示在「数据源」页面的面板里。总结一套省钱的缓存哲学回顾这四道防线你会发现 PanWatch 的行情缓存设计没有任何花哨技术全是朴素权衡防线机制源码位置解决的问题①TTL 缓存按数据类型分级cache.py时间上的重复请求②盘中 3 分钟 / 收盘 30 分钟kline_collector.py批量任务的重复拉取③并发合并锁 失败负缓存test_kline_fetch_coalesce.py同一时刻的并发突发、故障刷屏④按 host 节流 退避抖动重试http.py兜底限速文明取数对新手来说这套设计也值得借鉴做爬虫或接免费 API 时先问自己这个请求能不能不发再问能不能慢一点发——TTL 缓存、请求合并、失败冷却这三件套加上按域名的最小请求间隔基本能让你的应用在免费数据源上稳定运行。PanWatch 的 packages/marketdata/README.md 对这一整套可插拔数据源 主备故障转移架构有更完整的说明感兴趣可以延伸阅读。【免费下载链接】PanWatchPanWatch — AI stock monitoring for A-shares, HK US markets, powered by TradingAgents. Portfolio insights, real-time alerts automated reports.盯盘侠覆盖 A股/港股/美股的 AI 盯盘、持仓分析、实时提醒与自动报告。项目地址: https://gitcode.com/GitHub_Trending/pa/PanWatch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
PanWatch 行情缓存与节流设计：4道防线让你的免费数据源永不限流
PanWatch 行情缓存与节流设计4道防线让你的免费数据源永不限流【免费下载链接】PanWatchPanWatch — AI stock monitoring for A-shares, HK US markets, powered by TradingAgents. Portfolio insights, real-time alerts automated reports.盯盘侠覆盖 A股/港股/美股的 AI 盯盘、持仓分析、实时提醒与自动报告。项目地址: https://gitcode.com/GitHub_Trending/pa/PanWatchPanWatch盯盘侠是一款覆盖 A股、港股、美股的 AI 盯盘工具它的实时提醒与自动报告背后是一套精心设计的行情缓存与节流体系。免费行情接口腾讯、新浪、东财随时可能因为请求过猛而限流本文用通俗的方式拆解 PanWatch 如何用TTL 缓存、并发合并、负缓存、按 host 节流四道防线把打爆数据源这件事变成历史。为什么免费行情接口容易被限流先说痛点。PanWatch 的后台任务比想象中密集定时行情轮询每个持仓/自选股都要拉报价批量分析任务入场候选扫描、策略回测、组合归因会在同一时刻对同一批股票并发拉取 K 线多数据源故障转移主源挂了立刻切备源请求量不减反增。如果不做任何防护一次调度轮转就是几百次 HTTP 请求的突发免费接口的风控系统很快会给你的 IP 上枷锁。PanWatch 的解法可以概括为一句话能不发就不发必须发就慢慢发具体分成四道防线。第一道防线TTL 缓存——同样的请求只发一次核心实现在 packages/marketdata/src/marketdata/cache.py一个不到 60 行的线程安全内存缓存TTLCache每个数据带一个过期时间戳过期后自动失效再请求才会真正联网。PanWatch 为不同数据类型设置了不同的 TTL配置集中在 packages/marketdata/src/marketdata/client.py设计思路非常朴素——数据更新越慢缓存时间越长数据类型默认 TTL设计理由实时报价quotes5 秒价格敏感短 TTL 防抖快讯flash_news30 秒7×24 滚动但同一分钟内重复看没意义北向资金northbound60 秒盘中分钟级递增比 5 分钟更贴合基本面/龙虎榜/融资融券等300 秒日频/期频数据5 分钟内几乎不变更巧妙的是TTLCache的两个细节见 cache.py被动剔除不在定时器里主动清理而是下次 get 时发现过期就删零后台开销容量保护缓存条数超过max_size时优先淘汰最早过期的条目保证内存不无限增长。第二道防线K线市场态感知缓存——盘中短 TTL、收盘长 TTLK 线是批量任务的大户。日 K 一天只定稿一次收盘后但调度任务每轮都逐只重新联网拉取正是触发限流的元凶。采集层在 src/platform/marketdata/collectors/kline_collector.py 做了一个看市场状态决定缓存多久的策略交易时段缓存 180 秒3 分钟——最后一根 K 线盘中还在动太长的缓存会拿到旧数据收盘之后缓存 1800 秒30 分钟——数据已定稿再拉就是浪费。同样一份 K 线收盘前被缓存 3 分钟、收盘后被缓存 30 分钟联网次数直接下降一个数量级而且用户完全无感。第三道防线并发合并 失败负缓存——突发请求只出门一次缓存解决的是时间上重复还有另一种更隐蔽的重复同一时刻的并发重复。设想收盘后 5 个批量任务同时拉取贵州茅台的日 K如果没有合并就是 5 次请求。PanWatch 给每个市场:代码组合挂了一把锁kline_collector.py第一个线程真正联网其余 4 个排队等待拿到结果后直接复用——5 次并发合并为 1 次联网且不同股票各用各的锁互不阻塞。这个行为有专门的测试固化tests/test_kline_fetch_coalesce.py。更狠的是失败负缓存数据源短暂故障限流、断连时PanWatch 会把这个标的标记为冷却中——交易时段冷却 60 秒收盘后冷却 15 分钟。冷却窗口内所有请求直接返回缓存里的旧数据哪怕是空数据绝不重复联网。这解决了最难缠的一类刷屏如果源返回的数据条数不足正缓存永远不会命中没有负缓存的话每个消费者每轮都会重新打一遍补全源。第四道防线按 host 节流 退避重试——必须发就慢慢发前三道防线都在减少请求量最后一道防线兜底真正发出的请求也要文明。统一的 HTTP 出口 packages/marketdata/src/marketdata/http.py宿主侧对应 src/platform/marketdata/collectors/market_http.py内置了throttle()按域名节流对同一个 host两次请求之间强制保持最小间隔把并发突发拉平成匀速流水退避 抖动重试请求失败后按 0.4s、0.8s 递增等待再叠加 0~0.25s 随机抖动——随机性避免了所有重试齐步走再次撞墙失败来源标记每次取数都打上[srcxxx]日志标签限流发生时能立刻定位是哪个调度任务触发的。配合 Engine 层的主备故障转移按priority依次试数据源详见 packages/marketdata/src/marketdata/engine.py单次请求失败会自动切源而不是原地死磕健康度指标还会实时展示在「数据源」页面的面板里。总结一套省钱的缓存哲学回顾这四道防线你会发现 PanWatch 的行情缓存设计没有任何花哨技术全是朴素权衡防线机制源码位置解决的问题①TTL 缓存按数据类型分级cache.py时间上的重复请求②盘中 3 分钟 / 收盘 30 分钟kline_collector.py批量任务的重复拉取③并发合并锁 失败负缓存test_kline_fetch_coalesce.py同一时刻的并发突发、故障刷屏④按 host 节流 退避抖动重试http.py兜底限速文明取数对新手来说这套设计也值得借鉴做爬虫或接免费 API 时先问自己这个请求能不能不发再问能不能慢一点发——TTL 缓存、请求合并、失败冷却这三件套加上按域名的最小请求间隔基本能让你的应用在免费数据源上稳定运行。PanWatch 的 packages/marketdata/README.md 对这一整套可插拔数据源 主备故障转移架构有更完整的说明感兴趣可以延伸阅读。【免费下载链接】PanWatchPanWatch — AI stock monitoring for A-shares, HK US markets, powered by TradingAgents. Portfolio insights, real-time alerts automated reports.盯盘侠覆盖 A股/港股/美股的 AI 盯盘、持仓分析、实时提醒与自动报告。项目地址: https://gitcode.com/GitHub_Trending/pa/PanWatch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
