7
在nacos server集群模式下，客户端通过getServicesOfServer分页功能查询所有服务列表，当连续的分页请求命中到不同的集群节点时，由于每个集群节点在内存中的服务列表顺序不完全一样，在分页的边界处可能会出现丢失服务的情况。对于分布式系统的内存分页功能是否应该设计为保持各节点的列表顺序严格一致？
Q
[alibaba/nacos]NamingService.getServicesOfServer分页情况下返回服务列表不完整
A
回答
3
版本2.0.1，最新版本也存在同样的问题，ServiceOperatorV2Impl文件中 1、listService方法
2、在集群模式下，不同节点的selectServiceWithGroupName方法中使用hashset去重时可能会出现顺序不完全一致
7
在集群模式下出现同一个时刻节点的上Server的数据上不一致，在所难免，因为Distro是最终一致性，但是我们可以尽可能的保证数据的一致性，我觉得有两种方式：
将com.alibaba.nacos.naming.core.v2.ServiceManager里面的ConcurrentHashMap改为ConcurrentSkipListMap，定义一个默认排序的规则，保证数据的顺序 com.alibaba.nacos.naming.utils.ServiceUtil#pageServiceName进行默认的排序方式保证它的有序性
6
我能为该问题提一个PR嘛？
5
在集群模式下出现同一个时刻节点的上Server的数据上不一致，在所难免，因为Distro是最终一致性，但是我们可以尽可能的保证数据的一致性，我觉得有两种方式：
将com.alibaba.nacos.naming.core.v2.ServiceManager里面的ConcurrentHashMap改为ConcurrentSkipListMap，定义一个默认排序的规则，保证数据的顺序 com.alibaba.nacos.naming.utils.ServiceUtil#pageServiceName进行默认的排序方式保证它的有序性getServicesOfServer是分页接口形式，最后返回的结果也没有保障最终一致性，而这个问题又比较容易解决，就像您刚才提到的一样，希望官方能修复一下
1
我能为该问题提一个PR嘛？
期待：）
1
看大佬认为有没有必要，如果我的方式可行，我将会提一个PR啦。
3
我记得以前就提过，应该有类似的issue， 可以搜索一下。
我提过解决方案， 如果有必要的话， 在返回结果的地方做排序，而不是在插入时做排序。
0
只是我认为这个没有必要，因为大多数情况检索不会大规模一页页看，多数情况下是有精确服务名，或者是范围比较精确的模糊检索， 实际上过滤后剩余的服务名并不多。
1
@iGavinTian 老哥，你们sdk用分页去查是什么场景哇。
1
我记得以前就提过，应该有类似的issue， 可以搜索一下。
我提过解决方案， 如果有必要的话， 在返回结果的地方做排序，而不是在插入时做排序。
主要是困惑于这个分页接口返回的数据不全，在分页的边界存在丢失的情况，示意图如下 在已知这个问题的情况下，解决方案倒是有很多，比如： 1、请求集群节点时，保证分页请求落在同一个集群节点 2、后面的分页结果如果和前面的有重合时，再去补一次请求 3、用一个超大的分页规避问题
9
@iGavinTian 老哥，你们sdk用分页去查是什么场景哇。
我们有个定时拉取所有服务名，然后本地判断某个服务是否存在的情况
3
只是我认为这个没有必要，因为大多数情况检索不会大规模一页页看，多数情况下是有精确服务名，或者是范围比较精确的模糊检索， 实际上过滤后剩余的服务名并不多。
如果用这个接口，就很容易掉进坑里， spring-cloud-starter-alibaba-nacos-discovery是用一个超大的分页规避的
3
我记得以前就提过，应该有类似的issue， 可以搜索一下。
我提过解决方案， 如果有必要的话， 在返回结果的地方做排序，而不是在插入时做排序。
我之前也用getServicesOfServer搜索，并没有找到相关issue:(
5
2.0客户端不会有图中的问题， 因为是长连接是同一个节点。自然解决