负载均衡：四层与七层、算法与副作用
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 1 · 接入层扩展 · 第 5/49 篇 · 🚧 占位待学
上一篇：《扩容两条路：先把单机榨干，再谈横向》
下一篇：《API 网关：统一入口的得与失》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 1 · 单元 1.2
一、本文要解决的问题
有了 10 台机器，流量怎么分才公平？分不均，最忙的那台先死，然后流量涌向下一台——「雪崩式连环倒」。而且算法不是随便选的：轮询对缓存不友好，一致性哈希才是有状态请求的答案。
二、知识点清单
- 四层负载均衡（LVS / DPVS，转发包）vs 七层（Nginx / Envoy，解析 HTTP）：性能与功能的取舍
- 调度算法四种：轮询、加权轮询、最少连接、一致性哈希——各自适合什么请求特征
- 一致性哈希原理：环、虚拟节点、只迁移相邻节点的数据（为阶段 2 缓存与阶段 4 分片埋线）
- 会话保持两种做法：IP 哈希（黏住）vs session 外置（推荐），及各自的坑
- 健康检查：主动探测 vs 被动失败计数，摘除与恢复的阈值
- 动静分离：静态资源为什么不该经过应用服务器
三、动手实验（学习时必须真跑）
- Docker Compose 起 3 个后端实例 + Nginx，配加权轮询（1:2:3），wrk 压测后查各实例访问日志验证流量分布
- 配置 upstream 健康检查，手动 stop 一台，观察请求错误数与自动摘除时间；重启观察恢复
- 切换为 ip_hash 模式，用固定 IP 客户端验证黏性；再切换一致性哈希（upstream hash 模块）
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。