三台服务器跑同一个服务请求来了给谁轮询。一人一个公平。这个答案对但只对了一小部分。负载均衡要回答的问题比怎么分多得多怎么知道谁忙谁闲某个节点挂了怎么办新加的节点怎么接流量会话状态怎么处理几种分法轮询Round Robin。1号请求给A2号给B3号给C4号回A。Nginx 的默认策略。简单不需要知道节点的状态。简单也是它的局限所有节点被当作一样的不管有的机器4核8G、有的8核32G不管有的满负荷了、有的还在空转。加权轮询。给每个节点一个权重权重大的多分。4核机器权重18核机器权重2。比纯轮询好一步但权重是静态配的。一台机器白天正常、晚上跑批处理权重该怎么定静态权重跟不上动态变化。最少连接Least Connections。把请求发给当前连接数最少的节点。Nginx 的least_conn指令。比轮询聪明了一步开始考虑节点的实时负载。但连接数少不代表最闲。一个节点连接少可能因为它处理慢每个请求占的时间长连接积不起来。一致性哈希Consistent Hashing。前三种分法适合无状态服务。有些场景需要同一个用户的请求落到同一个节点。比如缓存用户A的数据缓存在节点B上下次请求落到节点C缓存没命中又得去数据库取。一致性哈希把节点和请求 key 都映射到哈希环上顺时针找最近的节点。加节点时只影响相邻的一段不全量洗牌。Memcached 和 Redis Cluster 都用一致性哈希。Kafka 的 partition 分配也用了类似思路。有状态怎么办无状态服务请求打到哪个节点都一样。有状态服务不行。用户的购物车在节点A上请求落到节点BB看不到购物车。会话亲和Session Affinity。让同一个用户的请求落同一个节点。Nginx 的ip_hash按客户端 IP 哈希同一个 IP 落同一台。简单但 IP 变了手机切 WiFi、运营商换出口就失效。某个节点挂了粘在上面的用户全受影响。集中存储。会话不放在节点本地放 Redis 或数据库里。任何节点都能读。解决了亲和性问题多了一次网络 IO。Redis 挂了所有人掉线。无状态化。把状态从服务里挪出去服务本身不存会话信息。每次请求带完整上下文JWT 是典型做法。任何节点都能处理任何请求。代价是请求变大了每次都要传完整状态。实际系统里三种方式混着用。核心链路无状态化非核心用会话亲和缓存用一致性哈希。健康检查负载均衡器要知道哪些节点活着。不知道就把请求发给死节点用户看到超时。被动检查。不主动探测靠正常请求的结果判断。连续几次请求超时或报错标记为不可用。Nginx 的被动健康检查。好处是不增加额外流量。坏处是发现慢要等真实请求去撞前几个请求白白超时。主动检查。定期发探测请求不等真实请求。HTTP 健康检查端点/healthTCP 探活。发现快多了一份探测流量。探测间隔太短浪费资源太长发现晚了。两种方式一起用。主动检查负责快速发现故障被动检查负责实时感知服务质量下降。加节点和摘节点集群是动态的。加机器、下机器、机器挂了负载均衡器要及时感知。加节点新节点上线注册到负载均衡器。新节点可能还没 readyJVM 没预热、缓存没填满灌全量流量会拖慢响应。好的做法是先给小流量逐步加码。Nginx Plus 的 slow start、Kubernetes 的 readiness probe 都在做这件事。摘节点节点要下线先从负载均衡器摘掉等存量请求处理完再关。kill 掉的话存量请求中断用户看到错误。Kubernetes 的 preStop hook 和 graceful shutdown 配合给应用一个先摘流量、等请求跑完、再退出的窗口。窗口期的长短是个问题。长连接WebSocket、gRPC stream可能撑很久。等部署时间拉长。不等长连接被强切。具体多久看连接类型和业务容忍度。反面案例均衡了但没均匀某系统三台应用服务器Nginx 轮询。流量看着分得均匀每台 QPS 差不多。其中一台 CPU 经常飙到 90%另外两台只有 40%。轮询分的是请求数量不是请求开销。三台机器各分到 1000 QPS但其中一台接到的请求里有大量复杂查询商品详情页带多表关联另外两台接到的多是简单查询静态页。请求数量均匀了工作量没均匀。换成最少连接策略后CPU 利用率拉平了一些没根治。连接数只是负载的一个维度CPU 密集型和 IO 密集型的请求连接数一样消耗差几倍。最终做法在应用层把请求按类型分类重请求和轻请求分到不同的 upstream pool。Nginx 层做粗粒度分流应用层做细粒度调度。负载均衡不是一个层能搞定的事。和熔断的配合负载均衡器知道哪些节点健康熔断器知道哪些服务在报错。两个信息源不总是一致。一个节点没挂健康检查通过但它的下游数据库慢了。请求发到这个节点节点等数据库超时返回错误。负载均衡器看到节点活着继续发请求。熔断器看到失败率升高触发熔断。负载均衡器管节点在不在熔断器管服务好不好。在不代表好。熔断打开时即使节点健康检查通过请求也不该发过去。小结负载均衡分请求听起来像切蛋糕一人一份。实际要处理的维度远多于怎么分节点能力不同要加权实时负载不同要动态选有状态要保亲和缓存要一致性哈希节点上下线要平滑过渡健康检查要主动加被动还得和熔断配合。选什么策略看服务有没有状态、节点是否同质、对故障发现的实时性要求多高。多层配合比单层完美更靠谱。
