Nginx作为Ubuntu系统中常用的反向代理服务器，支持多种负载均衡策略，可根据后端服务器性能、业务需求（如会话保持）等场景选择合适的策略。以下是具体策略及特点：
核心逻辑：Nginx默认采用的负载均衡方式，按请求顺序依次将请求分发到后端服务器列表中的每一台服务器。
适用场景：后端服务器性能相近（如CPU、内存配置相同），且业务无会话保持需求（如静态页面、API接口）。
配置示例：
upstream backend { server 192.168.1.101:80; server 192.168.1.102:80; } 特点：无需额外配置，请求分配均匀；若某台服务器宕机，Nginx会自动剔除该服务器，后续请求不再分发至其上。
核心逻辑：为每台后端服务器分配一个权重（weight参数），权重越高，被分配到的请求比例越大。权重与服务器性能成正比（如高性能服务器权重设为3，低性能服务器设为1）。
适用场景：后端服务器性能差异较大（如旧服务器与新服务器混合集群），需根据性能分配流量。
配置示例：
upstream backend { server 192.168.1.101:80 weight=3; # 权重3，接收约50%请求 server 192.168.1.102:80 weight=1; # 权重1，接收约16.7%请求 } 特点：灵活调整流量分配，提升资源利用率；同样支持服务器宕机自动剔除。
核心逻辑：通过客户端IP地址的哈希值计算，将同一IP的请求固定分发到同一台后端服务器。哈希算法确保相同IP始终对应同一服务器（除非服务器列表变更）。
适用场景：需要会话保持的业务（如电商购物车、登录状态、用户缓存），避免用户在不同服务器间切换导致会话丢失。
配置示例：
upstream backend { ip_hash; # 开启IP哈希 server 192.168.1.101:80; server 192.168.1.102:80; } 特点：保证同一用户的请求始终由同一服务器处理；但可能导致流量分配不均（如某IP段用户量大，对应服务器压力高）。
核心逻辑：动态选择当前活跃连接数最少的后端服务器，将新请求分发至该服务器。活跃连接数指正在处理的请求数（如$connections_active变量）。
适用场景：后端服务器处理请求的时间差异较大（如长连接业务，如WebSocket、文件上传），需避免某台服务器因处理大量慢请求而过载。
配置示例：
upstream backend { least_conn; # 开启最少连接策略 server 192.168.1.101:80; server 192.168.1.102:80; } 特点：动态调整流量，提升整体吞吐量；适合处理长连接或突发流量的场景。
核心逻辑：通过第三方模块（如ngx_http_upstream_fair_module）实现，根据后端服务器的响应时间动态分配请求。响应时间短的服务器优先接收新请求（如某服务器平均响应时间为100ms，另一台为300ms，则前者分配更多请求）。
适用场景：后端服务器性能波动较大（如部分服务器因磁盘IO瓶颈导致响应慢），需根据实时性能调整流量。
配置示例：
upstream backend { fair; # 开启fair策略（需提前安装第三方模块） server 192.168.1.101:80; server 192.168.1.102:80; } 特点：动态适配服务器性能，提升用户体验；需安装第三方模块（Ubuntu下可通过apt或编译安装）。
核心逻辑：通过请求URL的哈希值计算，将同一URL的请求固定分发到同一台后端服务器。需配合hash指令指定哈希变量（如$request_uri），并可选设置哈希算法（如crc32）。
适用场景：缓存优化（如CDN、静态资源服务器），同一URL的请求始终由同一服务器处理，减少缓存穿透（如多次请求同一图片，只需从缓存服务器读取一次）。
配置示例：
upstream backend { hash $request_uri; # 按URL哈希 hash_method crc32; # 使用crc32算法 server 192.168.1.101:80; server 192.168.1.102:80; } 特点：提升缓存命中率，减少后端服务器压力；需安装第三方模块；URL变更会导致哈希失效，需谨慎使用。
以上策略覆盖了Nginx在Ubuntu环境下的主要负载均衡场景，可根据业务需求（如性能、会话保持、缓存）选择合适的策略。需注意，第三方模块（如fair、url_hash）需额外安装和配置，而默认策略（轮询、IP哈希）无需额外依赖。
