ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

tick-stock-panel看门狗与重型任务限流器:服务自愈与并发保护机制解析

tick-stock-panel看门狗与重型任务限流器:服务自愈与并发保护机制解析 tick-stock-panel看门狗与重型任务限流器服务自愈与并发保护机制解析【免费下载链接】tick-stock-panelTSP自托管、零运维的 A 股「选股 监控 回测」量化工作台 | LLM能力驱使策略定制个股分析复盘 | 自由接入第三方数据源与个性化扩展数据 | 个人开源项目地址: https://gitcode.com/GitHub_Trending/ti/tick-stock-paneltick-stock-panel 是一款自托管、零运维的 A 股「选股 监控 回测」量化工作台。它的后端要在 7×24 小时不间断服务里扛住高频数据查询、因子挖掘和全量回测一旦进程僵死或内存被打爆普通用户只能干等人工重启。本文带你拆解它的两大守护机制看门狗自愈重启与重型任务限流器并发保护帮你理解这套服务是如何做到自己会治病、还会自我克制的。为什么量化服务需要自愈能力2026 年 9 月 7 日tick-stock-panel 曾发生一次典型事故polars 并发死锁把线程悬死在collect内部0 CPU 永久挂起持锁线程让全局写锁被永久占用所有请求线程排队冻结页面完全无响应只能人工重启。自托管场景下没有运维值班恢复时间不能靠人发现。tick-stock-panel 为此构建了三层防线而看门狗是最后一道兜底防线作用源码位置并发闸削减死锁触发概率backend/app/polars_guard.py写锁瘦身缩小死锁扩散半径backend/app/tickflow/repository.py看门狗探测僵死、主动退出、自动拉起backend/app/watchdog.py看门狗如何探测后端僵死看门狗的核心设计很巧妙探测路径与事故路径完全相同。默认探测函数会执行一次毫秒级的微型 polarscollect并试探持有全局写锁 1 秒——这两条路正是事故中被毒化的资源任一被悬死线程占住就会超时探测逻辑见 default_probe工作流程只有四步定时心跳每 30 秒watchdog_interval_s发起一次探测限时判定单次探测超过 15 秒watchdog_probe_timeout_s记为一次失败连续计数连续失败达到 2 次watchdog_failure_threshold即判定进程僵死主动退出以退出码 70 结束进程os._exit交由 supervisor / Docker restart / dev 脚本自动拉起。整个判断循环在 HealthWatchdog._loop启动钩子挂在 FastAPI lifespan 上main.py关闭时也会优雅停止任务。误伤防护是重点探测本身是毫秒级微型操作阈值又要求连续失败高负载下慢而未死不会触发退出——把恢复时间从人工发现缩短到约一分钟又不会把忙碌的系统误杀。相关参数集中在 config.pywatchdog_enabled: bool True— 总开关watchdog_interval_s: float 30.0— 探测间隔watchdog_probe_timeout_s: float 15.0— 单次探测超时watchdog_failure_threshold: int 2— 连续失败阈值 配套测试覆盖了连续失败触发退出成功重置计数停止时任务被取消等场景见 test_watchdog.py。重型任务限流器加权槽位的并发保护看门狗解决死后复活而限流器解决别让自己累死。tick-stock-panel 的回测、因子挖掘、数据刷新都是内存密集型任务如果并发失控内存会被瞬间吃满。解决方案是一个进程级、加权、FIFO的限流器heavy_job_limiter.py三种任务类型两种权重 独占进程总预算默认为2 个槽位任务按类型消耗不同权重HeavyJobLimiter任务类型权重典型场景normal1单次回测、工具类计算mining2因子挖掘最耗资源exclusive全部槽位数据刷新、矩阵缓存预热等必须独占的任务关键特性一览FIFO 公平排队等待者按先来后到排票据ticket后面的任务不能插队挤占前面任务的槽位即使空闲槽位看起来够用可取消等待acquire支持cancel_event用户在页面上取消挖掘任务时排队中的任务立即退出而不是空等超时可区分等待失败会区分限流超时HeavyJobLimitTimeoutError与被取消HeavyJobCancelledError前端能给出准确提示异常自动释放推荐用上下文管理器slot()slot 方法即使任务中途抛错槽位也必定归还不会泄漏防死锁升级已持normal槽位时再请求exclusive会直接报错而不是原地死等嵌套调用则复用外层预留。谁在用这个限流器限流器以模块单例 shared_heavy_job_limiter 的形式被各处复用典型入口包括回测接口api/backtest.py因子挖掘mining_manager.py数据管道刷新独占 可取消pipeline_jobs.py仓库数据刷新独占repository.py矩阵缓存预热独占 可取消main.py两层守护如何协作用一句话概括限流器管别太累看门狗管死了能复活。日常运行中HeavyJobLimiter把并发内存压力压在 2 槽位预算内重任务排队、可取消、公平调度极小概率下若仍出现线程悬死/锁毒化看门狗连续两次探测超时后主动退出Docker 或 supervisor 自动拉起新进程服务恢复——全程无需人工介入。这正是零运维承诺的底层支撑自托管用户即使把它跑在一台闲置的小主机上也能获得接近托管服务的可用性。想深入了解部署与参数配置可参考官方文档 docs/deployment.md 与 docs/configuration.md。小结看门狗与事故同路径的微型探测 连续失败阈值 自动重启约 1 分钟完成自愈重型任务限流器加权槽位 FIFO 排队 取消机制让回测、挖掘等重任务有节制地跑两者一攻一守构成了 tick-stock-panel 面向个人用户的关键可靠性设计。【免费下载链接】tick-stock-panelTSP自托管、零运维的 A 股「选股 监控 回测」量化工作台 | LLM能力驱使策略定制个股分析复盘 | 自由接入第三方数据源与个性化扩展数据 | 个人开源项目地址: https://gitcode.com/GitHub_Trending/ti/tick-stock-panel创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表