HAProxy中基于路径的速率限制配置优化实践

问题背景

在HAProxy 2.2版本中实现基于API路径的请求速率限制时，开发人员发现一个异常现象：当配置多个不同路径的速率限制规则后，某些特定路径的请求会被错误地限制。例如配置了/ann/user和/ann/user/remoteDestinations两个路径的不同速率限制，但后者总是被错误地拒绝。

根本原因分析

经过深入排查，发现问题源于stick-table的键值存储配置不当。原始配置中使用了二进制类型存储路径：

stick-table type binary len 8 size 100k expire 10s store http_req_rate(1s)

这里的关键问题在于len 8参数限制了键值的最大长度为8字节。当路径长度超过8字节时，HAProxy只会存储前8个字节作为键值。这导致类似/ann/user和/ann/user/remoteDestinations这样的路径在存储时都被截断为相同的前缀，从而共享同一个计数器。

解决方案

方案一：增加键值长度

最直接的解决方案是增加键值长度，确保能完整存储所有路径：

stick-table type string len 256 size 100k expire 10s store http_req_rate(1s)

这种方法简单直接，但需要注意：

1. 需要预估最大路径长度
2. 较长的键值会占用更多内存

方案二：使用哈希值作为键

更优雅的解决方案是使用哈希函数将路径转换为固定长度的整数：

http-request set-var(req.path_key) path,xxh32
stick-table type integer size 100k expire 10s store http_req_rate(1s)
http-request track-sc0 var(req.path_key)

这种方法优势明显：

1. 固定长度的整数键节省内存
2. 哈希计算确保不同路径有不同键值
3. 查找速度更快

完整优化配置示例

frontend http
  bind 127.0.0.1:84 tfo accept-proxy
  acl is_ssl fc_rcvd_proxy
  option nolinger
  
  # 使用哈希值作为键
  http-request set-var(req.path_key) path,xxh32
  stick-table type integer size 100k expire 10s store http_req_rate(1s)
  http-request track-sc0 var(req.path_key)
  
  acl remoteDestinations_ep1 path_end /remoteDestinations
  http-request set-var(req.rate_limit) path,map_beg(/usr/haproxyrates.map,500) unless remoteDestinations_ep1
  http-request set-var(req.rate_limit) int(10) if remoteDestinations_ep1
  http-request set-var(req.request_rate) var(req.path_key),table_http_req_rate()
  
  acl rate_abuse var(req.rate_limit),sub(req.request_rate) lt 0
  http-request deny deny_status 503 if rate_abuse remoteDestinations_ep1
  use_backend slowservers if rate_abuse
  default_backend usemultipleports

最佳实践建议

1. 对于路径较长的场景，优先考虑使用哈希方案
2. 定期监控stick-table的使用情况，避免内存耗尽
3. 考虑升级到HAProxy 3.0+版本，获取更好的性能和功能
4. 在map文件中明确定义所有需要特殊限制的路径
5. 为不同的API端点设置合理的速率限制值

通过这种优化，可以确保HAProxy准确地对不同路径实施独立的速率限制，避免误限制的情况发生，同时保持高效的性能表现。