dubbo的提供者服务所在的节点直接意外关机了，原来的服务提供者虽然剔除了但消费者仍然在调用原来的服务提供者，这是怎么回事啊，求大佬解答。

[qigeqigeqi]

dubbo是做了服务下线的钩子程序，按zk会下线老的提供者，且用的2.7.8的版本 dynamic默认就是true，但是消费者还是会去调用原来的提供者，导致服务出错。

[ningboliu]

推送会有延迟吧，出错重试调用其他服务就可以

[qigeqigeqi]

推送会有延迟吧，出错重试调用其他服务就可以

就是想搞清楚为啥没有及时把已经下线的节点剔除掉，还去调用原来的节点。就算不是优雅退出，整个节点都关机了，zk的心跳机制也会判定老节点失效了应该不会再去调用才对啊。

[AlbumenJ]

推送会有延迟吧，出错重试调用其他服务就可以

就是想搞清楚为啥没有及时把已经下线的节点剔除掉，还去调用原来的节点。就算不是优雅退出，整个节点都关机了，zk的心跳机制也会判定老节点失效了应该不会再去调用才对啊。

心跳是有周期的，需要看下这个错误调用是有多久，如果是短时间的那就是推送时效的问题。（大约在 1 分钟内）

[qigeqigeqi]

操作的间隔时间是满足了周期的，旧节点关机下线都差不多一个小时了，但是消费者还在调用旧的提供者，但是dubbo_admin中的提供者清单里面是没有旧的节点信息了。

[qigeqigeqi]

会不会是dubbo的消费者的本地缓存没有更新，导致调用原来的老的提供者。
但是为什么老的提供者下线后消费者的本地缓存没有更新？zk中的信息确实是更新了（因为admin中没有老的提供者）

[qigeqigeqi]

dubbo在有服务提供者宕机或正常关闭时，ZK注册中心会把该节点剔除，并通知所有服务消费者更新本地缓存，但是从此问题的现象看消费者的本地缓存并没有更新。
dubbo 的版本是2.7.8

[AlbumenJ]

升级到 3.1.1 版本看下有没有问题呢

[goto456]

dubbo在有服务提供者宕机或正常关闭时，ZK注册中心会把该节点剔除，并通知所有服务消费者更新本地缓存，但是从此问题的现象看消费者的本地缓存并没有更新。 dubbo 的版本是2.7.8

我也遇到过类似的问题，consumer的本地缓存文件已经更新了，但是consumer还是调用已经下线的provider，并且一直持续。
我用的nacos 2.1.0 + dubbo 2.7.16，也一直没解决。

[qigeqigeqi]

对，就很奇怪；按道理讲本地缓存都更新了，最先调用的又是本地缓存为什么还要去调用下线的服务提供者。
看来只能生产中规避暴力停机的场景了，出现这种现象就只能重新注册消费者了。

[AlbumenJ]

dubbo 2.7 的版本中可能存在 zk 连接断了的情况，这个时候 consumer 是不会再刷新数据的

[qigeqigeqi]

哦 原来是这样 这种场景能通过代码说明 或者 什么情况会复现呢 大佬

[AlbumenJ]

See #5135 #5126

[daydaypure1]

dubbo在有服务提供者宕机或正常关闭时，ZK注册中心会把该节点剔除，并通知所有服务消费者更新本地缓存，但是从此问题的现象看消费者的本地缓存并没有更新。 dubbo 的版本是2.7.8

我也遇到过类似的问题，consumer的本地缓存文件已经更新了，但是consumer还是调用已经下线的provider，并且一直持续。 我用的nacos 2.1.0 + dubbo 2.7.16，也一直没解决。

请问问题解决了吗？单位用的同样的nacos和dubbo

[JadeYeung]

dubbo 2.7 的版本中可能存在 zk 连接断了的情况，这个时候 consumer 是不会再刷新数据的

我们也遇到类似的，但跟provider没有太大关系。
线上环境，provider已经尝试过重启，且元数据已经发生变更，但是consumer端依旧持有旧数据的invoker。
通过Zookeeper的watcher可以看到consumer对于这个服务的watch事件已经丢失，没有办法再收到zk关于这个服务的数据变更了，最终只能重启consumer。
一直没找到丢失的原因，没有错误日志，最后只能定性为是网络问题导致consumer在收到一次监听变更后，再建立监听时数据包丢失，导致监听丢失