[alibaba/nacos]1.4.5版本的集群节点数量发生变更时，distro checkSum时会删除节点中的临时服务实例缓存，导致服务发现请求返回空

虽然在1.x版本中，nacos client有提供服务发现时防推空功能，但还是想了解下在不升级至2.x版本前提下，nacos server有无更好的解决办法。

nacos1挂掉， nacos2和3会重新计算责任节点，s1会被另外一个节点所负责，这个过程一般会小于心跳过期时间，除非你设置了过期时间为几个毫秒。

远离上 在客户端和服务端都是2.0以上的话， 使用长连接， 数据连接到那个节点，哪个节点就是责任节点，停止节点后长连接会飘到其他节点上，这个时间一般在1s内就会完成， 其他节点上旧数据会在3分钟之后才过期移除，期间这部分数据会重复一份。

nacos1挂掉， nacos2和3会重新计算责任节点，s1会被另外一个节点所负责，这个过程一般会小于心跳过期时间，除非你设置了过期时间为几个毫秒。

远离上 在客户端和服务端都是2.0以上的话， 使用长连接， 数据连接到那个节点，哪个节点就是责任节点，停止节点后长连接会飘到其他节点上，这个时间一般在1s内就会完成， 其他节点上旧数据会在3分钟之后才过期移除，期间这部分数据会重复一份。

@KomachiSion

nacos1关闭后s1会由其他节点负责，而且在各节点变更healthList完成前，不会在checkSums时删掉自己的s1缓存（nacos2和nacos3之前都不负责s1）。

但是，剩余节点（nacos2和nacos3）本来负责的服务，在集群变动后可能由其他节点负责（比如s4从原来由nacos3负责，改为由nacos2负责），因节点healthyList变更时间不一致，导致nacos3过早删除了s4实例缓存（上面图里的Step 4）。

我能理解这是nacos 1.x集群一致性设计的一部分，目的是让节点发现自己负责服务与集群内其他节点产生冲突时，优先放弃自己的管理权（并清理缓存），来规避集群扩缩容时产生脏数据的可能， 但是该设计也会导致集群扩缩容后请求服务发现接口返回为空的异常现象。

上文第7项的调整建议，可否改善此类问题在1.x版本出现的可能？

nacos1挂掉， nacos2和3会重新计算责任节点，s1会被另外一个节点所负责，这个过程一般会小于心跳过期时间，除非你设置了过期时间为几个毫秒。 远离上 在客户端和服务端都是2.0以上的话， 使用长连接， 数据连接到那个节点，哪个节点就是责任节点，停止节点后长连接会飘到其他节点上，这个时间一般在1s内就会完成， 其他节点上旧数据会在3分钟之后才过期移除，期间这部分数据会重复一份。

@KomachiSion

nacos1关闭后s1会由其他节点负责，而且在各节点变更healthList完成前，不会在checkSums时删掉自己的s1缓存（nacos2和nacos3之前都不负责s1）。

但是，剩余节点（nacos2和nacos3）本来负责的服务，在集群变动后可能由其他节点负责（比如s4从原来由nacos3负责，改为由nacos2负责），因节点healthyList变更时间不一致，导致nacos3过早删除了s4实例缓存（上面图里的Step 4）。

我能理解这是nacos 1.x集群一致性设计的一部分，目的是让节点发现自己负责服务与集群内其他节点产生冲突时，优先放弃自己的管理权（并清理缓存），来规避集群扩缩容时产生脏数据的可能， 但是该设计也会导致集群扩缩容后请求服务发现接口返回为空的异常现象。

上文第7项的调整建议，可否改善此类问题在1.x版本出现的可能？

不太合理， 出现冲突时，其实并不知道谁才是正确的，肯定以自身计算为准比较好。 同时删除数据（缓存）对业务损耗会更大。 毕竟一时的脏数据可能只是流量不均， 但是删除数据后一定会导致找不到提供者报错。

建议是赶紧找机会升级到2.0的版本，长连接的机制能比较好的解决这个问题。

nacos1挂掉， nacos2和3会重新计算责任节点，s1会被另外一个节点所负责，这个过程一般会小于心跳过期时间，除非你设置了过期时间为几个毫秒。 远离上 在客户端和服务端都是2.0以上的话， 使用长连接， 数据连接到那个节点，哪个节点就是责任节点，停止节点后长连接会飘到其他节点上，这个时间一般在1s内就会完成， 其他节点上旧数据会在3分钟之后才过期移除，期间这部分数据会重复一份。

@KomachiSion nacos1关闭后s1会由其他节点负责，而且在各节点变更healthList完成前，不会在checkSums时删掉自己的s1缓存（nacos2和nacos3之前都不负责s1）。 但是，剩余节点（nacos2和nacos3）本来负责的服务，在集群变动后可能由其他节点负责（比如s4从原来由nacos3负责，改为由nacos2负责），因节点healthyList变更时间不一致，导致nacos3过早删除了s4实例缓存（上面图里的Step 4）。 我能理解这是nacos 1.x集群一致性设计的一部分，目的是让节点发现自己负责服务与集群内其他节点产生冲突时，优先放弃自己的管理权（并清理缓存），来规避集群扩缩容时产生脏数据的可能， 但是该设计也会导致集群扩缩容后请求服务发现接口返回为空的异常现象。 上文第7项的调整建议，可否改善此类问题在1.x版本出现的可能？

不太合理， 出现冲突时，其实并不知道谁才是正确的，肯定以自身计算为准比较好。 同时删除数据（缓存）对业务损耗会更大。 毕竟一时的脏数据可能只是流量不均， 但是删除数据后一定会导致找不到提供者报错。

建议是赶紧找机会升级到2.0的版本，长连接的机制能比较好的解决这个问题。

@KomachiSion 但是当前1.x版本处理方式，并不是以自身计算为准，而是“直接删除了自身数据，却也并未采纳对方数据”，导致在下一轮数据校验同步完成前，找不到提供者报错：

2.x长连接设计的确能提供更好的使用体验，这个我也了解，但社区当前也并未彻底遗弃1.x版本（陆续发布了1.4.4、1.4.5等fix版本）。 现实情况是1.x版本就是存在一种集群正常扩缩容场景下几乎必现的实例缓存丢失问题，想咨询下社区团队对于问题的看法，是真实的缺陷？还是设计如此？

Save problem ! 1.x 版本还能不能正常线上使用的?

就是因为都是以自身计算为准， 所以服务端认为这个服务并非自己负责的节点，来源给的checksum是移除了，因此移除数据是正常的。这里的以自身计算为准，指的是计算的责任节点，而不是实际的数据内容，你大概是误解了代码的意思，认为是服务数据。

Nacos的非持久化实例作为AP协议，保证的是最终一致性， 尽量做到数据过程中的一致性，但会有一定延迟存在。

如果不能升级2.0版本， 可以升级到1.4.2以上的客户端， 开启推空保护功能，防止AP协议过程中短暂数据不一致的场景。

但社区当前也并未彻底遗弃1.x版本（陆续发布了1.4.4、1.4.5等fix版本）。

1.X 已经进入生命周期末期的维护阶段， 发版节奏很慢且不会有新功能添加。机制和整个1.X阶段也是一致的。估计很快会结束生命周期。还是建议尝试升级到2.X

@KomachiSion 如果采用升级nacos-server集群至2.x，客户端保持使用1.x版本，可以规避这类问题吗？ （之所以不使用2.x客户端的原因：服务实例和nacos-server中间会存在多层网络代理，不便于使用grpc长连接）