Workerman 4 本身不直接提供 Redis Pipeline 功能，但可结合 phpredis 扩展实现高效异步批量命令；需在 Worker 启动时复用连接、调用 pipeline() 缓冲命令并显式 execute() 发送，分批执行（1000–5000 条/批），注意集群下按 slot 分组处理以避免跨槽错误。
Workerman 4 本身不直接提供 Redis Pipeline 功能，但可以结合 phpredis 扩展（推荐）或 redis-py（若用 Python 子进程）实现真正的异步批量命令。关键在于：Pipeline 是客户端行为，必须在连接层完成缓冲与批量发送，而 Workerman 的常驻进程特性恰好能复用连接、规避反复建连开销——这才是优化网络 IO 的核心前提。
用 phpredis + Pipeline 实现高效批处理
确保已安装 phpredis 扩展（v5.3+ 支持原生 pipeline），并在 Workerman Worker 中复用 Redis 连接实例：
- 不要每次请求都 new Redis()，应在 Worker 启动时初始化并保存为静态/属性变量
- 调用
$redis->pipeline()获取管道对象，连续添加命令（如 set、hSet、expire） - 必须显式调用
$pipe->execute()触发实际网络发送；不调用则命令永远滞留在内存中 - 建议按每 1000–5000 条命令分批执行，避免单次 payload 超过 Redis 默认 client-output-buffer-limit（256MB soft）
Workerman 中避免阻塞的关键点
phpredis 的 pipeline 默认是同步阻塞的，但可通过以下方式适配 Workerman 异步模型：
- 使用
Redis::setOption(Redis::OPT_READ_TIMEOUT, 0.1)设置短超时，防止某条命令卡死整个管道 - 禁用持久连接（
connect而非pconnect），因 Workerman 多进程下 pconnect 易引发连接错乱 - 对耗时长的批量操作（如 10 万条 mset），拆成多个子任务投递到
Worker::sendToWorkerProcess()或独立子进程，避免阻塞事件循环 - 不依赖 pipeline 的“原子性”——它只是批量发包，不保证事务；如需强一致性，应改用 MULTI/EXEC 或业务层重试
集群环境下 key 分组与并行处理
Redis Cluster 不允许跨 slot 批量命令。在 Workerman 中需提前路由：
- 用
Redis::cluster('SLOT', $key)或手动 CRC16 计算每个 key 对应 slot - 将待处理 key 按 slot 分组，每组单独创建 pipeline 并串行执行
- 若组数较多（如 > 4），可用
pcntl_fork或Worker::sendToWorkerProcess()并行处理不同 slot 组，显著缩短总耗时 - 慎用 hash tag（如
{user}:1001）强行归一 slot——虽简化逻辑，但易导致数据倾斜和热点问题
对比原生 M 命令的适用边界
MSET/MGET/HMSET 等原生命令虽快，但有硬限制：
- 只支持单一数据类型（MSET 仅 String，HMSET 仅 Hash），无法混合 set + hSet + expire
- 不支持带条件的命令（如 SETNX、EXPIRE 原子组合）
- 集群下同样要求所有 key 落在同一 slot，约束未减少
- 当需灵活编排多类型、多 key、带 TTL 的批量写入时，pipeline 是唯一可行方案
