长连贯介绍
说长连贯，与之对应的是短连贯，对于这两个的介绍网上比拟多，这里只用一个表格来总结下他们的工作流程、优缺点、实用场景等：
长连贯负载平衡
长连贯为什么须要负载平衡
长连贯单机的连接数是存在下限的。
存在下限的起因，可能有同学认为是单机的端口数限度，也就是常常听到的问题「一台服务器最多能撑持多少个 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，运气好的话，其余节点都不必计算。
结语
本文介绍了长连贯与短连贯的特点，为什么须要做长连贯负载平衡，以及几个长连贯负载平衡的问题和解法，相对来说还是比拟通俗易懂，心愿对大家有所帮忙。