负载均衡是大型架构核心，下面我详解负载均衡算法@mikechen
1.轮循
算法思路
把后端服务器排成一个列表，请求按顺序一个接一个轮着分配给各个服务器。
优点
实现极其简单，负载均衡设备只需维护一个索引指针即可。
请求分配“看起来很公平”，长期来看每台服务器收到的请求数大致相同。
缺点
不考虑服务器性能差异，低配和高配机器拿到的请求数量相同，容易导致低配机器先被压垮。
不感知当前负载，如果某台机器连接数或 CPU 已经很高，依然会继续分给它请求。
典型应用场景
各节点配置相近、业务请求处理时间分布比较均匀的场景（静态文件服务、简单读接口等）。
追求实现简单、对负载均衡精度要求不高的中小规模系统或内部服务。
2.加权轮循
算法思路
在普通轮循基础上给每台服务器配置一个“权重”，权重大表示该服务器更“能干”。
请求按权重比例分配：例如 A:3，B:1，则每 4 个请求里平均 3 个给 A、1 个给 B。
优点
能体现服务器性能差异，高配机器分到更多请求，资源利用率更好。
缺点
需要评估、配置合适的权重，权重随硬件变更或部署变更需要维护更新。
只依据“静态权重”，不看实时负载，对瞬时流量波动或短期异常不够敏感。
典型应用场景
服务器配置明显不一致（新旧机混用、混合云、多规格实例）的集群。
流量模式较稳定、服务器性能差异可通过权重大致体现的业务，例如 Web/API 集群、CDN 边缘节点等。
3.随机
算法思路
每次请求随机选择一台后端服务器，可做等概率随机，也可做“加权随机”。
不记录顺序指针，也不必关注具体连接状态，只依赖随机数选择目标节点。
优点
实现简单，不需要维护复杂状态，算法逻辑极轻量。
缺点
不考虑服务器性能差异和当前负载，默认所有节点等价。
即使从概率上平均，短时间窗口内也可能出现“抖动”，例如某台机器在短时间内被随机选中过多次。
典型应用场景
节点性能相似、且对负载均衡精度要求不高的场景，随机策略足够好且实现最简单。
4.最少连接
算法思路
对每台服务器维护当前“活动连接数”，每个新请求分配给当前连接数最少的那台机器。
属于动态算法，会随着连接建立、释放实时调整决策，更关注“当前负载”而不是“历史请求计数”。
优点
能自适应请求耗时差异和长连接场景：处理慢、连接多的机器会自动少分请求。
缺点
需要实时统计和维护各节点的连接数，算法实现和状态同步比轮循/随机复杂得多。
典型应用场景
有大量长连接的系统（如 WebSocket、HTTP/2、数据库连接、FTP/SFTP 等）。
请求耗时差异大（有的几十毫秒，有的几秒甚至更久）的业务，如复杂报表、搜索、推荐系统等。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》