search

sofastack / sofa-registry

SOFARegistry is a production-level, low-latency, high-availability service registry powered by Ant Financial.
https://www.sofastack.tech/sofa-registry/docs/Home
Apache License 2.0
652 stars 247 forks source link

SOFARegistry client connection load balancing problem #91

Open HuangSheng opened 4 years ago

HuangSheng commented 4 years ago

Your question

我想问个SOFARegistry连接的问题，registry的客户端应该是与服务端的session服务建立长连接，但是如果session服务集群中某台机器挂了，那么客户端的连接会漂到其它正常的机器上，如果这时这台挂掉的session服务又好了，这时如果客户端没有重启，是不是这台挂掉重启的机器就没有连接了？我看代码好像只有在连接不可用时客户端才会做重连 image

Your scenes

SOFARegistry集群部署，session节点由于突发事件导致挂掉或session升级版本重启服务

Your advice

客户度是否应该在挂掉的session节点重启后自动重新做一次负载策略，使session集群整体连接是均衡的

Environment

sofastack-bot[bot] commented 4 years ago

Hi @HuangSheng, we detect non-English characters in the issue. This comment is an auto translation by @sofastack-robot to help other users to understand this issue.

We encourage you to describe your issue in English which is more friendly to other users.

Your question I would like to ask a question about the SOFARegistry connection. The registry client should establish a long-term connection with the server's session service, but if a machine in the session service cluster hangs up, the client's connection will drift to other normal On this machine, if the suspended session service is fine again at this time, if the client is not restarted at this time, is it that the suspended machine is not connected? I think the code seems that the client will reconnect only when the connection is not available! [Image] (https://user-images.githubusercontent.com/2976373/74824632-6c1d5f80-5343-11ea-9a5d-02898e5749d9.png) # ## Your scenes SOFARegistry cluster deployment, the session node hangs due to an emergency or the session upgrade version restarts the service ### Your advice Whether the client should automatically reload the load policy after the restart of the suspended session node to make the session cluster The overall connection is balanced ### Environment-SOFARegistry version:-JVM version (eg java -version):-OS version (eguname -a):-Maven version:-IDE version:

atellwu commented 4 years ago

如果这时这台挂掉的session服务又好了，这时如果客户端没有重启，是不是这台挂掉重启的机器就没有连接了？

是的，的确是这样，目前client只有在断链后才有机会尝试重新连新sessionServer

HuangSheng commented 4 years ago

如果这时这台挂掉的session服务又好了，这时如果客户端没有重启，是不是这台挂掉重启的机器就没有连接了？

是的，的确是这样，目前client只有在断链后才有机会尝试重新连新sessionServer

那这样的话如果session服务需要升级版本，就一定会出现升级完成后的最后一台重启的session服务上没有client，而其他session服务上连接非常多的情况。这种策略我感觉不是很OK，因为线上我们会保证单台session机器的资源利用率在50%左右，但是因为session升级版本而导致线上某几台session机器的资源利用率飙升并且无法在升级完成后回归均衡。这块儿是否可以作为优化点优化一下呢？

straybirdzls commented 4 years ago

@HuangSheng 的确是非常好的建议，在实际环境中可能也会遇到类似的问题，我们也在考虑尝试做一些优化，比如在服务端做一些保护的阈值，但这个也只是防止出现机器无法承载的情况，如果想要完全回归到均衡的状态，这个就必须有协商机制了。不知道你这里是否有什么建议？另外你们是在实际场景中遇到这个问题了吗？

HuangSheng commented 4 years ago

@HuangSheng 的确是非常好的建议，在实际环境中可能也会遇到类似的问题，我们也在考虑尝试做一些优化，比如在服务端做一些保护的阈值，但这个也只是防止出现机器无法承载的情况，如果想要完全回归到均衡的状态，这个就必须有协商机制了。不知道你这里是否有什么建议？另外你们是在实际场景中遇到这个问题了吗？

client端我看到有一个线程是异步读取session地址列表的，可以考虑在读取后判断与当前服务存储的列表是否相同，不相同则触发一次重连。重连的时候可以加一个随机等待时间，防止所有客户端同一时间全部重连服务端而造成的压力。 image 这个问题是我在实际场景中遇到了，因为我在测试环境会经常重启session服务，结果发现我们的session服务连接严重不均衡，后来查看源码发现的这个问题

atellwu commented 4 years ago

「可以考虑在读取后判断与当前服务存储的列表是否相同，不相同则触发一次重连」

因为SOFARegistry的数据是和连接绑定的，如果这么做的话，在生产环境，代价会很高，相当于全站的数据都销毁又重新pub上来。

HuangSheng commented 4 years ago

「可以考虑在读取后判断与当前服务存储的列表是否相同，不相同则触发一次重连」

因为SOFARegistry的数据是和连接绑定的，如果这么做的话，在生产环境，代价会很高，相当于全站的数据都销毁又重新pub上来。

我没太细看数据存储和连接这块儿的代码。

所以如果session服务重启的话，理论上SOFARegistry的数据也会重洗一遍是吗？

如果是这样的话，用我的方法，等于全站数据重洗了两遍？不知道我这样理解是否正确？

atellwu commented 4 years ago

「所以如果session服务重启的话，理论上SOFARegistry的数据也会重洗一遍是吗？」 是的。