24 lines
1.7 KiB
Markdown
24 lines
1.7 KiB
Markdown
# 2026-09-01-云端计划预测昨日销量缓存过期修复
|
||
|
||
<!-- project: path:/home/gxd/.openclaw/workspace/dy-dashboard -->
|
||
|
||
### 1. 云端计划预测昨日销量与出库数据不一致
|
||
|
||
**旭东 → OpenClaw：**
|
||
> 发现一个异常，云端系统里面，一个品的出库数据合计，也就是昨日销量是79，但是在计划预测里面显示昨日销量不是79，但是在8.186环境系统里面就是正常显示的79，看一下什么原因？
|
||
>
|
||
> （随后）这个计算缓存文件时间为什么不是每次导入完数据之后就自动计算缓存
|
||
>
|
||
> （随后）先刷一下云端的缓存，再把定时刷新也配上
|
||
|
||
**OpenClaw 响应：**
|
||
定位根因：计划预测「昨日销量」走计算缓存（`compute_product_sales_cached`，`RefreshableCache` 文件持久化），云端该缓存停在 8-29 09:35 未刷新，而 daily_outbound 数据已更新到 8-31（与 8.186 完全一致），故计划预测仍用旧数据算昨日销量；出库数据是实时查库所以显示正确 79。
|
||
|
||
原因：云端数据是「手工 SSH + SQL 导入」绕过导入脚本，且云端无 crontab、`auto_update.py` 未定时跑，导入后未调用 `refresh_all_caches()`；手工导入后仅服务重启，但重启只清内存缓存不清文件缓存（`tmp_cache/*.cache` 跨进程持久化）。
|
||
|
||
处理：
|
||
1. 云端执行 `refresh_all_caches()` 立即刷缓存（11 个模块），抽查 8 个产品昨日销量全部与 8-31 实时数据一致；
|
||
2. 云端新增 `/opt/dy-dashboard/refresh_cache.sh` 并配置 crontab `30 7,12,18,23 * * *` 定时刷缓存，防止手工导入后缓存过期复发。
|
||
|
||
遗留建议：后续每次云端手工 SQL 导入数据后，应补一步 `refresh_all_caches()`（现已由 cron 兜底）。
|