单机Semaphore不能用于分布式限流，因其仅控制本JVM并发，无法共享状态；分布式限流需用Redis等中间件实现全局许可池，支持原子操作、租约自动释放及多维粒度控制。
单机信号量（如 Java 的 Semaphore）本身不支持跨进程/跨节点状态共享，因此**不能直接用于分布式限流**。它的核心作用是控制本 JVM 内的并发数，属于“本地计数器”模型。要在分布式系统中实现真正有效的限流，必须跳出单机思维，把信号量的“许可思想”迁移到分布式协调机制中——即用分布式共识或共享存储来模拟全局许可池。
为什么单机 Semaphore 在分布式下会失效
假设你有 4 台服务实例，每台都配置了 new Semaphore(10)：
- 表面看是“总共最多 40 并发”，但实际是每台最多 10，并发峰值可达 40；
- 若下游依赖的是一个仅支持 20 并发的数据库，就可能被压垮；
- 某台机器宕机后，其已占用但未释放的许可无法回收，导致全局许可数永久丢失；
- 无法统一响应突发流量、动态扩缩容或按用户/接口维度差异化限流。
分布式限流的核心迁移思路
保留信号量“获取–执行–释放”的语义结构，但把许可的增减操作从内存计数改为对共享中间件的原子操作：
- 许可存储中心化：用 Redis（配合 Lua 脚本保证原子性）、Etcd 或 Consul 等提供分布式锁+计数能力；
- 许可生命周期绑定上下文：为每个请求生成唯一 ID，获取许可时写入租约（TTL），超时自动释放，避免节点宕机导致死锁；
-
许可粒度可配置：不再只是“1 请求 = 1 许可”，而是支持按用户 ID、API 路径、IP、业务标签等做分组限流，例如：
limit:api:/order/create:user_123； - 拒绝策略显式化：获取许可失败时，可选择快速失败（返回 429）、排队等待（进 Redis List 队列）、降级响应（返回缓存兜底数据）。
一个轻量可行的 Redis + Semaphore 思路示例
不引入复杂框架，用 Redis 实现类似信号量的语义：
- 使用
INCR+EXPIRE模拟 acquire：先设 TTL 再自增，若结果 ≤ 总许可数则成功； - 使用
DECR模拟 release：只在业务成功完成时调用，确保许可及时归还； - 用 Lua 脚本封装原子逻辑，防止竞态（例如：检查当前值 + 自增 + 设 TTL 必须一步完成）；
- 搭配 Sentinel 或 Redis Cluster 保障高可用，避免单点故障导致全局限流失效。
何时仍可结合本地 Semaphore 使用
分布式限流通常作为第一道网关防护（如 API 网关层），而本地 Semaphore 可作为第二道防线，在应用内部进一步约束资源消耗：
- 限制单机对下游 DB 的连接数（配合 HikariCP 的
maximumPoolSize）； - 控制异步任务线程池中同时执行的 IO 密集型任务数；
- 与分布式限流协同：比如网关层限制总 QPS ≤ 1000，单机再用
Semaphore(250)防止单机过载，形成两级保护。
