负载均衡
Load Balancing
高级通用负载均衡（Load Balancing）是把进入同一服务的请求分配给多个可用实例的机制。它解决单个实例忙不过来或故障时请求无处可去的问题，比如把网站访问分散到多台应用服务器。
你可能会说：「我的网站现在有好几台服务器，想让访问自动分过去，哪台坏了就先别发给它。」
动手看看网站访问如何避开故障服务器
访客打开网站，请求先到负载均衡器。它是服务的统一入口，再决定把请求交给哪台实例。
要点请求是怎么分到多台服务器的？
- 1
先有多个能处理请求的实例
你需要先把同一个服务运行在多个实例上，负载均衡器才有地方可分。它接到请求后选一个实例转发；如果后面只有一台服务器，加上负载均衡器也不会让处理能力凭空增加。
- 2
分配方式要看实例承载情况
最简单的做法是轮流转发，也可以结合连接数等信息选择实例。因为实例性能和请求耗时可能不同，所以平均分配请求数量，不一定意味着每台机器的压力相同。
- 3
故障切换依赖健康检查
负载均衡器可以通过健康检查判断实例是否还能接单，并暂时绕开异常实例。但这只解决请求往哪里发；如果所有实例共用的数据库出了问题，换一台应用服务器也救不了。
- 4
登录状态不能只放在单台机器
如果用户登录后，下一次请求被分到另一台机器，只存在原机器内存里的会话可能就找不到了。你可以让请求不依赖单台机器的本地状态，或把需要共享的状态放到共同可访问的存储中。
容易混淆的地方
多实例部署是把服务运行多份，负载均衡是决定新请求交给哪一份；两者常一起用，但不是一回事。负载测试则是模拟访问来测系统能承受多少压力，不负责分配真实用户的请求。负载均衡也不等于自动扩容：实例不够用时，仍要增加容量。
什么时候用
适合用
- 网站访问量上来后，你把应用部署到多台服务器，想让用户通过同一个入口访问，并把请求分散出去。
- 后台 API 有多个实例，你希望某个实例故障时，新请求能转到仍可用的实例。
- AI 工具的推理服务有多份副本，你想分摊并发请求，减少单个副本排队。
不适合用
- 个人作品页只有一台小服务器，访问量也很低；先用单实例部署，避免为不存在的分流需求增加组件。
- 页面卡顿是因为每次请求都在执行慢查询；先检查查询和数据库索引，分流请求未必能解决瓶颈。
- 只是想知道服务最多能承受多少并发；该做负载测试，而不是先搭负载均衡器。
练一练选一个答案，看看解释
你的 App 后端已运行三个实例。用户登录后偶尔突然掉线，而每个实例都把登录会话存在自己的内存里。你会怎样处理？
让 AI 帮你做复制给 AI Agent 直接用
请检查当前后端是否适合多实例部署，并为三个应用实例设计负载均衡方案。说明请求入口、健康检查和故障实例如何退出分流；重点检查登录会话及其他本地状态，避免请求切换实例后出错。先给方案和改动清单，不要直接改代码。