集群|计算机基础篇
# 一、负载均衡
30 秒速记
- 负载均衡位于用户请求与应用节点之间，核心职责是选择目标节点并完成请求转发。
- 应用节点通常按无状态方式设计，使同一用户的请求能够交给任意可用节点处理。
- 节点选择依赖负载均衡算法及各节点的负载情况；选择结果决定请求落到哪台服务器。
- 高可用来自故障转移：某个节点不可用时，请求可以转发给其他节点，避免单节点故障中断全部服务。
- 伸缩性来自节点池可调整：系统负载变化时，可以增加或移除应用节点。
- 负载均衡器承担统一入口和转发职责；原文未展开其自身故障处理方式，因此不能据此认定整个入口天然无单点风险。
负载均衡就是在请求进入集群后选择合适的应用节点，并把请求转发过去。 应用节点通常按无状态方式设计，因此同一用户的请求可以落到任意健康节点；会话状态可由客户端携带，或放在共享存储中。节点故障时可摘除并转发到其他节点，负载变化时也能通过增减节点实现伸缩。算法可按轮询、权重或连接情况选节点，但负载均衡器本身仍可能成为瓶颈或单点，需要另行设计冗余与故障转移。
集群中的应用服务器（节点）通常被设计成无状态，用户可以请求任何一个节点。
负载均衡器会根据集群中每个节点的负载情况，将用户请求转发到合适的节点上。
负载均衡器可以用来实现高可用以及伸缩性：
- 高可用：当某个节点故障时，负载均衡器会将用户请求转发到另外的节点上，从而保证所有服务持续可用；
- 伸缩性：根据系统整体负载情况，可以很容易地添加或移除节点。
负载均衡器运行过程包含两个部分：
- 根据负载均衡算法得到转发的节点；
- 进行转发。
# 负载均衡算法
原理拆解： 请求先到达负载均衡器，负载均衡算法从当前可用节点集合中选出目标，再由转发层把请求送到该节点。无状态并不是“服务器没有任何数据”，而是处理一次请求所需的会话状态不独占在某台应用节点上；状态可由客户端携带，或存入共享数据库、缓存等外部系统。这样同一用户的后续请求才能安全落到其他健康节点。
具体实现： 轮询适合处理能力接近、请求成本相近的节点；加权轮询可让配置更高的节点承担更多流量；最少连接更关注当前并发占用。负载均衡器通常结合健康检查维护可选节点集合：节点连续探测失败后暂时摘除，恢复并通过检查后再加入。扩容时把新节点注册进节点池，缩容时应先停止分配新请求，并给已有连接留出排空时间。
边界与反例： 如果登录会话只保存在某台节点的内存中，普通轮询可能让下一次请求丢失会话；可以迁移到共享存储，也可以使用会话亲和，但后者会削弱流量均匀性和故障切换能力。算法看到的连接数也不等同于真实计算压力，长连接、慢请求和高成本任务都可能造成偏差。负载均衡器作为统一入口仍可能成为瓶颈或单点，入口自身的冗余与故障转移需要另行设计。
工程验证： 给每个节点的响应加入唯一实例标识，在并发压测中统计请求分布、延迟和错误率；随后停止一个节点，确认健康检查窗口结束后不再出现该标识，并观察失败请求是否符合预期。扩缩容验证还应检查新节点预热、连接排空、超时、重试上限和幂等性，避免一次后端故障被无界重试放大成集群级流量峰值。
面试官追问
追问 1电商服务部署了四个应用节点，但登录会话只存在首次命中的节点内存里，运维直接启用轮询会出现什么现象？
同一用户的后续请求可能落到其他节点并丢失会话，因为普通轮询假设请求能由任意健康节点处理。应把会话迁移到客户端或共享数据库、缓存；会话亲和虽能暂时规避错投，却会削弱流量均匀性和故障切换能力。
追问 2大促前新增三台应用服务器，平台团队认为注册进节点池后即可立即承接全量流量，你会要求补哪些落地动作？
新节点应先完成注册、健康检查和必要预热，再进入可选节点集合，而不是注册后立即视为稳定容量。缩容时则要先停止分配新请求并排空已有连接；还需验证超时、重试上限和幂等性，避免节点波动被重试放大。
追问 3集群里既有短查询也有长连接，架构评审在轮询与最少连接之间争执，你会依据什么选择？
请求成本接近且节点能力相近时，轮询实现直接；长连接较多时，最少连接更能反映当前并发占用。连接数仍不等于真实计算压力，高成本任务或慢请求会造成偏差，因此选择后还要结合延迟、队列和资源利用率验证。
追问 4线上停止一个节点后仍有少量请求命中它，负载均衡器日志却显示轮询算法正常，你会怎样定位？
应先核对健康检查的失败阈值与摘除窗口，算法正常不代表节点集合已经及时更新。可给每个节点响应加入唯一实例标识，在并发请求中确认何时停止出现故障节点；窗口内失败可能符合配置，持续命中则要查探测和节点池同步。
追问 5技术负责人说入口已经部署负载均衡器，因此应用集群不存在单点故障，你会在方案评审中指出什么缺口？
负载均衡只能在可用节点集合中转发请求，不能自动证明统一入口自身高可用。还需单独设计负载均衡器的冗余、故障转移与容量，并验证后端摘除和恢复流程；否则入口仍可能成为瓶颈或单点。
追问 6后端故障时网关无限重试，希望靠其他健康节点兜底，这与负载均衡的故障转移能直接画等号吗？
不能，改投健康节点需要受控的超时和重试策略，不能依赖无界重试。应设置重试上限，并确认请求具备幂等性；否则同一次故障可能产生重复副作用，还会把额外流量放大为集群级压力。
# 1. 轮询（Round Robin）
30 秒速记
- 轮询按固定次序把连续请求依次分配给各服务器，用请求次数实现表面上的均匀分发。
- 两台服务器接收六个顺序请求时，一台处理第
1、3、5个，另一台处理第2、4、6个。 - 该算法不区分节点性能，适合处理能力接近的服务器集群。
- 当节点性能差异明显时，每台机器仍可能分到相近数量的请求，弱节点因承载能力不足而形成压力点。
- 轮询均衡的是请求数量，不是实际计算成本或实时负载；原文未提供加权、健康检查等改进机制，不能据此扩展其能力。
轮询会按固定顺序把请求依次分给各台服务器，本质上均衡的是请求次数。 例如节点列表是 A、B、C，请求就按 A、B、C 循环分配，单次选择通常很直接。它适合处理能力接近、请求成本相差不大的集群。若节点性能或请求耗时差异明显，即使请求数接近，弱节点仍可能排队甚至超时，而且节点是否可用还要靠额外的管理机制判断。
轮询算法把每个请求轮流发送到每个服务器上。
下图中，一共有 6 个客户端产生了 6 个请求，这 6 个请求按 (1, 2, 3, 4, 5, 6) 的顺序发送。(1, 3, 5) 的请求会被发送到服务器 1，(2, 4, 6) 的请求会被发送到服务器 2。
该算法比较适合每个服务器的性能差不多的场景，如果有性能存在差异的情况下，那么性能较差的服务器可能无法承担过大的负载（下图的 Server 2）。
原理拆解： 轮询调度器维护一个指向下一台服务器的游标。请求到达时选择游标对应的节点，再将游标移动到后继节点；到达列表末尾后回到第一台，因此其时间复杂度通常为 O(1)。只要节点列表不变，连续请求就会形成可预测的循环序列。它均衡的是调度次数，而不是每个请求消耗的 CPU、内存、网络带宽或处理时间。
最小验证： 假设节点列表为 [A, B, C]，初始游标指向 A，七个请求的分配结果依次是 A、B、C、A、B、C、A，计数为 3:2:2；继续发送到第九个请求后，三台节点均得到三个请求。由此可见，短时间窗口内允许最多一次左右的数量差异，完整轮询周期内才会表现为请求数相等。
边界与反例： 若 A 每秒能处理 100 个请求，而 B 只能处理 20 个，二者仍各收一半请求，B 会更早出现排队和超时。即使机器性能相同，一个耗时 10 ms 的请求和一个耗时 10 s 的请求也被视为同一次分配，所以慢请求集中时仍会失衡。轮询本身也不能证明节点可用；节点退出后是否剔除、恢复后何时加入，取决于轮询之外的节点管理机制。
工程验证： 压测时应同时观察各节点请求计数、响应时间、错误率、队列长度和资源利用率。若请求计数接近但某节点的延迟、积压或利用率持续偏高，说明调度次数均匀而工作量并不均匀。还应验证节点列表变化时游标是否仍落在有效范围，并用多轮连续请求确认分配序列与配置中的节点顺序一致。
面试官追问
追问 1三台节点收到的请求数长期接近 1:1:1，但其中一台持续超时，值班同学说轮询均匀所以不可能是调度问题，你会怎样反驳？
轮询均衡的是调度次数，不是 CPU、内存、带宽或处理时间。即使计数接近，弱节点或集中收到慢请求的节点仍会积压；应同时比较各节点延迟、错误率、队列长度和资源利用率，不能只看请求数量。
追问 2节点列表为 [A, B, C]，测试只发送七个请求，发现计数是 3:2:2 就判定轮询失效，你会如何复核实现？
该结果符合轮询序列，七次可依次落到 A、B、C、A、B、C、A，短窗口允许约一次的数量差异。应继续发送到完整周期并核对目标顺序；若第九次后仍明显偏离，再检查游标推进和节点列表配置。
追问 3服务器 A 的处理能力明显高于 B，产品又要求两台都保留，继续使用普通轮询会承担什么代价？
普通轮询仍会让两台节点获得近似相同的请求次数，低能力的 B 可能先排队并超时。若性能差异稳定，应改变选节点规则以表达承载差异；仅扩大发送样本只能让次数更均匀，无法修正能力不对称。
追问 4发布时节点 B 已退出服务，但轮询游标下一次仍指向它，线上出现间歇性失败，你会优先检查哪两层？
先检查健康检查或节点管理是否已将 B 从可选列表剔除，再检查列表变化后游标是否仍落在有效节点上。轮询算法本身不证明节点可用；若节点池更新滞后或游标未正确调整，即使循环逻辑无误也会继续命中失效节点。
追问 5接口中一半请求耗时约 10 ms，另一半可能持续 10 s，团队想用普通轮询保持机器公平，你会接受这个选型吗？
只能在接受实时压力可能失衡的前提下使用，因为轮询把快请求和慢请求都视为一次分配。请求数公平并不等于存量工作量公平；若长任务集中，需结合连接、队列和资源指标评估其他调度依据，但任何单一指标也有偏差。
# 2. 加权轮询（Weighted Round Robbin）
30 秒速记
Weighted Round Robin用权重表达服务器处理能力差异，能力越强的节点获得越多请求。- 调度仍按轮询周期执行，但周期内各节点被选中的次数与其权重相关。
- 权重为
5:1时，一个分配周期可将前5个请求交给高权重节点，第6个交给低权重节点。 - 它适合服务器性能不同、请求处理成本相近的场景。
- 它只控制请求数量比例；当连接持续时间差异明显时，不能保证各节点的实时负载均衡。
加权轮询是在普通轮询上加入权重，让处理能力更强的服务器获得更多请求。 比如两台节点权重是 5:1，长期分配数量会接近这个比例；具体请求连续分配还是交错分配，要看实现。它适合机器性能不同、单个请求成本大致相近的场景。权重只是静态配置，若长任务集中或机器实际容量发生变化，请求比例正确也不代表实时负载一定均衡。
← 缓存
