缓存重建时,要不要让用户先查旧数据?

缓存重建时,要不要让用户先查旧数据?

一、它管的是"什么时候能查"

OnlineMode 位于主动缓存(ProactiveCaching)配置下,作用是:指定数据库是在缓存重建开始时立刻恢复在线,还是等缓存重建完成后才恢复在线。

项目说明
数据类型字符串(枚举)
默认值Immediate
可选性0 到 1,可选且最多出现一次
父元素主动缓存(ProactiveCaching)

二、两个取值,两种体验

取值行为用户感受
Immediate缓存重建一开始,数据库立即恢复在线随时能查,但重建期间拿到的可能是旧数据或不完整结果
OnCacheComplete只有缓存重建完成后,数据库才恢复在线查询结果更一致,但要等;高峰期可能影响体验
关键判断:这份数据"看到旧值"和"暂时看不到",哪个代价更大。

三、怎么选:按业务场景分

场景建议理由
运营看板、日常监测Immediate用户要的是"随时能看",几秒的旧数据不影响决策
对外报表、结算数据OnCacheComplete数字必须一致,宁可短暂不可用也不能给错数
内部探索分析Immediate交互频繁,等待会打断分析节奏
合规报送、审计取数OnCacheComplete取数口径必须确定,不能取到"半成品"

四、两个容易忽略的连带问题

默认值的隐性成本:默认 Immediate 意味着,如果不做任何配置,系统会在缓存重建期间就让用户进来查。一个从没被审视过的默认值,可能在你不注意的时候决定了数据可信度。

与其他缓存参数的配合:主动缓存不是单一开关,它还有延迟、通知方式等一组配置。OnlineMode 只决定"什么时候上线",不决定"多久重建一次"。两者混在一起调,容易出现"配置改了但现象没变"的困惑。

五、落地建议

  1. 先明确这份数据的"错误容忍度"——能否接受短暂的不一致;
  2. 按上表选定模式,并写进文档,而不是靠默认值;
  3. 对选择 OnCacheComplete 的库,评估重建耗时,确认可接受;
  4. 在监控里区分"重建中的查询"和"正常查询",否则性能问题会被误判。

一句话总结:这个参数回答的是"可用性和一致性,你先保哪个"。默认值选了可用性——如果你的业务更需要一致性,就得主动改。