1. 项目概述：从单机到十万并发的挑战

做性能测试的同行，估计都经历过一个阶段：用JMeter或者LoadRunner，吭哧吭哧配好脚本，一跑高并发，要么是机器先扛不住，内存飙升，要么是结果数据七零八落，难以分析。当业务发展到需要验证十万级并发用户场景时，传统单机测试工具的瓶颈就暴露无遗了。这时候，一个基于代码、支持分布式、资源消耗友好的工具就成了刚需，而Locust，正是为此而生。

我最近刚完成一个电商大促活动的全链路压测，目标就是模拟超过十万真实用户同时在线操作。整个实战下来，Locust的分布式架构给了我很大惊喜，但也踩了不少坑。这篇文章，我就结合这次实战，把如何用Locust搭建分布式压测集群、一步步冲到十万并发，以及其中的核心配置、监控要点和避坑经验，系统地梳理一遍。无论你是刚开始接触Locust，还是正在规划大规模压测，相信这些从一线实战中总结出的细节，都能给你提供直接的参考。

2. Locust分布式架构核心设计解析

2.1 为什么是Locust？事件驱动与协程优势

在讨论分布式之前，必须先理解Locust的立身之本。与JMeter基于线程的模型不同，Locust底层采用了gevent库实现的事件驱动和协程机制。这听起来有点抽象，我打个比方：传统的线程模型好比开一家餐厅，每个顾客（虚拟用户）都需要一个专属的服务员（线程）。一万个顾客就需要一万个服务员，且不说招聘和管理成本（系统线程开销），光是这一万人的工资（内存）和协调（CPU上下文切换）就能把餐厅（测试机）拖垮。

而Locust的协程模型，则像是一个“超级服务员”。这个服务员通过高效的“时间管理”（事件循环），可以在服务A顾客点菜的间隙，去给B顾客上菜，再去招呼C顾客入座。从宏观上看，他仿佛在同时服务所有人，但实际上他只有一个（单线程）。这就是协程的“轻量级”，一个Locust进程（一个系统线程）内可以轻松运行成千上万个这样的“虚拟用户”（协程），它们之间的切换代价极低。

带来的直接优势就是资源效率。在我的测试中，一台16核32GB的服务器，用JMeter跑5000个线程（用户）已经非常吃力，内存接近30GB。而用Locust，跑10000个用户，内存占用稳定在8GB左右，CPU利用率也更平滑。这意味着，用更少的硬件资源，你可以模拟出更高的并发量，这是实现十万并发的物理基础。

2.2 分布式架构：Master-Worker模型详解

单机能力再强，也有上限。要突破十万并发，必须分布式。Locust采用了经典的Master-Worker（主从）架构，清晰且易于管理。

• Master节点（主节点）：这是整个压测集群的大脑。它不模拟任何用户，只负责三件事：

  1. 协调与分发：接收来自Web UI或命令行发起的测试指令，并将测试任务（即用户行为和负载形状）分发给所有Worker。
  2. 数据聚合：收集所有Worker节点发回的实时测试数据（请求数、响应时间、失败率等）。
  3. 提供Web UI：运行一个内置的Web服务器，提供实时的数据图表展示和测试控制界面（启动、停止、设置用户数等）。

  正因为Master不承担生成流量的压力，所以它对资源要求极低。通常，一台2核4GB的虚拟机就完全足够，甚至可以用一台开发笔记本临时充当。

• Worker节点（工作节点）：这些是真正“干活”的肌肉。每个Worker节点都是一个独立的Locust进程，它从Master节点获取测试任务，然后在本机启动协程，模拟大量虚拟用户执行测试脚本中定义的行为（如HTTP请求）。Worker节点的性能直接决定了整个集群的并发能力。你需要根据目标并发数，来计算需要多少台、什么配置的Worker节点。

集群通信：Master和Worker之间通过TCP协议进行通信。默认端口是5557（用于Worker连接Master）和5558（用于Master向Worker推送数据）。确保这些端口在防火墙中是开放的，并且节点间的网络延迟尽可能低（最好在同一个内网，延迟<2ms），否则会影响协调效率和统计数据的时间同步。

2.3 实施路线图：从零搭建到十万并发

规划一次十万并发的压测，不能一上来就蛮干。我总结了一个四阶段的实施路线图，能有效降低风险，步步为营：

1. 第一阶段：脚本与单机验证（1-1000并发）

   • 目标：确保测试脚本逻辑正确，能模拟核心业务场景（如用户登录、浏览商品、下单、支付）。
   • 关键动作：在本地或一台测试机上，用Locust单机模式运行脚本。通过Web UI观察请求成功率、响应时间是否正常。使用参数化工具（如Faker）避免数据冲突。这个阶段重点是功能正确性。

2. 第二阶段：单Worker节点容量摸底（1000-单节点上限并发）

   • 目标：摸清单台Worker服务器的性能天花板。
   • 关键动作：选择一台规划好的Worker服务器，单独部署Locust Worker并连接到Master。逐步增加并发用户数，同时监控该服务器的CPU、内存、网络IO。当资源（通常是CPU或端口数）接近饱和，且响应时间开始非线性增长或错误率上升时，记录下该节点能稳定支撑的最大用户数。例如，我的16核32GB服务器，单个Worker稳定支撑了约8000个用户。

3. 第三阶段：分布式集群联调与阶梯加压（多节点，至目标并发80%）

   • 目标：验证分布式集群的协调能力，并观察系统在压力逐步上升下的表现。
   • 关键动作：启动所有规划好的Worker节点（比如10台），连接到Master。在Web UI或使用--headless模式，设计一个阶梯式负载模型，缓慢增加总用户数。例如，先压到5万并发，稳定运行10分钟，观察被测系统的各项监控指标（应用服务器CPU、数据库连接数、缓存命中率等）。这个阶段的目标是发现瓶颈，而不是直接压垮系统。

4. 第四阶段：峰值冲击与稳定性测试（目标并发100%-120%）

   • 目标：验证系统在极限压力下的表现和恢复能力。
   • 关键动作：使用负载形状（LoadTestShape）模拟“秒杀”场景，在短时间内（如2-3分钟）将并发用户数从5万猛增至12万，并维持峰值一段时间。记录系统是否出现雪崩（错误率飙升）、资源是否耗尽（如数据库连接池满）、以及压力停止后的自恢复时间。这是最具破坏性也是最有价值的阶段，能暴露系统最脆弱的部分。

3. 十万级并发实战配置与部署

3.1 硬件与网络资源配置建议

兵马未动，粮草先行。硬件是压测的基石，配置不当会导致测试结果失真，甚至先把自己压垮。

Worker节点配置（计算型密集型）：

• CPU：核心数至关重要。Locust的协程虽然在IO等待时能释放控制权，但在解析响应、生成下一个任务时仍需CPU。建议选择高频多核的CPU。我的经验公式是：单核可稳定支撑约500-800个简单HTTP请求的虚拟用户。对于16核的机器，支撑8000-12000用户是合理的预期。
• 内存：每个Locust协程（用户）占用内存很小，通常1-2KB。1万个用户也就20MB左右。主要内存消耗在Python运行时和请求响应数据上。32GB内存对于单节点万级并发绰绰有余，留有充足缓冲。
• 网络：节点间通信带宽和被测系统出口带宽是关键。如果Worker与被测系统不在同一机房，网络延迟和带宽可能成为瓶颈。建议Worker集群与被测系统处于同一内网或可用区。节点间（Master-Worker）通信流量不大，但要求低延迟、稳定。
• 系统限制：Linux系统默认的单个进程可打开文件数（ulimit -n）和本地端口范围可能限制高并发连接。务必提前调整。

  # 修改系统限制，需sudo权限或root用户 echo "* soft nofile 65535" >> /etc/security/limits.conf echo "* hard nofile 65535" >> /etc/security/limits.conf # 扩大本地端口范围 sysctl -w net.ipv4.ip_local_port_range="1024 65000" # 生效需要重启或重新登录

Master节点配置（管理型）：

• 资源需求低。2核4GB足够。确保其网络能与所有Worker节点互通。

3.2 分布式集群启动与配置详解

配置好环境后，启动集群就几条命令，但细节决定成败。

1. 启动Master节点：假设Master节点的IP是192.168.1.100，测试脚本是stress_test.py。

# 在Master节点上执行 locust -f stress_test.py --master --host=http://your-target-system.com --web-host=0.0.0.0 --web-port=8089

• --master: 指定该节点为Master。
• --host: 指定被测系统的基地址。
• --web-host和--web-port: 指定Web UI监听的地址和端口，0.0.0.0表示允许任何IP访问。
• --expect-workers=10: 这是一个非常有用的参数，告诉Master你期望有10个Worker连接。当所有Worker都连接上后，Web UI上会显示就绪，可以避免Worker还没启动完就误开始测试。

2. 启动Worker节点：在每一台Worker服务器上执行。

# 在Worker节点上执行 locust -f stress_test.py --worker --master-host=192.168.1.100

• --worker: 指定该节点为Worker。
• --master-host: 指定Master节点的IP地址或主机名。
• --master-port: 如果Master修改了默认通信端口（5557），则需要用此参数指定。

注意：所有Worker节点上的stress_test.py脚本必须完全一致。最好通过版本控制工具（如Git）进行管理，确保同时部署同一版本。脚本中引用的任何资源文件（如CSV数据文件）也需要在各Worker节点相同路径下存在。

3. 验证集群状态：打开浏览器，访问http://192.168.1.100:8089。在Locust的Web UI中，你应该能看到“已就绪的Worker数量”与你启动的Worker数一致。这时，你就可以在UI上设置总用户数、每秒启动速率，并开始压测了。

3.3 高级负载模型设计：模拟真实流量曲线

在UI上手动设置用户数太粗糙了。对于复杂的压测场景，我们需要用代码定义负载模型。Locust的LoadTestShape类是我们的利器。

例如，要模拟一个“双十一”零点秒杀的流量洪峰：

from locust import LoadTestShape class SpikeLoadShape(LoadTestShape): """ 模拟秒杀场景的负载形状： 1. 预热期：缓慢增长，预热系统。 2. 飙升期：瞬间达到峰值，模拟零点抢购。 3. 峰值保持期：维持高压一段时间。 4. 衰退期：缓慢下降。 """ time_limit = 1800 # 总测试时间30分钟 stages = [ {"duration": 300, "users": 5000, "spawn_rate": 100}, # 第0-5分钟：缓慢增长到5000用户 {"duration": 60, "users": 100000, "spawn_rate": 5000}, # 第5-6分钟：瞬间飙升至10万用户（关键！） {"duration": 300, "users": 100000, "spawn_rate": 1000},# 第6-11分钟：保持10万用户压力 {"duration": 600, "users": 20000, "spawn_rate": 500}, # 第11-21分钟：下降至2万用户 {"duration": 240, "users": 0, "spawn_rate": 100}, # 第21-25分钟：用户退出，测试结束 ] def tick(self): run_time = self.get_run_time() for stage in self.stages: if run_time < stage["duration"]: return (stage["users"], stage["spawn_rate"]) run_time -= stage["duration"] return None

在启动Master时，使用--shape-class参数指定这个类：

locust -f stress_test.py --master --shape-class=SpikeLoadShape

这个模型能精准地测试系统在流量陡增时的弹性能力，比如自动扩容是否及时、缓存是否被击穿、数据库连接池是否够用。

4. 性能监控与瓶颈定位三维体系

压测不只是发请求，更重要的是观测。你需要建立一个从宏观业务指标到微观系统资源的立体监控体系。

4.1 第一维度：核心性能指标监控

这是Locust Web UI直接提供的，也是我们最关注的业务层指标。

• 吞吐量（RPS， Requests Per Second）：每秒完成的请求数。这是衡量系统处理能力的核心。在压测过程中，你需要观察RPS曲线是否随着并发用户数增长而平稳上升。如果用户数翻倍，但RPS几乎不变，甚至下降，说明系统遇到了瓶颈。
• 响应时间（Response Time）：要特别关注分位数，而不仅仅是平均值。
  • 50%分位（中位数）：代表大多数用户的体验。它主要受网络延迟和应用基础处理时间影响。
  • 95%分位与99%分位（P95， P99）：这是黄金指标。它们反映了尾部用户的体验。P95/P99响应时间飙升，通常意味着系统存在资源竞争或阻塞。例如：
    • P95升高：可能指向应用服务器线程池排队、数据库慢查询增多。
    • P99飙升：可能指向个别极端情况，如数据库死锁、某台服务器故障、缓存穿透导致直接访问数据库。
• 错误率（Failure Rate）：任何非2xx/3xx的HTTP状态码或未捕获的异常都会被记为失败。压测中，错误率需要密切监控。一个健康的系统在稳态压力下错误率应接近于0。错误率上升是系统过载或存在缺陷的明确信号。

实操心得：不要只盯着总览图。Locust UI可以下载每次请求的CSV明细数据。将其导入到Grafana或甚至用Excel/Python分析，你可以绘制出响应时间分布直方图，更精确地定位是哪些接口、在什么时间点出现了性能劣化。

4.2 第二维度：系统资源监控

当业务指标出现异常时，我们需要向下钻取，查看服务器本身的资源状态。这里推荐使用node_exporter+Prometheus+Grafana这套组合。

• CPU使用率：使用vmstat 1或top命令。重点看us（用户态）和sy（内核态）CPU。如果sy占比过高，可能意味着系统调用频繁，存在大量IO等待或上下文切换。
• 内存使用：使用free -h。关注available内存。如果内存使用率持续增长且不释放，可能存在内存泄漏。对于Locust Worker本身，可以用ps aux | grep locust查看其RSS（常驻内存集）大小。
• 磁盘IO：使用iostat -x 2。关注%util（利用率）和await（平均等待时间）。如果%util持续接近100%，说明磁盘已是瓶颈。对于写日志频繁的应用，这很常见。
• 网络IO：使用iftop或nethogs。观察网络带宽是否打满，以及是否有大量的重传（Retr），这暗示网络不稳定。

建立监控仪表盘：将上述指标和Locust的RPS、响应时间整合在同一个Grafana看板上，可以非常直观地看到：当并发用户数上升时，CPU先达到瓶颈，还是数据库连接数先满，或是网络带宽先占满。这种关联性分析是定位瓶颈的关键。

4.3 第三维度：被测应用与中间件监控

这是最深的一层，需要被测系统具备相应的监控能力。

• 应用服务器（如Tomcat, Spring Boot Actuator）：监控线程池活跃线程数、队列大小。如果队列满了，请求就会被拒绝或等待。
• 数据库（如MySQL）：监控活跃连接数、慢查询数量、锁等待情况。SHOW PROCESSLIST;和SHOW ENGINE INNODB STATUS;是救命命令。
• 缓存（如Redis）：监控连接数、内存使用率、命中率、每秒操作数。连接数耗尽是压测中常见问题。
• 消息队列（如Kafka, RabbitMQ）：监控消息堆积数、生产/消费速率。
• 外部依赖API：如果系统调用第三方服务，必须监控其响应时间和可用性。一个慢速的外部API可以拖垮整个系统。

瓶颈定位流程：当P95响应时间变长时，遵循以下路径排查：

1. 看应用错误日志，是否有大量异常抛出。
2. 看应用服务器监控，线程池是否健康。
3. 看数据库监控，是否有慢查询或锁等待。
4. 看缓存监控，命中率是否骤降。
5. 看系统资源监控，CPU/内存/IO是否饱和。

5. 实战案例：电商秒杀场景压测与调优

理论说再多，不如一个实战案例。我们模拟一个“秒杀1000件商品”的场景，目标是验证系统在10万并发抢购下的表现。

5.1 测试脚本设计要点

from locust import HttpUser, task, between from faker import Faker import random fake = Faker() class QuickBuyUser(HttpUser): wait_time = between(1, 3) # 用户任务间等待1-3秒，更真实 def on_start(self): """用户初始化：登录并获取令牌""" # 使用参数化数据，避免所有用户用同一账号 self.username = fake.user_name() self.email = fake.email() login_resp = self.client.post("/api/login", json={"username": self.username, "password": "default_pwd"}) if login_resp.status_code == 200: self.token = login_resp.json()["token"] self.headers = {"Authorization": f"Bearer {self.token}"} else: # 登录失败，此用户后续任务不会执行 self.stop() @task(3) # 权重为3，执行频率更高 def browse_product(self): """浏览商品详情页""" product_id = random.randint(1, 100) with self.client.get(f"/api/product/{product_id}", headers=self.headers, catch_response=True) as resp: if resp.status_code != 200: resp.failure(f"Browse failed: {resp.status_code}") @task(1) def quick_buy(self): """核心：秒杀下单""" # 1. 进入秒杀接口，获取秒杀资格和令牌 seckill_resp = self.client.post("/api/seckill/1001/enter", headers=self.headers) if seckill_resp.status_code != 200: return verify_token = seckill_resp.json().get("verifyToken") # 2. 提交秒杀请求 payload = { "productId": 1001, "verifyToken": verify_token, "addressId": random.randint(1, 10) } with self.client.post("/api/order/seckill", json=payload, headers=self.headers, catch_response=True) as resp: # 对结果进行精细化判断 if resp.status_code == 200: order_data = resp.json() if order_data.get("code") == "SUCCESS": resp.success() elif order_data.get("code") == "SOLD_OUT": resp.success() # 商品售罄是业务正常结果，不算失败 else: resp.failure(f"Order failed with code: {order_data.get('code')}") elif resp.status_code == 429: # Too Many Requests， 限流 resp.success() # 被限流也是系统设计的正常表现 else: resp.failure(f"HTTP error: {resp.status_code}")

脚本关键点：

1. 参数化：使用Faker库为每个虚拟用户生成唯一的用户名、邮箱，避免数据库唯一约束冲突和缓存热点。
2. 状态保持：在on_start中登录并保存token，模拟有状态会话。
3. 任务权重：通过@task(weight)设置不同任务执行的概率，模拟用户行为比例（浏览多，下单少）。
4. 精细化响应校验：使用catch_response=True和手动调用success()/failure()，区分HTTP成功但业务失败（如售罄、库存不足）和真正的系统错误（如5xx）。这对于计算真实的系统错误率至关重要。

5.2 压测过程与发现的问题

我们按照“阶梯加压”模型，最终在15分钟内将并发用户数提升至10万。压测仪表盘显示：

• RPS：在8万并发时达到峰值12,000 RPS，之后不再增长。
• P99响应时间：在并发超过6万后，从200ms飙升至2s以上。
• 错误率：在峰值时达到0.5%，主要是HTTP 500和少量超时。

结合系统监控，我们发现了以下瓶颈：

1. Redis连接池耗尽：应用服务器配置的Redis连接池最大连接数为5000。当并发用户激增时，大量协程同时尝试获取连接，导致连接池瞬间被占满，后续请求等待超时或失败。
2. 数据库慢查询：订单创建后，有一个更新用户积分历史的操作，关联查询了一张大表，未使用索引。在高压下，该SQL执行时间从10ms恶化到800ms，阻塞了数据库连接。
3. 应用服务器线程池排队：虽然我们用了异步非阻塞框架，但某个外部HTTP客户端调用是同步的，且未配置合理的超时和熔断，导致部分请求线程被长时间挂起。

5.3 优化措施与效果验证

针对以上问题，我们协同开发团队进行了紧急优化：

1. 动态连接池调整：将Redis连接池最大连接数扩大到8000，并设置了合理的空闲连接超时时间。同时，在应用代码中增加了连接获取失败时的快速失败和降级逻辑（如直接返回“活动太火爆”）。
2. 数据库优化：为积分历史表的user_id和create_time字段添加了联合索引，使该慢查询速度恢复到20ms以内。同时，在代码层面将该操作改为异步处理，不阻塞主下单流程。
3. 同步调用改造：将那个外部HTTP客户端调用改为异步非阻塞方式，并设置了200ms的超时和熔断器，防止一个慢速依赖拖垮整个服务。

优化后复测结果：

• RPS：在10万并发下稳定在15,000 RPS。
• P99响应时间：维持在500ms以内。
• 错误率：降至0.02%以下（主要是正常的售罄和限流）。

6. 分布式压测七大避坑指南

踩过的坑，都是宝贵的经验。以下是我在多次大规模分布式压测中总结出的七个关键陷阱：

陷阱一：时钟不同步

• 现象：Master和Worker服务器时间不一致，导致聚合的统计数据时间戳错乱，响应时间计算不准，甚至触发一些基于时间的断言失败。
• 解决方案：所有压测集群节点（包括Master和Worker）必须使用NTP（网络时间协议）同步到同一时间源。时间偏差应控制在50毫秒以内。在Linux上，可以使用chronyd或ntpd服务。

陷阱二：网络分区与延迟

• 现象：Worker节点偶尔失联，Web UI显示Worker数波动；或者测试数据上报延迟，导致实时图表“跳变”。
• 解决方案：
  1. 确保所有节点处于同一低延迟内网。跨机房、跨公网的部署方案不可取。
  2. 使用ping和mtr命令检查节点间网络质量，延迟应稳定在2ms以下，无丢包。
  3. 如果必须跨网络，考虑在目标网络区域内部署一套完整的Master-Worker子集群，然后通过Locust的第三方扩展（如使用消息队列）进行数据聚合，但这会引入复杂度。

陷阱三：测试数据污染与热点

• 现象：大量用户使用相同的账号、商品ID进行请求，导致数据库锁竞争激烈，缓存命中个别Key，无法模拟真实分散的用户行为。
• 解决方案：坚决使用参数化工厂。像上面的例子一样，用Faker、自定义ID生成器等方式，为每个虚拟用户生成唯一或随机的测试数据。对于需要提前准备的测试数据（如用户账号），可以预生成一个大的CSV或JSON文件，让每个Worker读取并使用其中不同的部分。

陷阱四：资源泄漏（端口、内存、连接）

• 现象：压测运行一段时间后，Worker节点内存持续增长，或者出现“Cannot assign requested address”错误（端口耗尽）。
• 解决方案：
  1. 端口耗尽：调整系统net.ipv4.ip_local_port_range，扩大可用端口范围。确保Locust的HttpUser使用了requests.Session的连接池（默认就是），并且合理设置连接池大小和超时。
  2. 内存泄漏：编写Locust脚本时，避免在任务方法中不断创建全局对象或大对象。定期对Worker进程进行内存分析（如使用memory_profiler）。
  3. 连接未关闭：虽然requests库会自动管理连接，但在异常情况下仍需注意。确保所有请求都在with语句或try-finally块中，或在teardown方法中清理资源。

陷阱五：Master节点单点故障

• 现象：Master节点宕机，整个压测停止，且实时数据丢失。
• 解决方案：Locust原生Master有单点风险。对于生产级长期压测，可以考虑：
  1. 使用--master的--expect-slaves参数，并编写脚本监控Worker连接状态，实现简单的存活检测。
  2. 采用第三方扩展，如locust-swarm或boomer（Go语言编写的Worker），它们支持更健壮的集群管理。
  3. 最重要的：定期通过API导出测试数据。Locust Master提供了/stats/requests/csv等API端点，可以定时将数据导出到外部时序数据库（如InfluxDB）进行持久化，这样即使Master重启，历史数据仍在。

陷阱六：忽略系统监控，只关注Locust UI

• 现象：Locust UI显示一切正常，但被测系统实际已濒临崩溃（如数据库CPU 100%）。
• 解决方案：建立端到端的监控视角。压测工程师的屏幕上至少应该同时打开：1) Locust Web UI， 2) 被测系统应用监控（如APM）， 3) 服务器资源监控（如Grafana）， 4) 中间件监控（如Redis， MySQL）。任何一处的异常波动都需要关联分析。

陷阱七：一次压测时间过长或过短

• 现象：压测运行几分钟就结束，发现不了内存泄漏或连接池缓慢增长的问题；或者一次压测运行几小时，结果数据过于庞杂，难以分析。
• 解决方案：设计组合式压测场景。
  • 稳定性测试：中低压力（如30%最大并发）长时间运行（如8-12小时），检查系统是否有内存泄漏、性能是否缓慢退化。
  • 峰值压力测试：高压力短时间运行（如30分钟），使用LoadTestShape模拟尖峰，检验系统弹性。
  • 疲劳测试：在峰值压力后，迅速降至中等压力并维持，观察系统恢复情况。 每次压测目标明确，时间控制在1-2小时内完成数据收集和分析，效率更高。

最后，我想说的是，十万并发压测不是一个简单的工具执行过程，而是一个系统的工程实践。它要求测试人员不仅熟悉Locust工具本身，更要深入理解被测系统的架构、业务逻辑和依赖组件。从精准的脚本编写，到合理的集群规划，再到立体的监控分析和有效的瓶颈定位，每一步都需要严谨和耐心。当你看到系统在精心设计的压力下暴露出问题，并通过优化使其变得更强健时，那种成就感，正是性能测试工作的魅力所在。