针对php接口高并发问题，可采用五种限流方案：一、令牌桶算法通过redis实现动态令牌发放，控制请求速率并允许突发流量；二、固定窗口计数器利用redis键统计单位时间请求数，超限则返回错误信息，适用于简单场景；三、滑动日志算法以有序集合记录请求时间戳，精确统计窗口内请求量，避免瞬时高峰；四、nginx的limit_req模块在前端拦截过多请求，减轻php处理压力；五、分布式环境下使用redis集群配合lua脚本实现原子化限流，确保多节点状态一致。
如果您的PHP接口面临高并发请求，导致服务器资源耗尽或响应延迟，可能是缺乏有效的流量控制机制。以下是几种可行的限流方案，帮助您在不同场景下实现稳定的接口访问控制。
一、基于令牌桶算法的限流
令牌桶算法通过固定速率向桶中添加令牌，每个请求需要消耗一个令牌。当桶中无令牌时，请求被拒绝。这种方式允许一定程度的突发流量，同时保证长期平均速率可控。
1、定义一个存储令牌数量和上次填充时间的数组或缓存结构，例如使用Redis保存状态。
2、每次请求时检查当前时间与上次填充时间的间隔，按设定速率计算应补充的令牌数，但不超过桶的最大容量。
立即学习“PHP免费学习笔记（深入）”；
3、判断桶中是否有足够令牌，若有则扣除一个并放行请求；否则返回 429 Too Many Requests 状态码。
4、将更新后的令牌数和时间写回存储，确保后续请求能正确获取最新状态。
二、固定窗口计数器限流
固定窗口计数器在指定时间窗口内统计请求数量，一旦超过阈值即触发限流。实现简单，适用于对精度要求不高的场景。
1、使用Redis设置一个带过期时间的键，如 key 为 "rate_limit:{IP}"，有效期设为60秒。
2、每次请求时对该键执行自增操作，并判断其值是否超过预设上限（如每分钟最多100次）。
3、若超出限制，则立即中断处理流程并输出 {"error": "请求过于频繁，请稍后再试"} 的JSON响应。
4、利用Redis自动过期特性清除旧计数，无需手动清理。
三、滑动日志算法实现精确限流
滑动日志记录每一次请求的时间戳，通过统计最近一段时间内的请求数来决定是否放行。相比固定窗口更平滑，避免瞬时峰值问题。
1、为每个用户或IP维护一个有序集合（Sorted Set），以时间戳为score，请求ID为member，存于Redis中。
2、接收请求时，先移除集合中早于当前时间减去时间窗口的所有记录（如过去60秒外的日志）。
3、计算集合中剩余元素个数，若大于阈值则拒绝请求，并返回 HTTP 429 响应。
4、将本次请求的时间戳加入集合，并设置合理的过期时间以防内存泄漏。
四、Nginx配合PHP进行前置限流
借助Nginx的limit_req模块，在请求到达PHP之前完成部分限流工作，减轻后端压力，提升整体系统稳定性。
1、在Nginx配置文件中定义一个共享内存区域，用于存储请求状态，例如：limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
2、在location块中引用该区域，添加指令 limit_req zone=api burst=20 nodelay; 以允许短暂突发。
3、重启Nginx使配置生效，此时高频请求会被Nginx直接拦截并返回 503 Service Temporarily Unavailable。
4、PHP脚本只需处理通过Nginx筛选的请求，可进一步执行业务级细粒度限流逻辑。
五、分布式环境下使用Redis集群限流
在多服务器部署的情况下，本地内存无法共享限流状态，必须依赖集中式存储实现统一控制。
1、选择Redis Cluster或Sentinel架构作为共享数据源，确保高可用性与扩展能力。
2、设计通用的限流函数，接受用户标识、时间窗口和最大请求数作为参数。
3、在函数内部使用Lua脚本原子地完成读取、判断与写入操作，防止竞态条件。
4、所有节点调用同一套接口进行限流校验，确保跨机器请求仍受控，任何超限行为都将收到 {"code": 429, "msg": "请求频率超限"} 提示。
