多用户仪表盘场景下REST API请求最优缓存方案咨询

核心逻辑 #

这个场景是典型的高频重复读请求打源站的问题，没必要搞复杂架构，核心就是把原来「客户端直连各门店Woocommerce源站」的链路，替换成「中间代理层统一回源拉取数据+所有前端只读代理层缓存」的模式，从根源上把源站收到的请求量，从原来的在线用户数 * 轮询频率降到固定的代理层回源频率，不管多少人同时看仪表盘，源站的请求压力都是恒定的，不会随用户数上涨。

具体落地步骤 #

• 搭建轻量代理缓存服务
  不用上微服务、网关那套重组件，选你团队最熟的后端技术栈就行（Node.js/Go/Python都可以），核心只需要实现两个能力：
  1. 内置定时轮询任务，按照你业务能接受的数据延迟阈值（原来前端是5秒刷新，直接设5秒间隔就行），主动逐个调用所有门店的Woocommerce REST API，拉取你需要的商品销量、营业总收入等指定字段
  2. 拉回来的数据直接做缓存，对外暴露和原有Woocommerce API参数完全兼容的HTTP接口，前端不用改业务查询逻辑，只需要把原来的接口请求根地址改成代理服务的地址就行，改造成本极低。
     注意点：回源请求要加超时控制、最多2次的失败重试，单次拉取失败就沿用上一次缓存的有效数据返回给前端，不要直接抛错导致仪表盘空白。如果用Node.js栈实现，定时任务直接用node-cron，内存缓存用lru-cache就行，初期连Redis都不用部署，足够支撑上百人的内部团队访问。
• 配置缓存规则
  • 缓存TTL和定时回源间隔对齐，比如5秒回源一次就设TTL为6秒，既不会出现长时间的脏数据，也不会出现缓存空窗
  • 按照查询维度做缓存key隔离，比如按门店ID+查询日期+数据类型生成唯一缓存key，不同查询条件的数据不要混存
  • 加缓存击穿防护：如果遇到缓存刚好失效的极端场景，多个前端同时请求同一个维度的数据，代理层只放行1个请求回源，剩下的请求等待这次回源结果返回后直接读结果，不要并发打源站
• 前端轻量优化
  原有每5秒轮询的逻辑基本不用改，只改请求地址即可，额外加两个小逻辑就能进一步减少无意义请求：
  1. 监听浏览器标签页 visibility 状态，切到后台的时候自动暂停轮询，切回前台再恢复请求
  2. 前端请求层加3秒的本地内存缓存，避免用户频繁手动刷新页面产生重复请求

效果对比 #

按你现在20个用户同时查看的场景算，假设你运营10个Woocommerce门店：

• 原有模式：每5秒会给每个门店发20次请求，单轮总请求量200次，折算下来每天源站要承接345万+次请求
• 代理缓存模式：不管多少个用户在线，每5秒只会给每个门店发1次请求，单轮总请求量10次，源站压力直接降到原来的5%，完全不会再有访问压力问题。

可选进阶优化（初期不用做，后续规模上来再加） #

• 当门店数超过50家的时候，把定时回源逻辑改成异步队列调度，错峰拉取不同门店的数据，避免瞬时并发拉取占满出口带宽
• 给代理接口加简单的token权限校验，避免内部经营数据被无关人员访问
• 可以在代理层提前做跨门店数据聚合计算，比如总营收、总销量这类全局统计值直接在代理层算好返回，减少前端的计算量

内容的提问来源于stack exchange，提问作者Mark