默认轮询策略是分布式存储网关水平扩展最直接、低侵入的方式，适用于节点性能相近、网络延迟均匀的环境，依赖共享后端与无状态设计，需配合健康检查与容错机制保障可用性。
默认轮询策略（Round Robin）是实现分布式存储网关水平扩展最直接、低侵入的方式之一，适用于节点性能相近、网络延迟均匀的集群环境。它不依赖外部调度组件，靠网关自身或前置负载均衡器按序分发请求，天然支持无状态扩展。
网关层轮询：配置简单，即配即用
多数分布式存储网关（如MinIO网关模式、Ceph RGW代理层、或自研S3兼容网关）支持在反向代理或客户端SDK中配置多个后端地址，启用内置轮询逻辑：
- Nginx作为前置网关时，直接定义upstream块，默认即为轮询：
upstream storage_backend {
server 10.0.1.10:9000;
server 10.0.1.11:9000;
server 10.0.1.12:9000;
} - 若网关自身支持多后端（如某些对象存储网关的multi-backend模式），可在配置文件中以逗号分隔IP列表，启动后自动按序路由请求
- 客户端SDK（如AWS SDK for S3）也可通过自定义HTTP客户端注入多个endpoint，配合RetryPolicy与ConnectionPool实现软轮询
数据一致性与会话无关性是前提
轮询有效运行的前提是：所有网关实例背后连接的是同一套共享存储后端（如统一的etcd元数据集群 + 分布式对象存储池），且网关本身无本地状态缓存。否则会出现：
- 上传分片后无法合并（因不同请求落到不同网关，各自维护独立上传上下文）
- ListBucket结果不一致（各网关缓存不同、或元数据同步延迟）
- 签名验证失败（时间戳/nonce校验跨节点不共享）
建议关闭网关本地元数据缓存，强制所有元数据操作走中心化服务（如Consul或etcd），确保“一次写入，全局可见”。
扩展过程无需停服，但需同步更新发现机制
新增网关节点时，只需三步即可完成平滑接入：
- 部署新网关实例，确认其能正常连通后端存储与元数据服务
- 更新Nginx upstream配置或DNS记录（若使用DNS轮询），重载配置（nginx -s reload）
- 观察流量分布（如Prometheus + nginx_exporter指标中的upstream_response_time和request counter），确认新节点承接请求量逐步上升
注意：DNS轮询存在TTL缓存问题，生产环境更推荐Nginx或API网关（如Kong、Traefik）做7层轮询，可控性强、健康检查完备。
轮询不是万能的，需搭配基础容错
默认轮询不感知节点健康状态，因此必须叠加最小可用保障：
- Nginx中启用health_check指令，自动剔除不可达节点
- 网关自身开启主动探活（如每5秒GET /health），失败三次触发临时摘除
- 客户端侧设置合理超时（connect: 1s, read: 5s）和重试（最多1次，避免放大故障）
这样即使某台网关宕机，轮询仍能在剩余节点间继续工作，整体可用性不受影响。
