在互联网高并发系统中，流量瞬时激增极易导致服务过载甚至雪崩。早期系统常用单机限流，但单点限流无法适应多实例、多服务部署环境。本文围绕分布式动态流控展开，结合多语言代码示例，分享从单机限流到高可用流控体系落地的工程实践经验。
一、单机限流的局限
初期系统通常用固定阈值限制请求：
MAX_RPS = 100 requests = [] def allow_request(): now = time.time() requests[:] = [t for t in requests if now - t < 1] return len(requests) < MAX_RPS
逻辑简单，但在多实例部署下，每个节点独立计算，无法实现全局流控，也无法应对流量突发。
二、分布式限流引入
通过 Redis 或一致性存储实现全局限流：
Long count = redis.incr("global_limit"); if(count <= LIMIT) { processRequest(); } else { rejectRequest(); }
语法上明确全局计数，工程上保证多实例共享流控状态，实现统一流量控制。
三、用户与接口维度限流
不同用户或接口流量敏感度不同，可实现多维度限流：
if limiter.Allow(userID) && limiter.Allow(endpoint) { handleRequest() } else { rejectRequest() }
语法上表达多维限流，保证核心业务优先执行。
四、漏桶与令牌桶算法
高性能系统使用令牌桶或漏桶平滑流量：
TokenBucket bucket = new TokenBucket(rate, capacity); if(bucket.tryConsume()) { processRequest(); } else { rejectRequest(); }
通过语法体现平滑限流，避免瞬时流量峰值打垮系统。
五、动态阈值与灰度控制
限流阈值可动态调整，根据系统负载自动扩展或收缩：
threshold := baseThreshold + rand.Intn(50) if currentRPS < threshold { process() } else { reject() }
语法上明确动态化和随机化，降低集中流量冲击。
六、降级与熔断结合
限流策略常与降级、熔断结合，保证系统核心能力：
if(circuitOpen || overLimit) { return fallback(); } processRequest();
形成闭环，使系统在高压下仍能提供核心功能。
七、监控与告警
限流体系必须可观测：
metrics.inc("requests_rejected_total") metrics.observe("request_latency_seconds", duration)
指标帮助及时发现流控异常和压力峰值。
八、分布式限流的工程思维升级
工程师需要认识到：
-
单机限流无法应对多节点部署
-
多维度、动态、分布式流控是高并发系统的核心能力
-
可观测性与告警是限流策略落地的前提
九、从单机到全局流控的认知转变
高并发系统不仅需要阻止请求过载，更要保证核心业务优先、系统可恢复 。
分布式流控体系通过全局计数、多维度限流、令牌桶算法、动态阈值、降级和监控闭环，实现系统韧性和业务连续性。
十、结语
分布式动态流控不仅防止雪崩，还提升整体系统可用性和稳定性。
通过限流、熔断、降级和可观测闭环，系统从"单机保护"升级为"全局韧性体系"。
这篇围绕分布式动态流控落地的工程随笔，为构建高并发互联网系统的工程师提供偏长期、偏系统性的参考，而不仅停留在单机 RPS 或简单限流框架层面。