HAProxy高并发场景下Stick-Table锁争用问题分析与优化

问题背景

在HAProxy 2.9.6版本中，当在高并发环境下使用stick-table功能时，特别是在64线程配置下处理85Gbps流量时，出现了显著的CPU使用率飙升问题。通过性能分析发现，stick-table的锁争用成为了系统瓶颈，单个线程的CPU使用率甚至达到了93%。

技术分析

Stick-Table工作机制

Stick-Table是HAProxy中用于存储和跟踪客户端会话状态的机制，常用于实现会话保持、限速等功能。在本次案例中，它被用于JWT验证和源IP跟踪，配置了3秒的短过期时间以实现快速会话状态更新。

性能瓶颈定位

通过火焰图分析发现，stick-table的解锁操作(pl_wait_unlock)消耗了约50%的CPU周期。深入分析表明：

1. 当多个线程同时访问同一个stick-table时，会产生严重的锁争用
2. 特别是当有线程持有写锁进行条目清理或插入时，其他线程的读操作会被阻塞
3. 短过期时间(3秒)导致更频繁的写操作，加剧了锁争用

优化方案

分片锁设计

核心优化思路是将单一的stick-table拆分为多个分片(shard)，每个分片拥有独立的锁机制。具体实现包括：

1. 将stick-table的键空间划分为64个独立子树
2. 通过哈希算法将键值均匀分布到不同分片
3. 每个分片维护自己的过期机制和锁

实现细节

优化后的实现需要特别注意：

1. 保持原有API接口不变，内部实现分片处理
2. 处理peers同步时的特殊锁定需求
3. 确保分片间的负载均衡
4. 维护show table命令的兼容性

优化效果

在实际生产环境测试中，优化后的版本展现出显著改进：

1. 在24核EPYC服务器上，请求处理能力从358k RPS提升到2.35M RPS
2. pl_wait_unlock的CPU消耗几乎可以忽略不计
3. 整体系统吞吐量提升约6.5倍
4. peers同步操作的开销大幅降低

版本兼容性

该优化主要针对HAProxy 3.0及以上版本。对于2.9版本，虽然可以通过补丁方式应用，但需要注意：

1. 需要禁用peers功能或指向关闭的端口
2. show table命令可能无法显示完整数据
3. 可能存在一些边界条件需要特别处理

生产环境建议

对于高并发场景下的HAProxy部署，建议：

1. 考虑升级到3.0版本以获得完整优化
2. 监控stick-table的使用情况和锁争用指标
3. 合理设置过期时间，平衡性能与功能需求
4. 在测试环境充分验证后再部署到生产

这项优化显著提升了HAProxy在高并发场景下的性能表现，特别是在使用stick-table功能时，为解决锁争用问题提供了有效方案。