压测环境搭建：硬件选型、网络拓扑、数据库与中间件配置
做交易系统压测，环境搭建是第一步，也是最容易踩坑的一步。
很多人觉得，压测嘛，拿台服务器跑脚本就行了。真这么干，结果往往惨不忍睹。我见过太多团队，压测环境跟生产环境差了十万八千里，最后压出来的数据，老板一看就摇头。
今天咱们聊聊，怎么搭一个靠谱的压测环境。
硬件选型：别省钱，也别乱花钱
硬件选型这事儿，说白了就是「够用」两个字。但「够用」的标准，得看你的交易系统是什么量级。
核心原则：压测机器的性能，至少要比生产环境高一个档次。
为什么？因为压测本身会消耗资源。你想想看，压测工具要模拟成千上万的并发用户，CPU、内存、网络IO，哪样不是开销？
我个人习惯，压测机器选型分三档：
| 场景 | CPU | 内存 | 磁盘 | 网络 |
|---|---|---|---|---|
| 小规模（<1000 TPS） | 8核 | 32GB | SSD 500GB | 千兆 |
| 中规模（1000-10000 TPS） | 16核 | 64GB | NVMe 1TB | 万兆 |
| 大规模（>10000 TPS） | 32核+ | 128GB+ | NVMe 2TB+ | 万兆+ |
避坑指南：我曾经遇到过，压测机器用机械硬盘，结果压到一半，磁盘IO直接打满，压测工具自己先挂了。嗯，从那以后，压测机器我必上SSD，最好是NVMe。
还有一点，压测机器最好跟目标服务器在同一机房，或者至少同一地域。延迟这东西，差几毫秒，结果就完全不一样了。
网络拓扑：别让网络成为瓶颈
网络拓扑设计，很多人不重视。觉得交换机一接，网线一插，完事了。其实不然。
交易系统对延迟极其敏感。你想想看，一个订单从客户端发出，经过网关、路由、交易引擎、数据库，最后返回确认。这一路上，每一跳的延迟都在累积。
我建议的网络拓扑是这样的：
压测客户端 → 交换机（万兆） → 负载均衡器 → 应用服务器集群 → 数据库集群
↓
监控服务器（旁路）这里有几个关键点：
- 压测客户端跟应用服务器之间，最好直连交换机，不要经过防火墙。防火墙会引入额外的延迟和丢包。
- 监控服务器走旁路，不要串在业务链路上。否则监控本身就会影响压测结果。
- 网络带宽要留余量。我一般留30%的余量。比如压测需要跑满800Mbps，我就配万兆口，实际跑个1Gbps左右，留足空间。
注意：千万别用无线网络做压测。无线的不确定性太大，丢包、抖动，你根本分不清是系统问题还是网络问题。
我曾经在一个项目中，压测环境跟生产环境共用交换机。结果压测一跑，生产业务直接卡死。嗯，从那以后，压测环境必须独立组网，物理隔离。
数据库配置：压测的「心脏」
数据库是交易系统的核心。压测时，数据库的配置直接影响结果。
我见过太多人，压测时数据库用默认配置。结果呢？连接数不够，慢查询一堆，TPS死活上不去。
这里我列几个关键配置项：
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| max_connections | 压测并发数 * 1.5 | 连接数要留余量，避免连接池打满 |
| innodb_buffer_pool_size | 物理内存的70% | InnoDB缓存，越大越好 |
| innodb_log_file_size | 1GB-4GB | 日志文件大小，太小会导致频繁刷盘 |
| sync_binlog | 0 或 1 | 压测时建议设为0，提升写入性能 |
| innodb_flush_log_at_trx_commit | 2 | 压测时设为2，减少磁盘IO |
个人经验：压测前，一定要先跑一次「预热」。让数据库把热数据加载到缓存里。否则压测刚开始，全是磁盘IO，结果会很难看。
还有一点，数据库的慢查询日志要打开。压测过程中，随时盯着慢查询。一旦出现，立刻优化。别等到压测结束再分析，那时候黄花菜都凉了。
中间件配置：别让消息队列拖后腿
交易系统里，中间件用得最多的是消息队列和缓存。
消息队列这块，我推荐用Kafka或RocketMQ。压测时，有几个配置要特别注意：
- 分区数：分区数至少是消费者线程数的2倍。我一般设3倍，保证负载均衡。
- 副本数：压测环境副本数设为1就行。副本多了，写入性能会下降。
- 批量大小：Kafka的batch.size，我习惯设成16KB。太小了，网络开销大；太大了，延迟高。
- 压缩：压测时关掉压缩。压缩会消耗CPU，影响吞吐量。
注意：消息队列的磁盘空间要留够。压测时，消息积压是常有的事。磁盘写满了，整个系统就挂了。
缓存方面，Redis用得最多。压测时，Redis的配置要点：
- maxmemory：设为物理内存的80%。留20%给操作系统和其他进程。
- 淘汰策略：压测时用allkeys-lru。别用noeviction，否则内存满了直接报错。
- 持久化：压测时关掉RDB和AOF。持久化会严重影响性能。
我曾经遇到过，压测时Redis的maxmemory设得太小，结果大量key被淘汰，缓存命中率暴跌，数据库直接被压垮。嗯，从那以后，我每次压测前都会检查Redis的内存配置。
整体架构图
下面这张图，是我做压测时常用的环境架构。你可以参考一下：
这张图里，压测客户端、交换机、负载均衡、应用服务器、数据库，一条链路下来。监控走旁路，不干扰主链路。每个环节都独立部署，互不影响。
最后说几句
压测环境搭建，说白了就是「模拟生产，但优于生产」。硬件选型别省钱，网络拓扑别凑合，数据库和中间件配置别偷懒。
你想想看，如果压测环境本身就有问题，那压出来的数据还有什么意义？
我见过太多团队，压测环境跟生产环境配置不一样，结果压测时一切正常，上线就崩。嗯，这种坑，踩一次就够了。
记住：压测环境越接近生产，压测结果越有价值。别在环境搭建上省钱省力，否则后面花的时间会更多。
公众号:蓝海资料掘金营，微信deep3321