大家好，感谢邀请，今天来为大家分享一下浅谈长连接负载均衡-springcloud 负载均衡的问题，以及和的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！
短连接
长连接
过程
建立连接——传输数据——关闭连接
建立连接-传输数据-传输数据-.-关闭连接
优势
实施简单
耗时更少（DNS解析、TCP握手、挥手）；可以实现服务器推送
缺点
耗时（DNS解析、TCP握手、挥手）
需要管理连接，实现起来比较复杂；当连接很多时，服务器消耗很大。
场景
单个客户端操作频率不高，但客户端较多；例如网络服务
单个客户端频繁操作；例如需要推送能力的数据库和服务
长连接负载均衡
长连接为什么需要负载均衡长连接的单机连接数有上限。
之所以有上限，可能有同学认为是单机端口数的限制，也就是经常听到的问题“一台服务器最多可以支持多少个TCP连接？”
有人回答“65535”，但事实并非如此。如果不考虑硬件限制，单机可以支持超过200万亿个TCP连接，但这太理想了。事实上，支持百万连接还是有可能的。
从经验来看，CPU和内存是限制连接数的主要原因。
内存就不用说了，每个连接都会占用一点内存。空连接也会占用几KB 的内存。如果添加一些数据，通常有几百KB到几MB。一个连接为1MB。计算一下，一台128GB内存的物理机可以支持几十万个连接。
其次是CPU。上面我们提到，长连接场景一般会涉及到单个客户端的频繁操作，这会导致每增加一个连接，CPU消耗就会增加。一般单机能支持10万个连接就已经足够了。
基于单机性能和高可用容灾的考虑，生产环境中的长连服务通常会部署多个节点。为此，我们需要考虑长连接服务的负载均衡问题。
长连接负载均衡粒度
与短连接中每个请求的负载均衡策略不同，长连接不仅有请求粒度的负载均衡，还有连接粒度的负载均衡。
请求粒度负载均衡是通过客户端与各个服务器建立连接，在发送请求时，按照一定的负载均衡策略选择一台服务器发出请求；连接粒度负载均衡是当客户端建立连接时按照一定的负载均衡策略选择一个节点建立连接，后续的请求都发送到这个节点。
如何选择主要取决于单台服务器可能的连接数。如果连接数远未达到瓶颈（个人认为小于10000），可以考虑请求粒度。否则，连接粒度负载均衡策略更好。
例如，Dubbo 中的Provider 节点已与订阅Consumer 的所有节点建立了连接。前提是Dubbo中的一个Provider基本不可能被上万个节点消耗掉，所以Dubbo可以在请求粒度上进行长连接负载均衡。但如果是Nacos，所有需要服务发现的机器都必须与Nacos服务器建立连接。长连接的数量与公司服务器的数量级有关。大规模的情况下，几万、几十万、几百万也是可能的，所以Nacos如果像Dubbo那样设计的话，就无法支持大规模的服务发现。
连接粒度的负载均衡
对于长连接，在连接粒度上遇到的负载均衡问题较多，所以这里重点关注。
连接数均衡由于连接建立后，除非出现异常，否则不会断开，所以问题就出现了。如果某个节点的连接数量远多于其他节点的连接数量，这就是不平衡。出现此问题最常见的情况是服务器端发布（重启）。如果重启时服务不可用，则节点原有的连接将被断开。找到一个幸存的节点进行连接。当服务启动时，它的连接数量会非常少。如果是一轮发布，最先发布的机器最后连接数最多，最后发布的机器连接数最少。
这种情况下，我们可以将连接建立的负载均衡算法调整为最小连接数模式。当服务重启完成后，后续的所有连接都可以连接到该节点。
但这种方法并不总是有效，因为当服务重新启动时，断开的连接已经与其他节点建立起来了。
这时候我们可能需要额外的平衡方法，比如定期从全局角度检查每个节点的连接数是否平衡。如果不平衡，则必须断开连接最多的节点，直至平衡。
这里我们的客户端需要特别注意断线的处理，当然我认为这是必要的。
但也要注意的是，如果长时间不保持连接，可能不需要额外的平衡方法，过一段时间自然会平衡。什么情况下会出现这种情况？例如，在公网长期连接，客户端的网络条件不如内网，经常会出现连接断开的情况。这相当于自动为我们平滑了连接。
如果是内网服务，并且可以一直保持连接，就需要额外的平衡措施。
服务器规格不同为了在单机上维持更多的长连接，我们通常使用物理机来部署服务。有时每台物理机的规格并不统一。如果我们的平衡方法对所有人一视同仁，那么每个节点的连接数就会差不多，规格不好的服务器可能会比其他机器承受的压力更大。
因此，建立连接的负载均衡算法和附加均衡方法也必须考虑服务器规格。您可以简单地将服务器规格和当前连接数抽象为一个权重，然后在客户端建立连接时进行权重选择。
扩容无效问题我们的长连接服务应该是可以水平扩展的。随着连接数量的增加，只需添加更多机器即可。我们的大多数设计也是如此。
但有时可能一不小心，导致横向扩展效果不佳。
我们以注册中心为例。假设有一个注册中心集群，有3个节点。此时，有10,000 个客户端已连接并订阅各种服务。由于客户端数量远大于注册中心节点，基本上可以认为各个注册中心节点订阅的服务是相似的。大约每次服务变更都必须由每个注册中心节点来处理，这自然会消耗更多的CPU。如果注册中心节点扩展到5个，每个服务实际上只会丢失几个连接，但每个注册中心节点仍然要处理几乎所有的服务变更。
这种情况下，就需要考察长连接服务的设计是否合理。一般采用分层的思路。长连接层服务只关注推送，一般称为通道层或会话层。它没有复杂的计算逻辑。
如果设计有问题，短时间内无法修改，可以尝试根据服务订阅者的名称路由到特定的服务器节点，以保证同一个消费者只连接到一个注册中心节点。这样，当某个服务发生变化时，节点只需要计算一次，然后推送给所有消费者。如果幸运的话，其他节点将不需要计算它。
结语
如果你还想了解更多这方面的信息，记得收藏关注本站。
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/7509.html
用户评论
听说现在很多平台都在用长连接了，这篇文章讲得挺中肯。
有6位网友表示赞同！
我一直对Spring Cloud不熟悉，看这个标题像是入门指南的样子。
有9位网友表示赞同！
负载均衡这种东西在大型系统的搭建真是超级重要啊！
有18位网友表示赞同！
感觉文章能帮我理解一下长连接和负载均衡的结合方式，太棒了!
有9位网友表示赞同！
最近在研究微服务架构，要了解一下这些技术的应用场景。
有17位网友表示赞同！
这个标题看起来很专业，我得好好看看这篇分析的文章才行。
有15位网友表示赞同！
对Spring Cloud技术感兴趣的朋友，这篇文章一定很有帮助。
有14位网友表示赞同！
"浅谈"就说明文章不会很深奥，适合初学者阅读哈！
有17位网友表示赞同！
长连接负载均衡这种黑科技我还没涉及过，希望能从这篇文章里学到东西。
有10位网友表示赞同！
对软件工程感兴趣的同学可以收藏这篇博客文吧!
有9位网友表示赞同！
感觉这个标题很有特色，能让我快速了解文章内容的关键点。
有15位网友表示赞同！
希望作者能用通俗易懂的语言讲解技术细节，方便我们理解。
有8位网友表示赞同！
负载均衡问题困扰了我好久了，看这篇文章也许能得到答案！
有16位网友表示赞同！
学习新技术的路上，这样的文章都是很好的参考来源。
有7位网友表示赞同！
期待作者能够分享更多关于Spring Cloud的宝贵经验！
有17位网友表示赞同！
文章可能涉及到一些高级运维知识点，很有价值!
有17位网友表示赞同！
这个标题让我对长连接负载均衡这种技术产生了好奇心。
有13位网友表示赞同！
这篇文章可以帮助我更好地理解长连接的使用场景和优势。
有5位网友表示赞同！
Spring Cloud 的技术栈越来越强大，看来还是需要持续学习了！
有14位网友表示赞同！
想要打造一个高效稳定系统，负载均衡是关键环节吧！
有5位网友表示赞同！