痛点

1. 用户请求谁来转发到具体的应用服务器
2. 用户每次访问的服务器不一样，如何维护 session一致性

负载均衡的引入

graph TD
    %% 定义样式
    classDef server fill:#fff,stroke:#333,stroke-width:2px;
    classDef storage fill:#fff,stroke:#333,stroke-dasharray: 5 5;

    %% 客户端层
    Client[客户端/PC] -- 访问请求 --> LB[负载均衡器]

    %% 应用服务器集群 (模拟堆叠)
    subgraph AppGroup [应用服务器集群]
        direction TB
        App1[应用服务器 1]
    end

    LB --> AppGroup

    %% 核心逻辑 (以应用服务器1为例展开)
    subgraph AppInternal [应用服务器内部]
        Logic[应用程序] --> LocalCache[(本地缓存)]
    end
    AppGroup -.-> Logic

    %% 后端服务层
    Logic --> DB[数据库服务器]
    Logic --> FS[文件服务器]
    Logic --> DistCache[分布式缓存服务器集群]

    %% 详细描述后端
    subgraph DB_Details [数据库]
        DB --> DB_Content[学员表 / 视频表]
    end

    subgraph FS_Details [文件存储]
        FS --> Files[文件资源]
    end

    subgraph Cache_Details [分布式缓存]
        DistCache --> Cache1[缓存节点 1]
        DistCache --> CacheN[缓存节点 n]
    end

负载均衡技术

flowchart LR
subgraph PARTA [OSI七层模型]
A[应用层]
B[传输层]
end

C[基于特定软件的负载均衡]
D[反向代理负载均衡]
E[基于DNS负载均衡]
F[基于NAT负载均衡]

A --> C
A --> D
B --> E
B --> F

应用层负载均衡

软件设计师/软件架构设计师/大型网站架构演化/负载均衡

http重定向

应用层的请求转发 特点：实现简单，性能较差

反向代理服务器

用户请求到达反向代理服务器，根据算法转发到具体服务器 特点：部署简单，可能成为性能瓶颈

传输层负载均衡

DNS域名解析负载均衡

基于 NAT的负载均衡

特点：技术较为成熟，一般在网关位置，可以通过硬件实现。例如：四层交换机

Session

Session的共享机制

将缓存存入 Redis

有状态和无状态问题

• 无状态服务：对单次请求处理，不依赖其他请求，服务器本身不存储任何信息
• 有状态服务：会自身保存一些数据，先后的请求有关联