面试官:聊聊长连接下的负载均衡

长连接介绍

说长连接,与之对应的是短连接,关于这两个的介绍网上比较多,这里只用一个表格来总结下他们的工作流程、优缺点、适用场景等:

长连接负载均衡

长连接为什么需要负载均衡

长连接单机的连接数是存在上限的。

存在上限的原因,可能有同学认为是单机的端口数限制,也就是经常听到的问题「一台服务器最多能支撑多少个 TCP 连接?」

有人回答「65535」,其实不然,如果硬件限制不考虑,单机能撑200多万亿个 TCP 连接,但这太理想,现实是撑个百万连接还是可以的。

从经验来看,CPU 和 内存是限制连接数的主要原因。

内存不必多说,每个连接的保持都要占用一点内存,一条空连接,也要占用几 KB 的内存,如果再塞点数据,几百 KB 到几 MB 也是常有的事,按一条连接 1MB 算,一台 128GB 内存的物理机能撑十几万的连接。

其次是 CPU,我们上面说了长连接的场景一般是单个客户端操作频繁,这就会导致每增加一条连接,CPU 消耗就增加一些,一般单机能撑十万的连接,已经算是可以了。

基于单机性能和高可用容灾的考虑,生产环境长连接服务通常会部署多个节点,为此,我们需要考虑长连接服务的负载均衡问题。

长连接负载均衡粒度

与短连接每次请求都做负载均衡策略不同,长连接不光有请求粒度的负载均衡,还有连接粒度的负载均衡。

请求粒度负载均衡的实现方式是一个客户端与每个服务端都建立连接,发送请求时按照某种负载均衡策略选择一个服务端进行请求;连接粒度的负载均衡则是客户端在建立连接时按照某种负载均衡策略挑选一个节点进行建连,后续请求都发往这个节点。

如何选择主要是考量单个服务端可能的连接数量,如果连接数远不是瓶颈的时候(个人认为万级以下),可考虑请求粒度,否则连接粒度的负载均衡策略更佳。

举个例子,Dubbo 一个 Provider 节点和来自订阅 Consumer 的所有节点都建立了连接,前提是 Dubbo 一个 Provider 基本不太会可能被几万个节点消费,所以 Dubbo 可以做请求粒度的长连接负载均衡。但如果是 Nacos,所有需要服务发现的机器都要和 Nacos 服务端建立连接,长连接数量就和公司服务器数量级相关,规模大的情况,几万、上十万、百万也是有可能的,所以如果 Nacos 也像 Dubbo 那样设计,就无法支撑大规模服务发现了。

连接粒度的负载均衡

对于长连接,连接粒度的负载均衡问题遇到得更多,所以这里着重说明下。

连接数均衡

由于连接建立之后,除非异常不会断开,所以问题就来了,如果某一个节点的连接数相比较其他节点要多出很多,这种就属于不均衡了。出现这种问题的情况最常见的就是服务端发布(重启)。重启时服务不可用,该节点原先的连接会断开,找到存活的节点进行连接,当这台服务起来时,它的连接数将非常少。如果是一轮发布,最先发布的机器最后连接数最多,最后发布的连接数最少。

这种情况下,我们可以调整建连的负载均衡算法为最小连接数模式,当服务重启完成后,后续的连接就能全部连接到此节点。

但这个方法并不总是奏效,因为服务在重启时,断开的连接已经和其他节点建立了连接。

这时我们可能需要额外的均衡手段,如定时从全局视角看各个节点的连接数是否均衡,如果不均衡则要断开最多连接的节点,直到平衡。

这里我们的客户端需要对连接的断开处理特别小心,当然我觉得这是必须的。

但也要说明一点,如果连接不是长时间保持的,额外的均衡手段可能就不需要了,等一会就自然平衡了。这种发生在什么情况呢?比如公网的长连接,客户端的网络情况没内网那么好,经常断开连接,这就相当于帮我们自动平滑连接了。

如果是内网服务,连接能一直保持,额外的平衡手段就显得有必要了。

服务器规格不同

我们通常为了单机能保持更多的长连接,一般会选用物理机部署服务,有时候各个物理机规格不统一,如果我们的均衡手段一视同仁,每个节点连接数差不多,规格差的服务器可能压力就比其他机器大。

所以建连的负载均衡算法和额外的均衡手段也要考虑服务器规格,可以简单地把服务器规格与当前的连接数抽象为一个权重,客户端建连时加权再选择。

扩容无效问题

我们的长连接服务理应是可水平扩容的,连接数变多,加机器就可以,我们的设计大多也是如此。

但有时候可能不小心,导致水平扩容无效。

举个例子,还是注册中心,假设有3个节点的注册中心集群,此时有 1w 个客户端连上来,订阅了各种各样的服务,由于客户端的数量远远大于注册中心节点,所以基本可以认为每个注册中心节点订阅的服务是差不多的,近似每个服务的变更,每个注册中心节点都要处理,CPU 消耗自然就多了。如果把注册中心节点扩容为5台,其实每台服务只是少了一点连接,但依然每个注册中心节点还是近乎要处理所有的服务变更。

这种情况下就要审视长连接服务设计的是否合理,一般采取分层的思想,长连接这层服务只专注推送,一般称为通道层或者 session 层,它并不复杂复杂的计算逻辑。

如果设计有问题,短时间又没法修改,可以试试按照服务订阅者的名字路由到特定的服务端节点,保证同一个 Conusmer 只连同一个注册中心节点,这样某服务变更时,该节点只需要计算一次,就可以推送给所有 Conusmer,运气好的话,其他节点都不用计算。

结语

本文介绍了长连接与短连接的特点,为什么需要做长连接负载均衡,以及几个长连接负载均衡的问题和解法,相对来说还是比较通俗易懂,希望对大家有所帮助。

140 声望
34 粉丝
0 条评论
推荐阅读
架构杂谈——互联网系统架构演进
说到互联网系统架构,在互联网行业日渐成熟的今天,一谈到这背后的技术体系,很多人脑海中可能就会浮现从网上看到的,一个个庞大的知识图谱,能说地清楚其中一二的同学,自然是志得意满,而对于新入行的同学来说...

Java架构师阅读 92

从零搭建 Node.js 企业级 Web 服务器(十五):总结与展望
总结截止到本章 “从零搭建 Node.js 企业级 Web 服务器” 主题共计 16 章内容就更新完毕了,回顾第零章曾写道:搭建一个 Node.js 企业级 Web 服务器并非难事,只是必须做好几个关键事项这几件必须做好的关键事项就...

乌柏木66阅读 6.1k评论 16

从零搭建 Node.js 企业级 Web 服务器(一):接口与分层
分层规范从本章起,正式进入企业级 Web 服务器核心内容。通常,一块完整的业务逻辑是由视图层、控制层、服务层、模型层共同定义与实现的,如下图:从上至下,抽象层次逐渐加深。从下至上,业务细节逐渐清晰。视图...

乌柏木43阅读 7.3k评论 6

从零搭建 Node.js 企业级 Web 服务器(二):校验
校验就是对输入条件的约束,避免无效的输入引起异常。Web 系统的用户输入主要为编辑与提交各类表单,一方面校验要做在编辑表单字段与提交的时候,另一方面接收表单的接口也要做足校验行为,通过前后端共同控制输...

乌柏木33阅读 6.2k评论 9

从零搭建 Node.js 企业级 Web 服务器(五):数据库访问
回顾 从零搭建 Node.js 企业级 Web 服务器(一):接口与分层,一块完整的业务逻辑是由视图层、控制层、服务层、模型层共同定义与实现的,控制层与服务层实现了业务处理过程,模型层定义了业务实体并以 对象-关系...

乌柏木34阅读 4.6k评论 9

从零搭建 Node.js 企业级 Web 服务器(十三):断点调试与性能分析
Node.js 官方提供了断点调试机制,出于安全性考虑默认为关闭状态,可以通过 node 参数 --inspect 或 --inspect-brk 开启,配合 IDE 能够非常方便地调试代码,本章就上一章已完成的项目 licg9999/nodejs-server-ex...

乌柏木31阅读 3.9k评论 9

从零搭建 Node.js 企业级 Web 服务器(八):网络安全
计算机网络依据 TCP/IP 协议栈分为了物理层、网络层、传输层、应用层,通常基础设施供应商会解决好前三层的网络安全问题,需要开发者自行解决应用层的网络安全问题,本章将着重表述应用层常见的网络安全问题及处...

乌柏木33阅读 5.8k评论 1

140 声望
34 粉丝
宣传栏