04 配置新鲜度同步

04 配置新鲜度同步

本节摘要:前三节讲了托管、注入、合并,这一节讲最后一个机制——配置新鲜度同步。OpenWork 的运行时数据库会不断变化(用户加能力、改配置),这些变化怎么同步到「服务端管理的配置文件」,让引擎重读后用上新配置?这就是新鲜度同步要解决的事。本节讲清这套同步:它如何触发、如何保持配置文件新鲜、以及它和第 8 章 Reload 事件的分工。

一、问题:运行时数据库 vs 配置文件

先理清 OpenWork 里两个「存配置的地方」:

问题来了:运行时数据库是真实状态,但引擎读的是配置文件。如果数据库变了、配置文件没跟着变,引擎读到的就是过时配置。所以需要一套机制,保证配置文件「新鲜」——始终反映数据库的最新状态。这就是「新鲜度同步」。

运行时数据库(真实状态,不断变)
   │
   ▼ 新鲜度同步
服务端管理的配置文件(给引擎读)
   │
   ▼ 引擎重建时读
引擎实例
​

二、同步如何触发

新鲜度同步的触发时机大致是:每次运行时数据库写入后,同步更新配置文件。

用户加了一个能力
   │
   ▼ 写入运行时数据库
   │
   ▼ 触发新鲜度同步
   │
   ▼ 重新生成服务端管理的配置文件(反映最新数据库状态)
   │
   ▼ 配置文件保持新鲜
​

这种「写数据库 → 同步配置文件」的模式,保证了配置文件始终是数据库的「镜像」。数据库是真相,配置文件是给引擎看的投影,同步保证投影不滞后。

三、「保持新鲜」的具体含义

「新鲜」指的是:配置文件的内容,始终等于「从当前运行时数据库推导出的、引擎该用的配置」。换句话说,任何时刻你打开配置文件看,它都应该反映数据库的最新状态——没有「数据库已经改了,但文件还是旧的」的滞后。

💡 类比:配置文件是数据库的「缓存」。新鲜度同步就是「缓存一致性」——保证缓存(文件)和源(数据库)一致。这和数据库的缓存一致性是同一类问题。

四、同步与第 8 章 Reload 的分工

这里要讲清一个容易混淆的分工——新鲜度同步(本节)和第 8 章 Reload 事件各管一段:

二者是接力关系:

数据库变了
   │
   ▼ 本节:新鲜度同步
配置文件更新(新鲜了)
   │
   ▼ 但引擎还在用旧配置(还没重读)
   │
   ▼ 第 8 章:Reload 事件
引擎重读配置 + 重建实例
   │
   ▼ 引擎用上新配置
​

本节只管到「配置文件新鲜」,不管「引擎重读」——后者是第 8 章 Reload 的事。两节合起来,才构成「改了能力 → 引擎生效」的完整链路。这个分工很重要:不要以为「同步了配置文件引擎就生效了」——还要 Reload 驱动引擎重读。

五、同步的频率与开销

新鲜度同步是「每次数据库写入都同步」,这会不会太频繁、开销太大?实际不会,因为:

• 写入本身就不是很频繁:用户加能力、改配置不是每秒都做的事。
• 同步是顺序写文件:很快(毫秒级)。
• 可以合并:短时间内多次写入可以合并成一次同步(避免重复写)。

所以开销可控。真正需要担心频率的是第 8 章的 Reload(它驱动引擎重建,代价更高),那里有「指纹去重」防风暴(第 8 章 01 节)。

六、第 5 章收尾:你现在理解的引擎托管

读完第 5 章四节,你完成了对「平台如何接管引擎」的完整理解:

这四节合起来,回答了一个核心问题:OpenWork 怎么让一个独立产品(引擎)听自己指挥,又不绑架它? 答案就是——反向托管建立管理关系,配置注入传递指令,三方合并兼容并蓄,新鲜度同步保持时效。这是 OpenWork 作为「平台」的工程根基,也是「可弹出」哲学的实现机制。

本节要点回顾

1. 两个存储:运行时数据库(真实状态,不断变)+ 服务端管理配置文件(给引擎读,静态)。
2. 新鲜度同步:每次数据库写入后,重新生成配置文件,保证它反映数据库最新状态。
3. 新鲜 = 缓存一致:配置文件是数据库的投影/缓存,同步保证不滞后。
4. 与 Reload 分工:本节管「文件新鲜」,第 8 章 Reload 管「引擎重读」——接力关系,缺一不可。
5. 开销可控:写入不频繁、同步是顺序写、可合并——不用担心开销。
6. 第 5 章结束:你已理解「平台接管引擎」的全貌——托管 + 注入 + 合并 + 同步,这是可弹出哲学的实现。

第 5 章结束。到这里,OpenWork 教程的核心章(1、2、5、7)子节正文已完成。下一步可以继续推进其余章节(3、4、6、8、9、10、11、12、13)的子节,按 Cron 连载节奏走。