k8s下部署nacos2.1.0集群当某个节点nacos重启时,负载在此节点客户端会进行重连到别的节点 。这个可靠性操作很棒。但是有个疑问,就是当重启的节点正常时,据观察长连接依旧保持在之前切换的节点如果能够在集群中节点都正常时 重新负载均衡一下感觉就更棒了
请问有没有什么机制当集群由不健康的状态转为健康状态时 重新控制一下负载?
pcww981p1#
期待可以重新均衡,最好能支持权重,我这边压测时,遇到过 cpu 型号不一致的情况,即使申请云主机,也遇到过类似的情况(当然这是我们公司内部的事了)在 1.x,我自己改了代码去做了这样的均衡,期待 2.x 能支持。
tjjdgumg2#
关注一下。
drkbr07n3#
我看nacos源码ConnectionManager的COMMON_SERVER_EXECUTOR,会定时处理不活跃的长连接。同时会在连接数超过某个值的时候,给客户端发送重新连接的指令。这应该也是一种均衡机制吧,只是需要达到触发阈值。我看这个规则是默认不生效的。需要是从磁盘配置或者通过请求配置。
arknldoa4#
如果有重新连接的指令,只需要再开发一个运维的接口而已啦,我使用的 nacos 是魔改过的,主要是 1.x 的 hash 算法太糟糕。
3zwtqj6y5#
这个感觉是一种类似于限流的防护 真正的诉求是连接平衡,希望多个节点的负载能够保持一致
1tu0hz3e6#
确实,这种应该只是一种防护。
gwo2fgha7#
我在看 nacos官网文档 的时候发现了这么个图。
现在好像只有人工干预方案,官方的目标应该还是自动平衡。
yrdbyhpb8#
目前只有手动方案, 没有自动方案。
8条答案
按热度按时间pcww981p1#
期待可以重新均衡,最好能支持权重,我这边压测时,遇到过 cpu 型号不一致的情况,即使申请云主机,也遇到过类似的情况(当然这是我们公司内部的事了)在 1.x,我自己改了代码去做了这样的均衡,期待 2.x 能支持。
tjjdgumg2#
关注一下。
drkbr07n3#
我看nacos源码ConnectionManager的COMMON_SERVER_EXECUTOR,会定时处理不活跃的长连接。同时会在连接数超过某个值的时候,给客户端发送重新连接的指令。这应该也是一种均衡机制吧,只是需要达到触发阈值。我看这个规则是默认不生效的。需要是从磁盘配置或者通过请求配置。
arknldoa4#
我看nacos源码ConnectionManager的COMMON_SERVER_EXECUTOR,会定时处理不活跃的长连接。同时会在连接数超过某个值的时候,给客户端发送重新连接的指令。这应该也是一种均衡机制吧,只是需要达到触发阈值。我看这个规则是默认不生效的。需要是从磁盘配置或者通过请求配置。
如果有重新连接的指令,只需要再开发一个运维的接口而已啦,我使用的 nacos 是魔改过的,主要是 1.x 的 hash 算法太糟糕。
3zwtqj6y5#
我看nacos源码ConnectionManager的COMMON_SERVER_EXECUTOR,会定时处理不活跃的长连接。同时会在连接数超过某个值的时候,给客户端发送重新连接的指令。这应该也是一种均衡机制吧,只是需要达到触发阈值。我看这个规则是默认不生效的。需要是从磁盘配置或者通过请求配置。
这个感觉是一种类似于限流的防护 真正的诉求是连接平衡,希望多个节点的负载能够保持一致
1tu0hz3e6#
我看nacos源码ConnectionManager的COMMON_SERVER_EXECUTOR,会定时处理不活跃的长连接。同时会在连接数超过某个值的时候,给客户端发送重新连接的指令。这应该也是一种均衡机制吧,只是需要达到触发阈值。我看这个规则是默认不生效的。需要是从磁盘配置或者通过请求配置。
这个感觉是一种类似于限流的防护 真正的诉求是连接平衡,希望多个节点的负载能够保持一致
确实,这种应该只是一种防护。
gwo2fgha7#
我在看 nacos官网文档 的时候发现了这么个图。
现在好像只有人工干预方案,官方的目标应该还是自动平衡。
yrdbyhpb8#
目前只有手动方案, 没有自动方案。