本文详解如何在 node.js 中高效、安全地批量读取 redis 中多个以 user:gxxxx 格式命名的有序列表（list），并按员工 id 映射结构化返回，规避异步并发导致的客户端关闭错误及数据错位问题。
在构建高并发调度系统时，常需从 Redis 快速拉取大量员工（如 G1257, G1189）关联的排班记录——每条记录以 JSON 字符串形式存储于独立 LIST 中（键为 user:{empid}）。若采用循环 + 回调方式逐个 lRange 查询（如原始代码），不仅因 Node.js 事件循环与 Redis 客户端生命周期不匹配而触发 ClientClosedError，更会因异步竞态导致结果顺序错乱、empid 映射丢失。
✅ 正确解法是：使用 Redis 事务管道（MULTI/EXEC）实现原子性批量命令提交，配合 async/await 保证执行流可控，并在结果解析阶段严格对齐原始人员顺序。
✅ 推荐实现：基于 multi.exec() 的批处理方案
以下为生产就绪的完整示例（适配 redis@4.x 及 Sequelize）：
const { promisify } = require('util');
const { createClient } = require('redis');
// 假设 client 已全局初始化并连接成功
const client = createClient({ url: 'redis://localhost:6379' });
await client.connect(); // 确保连接建立
router.get('/scheduler', async (req, res) => {
try {
// 1. 查询符合条件的员工列表（如按职级筛选）
const personnelList = await Personnel.findAll({
where: { mgr_wrkpersonnels_designation: req.query.mgr_wrkpersonnels_designation }
});
if (personnelList.length === 0) {
return res.json([]);
}
// 2. 构建 MULTI 批量命令：为每个 empid 发起 lRange 查询
const multi = client.multi();
personnelList.forEach(person => {
const empId = person.dataValues.mgr_wrkpersonnels_empid;
multi.lRange(`user:${empId}`, 0, -1); // 获取全部元素
});
// 3. 执行所有命令，返回扁平化结果数组（按入队顺序）
const rawResults = await multi.exec();
// 4. 解析结果：JSON.parse + 注入 empid，保持与 personnelList 索引一致
const schedules = rawResults.map((reply, idx) => {
if (reply instanceof Error || !Array.isArray(reply)) {
console.warn(`Failed to fetch list for ${personnelList[idx].dataValues.mgr_wrkpersonnels_empid}:`, reply);
return [];
}
const empId = personnelList[idx].dataValues.mgr_wrkpersonnels_empid;
return reply
.filter(item => typeof item === 'string' && item.trim())
.map(item => {
try {
const parsed = JSON.parse(item);
parsed.resource = empId; // 显式绑定员工标识
return parsed;
} catch (e) {
console.error(`Invalid JSON in list user:${empId}:`, item);
return null;
}
})
.filter(Boolean); // 过滤解析失败项
});
res.json(schedules);
} catch (error) {
console.error('[Scheduler API] Redis batch read error:', error);
res.status(500).json({ error: 'Failed to load schedules' });
}
});⚠️ 关键注意事项
- 绝不混用回调与 Promise：原始错误 ClientClosedError 根源在于 forEach + callback 模式下，client 可能在所有回调执行前被意外关闭（如中间件提前结束响应）。multi.exec() 返回 Promise，天然兼容 async/await，避免竞态。
- 索引强对齐：multi.exec() 返回结果数组严格按 multi.xxx() 调用顺序排列，因此 rawResults[i] 必然对应 personnelList[i]，这是实现 empid 准确映射的基石。
- 错误防御性处理：每个 lRange 结果可能为 Error 实例（如 key 不存在），需显式判断；JSON 解析也应 try/catch，防止单条脏数据阻断整个响应。
- 连接管理：确保 client.connect() 在应用启动时完成，且避免在请求中重复创建/关闭 client（除非使用连接池）。
- 性能边界：MULTI/EXEC 本质是将 N 条命令打包为一次 TCP 往返，大幅提升吞吐。但单次 lRange 若列表过长（如 >10k 元素），仍建议分页或改用 Sorted Set + ZRANGEBYSCORE 优化。
✅ 输出结构说明
最终返回为二维数组，每个子数组代表一位员工的完整排班列表，每项含原始字段（id, start, end）及新增 resource 字段（即 empid）：
[
[
{ "id": 2, "start": "2023-08-05T00:00:00", "end": "2023-08-12T00:00:00", "resource": "G1257" },
{ "id": 4, "start": "2023-08-14T00:00:00", "end": "2023-08-19T00:00:00", "resource": "G1257" }
],
[
{ "id": 2, "start": "2023-08-07T00:00:00", "end": "2023-08-08T00:00:00", "resource": "G1189" }
]
]此结构可直接被前端按 resource 分组渲染，兼顾性能、准确性与可维护性。
