xxxlxy2008

@Bo-Qiu 咱们可以做个简单的测试。 先在 org.apache.dubbo.registry.zookeeper.ZookeeperRegistry.ZookeeperRegistryNotifier#notify() 方法里面，添加下面这行日志，在每次 doNotify() 之前进行一次输出： 然后，把 dubbo-demo-xml-consumer 和 dubbo-demo-xml-provider 调整成【接口级】注册和订阅，启动。 在 Zookeeper 里面，/dubbo/org.apache.dubbo.demo.DemoService/providers 节点下只有一个节点，如下： 最后，我们执行快速执行下面两个命令，这两个命令，只是把上面 dubbo-demo-xml-provider 注册的 URL 里面的 IP，从 192.168.2.146 改成192.168.2.147和192.168.2.148节点，模拟两个 Provider 节点同时上线的情况： `create /dubbo/org.apache.dubbo.demo.DemoService/providers/dubbo%3A%2F%2F192.168.2.147%3A20880%2Forg.apache.dubbo.demo.DemoService%3Fanyhost%3Dtrue%26application%3Ddemo-provider%26background%3Dfalse%26delay%3D5000%26deprecated%3Dfalse%26dubbo%3D2.0.2%26dynamic%3Dtrue%26generic%3Dfalse%26interface%3Dorg.apache.dubbo.demo.DemoService%26ipv6%3D2408%3A8207%3A7889%3Ac32%3Ada3d%3Accff%3A0%3Ab9d%26methods%3DsayHello%2CsayHelloAsync%26pid%3D29364%26service-name-mapping%3Dtrue%26side%3Dprovider%26timeout%3D3000%26timestamp%3D1673276136517` `create /dubbo/org.apache.dubbo.demo.DemoService/providers/dubbo%3A%2F%2F192.168.2.148%3A20880%2Forg.apache.dubbo.demo.DemoService%3Fanyhost%3Dtrue%26application%3Ddemo-provider%26background%3Dfalse%26delay%3D5000%26deprecated%3Dfalse%26dubbo%3D2.0.2%26dynamic%3Dtrue%26generic%3Dfalse%26interface%3Dorg.apache.dubbo.demo.DemoService%26ipv6%3D2408%3A8207%3A7889%3Ac32%3Ada3d%3Accff%3A0%3Ab9d%26methods%3DsayHello%2CsayHelloAsync%26pid%3D29364%26service-name-mapping%3Dtrue%26side%3Dprovider%26timeout%3D3000%26timestamp%3D1673276136517`...

@Bo-Qiu 我看现在已经是用 Watcher 了，没有用 Cache 了吧。我看org.apache.dubbo.remoting.zookeeper.curator.CuratorZookeeperClient.CuratorWatcherImpl 的 486 行，用的是client.getChildren().usingWatcher(CuratorWatcherImpl.this).forPath(path) 的方式。 看你这边的方案，是把这个注册Watcher 的逻辑放到 5 秒（默认值）延迟之后。 另外，想讨论延迟通知这个特性本身，会不会造成一些问题。例如，有 1-10、11-20、21-30 三组 Provider 实例，分批进行更新，进行一次上线更新之后，变成 31-40、41-50、51-60 三个 Provider 实例，延迟订阅的方式 会不会 出现部分 Provider 连接失败的情况，导致线上用户的请求失败。毕竟，延迟订阅的话，相当于和 Zookeeper 断开了 5...