The reversion of the client is not synchronized when the instance is registered

[lbq972149981]

Describe the bug
客户端实例注册时，责任nacos节点需要将数据及版本信息同步给其他非责任nacos节点，但是目前发现非责任节点的版本未更新。

Expected behavior
当有责任节点的sync数据时，版本号应该即刻更新才对。

Desktop (please complete the following information):

• OS: [e.g. Centos]
• Version nacos-server 2.2.0.1
• Module naming

Additional context
实际三分钟后由健康监测的线程清理了该clientId对应的缓存，当下一次同步数据重新创建client对应，并初始化了revision

[KomachiSion]

看了一下，简单的修复是可以直接setRevision，但是有个问题是setRevision如果在部分并发场景下，可能出现数据和revision不对应的情况，所以这里要彻底修复可能需要对同步数据处理的逻辑做一些修改， 使用替换client的方案，而不是在旧client直接修改。

目前的机制，在大多数情况下应该是正常的， 少量情况下会出现revision不一致，但是数据一致的情况， 这少量数据会三分钟清理后重新同步回来。总体上风险不是很大。

[lbq972149981]

目前看和并发应该没关系，只要有注册注销同步数据时，版本责任节点和非责任节点之间的 revision 就是不一致的，每次都是等着三分钟清理，重新构造最新revision 的 client

[skywalkerfy]

补充测试case：

客户端使用同一Client依次注册2个instance

naming.registerInstance("demo", "11.11.11.11", 8888); 
naming.registerInstance("demo2", "22.22.22.22", 9999);

从Nacos服务端查看日志
1、从责任节点查看 naming-distro.log，接受到非责任节点VERIFY失败后请求同步数据，持续时间3分钟。

2023-03-08 20:40:06,015 INFO Target 10.126.95.7:8848 verify client 1678279008118_10.252.154.201_53726 failed, sync new client
2023-03-08 20:40:06,015 INFO Target 10.126.95.4:8848 verify client 1678279008118_10.252.154.201_53726 failed, sync new client

2、非责任节点查看 naming-distro.log，显示VERIFY失败，持续时间 3 分钟。

2023-03-08 20:40:06,022 INFO [DISTRO-VERIFY-FAILED] ConnectionBasedClient[1678279008118_10.252.154.201_53726] revision local=0, remote=1
2023-03-08 20:40:06,022 INFO client 1678279008118_10.252.154.201_53726 is invalid, get new client from 10.126.95.5
2023-03-08 20:40:06,078 INFO [Client-Add] Received distro client sync data 1678279008118_10.252.154.201_53726, revision=1
2023-03-08 20:40:06,078 INFO [processBatchInstanceDistroData] BatchInstanceData is null , clientId is :1678279008118_10.252.154.201_53726

3、非责任节点VERIFY失败3分钟后，Client过期清空本地缓存instance列表，下一次SyncData发现本地Client为空，重新注册成功。日志如下

2023-03-08 20:40:16,146 INFO Client connection 1678279008118_10.252.154.201_53726 disconnect, remove instances and subscribers
2023-03-08 20:40:21,083 INFO Client connection 1678279008118_10.252.154.201_53726 connect
2023-03-08 20:40:21,083 INFO Client change for service Service{namespace='public', group='DEFAULT_GROUP', name='demo', ephemeral=true, revision=2}, 1678279008118_10.252.154.201_53726

总结：从测试过程中看，该现象和并发无关。只要Client对应的数据有变更，非责任节点在处理 ClientSyncData 数据时因未更新 reversion 必然会导致后续的 VERIFY 失败。3分钟后清空缓存数据后，再次同步才能恢复正常。如果有subscribers就会导致一次错误的推送

[skywalkerfy]

naming.subscribe("demo", new EventListener() {
    @Override
    public void onEvent(Event event) {
        NamingEvent namingEvent = (NamingEvent) event;
        LOGGER.info("Change: {} - {}", namingEvent.getServiceName(), namingEvent.getInstances());
    }
});

增加了一个订阅demo服务的进程，也同样发现收到一次instance被删除的变更后恢复正常

Change: demo - []
Change: demo - [Instance{instanceId='null', ip='11.11.11.11', port=8888, weight=1.0, healthy=true, enabled=true, ephemeral=true, clusterName='DEFAULT', serviceName='DEFAULT_GROUP@@demo', metadata={}}]

[KomachiSion]

并发有关系， 因为处理同步数据的地方没有做同一个client固定单线程处理的操作。可能会出现同一个client的2次同步同时在处理的情况，那可能出现revision是2，但是数据是1的情况。

[skywalkerfy]

我理解你说并发关系，是指直接修改 reversion 的方案，在并发修改的情况下可能出现你描述的数据和revision错乱的问题？
我指的和并发无关是当前只要责任节点负责的Client对应的 reversion 发生了变化，那非责任节点100%会出现3分钟 VERIFY 失败，清空缓存的问题。

[KomachiSion]

嗯，至少这样数据是对的，只是3分钟一致verify失败，会一直导致重复同步而已； 如果直接修改revision，导致了revision和数据不一致，从而导致数据无法再更新，数据一直不一致会更严重，所以要修复的话可能要稍微改一下同步数据的处理逻辑。

[KomachiSion]

我准备修复这个代码。 发现在#9214 中似乎已经对client的revision进行了设置。 但是在后续社区添加batch注册功能的时候， 这里重构出现了问题，把设置版本的逻辑移动到batch注册里了。

应该把位置调整一下就ok了。DistroClientDataProcessor#line211 --> DistroClientDataProcessor#189

[gavenpeng]

Describe the bug 客户端实例注册时，责任nacos节点需要将数据及版本信息同步给其他非责任nacos节点，但是目前发现非责任节点的版本未更新。

Expected behavior 当有责任节点的sync数据时，版本号应该即刻更新才对。

Desktop (please complete the following information):

• OS: [e.g. Centos]

Describe the bug 客户端实例注册时，责任nacos节点需要将数据及版本信息同步给其他非责任nacos节点，但是目前发现非责任节点的版本未更新。

Expected behavior 当有责任节点的sync数据时，版本号应该即刻更新才对。

Desktop (please complete the following information):

• OS: [e.g. Centos]
• Version nacos-server 2.2.0.1
• Module naming

Additional context 实际三分钟后由健康监测的线程清理了该clientId对应的缓存，当下一次同步数据重新创建client对应，并初始化了revision

Describe the bug 客户端实例注册时，责任nacos节点需要将数据及版本信息同步给其他非责任nacos节点，但是目前发现非责任节点的版本未更新。

Expected behavior 当有责任节点的sync数据时，版本号应该即刻更新才对。

Desktop (please complete the following information):

• OS: [e.g. Centos]
• Version nacos-server 2.2.0.1
• Module naming

Additional context 实际三分钟后由健康监测的线程清理了该clientId对应的缓存，当下一次同步数据重新创建client对应，并初始化了revision

我们在2.0.3 有同样的问题，

再次同步才能恢复

这个 verify 失败是因为 请求的clientid 在非责任节点找不到client，找不到client 是因为sync 的task 没有发上来，我这现象是这样的，也是等非责任节点把之前收到同步过来的client 超时后，责任节点才同步成功。最后verify 成功。

[gavenpeng]

还没有查到为啥，我是停了一台机器触发的，这个verify 成功依赖sync 成功。看代码verify 失败后，会创建一个add的distro同步任务，但就是没有同步的日志。

[bwangll]

这个问题预期是否有彻底修复的方案。

[XianYuDouFuBao]

这个问题在2.3.2中还会出现。三台搭建的集群部署模式下，还是会出现1到2台机器一直同步不成功的问题。