网站规模扩大时如何规避Steam API的速率限制
缓解Steam API 429速率限制的Nginx配置方案
1. 缓存Steam API响应,减少重复请求
既然已经优化了调用逻辑,优先用Nginx缓存API返回结果,避免重复触发Steam请求。修改Nginx配置如下:
首先在http块(所有server块外部)添加缓存存储定义:
http { # 保留原有配置,新增以下内容 proxy_cache_path /var/cache/nginx/steam_api levels=1:2 keys_zone=steam_api_cache:10m max_size=10g inactive=60m use_temp_path=off; }
然后修改/api的location块,启用缓存:
location /api { proxy_pass http://localhost:3005; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; # 新增缓存规则 proxy_cache steam_api_cache; proxy_cache_valid 200 5m; # 缓存正常响应5分钟,可根据Steam数据更新频率调整 proxy_cache_key "$request_uri"; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; # 缓存过期时仍返回旧数据,避免直接抛出错误 }
2. 限流控制请求速率,避免短时间爆冲
如果用户请求突增导致后端API高频调用Steam,用Nginx限制/api接口的请求频率,把速率平摊到Steam允许的范围内:
在http块添加限流区域:
http { # 保留原有配置,新增以下内容 limit_req_zone $binary_remote_addr zone=steam_api:10m rate=5r/s; # 单IP每秒最多5个请求,按需调整 }
在/api location块添加限流规则:
location /api { # 保留原有代理、缓存配置 limit_req zone=steam_api burst=10 nodelay; # burst允许短时间内的请求峰值 }
3. 多API实例负载均衡,分摊密钥请求量
你之前考虑的多端口部署API(每个实例用独立Steam密钥),可以通过Nginx自动分发请求,不用手动处理:
在http块定义上游服务器:
http { # 保留原有配置,新增以下内容 upstream steam_api_backends { server localhost:3005; server localhost:3006; server localhost:3007; # 可加weight参数调整权重,比如 server localhost:3005 weight=2; } }
修改/api的proxy_pass指向这个上游集群:
location /api { proxy_pass http://steam_api_backends; # 替换原来的http://localhost:3005 # 保留原有header、缓存、限流配置 }
Nginx会轮询分发请求到各个实例,每个密钥的请求量降到原来的1/N,大幅降低触发限制的概率。新增实例只需在upstream里加一行即可。
4. 解决多EC2实例的会话问题
如果用多EC2实例部署API,会话丢失的问题有两种解决方式:
- 把会话存储迁移到共享服务(比如Redis),所有实例连接同一个Redis实例,实现会话共享
- 在Nginx的upstream里启用
ip_hash,让同一用户的请求始终落到同一个EC2实例:
upstream steam_api_ec2 { ip_hash; server ec2-xx-xx-xx-xx.compute-1.amazonaws.com:3005; server ec2-yy-yy-yy-yy.compute-1.amazonaws.com:3005; }
内容的提问来源于stack exchange,提问作者Ole Dybedokken
相关产品推荐
相关产品推荐

