如果心跳太小,网络抖动可能会影响 storage 进程的状态维护,比如触发新的 leader 选举,期间服务的某些请求可能不能正常返回,报 LEADER CHANGE。

如果是源数据同步的问题,目前 12.30 这个版本正在解决这个问题,采用的是通过 PUB/SUB 的方式让各个 meta client 订阅 schema 的更新,可以近实时的刷新本地的 cache。

源数据更新的不及时的问题主要是刷新了 meta 数据之后没有立即刷新本地 cache 而必须等待心跳时间刷新导致的。因为后续方案采用了上述的方式,就没有再提交类似的修改。

目前 nebula 的 CI 系统中是设置的 1s,不过是在单机环境下,具体的数值,还是需要根据集群的状态做些验证。