HuangSheng

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

> @HuangSheng 的确是非常好的建议，在实际环境中可能也会遇到类似的问题，我们也在考虑尝试做一些优化，比如在服务端做一些保护的阈值，但这个也只是防止出现机器无法承载的情况，如果想要完全回归到均衡的状态，这个就必须有协商机制了。不知道你这里是否有什么建议？另外你们是在实际场景中遇到这个问题了吗？ client端我看到有一个线程是异步读取session地址列表的，可以考虑在读取后判断与当前服务存储的列表是否相同，不相同则触发一次重连。重连的时候可以加一个随机等待时间，防止所有客户端同一时间全部重连服务端而造成的压力。  这个问题是我在实际场景中遇到了，因为我在测试环境会经常重启session服务，结果发现我们的session服务连接严重不均衡，后来查看源码发现的这个问题

> 「可以考虑在读取后判断与当前服务存储的列表是否相同，不相同则触发一次重连」 > > 因为SOFARegistry的数据是和连接绑定的，如果这么做的话，在生产环境，代价会很高，相当于全站的数据都销毁又重新pub上来。 我没太细看数据存储和连接这块儿的代码。 所以如果session服务重启的话，理论上SOFARegistry的数据也会重洗一遍是吗？ 如果是这样的话，用我的方法，等于全站数据重洗了两遍？不知道我这样理解是否正确？

* 公司/组织名称：北京盈衍网络科技有限公司 * 地点：中国北京 * 网址：https://www.g-banker.com * 使用组件及场景：SOFABoot、SOFARpc、SOFARegistry、SOFALookout * 联系方式：[email protected]