本文介绍在 k6 分布式压测场景下，如何让所有 vu 共享一个全局有效的 jwt/access token，并在过期前统一刷新——通过 redis 实验模块实现跨 vu 状态同步，解决单点 token 管理难题。
本文介绍在 k6 分布式压测场景下，如何让所有 vu 共享一个全局有效的 jwt/access token，并在过期前统一刷新——通过 redis 实验模块实现跨 vu 状态同步，解决单点 token 管理难题。
在 K6 中，每个虚拟用户（VU）运行于独立的 JavaScript 运行时环境中，彼此内存隔离、无法直接共享变量或状态。这意味着 setup() 获取的初始 token 仅对当前 VU 有效；而当 token 需在运行中（如 1 小时后）统一刷新时，传统方式（如重启场景、修改全局变量）均无效——已运行的 VU 不会感知变更，导致鉴权失败或请求混杂多套 token。
✅ 正确解法：借助 Redis 实现跨 VU Token 协调
K6 官方提供的实验性模块 k6/x/redis 是目前最可靠、生产就绪度较高的方案。它允许 VU 通过 Redis 服务读写共享状态，天然支持原子操作与阻塞等待，完美契合“单点刷新、全量同步”的需求。
? 基础配置准备
- 启动 Redis 服务（本地或远程均可）：
docker run -d -p 6379:6379 --name k6-redis redis:alpine
- 在脚本中启用实验模块（需使用 k6 v0.45+）：
import redis from 'k6/x/redis';
? 推荐架构：双场景协同模式
将负载逻辑与 token 管理职责分离，提升可维护性与稳定性：
| 场景 | VUs 数量 | 职责 |
|---|---|---|
| token-manager | 1 | 定期调用 /auth/refresh 接口，获取新 token 并写入 Redis（如每 55 分钟执行一次） |
| main-test | 100+ | 每次请求前从 Redis 读取最新 token，自动阻塞等待（避免空值） |
? 示例代码（完整可运行）
import { sleep, check } from 'k6';
import http from 'k6/http';
import { SharedArray } from 'k6/data';
import redis from 'k6/x/redis';
// 初始化 Redis 客户端（连接本地 Redis）
const redisClient = redis.connect('redis://localhost:6379');
// Token 缓存键名（建议加前缀防冲突）
const TOKEN_KEY = 'k6:shared:auth_token';
export const options = {
scenarios: {
// 【场景1】Token 管理者：单 VU，周期性刷新
'token-manager': {
executor: 'constant-vus',
vus: 1,
duration: '2h',
exec: 'refreshToken',
},
// 【场景2】主压测：多 VU，并发执行业务请求
'main-test': {
executor: 'ramping-vus',
startVUs: 10,
stages: [
{ duration: '30s', target: 50 },
{ duration: '2m', target: 100 },
{ duration: '30s', target: 10 },
],
exec: 'makeApiRequest',
},
},
};
// ✅ 场景1：刷新 Token（单 VU 执行）
export function refreshToken() {
// 模拟调用刷新接口（实际需替换为真实 endpoint + refresh_token）
const res = http.post('https://api.example.com/auth/refresh', JSON.stringify({
refresh_token: __ENV.REFRESH_TOKEN,
}), {
headers: { 'Content-Type': 'application/json' }
});
if (res.status === 200) {
const data = res.json();
const newToken = data.access_token;
// 写入 Redis，设置 1 小时过期（与 token 实际有效期对齐）
redisClient.setex(TOKEN_KEY, 3600, newToken);
console.log(`✅ Token refreshed and stored in Redis: ${newToken.slice(0, 12)}...`);
} else {
console.error(`❌ Token refresh failed: ${res.status} ${res.body}`);
}
}
// ✅ 场景2：业务请求（所有 VU 执行）
export function makeApiRequest() {
// 阻塞式读取（若 key 不存在则等待，超时抛错）
let token;
try {
token = redisClient.get(TOKEN_KEY);
if (!token) throw new Error('Token not available');
} catch (e) {
console.warn(`⚠️ Failed to get token from Redis: ${e.message}. Retrying...`);
sleep(1); // 短暂退避后重试（生产环境建议加指数退避）
token = redisClient.get(TOKEN_KEY);
}
// 发起带认证的请求
const res = http.get('https://api.example.com/data', {
headers: { Authorization: `Bearer ${token}` }
});
check(res, {
'status is 200': (r) => r.status === 200,
'token present': () => !!token,
});
}⚠️ 关键注意事项
- Redis 高可用：生产环境务必部署 Redis 主从或集群，避免单点故障导致全量 VU 请求失败。
- Token 安全性：不要在日志中打印完整 token（示例中已做 slice 截断），敏感字段建议通过 __ENV 注入而非硬编码。
- 错误容错：redisClient.get() 在 key 不存在时返回 null，需主动判空并重试；建议封装 getTokenWithRetry() 工具函数。
- 刷新频率策略：推荐设为 token 过期时间的 80%（如 60min token → 每 48min 刷新），预留网络延迟与处理缓冲。
-
替代方案对比：
❌ 文件系统（open() / writeFileSync）→ 不支持并发写、无跨进程同步；
❌ HTTP Server（自建中继）→ 增加运维复杂度、引入额外延迟；
✅ Redis → 原子性、低延迟、成熟生态，是 K6 社区事实标准方案。
✅ 总结
K6 的 VU 隔离设计虽保障了压测稳定性，但也要求开发者主动采用外部协调机制来管理共享状态。通过 k6/x/redis 模块构建“单写多读”的 token 管理管道，不仅能精准实现全 VU 一致的认证上下文，还可扩展至共享限流计数器、动态测试数据、灰度开关等高级场景。记住核心原则：状态外置、职责分离、失败可退——这是构建高可靠性分布式压测脚本的基石。
