版本支持：v2.16.1+

两条腿

Rule-DB的多节点收敛靠两条独立机制叠加，任何一条都能把变更传到所有节点。两条腿的具体形态随后端不同：

后端	变更通知腿	周期	对账腿
SQL	seq轮询，SELECT MAX(seq)	poll-seconds，默认3秒	全量对账，reconcile-seconds，默认60秒
PostgreSQL	seq轮询，SELECT MAX(seq)	poll-seconds，默认3秒	同上
MongoDB	seq轮询，看sequence和change_log	poll-seconds，默认3秒	同上
Redis	seq轮询，GET seq	poll-seconds，默认3秒	同上
ZooKeeper	watch实时推送，CuratorCache监听meta节点	毫秒级	同上
Etcd	watch实时推送，按revision订阅	毫秒级	同上
Nacos	Listener推送，监听应用的Catalog	毫秒级或亚秒级	同上

zk、etcd、Nacos走的是长连接监听，轮询腿对它们不生效；SQL、PostgreSQL、MongoDB、Redis没有推送通道，靠seq轮询。Nacos的Listener如果跳过了中间版本，sequence断档会立即触发一次全量对账。

不管哪种后端，周期对账都是兜底，通知和轮询都失效了也照样能收敛。

收敛窗口

任何变更最迟会在max(通知延迟, 对账周期)内被所有节点感知。典型值如下：

模式	通知延迟	最迟收敛	多数情况下的实际表现
zk / etcd	watch，毫秒级	60秒	毫秒级
Nacos	Listener推送	60秒	毫秒级或亚秒级
SQL / PostgreSQL / MongoDB / Redis	轮询3秒	60秒	3秒内

同一条记录从创建到删除这段时间里，业务版本是单调递增的。变更通知会按版本和内容指纹做幂等保护，所以迟到的旧通知不会把已经激活的版本打回旧版。

删除后重建算新记录

删除之后用相同id重建，这算一条新记录，版本会重新从1开始，不能理解成原记录继续递增。如果备份恢复会降低业务版本，必须按限制与迁移里的流程来处理。

只发脚本、不发chain也能收敛

脚本发了新版之后，所有引用这个脚本的已编译chain都会在收敛窗口内切到新脚本，包括多条chain共享同一个脚本的情况，不需要把chain重发一遍。脚本级的变更就这么改。

一致性语义（务必读）

Rule-DB提供的是最终一致性，收敛窗口在秒级，它不是原子切换，也不是线性一致：

• 你发布一个新版本之后，在收敛窗口内，不同节点可能短暂地跑着不同版本，也就是还没收到通知的节点在跑旧版，收到的已经切到新版了。
• 正在执行中的请求会持有旧的条件树引用跑完，新的执行拿到新版，这和现有的copy-on-write语义一致。也就是说，不会所有节点在同一个逻辑时刻切换。
• 对绝大多数业务编排场景来说这是够用的，毕竟升级规则的时候本来就该接受短暂的版本差异。但如果你的业务要求全集群在同一时刻切版，那么当前版本的Rule-DB满足不了，请不要用。