关于负载均衡器机制的困惑及相关问题咨询

一、负载均衡器的核心作用：不止故障切换，更是流量分发 #

你之前的认知属于故障转移（Failover）场景，这只是负载均衡器的功能分支，而非核心定位。负载均衡器的核心是将外部请求按策略分发到多台同时运行的后端服务器，核心目的包括：

• 分摊单台服务器的流量压力，提升系统整体吞吐量
• 打破单节点性能瓶颈，支持业务水平扩容
• 附带故障检测能力，自动剔除宕机节点，将流量转移至健康节点

以Nginx为例，默认采用轮询策略，会把请求依次转发到每台正常的后端服务器，所有节点都会同时处理流量，而非等某台服务器故障后才启用其他节点。

二、会话与分布式数据的处理方案 #

1. 会话（Session）的处理 #

默认情况下用户会话数据存储在单台后端服务器内存中，若请求被分发到不同节点，会出现会话丢失问题，常见解决思路：

• 会话粘滞（Session Sticky）：通过Nginx配置，将同一用户的所有请求固定转发到同一台后端服务器（基于Cookie或IP哈希实现）。优点是配置简单，缺点是削弱了负载均衡的弹性，若绑定节点宕机，用户会话仍会丢失。
• 会话共享存储：将会话数据从服务器内存迁移至分布式存储（如Redis、Memcached），所有后端服务器统一从该存储读写会话数据。这是更推荐的方案，既保留负载均衡的灵活性，又避免会话丢失。
• 无状态架构设计：彻底移除服务器端会话，将会话数据加密后存储在客户端Cookie，或使用JWT令牌传递身份信息。这种方案最适配分布式架构，但需注意Cookie大小限制与数据安全性。

2. Redis这类内存数据库的处理 #

Redis本身具备分布式友好特性，通常有两种部署方式适配负载均衡场景：

• 主从/哨兵架构：所有后端服务器统一连接Redis主节点（或通过哨兵自动切换故障主节点），数据集中存储，所有节点共享同一份数据源。
• Redis集群（Cluster）：将数据分片存储在多个Redis节点，后端服务器通过集群客户端自动路由到对应分片，既提升存储容量，又分摊读写压力。

两种方案的核心逻辑一致：让所有后端服务器访问统一的共享数据源，避免节点间数据不一致问题。

内容的提问来源于stack exchange，提问作者andrew lockwood