限流是线上服务保护的第一道防线，而令牌桶又是限流算法里应用最广泛的一种。Nginx有成熟的limit_req模块，Apache其实也提供了对应的解决方案，只是很多人不知道怎么组合使用。这篇文章就来聊聊在Apache做反向代理时，如何用令牌桶的思路对请求进行限流，包括具体配置、模块选择和参数调优。
令牌桶算法的核心思想
令牌桶的原理并不复杂：系统以固定速率往桶里放令牌，桶有一个容量上限，满了就不再放入。每个请求到达时必须先从桶里取一个令牌，取到了才能通过，取不到就被拒绝或排队。这个机制带来两个重要特性：一是长期平均速率被限制在令牌生成速率，二是允许突发流量——桶里积攒的令牌可以在瞬间被消耗掉，短时间内通过的请求量可以超过平均速率。
这和漏桶算法形成鲜明对比。漏桶强制以恒定速率放行请求，突发流量会被均匀削平；令牌桶则对突发更友好，更符合真实业务里"平时平稳、偶尔尖刺"的流量形态。比如一个电商商品详情接口，平时每秒200个请求，但促销开始的几秒内可能瞬间冲到2000，如果用漏桶直接削平，正常用户会感觉卡顿，而令牌桶允许积攒的令牌一次性消化这波尖刺。
Apache从2.4.x开始原生提供了mod_ratelimit模块，它内部实现的正是基于令牌桶的速率控制，通过RateLimit指令可以限制响应body的发送速率。需要注意的是，这个模块限制的是带宽而非请求次数，如果要做请求数限流，还需要借助mod_reqtimeout或其他手段配合。理解这两者的区别，是用好Apache限流的前提。
Apache限流相关模块的选择与配置
Apache官方生态里有几个模块都和限流相关，先搞清楚各自的定位。mod_ratelimit负责响应带宽限制，基于令牌桶实现；mod_reqtimeout控制请求接收的超时和最小速率，防止慢速攻击；mod_limitipconn限制单IP并发连接数；而在反向代理场景下，mod_proxy本身也可以结合这些模块共同工作。
先看最基础的带宽限流配置。确保模块加载后，在虚拟主机或目录配置中加入RateLimit指令：
LoadModule ratelimit_module modules/mod_ratelimit.so
<VirtualHost *:80>
ServerName api.ipipp.com
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
# 限制该目录下的响应速率为 500 KB/s
<Location /download>
SetOutputFilter RATELIMIT
RateLimit initial 0
RateLimit sustained 512
</Location>
</VirtualHost>这里的initial参数设置起始突发速率，0表示不启用突发；sustained是持续速率，单位是KB/s。内部实现上，模块以秒为周期向桶中补充令牌，发送的数据量消耗令牌，桶空时发送动作就会暂停，直到下一个周期补充令牌。如果希望前几百KB不限速、之后再限速，可以把initial设大一些，比如设为2048，用户下载体验会更好。
如果是限制请求次数而不是带宽，Apache本身没有直接的QPS限流指令，常见做法是用mod_reqtimeout挡住慢速连接，再配合mod_limitipconn控制单IP并发：
LoadModule reqtimeout_module modules/mod_reqtimeout.so
LoadModule limitipconn_module modules/mod_limitipconn.so
<IfModule mod_reqtimeout.c>
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
</IfModule>
<Location /api>
# 单个IP在/api下最多同时保持10个连接
MaxConnPerIP 10
ProxyPass http://127.0.0.1:8080/api
</Location>这套组合的思路是：并发连接数限流相当于用连接层面的桶来保护后端，慢速请求超时避免连接被恶意占用。对于绝大多数反代场景，把这两个模块和带宽限流叠加使用，已经能覆盖大部分防护需求。
结合反向代理的后端保护实践
在纯反向代理的角色上，Apache限流的最终目的是保护后端应用。这里有一个容易被忽略的问题：RateLimit作用在Apache向外发送响应的阶段，对后端来说，请求仍然会全量打过去。如果后端真正的瓶颈是处理能力而不是出口带宽，单靠mod_ratelimit是不够的。
更完整的做法是分层次设防。第一层在Apache侧用mod_limitipconn和mod_reqtimeout过滤明显的异常连接；第二层用mod_proxy的连接池参数控制到后端的并发总量，避免瞬时打满后端线程：
<Proxy "http://127.0.0.1:8080/">
# Apache到后端的最大连接数，超出则排队
ProxyPass connectiontimeout=5 timeout=30
# 保活连接池
Keepalive On
retry=10
</Proxy>
<Location /heavy-api>
SetOutputFilter RATELIMIT
RateLimit sustained 256
MaxConnPerIP 5
ProxyPass http://127.0.0.1:8080/heavy-api
</Location>注意retry参数，当后端某个worker失败后，Apache会暂停向它转发请求一段时间，这本身就是一种故障隔离。而connectiontimeout能防止后端hang住时Apache堆积大量等待连接。
参数设定方面，不要拍脑袋。建议先用压测工具（比如ab或wrk）测出后端单实例的安全QPS和响应时间分布，然后把限流阈值设在这个值的70%到80%之间，给突发和故障留出余量。比如后端实测能扛1000 QPS，MaxConnPerIP和连接池总量就按700到800来规划。上线后观察Apache的server-status输出，重点看等待连接数和被限流请求的比例，如果限流触发率长期超过5%，说明阈值偏低，需要重新评估。
最后提醒一点，RateLimit对代理响应同样生效，但会占用Apache的工作进程时间——限速的连接在发送响应期间一直占着worker。大量慢速下载场景下要留意MaxRequestWorkers的配置，必要时开启mod_mpm_event减少线程占用。把这些细节都考虑到，Apache反代加令牌桶限流的方案才能真正稳定跑起来。