团队必备 | LVS vs 缓存架构：限流策略

我见过很多团队在搞分布式系统的时候，把LVS和缓存架构的限流策略搞混了，最后导致服务崩溃。LVS是基于IP层的负载均衡，它用的是iptables的nat模块，缓存架构是用Redis或者Memcached做热点数据存储，限流策略则是用Nginx、Envoy这类代理层来控制流量。这三者虽然都和性能有关，但用法和原理完全不同。LVS适合处理高并发的后端服务，而缓存架构是减少数据库压力。限流策略则是防御级手段，不能替代前者。我亲身经历的几次事故，都是因为没搞清楚这三者之间的关系，最后只能硬扛流量，结果服务器被炸了。限流策略配置得当，能降低系统压力；配置不当，反而会增加复杂度。真实落地中，我用的是Nginx的limit_req模块，配合Redis做token bucket，LVS则是用IPVS，配合iptables做连接追踪。别再拿这些概念当玩具了。

▌ 技术参考

一 LVS和缓存架构的限流策略是两个独立的体系，它们虽然都涉及流量控制，但实现机制和适用场景差异极大。LVS通过iptables规则拦截流量，在后端做连接分发；缓存架构的限流策略通常依赖于应用层的限流中间件或Nginx等代理层的内置功能。真实部署中，我遇到过很多团队把两者混为一谈，结果在流量高峰时既影响LVS的负载均衡效率，也打乱缓存系统的状态同步机制。LVS的限流通常需要结合iptables的connlimit模块，而缓存架构的限流则是通过设置最大并发请求、令牌桶容量等参数实现。两者的限流逻辑完全不同，不能互相替代。

二 LVS的限流配置可以通过iptables的connlimit模块完成，例如使用`iptables -A INPUT -m connlimit --connlimit-above 100 -j DROP`这条命令，就可以限制单个IP的连接数不超过100。但这种做法存在很大隐患，因为一旦流量超过限制，LVS就会直接丢包，这可能导致前端应用无法感知到服务降级，反而出现大量超时和错误。更智能的做法是将LVS和Nginx结合使用，Nginx负责流量控制，LVS负责后端服务分发。例如，在Nginx中可以用`limit_req zone=my_limit burst=50`来设置每秒最多50个请求，这样既能控制流量，又不会让LVS直接丢弃连接。这种组合在实际中被广泛采用，特别是在有高并发需求的业务场景。

三 缓存架构的限流策略通常是在应用层或网关层实现，比如通过Redis做限流，可以使用Redis的Lua脚本来实现令牌桶算法。比如，设置`redis-cli SETNX rate_limit:ip:${ip} 1`，然后使用`redis-cli EXPIRE rate_limit:ip:${ip} 60`来设置过期时间，再用`redis-cli GET rate_limit:ip:${ip}`来判断是否超过限制。这种方法虽然灵活，但需要正确设置Redis的持久化策略和集群分片，否则容易出现数据穿透或限流不准确的情况。我见过很多团队用这种方案，但忽略了Redis的写入性能限制，在高并发下导致缓存读写延迟。

四 如果用Nginx做限流，有两种常见方式：一种是基于ip的限制，比如`limit_req zone=one burst=10 nodelay`；另一种是基于请求的限制，比如`limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s`。这两种方式各有优劣，基于ip的限流适合阻止恶意IP攻击，但可能影响正常用户访问；基于请求的限流适合控制整体请求速率，但容易误伤正常用户。我见过一个团队在微服务架构中用Nginx的limit_req配合Redis做缓存，结果在大促期间出现误判，正常用户也被限流了，最终导致客户投诉。为了避免这种情况，建议在Nginx中使用`delay`参数，这样会在达到限流时等待一段时间再处理请求。

五 在LVS中，如果直接用iptables来做限流，可能会引发一些意想不到的问题，比如连接状态同步不及时、iptables规则冲突等。我见过一个团队在测试环境中用iptables限流，结果在生产环境上线后，由于iptables规则未能正确同步到所有节点，导致部分服务无法访问，最终引发全链路故障。为了避免这类问题，建议在LVS中用IPVS模块，并通过`ipvsadm -A -t 10.0.0.1:80 -s rr`来设置连接调度策略，同时结合`ipvsadm -e -t 10.0.0.1:80 -r 10.0.0.2:80 -w 1`来配置后端节点权重。如果要实现限流，可以在IPVS中用`--sched-flags`参数控制流量分发策略，但这不是标准限流手段，建议结合Nginx或Envoy。

六 缓存架构的限流策略在实际部署中有很多踩坑点。比如，使用Redis的Redisson客户端做限流，如果不知道它的`rate`和`capacity`参数如何配合，很容易出现限流失效或者误判。我见过一个团队在设置Redisson的限流器时，把`rate`设为100，`capacity`设为50，结果发现每秒只有50个请求能通过，这明显是参数配置错误。正确的做法是，`rate`代表每秒允许的最大请求数，`capacity`代表令牌桶的容量，通常应该设置为更大的值，比如`rate=100`，`capacity=200`，这样在突发流量时能更好地吸收压力。另外，要注意Redisson的配置项是否被正确加载，有时候需要手动调整`redisson.yaml`文件中的`clientConfig`。

七 如果用Envoy做限流，可以通过`cluster`和`rate_limits`配置项来实现。比如在Envoy的配置文件中，添加`rate_limits: [ { "stat_name": "my_rate_limit", "match": { "prefix": "/api/v1" }, "rate_limit": { "requests_per_second": 100, "burst_size": 200 } }, ... ]`这样的规则。这样就能对特定路径实施限流了。但在实际中，配置Envoy并不容易，尤其是在多层代理和负载均衡的场景下，容易出现配置冲突。我见过一个团队在Envoy配置文件中误将`rate_limits`设置在`http_connection_manager`层级，导致限流规则没有被正确应用到所有服务。建议在部署Envoy时，先做本地测试，再逐步扩展到生产环境。

八 LVS的限流策略在高并发场景下容易出现性能瓶颈。比如，如果用iptables做连接数限制，当连接数超过阈值时，iptables会丢包，但不会返回错误信息。这可能导致前端应用误判为服务不可用，进而触发自动扩容。我见过一个团队在使用LVS时，没有配置Nginx做流量预判，结果在流量突增时，LVS直接丢包，前端应用同时收到大量超时请求，最终导致整个服务链路崩溃。为了避免这种情况，建议在LVS和Nginx之间加一层预判，比如在Nginx中设置`error_page 503 /503.html`，让前端能感知到服务降级，而不是直接崩溃。

九 在缓存架构中，限流策略对业务影响很大。比如，如果用Redis做限流，需要考虑到Redis的写入性能，否则在高并发下可能会出现写入延迟。我见过一个团队在使用Redisson做限流时，没有设置合理的`maxQueueSize`，导致在瞬时流量高峰时，限流器的队列塞满，最终出现请求堆积。解决办法是调整`maxQueueSize`参数，比如设置为`1000`，同时监控Redis的内存和性能指标，确保不会出现OOM或延迟过高。此外，可以结合监控工具如Prometheus和Grafana，实时查看限流器的状态和请求分布，及时调整参数。

十 如果团队想同时使用LVS和缓存架构的限流策略，需要确保两者之间的协同工作机制。比如，在Nginx中设置`limit_req`，然后将Nginx作为LVS的前端，这样可以避免直接在iptables中做限流。我见过一个团队在配置LVS和Nginx时，把`limit_req`放在LVS的iptables规则中，结果导致Nginx无法正确处理流量，最终出现请求丢失。正确的做法是，让Nginx负责流量控制，LVS负责负载均衡。例如，在Nginx的配置中添加`limit_req_zone $binary_remote_addr zone=one:10m rate=100r/s`，然后在`location /api`中使用`limit_req zone=one burst=200 nodelay`来限制流量。这样既能控制速率，又不会影响LVS的正常分发逻辑。

十一 缓存架构的限流策略在大规模部署时需要考虑分布式一致性问题。比如，如果使用Redis做限流，那么必须确保所有节点上的Redis实例是同步的，否则可能出现限流策略不一致的情况。我见过一个团队在使用Redis Cluster时，误将限流器的key设计成单机模式，结果在集群扩容后，限流策略失效，导致部分节点被过载。解决办法是使用全局唯一的限流key，比如基于`$binary_remote_addr`的hash值，确保所有节点都能正确识别和处理同一个IP的限流请求。此外，还要注意Redis的持久化策略，避免在重启后数据丢失。

十二 在高并发环境下，LVS和Nginx的限流策略对性能有直接影响。比如，当Nginx设置`limit_req`后，如果请求被限流，会进入等待队列，这会增加Nginx的内存占用和处理延迟。我见过一个团队在使用Nginx做限流时，没有监控内存和CPU，结果在流量高峰时，Nginx的内存暴涨到4GB，导致服务崩溃。解决办法是配合Prometheus和Grafana，实时监控Nginx的`limit_req`状态，确保不会出现队列超限。另外，如果流量太大，Nginx的`limit_req`可能无法满足需求，这时候可以考虑使用Envoy做更精细的流量控制。

十三 缓存架构的限流策略在实际中需要和业务逻辑结合。比如，在电商系统中，针对秒杀商品的接口，可以用Redis做限流，同时结合业务的幂等性处理，避免重复下单。我见过一个团队在秒杀活动中误用了`SETNX`命令做限流，结果在高并发下，因为Redis的CAS策略没处理好，导致部分用户被误判为重复请求。正确做法是使用Lua脚本实现复合操作，比如`EVAL "local key = KEYS[1]; local count = redis.call('INCR', key); if count == 1 then return 1 else return 0 end" 1 rate_limit:ip:${ip}`，这样就能保证限流的原子性和一致性。同时，可以结合Redis的`TTL`机制，设置合理的过期时间，避免长时间占用缓存资源。

十四 在限流策略的实现中，要特别注意连接状态和请求队列的处理方式。比如，在Nginx中使用`limit_req`时，如果设置`nodelay`，那么即使请求超过阈值，也会直接拒绝，这可能导致大量请求被丢弃。我见过一个团队在大促期间，误将`limit_req`设置为`nodelay`，导致很多正常用户被直接拒绝，最终引发客户投诉。正确做法是使用`delay`参数，这样在达到限流阈值后，请求会被排队处理，而不是直接丢弃。这在有突发流量的场景下尤为重要，可以避免服务瞬时崩溃。

十五 如果团队在缓存架构中使用Envoy做限流，需要注意Envoy的配置项是否正确。比如，`rate_limits`需要配置在`http_connection_manager`层级，同时要确保`cluster`配置正确，否则限流规则不会被应用到后端服务。我见过一个团队在配置Envoy时，误将`rate_limits`放在`route`层级，导致限流规则被忽略。这种错误在上线后才被发现，浪费了大量时间修复。建议在部署Envoy时，先用本地测试环境验证配置，再逐步推广到生产环境，确保每个层级的限流策略都被正确应用。