用户问题 ：

大佬我想请教下，我们的4个应用服务和nacos服务分别部署在三台服务器上并且都使用docker部署，也就是应用服务和nacos server 都是三个节点，在做高可用测试的时候，模拟服务器断电后重启的情况，我们reboot其中一台A服务器，并且停掉C服务器上的nacos server节点，这时候应该只有B服务器上的nacos 节点是UP的状态，A服务器的nacos状态应该是先从UP变成SUSPICOUS 再变成 DOWN ,最后恢复成UP , 但是我们A服务器上的业务应用在开机自启动的时候，有出现服务注册不了的情况，按道理这时候A服务器上的业务应用的责任节点应该都重新分配到B的nacos节点上了才对，但是看nacos server的日志报了一个receive invalid redirect request from peer {ip} ,这种看源码应该是两个nacos节点计算责任节点出现不一致导致的，但是这里我一直搞不明白为什么会出现这种不一致？

---

专家官方解答 ：

根据您的描述，这个问题可能涉及Nacos集群的高可用机制与Docker容器重启后的服务注册逻辑。尽管提供的知识内容没有直接覆盖到您遇到的特定错误信息，我们可以结合Nacos的工作原理和您描述的现象进行分析。

原因分析：

1. Nacos节点状态转换异常：A服务器上的Nacos节点状态从UP到SUSPICOUS再到DOWN，理论上在恢复后应能回到UP状态，但这一过程中的异常可能与Nacos集群内部的健康检查机制或网络状况有关。特别是如果网络恢复不够稳定，可能导致节点状态判断出现问题。

2. 服务注册失败：开机自启动的应用服务注册失败，可能是因为在Nacos集群未完全稳定时（即所有节点状态未正确恢复为UP），应用服务尝试注册。此时，Nacos集群内部可能还在调整或有节点处于不一致状态，导致服务注册请求被错误处理或重定向到不可用节点。

3. 责任节点计算不一致：receive invalid redirect request from peer {ip}错误表明Nacos集群中不同节点对服务实例应当归属的“责任节点”计算出现了分歧。这可能是由于网络分区、节点状态更新延迟、或是Nacos配置不一致等原因造成。

解决思路：

虽然没有直接的步骤建议，但基于上述分析，您可以尝试以下策略来解决问题：

1. 确保网络稳定性：在进行高可用测试前，验证所有服务器间的网络通信稳定且无丢包现象，确保重启操作不会引起长时间的网络中断。

2. 优化Nacos配置：检查Nacos集群的配置，确保所有节点的配置文件一致性，包括但不限于集群配置、选举策略、健康检查间隔等，以减少节点状态判断的误差。

3. 服务注册重试机制：在应用服务的Nacos客户端配置中增加服务注册的重试次数与重试间隔，确保在Nacos集群不稳定时，服务注册请求能够有足够的机会在集群恢复后成功执行。

4. 检查与修复集群状态：利用Nacos提供的集群管理工具或API，检查集群内各节点的状态及数据一致性，必要时手动干预，比如清除不一致的元数据信息，确保所有节点对服务实例的分配达成共识。

5. 升级Nacos版本：如果当前使用的Nacos版本存在已知的类似问题，考虑升级到更稳定的版本，以利用官方修复的bug和改进的高可用机制。

6. 日志深入分析：详细查看A服务器Nacos节点及应用服务的启动日志，结合错误信息receive invalid redirect request出现的具体上下文，进一步定位问题所在。如果有必要，对比正常情况下的日志，寻找差异点。

结论：

虽然直接的步骤可能需要根据实际情况调整，上述分析和建议方向应能帮助您排查和解决服务注册失败的问题。如果问题依然存在，建议深入研究Nacos的源代码逻辑，特别是关于服务注册、集群管理和健康检查的部分，以获得更深层次的理解和解决方案。

---------------

参考链接 ：

• 专家经验：Nacos中持久化服务和临时服务的区别

• 专家经验：服务提供者已关闭，但是还在被其他应用调用

• 专家经验：实际服务正常再跑 注册中心上没了怎么回事?

---------------

答疑服务说明：

本内容经由技术专家审阅的用户问答的镜像生成，我们提供了专家智能答疑服务,使用方法： 用法1： 在页面的右下的浮窗”专家答疑“。 用法2： 点击专家答疑页（针对部分网站不支持插件嵌入的情况）

另：

有其他开源产品的使用问题？点击访问阿里AI专家答疑服务。

反馈

如问答有错漏，欢迎点：差评给我们反馈。