分布式限流算法的选择需根据业务需求和系统特性进行权衡。1. 令牌桶允许突发流量，适合短暂高并发场景，通过redis+lua实现令牌生成与消耗的原子操作；2. 漏桶以恒定速率处理请求，输出平滑但不适用于突发流量，可通过redis队列模拟实现；3. 计数器分为固定窗口和滑动窗口，后者更精确但实现复杂，适合对限流精度要求高的场景；选择时需考虑一致性、性能开销、容错性、突发流量容忍度及实现复杂度；使用redis时需防范单点故障、网络延迟、lua脚本复杂度过高等问题，并通过压测评估吞吐量、延迟和资源消耗，结合监控确保限流策略有效运行。
在构建高并发系统时，分布式限流是不可或缺的一环。简单来说，它就是为了保护你的系统不被突发流量冲垮，或者防止恶意请求耗尽资源。常见的实现算法无外乎令牌桶（Token Bucket）、漏桶（Leaky Bucket）和计数器（Counter，包括固定窗口和滑动窗口），每种都有其独特的脾气和适用场景。我个人觉得，没有哪个算法是万能的，关键在于你对业务流量特性的理解和取舍。
解决方案
要实现Java的分布式限流，核心在于将限流状态同步到所有服务实例都能访问到的地方，比如Redis、ZooKeeper或者数据库。
令牌桶算法（Token Bucket）
立即学习“Java免费学习笔记（深入）”；
令牌桶就像一个固定容量的桶，系统会以恒定速率往里面投放令牌。每次请求过来，都需要从桶里取走一个令牌才能通过。如果桶里没有令牌了，请求就得等待或者被拒绝。这个算法的优点是允许一定程度的突发流量，只要桶里有足够的令牌，请求就能快速通过。这在我看来，对于那些允许短暂爆发性访问的API非常友好。
-
实现思路： 可以用Redis的
INCR和EXPIRE命令来模拟令牌的生成和消耗。一个Key存储当前令牌数，另一个Key存储上一次刷新令牌的时间戳。每次请求到来，先计算应该增加了多少令牌，更新令牌数，然后尝试获取令牌。Lua脚本在这里是利器，可以保证操作的原子性。
漏桶算法（Leaky Bucket）
漏桶算法则像是有一个固定流速的桶，无论请求量多大，它都以一个恒定的速率“漏”出去处理。如果请求进来时桶已经满了，那么新来的请求就会被丢弃。这个算法的特点是输出流量平滑，能有效保护后端系统，避免其处理能力被瞬间压垮。但我有时候觉得它有点“死板”，不怎么擅长处理突发流量。
- 实现思路： 同样可以基于Redis。用一个列表（List）或者有序集合（ZSet）来模拟桶。每次请求到来就尝试入队，如果队列满了就拒绝。消费者则以固定速率从队列头部取出请求进行处理。
计数器算法（Counting Window）
这是最直观的限流方式。它又分为固定窗口和滑动窗口。
固定窗口计数器： 在一个固定的时间窗口内（比如1秒），统计请求数量，超过阈值就拒绝。它的问题在于，如果请求在窗口边缘扎堆，可能会导致实际的瞬时流量远超预期，这在实际应用中确实是个让人头疼的问题。比如，1秒的窗口，限流100次，如果99次请求都在第0.9秒发生，那第1秒开始的瞬间，系统可能瞬间涌入大量请求。
滑动窗口计数器： 相比固定窗口，滑动窗口更平滑、更准确。它将时间窗口分成更小的格子，每个格子有自己的计数。当时间向前滑动时，会移除旧的格子计数，并增加新的格子计数。这有效避免了固定窗口的边缘效应。在我看来，滑动窗口虽然实现复杂一些，但效果通常是最好的。
实现思路： 基于Redis的ZSet，每个请求到来时，将当前时间戳作为score，请求ID作为member存入。每次检查时，移除过期时间戳的member，然后统计当前ZSet中的member数量。
在分布式环境中，选择限流算法时需要考虑哪些关键因素？
选择分布式限流算法，可不是拍脑袋就能决定的事，这里面坑不少。在我看来，最核心的考量点有几个：首先是一致性，你的限流规则在所有服务实例之间必须是同步且一致的，不能说这个节点放行了，那个节点却拒绝了。这通常意味着需要一个中心化的存储来维护状态，比如Redis。其次是性能开销，限流本身不能成为系统的瓶颈，每次请求都去远程调用一次Redis或者ZooKeeper，这个延迟和网络IO是实实在在的，你得评估它是否在可接受范围内。
再者，容错性也不容忽视，如果你的Redis集群挂了，限流服务是直接失效然后系统被冲垮，还是能有降级策略？这是个大问题。业务对突发流量的容忍度也至关重要，有些业务允许短时间内的爆发性流量（比如秒杀活动），这时候令牌桶就显得很灵活；有些则需要严格的平滑流量输出（比如后端处理能力有限的批处理服务），漏桶就更合适。最后，实现复杂度也是个现实因素，毕竟资源有限，滑动窗口虽然好，但实现和维护成本摆在那里。
基于Redis的分布式限流方案有哪些常见陷阱和优化建议？
Redis在分布式限流里确实是“主力军”，但用不好也容易掉坑。一个常见的陷阱是单点故障，如果你的Redis是单实例，那它挂了，整个限流服务就瘫痪了。解决方案当然是上Redis Sentinel或者Redis Cluster，保证高可用。
另一个问题是网络延迟，每次请求都去Redis拿数据，这个网络往返时间会累加到你的请求响应时间里。优化上，可以考虑连接池，减少连接建立的开销。更进一步，对于一些非核心、流量巨大的接口，可以考虑在应用层做二级限流，先在本地内存里粗略地限一下，再往Redis走。
还有，Lua脚本的使用虽然能保证原子性，但如果脚本逻辑过于复杂，或者Redis实例负载过高，也可能导致执行超时。我的经验是，Lua脚本要尽量精简，只包含核心逻辑。另外，Key的命名和过期策略也很重要，避免Key冲突，及时清理过期Key，防止内存泄胀。对于超高并发场景，Redis的持久化方式（RDB/AOF）也需要仔细权衡，是追求数据一致性牺牲一点性能，还是追求极致性能牺牲一点点数据安全？这都是取舍。
如何评估不同限流算法在实际业务场景中的性能与开销？
评估限流算法的性能和开销，不能只看理论，得结合实际业务场景来。最直接的办法就是压测。你需要模拟不同流量模式（平稳、突发、尖峰）去压测你的限流服务，观察几个关键指标：
- 吞吐量（Throughput）：在限流生效的情况下，系统每秒能处理多少请求？这是最直观的指标。
- 延迟（Latency）：限流逻辑本身会引入多少额外的请求延迟？特别是P99、P999延迟，它们能反映出最慢的那批请求的表现。
- 资源消耗：限流服务本身（Redis、应用实例）的CPU、内存、网络IO消耗如何？这直接关系到部署成本。
我通常会先在开发环境或测试环境搭建一个与生产环境尽可能一致的限流服务，然后用JMeter、Locust或者Gatling这样的工具进行压力测试。模拟不同的QPS、并发用户数，观察系统行为。比如，令牌桶在突发流量下的表现，漏桶在平稳输出时的稳定性。
此外，监控也是不可或缺的一环。上线后，通过Prometheus、Grafana等工具实时监控限流计数、拒绝请求数、Redis连接数和延迟等指标，及时发现问题。有时候，算法的选择不仅仅是技术考量，更是对业务SLA（服务等级协议）的承诺。如果业务对延迟非常敏感，那即使某个算法在理论上很优秀，但如果引入的额外延迟过高，也可能不适用。最终，选择哪种算法，往往是性能、复杂度和业务需求之间的一个动态平衡。
