serverless函数无法维持subscribe长连接，因执行环境短生命周期导致tcp连接随函数退出而断开；必须改用redis streams（xadd/xread）替代pub/sub，通过显式管理offset、幂等消费和连接复用实现可靠消息处理。
Serverless函数无法长期维持SUBSCRIBE连接
Serverless平台（如 AWS Lambda、阿里云函数计算、Vercel Edge Functions）的执行环境是短生命周期的：函数冷启动后执行完就销毁，不支持长连接。而 SUBSCRIBE 必须保持 TCP 连接活跃才能收消息，一旦函数退出，连接立即断开，后续消息全部丢失。
这意味着你不能在函数体内直接调用 subClient.subscribe() 然后等回调——它根本没机会触发。
- 别写
exports.handler = async () => { subClient.subscribe('x', cb); }—— 订阅刚注册，函数就结束了 - 别依赖定时器轮询
PSUBSCRIBE状态——Redis 不提供“当前有哪些订阅者”的查询接口，且轮询违背 Pub/Sub 设计初衷 - Serverless 场景下，
redis-py的PubSub类、ioredis的subscribe方法全都失效，不是库的问题，是运行模型冲突
必须用 Redis Streams 替代 Pub/Sub
Pub/Sub 在 Serverless 中本质不可用，但 XRANGE/XREAD 这类阻塞/非阻塞流读取命令可以封装成「一次拉取多条」的幂等消费逻辑，适配无状态函数。
关键改造点：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 发布端改用
XADD order:events * event "paid" order_id "123"，而非PUBLISH order:paid ... - 消费函数启动时调用
XREAD COUNT 10 STREAMS order:events $（首次用$读最新），后续用上一次返回的 ID + 1 继续读 - 消费成功后，**必须显式记录最后处理的 ID**（比如写入
order:events:last_read或外部数据库），否则重试会重复处理 - 避免用
XREAD BLOCK长阻塞——Serverless 函数有超时限制（Lambda 默认 15 分钟，但通常设为几秒），应改用非阻塞XREAD COUNT N STREAMS ...+ 重试机制
如何避免消息重复或遗漏
Serverless 函数可能被多次调用（如超时重试、平台调度异常），而 Redis Streams 本身不提供消费者组自动 ACK，全靠业务自己维护 offset。
- 每次
XREAD返回的消息 ID 要逐条解析，不要一次性全 ACK；推荐用HSET last_processed_ids order:events <last_id></last_id>存储每个 stream 的最新位置 - 如果函数执行中崩溃，未更新 offset，下次调用会从旧 ID 重读——这是设计所需，但要求消费逻辑**必须幂等**（例如用
SETNX order:123:paid_processed true EX 3600做去重标记） - 不要把 offset 存在内存里（如
let lastId = '0-0'）——函数实例不共享内存，每次都是新变量 - 注意
XADD的 ID 冲突风险：多生产者并发时，手动指定 ID 容易重复；优先让 Redis 自动生成（用*），再由消费端按自然顺序处理
冷启动延迟与连接复用技巧
Serverless 函数每次冷启动重建 Redis 连接耗时明显（DNS 解析 + TCP 握手 + AUTH），尤其在高频率触发时成为瓶颈。
- 利用平台提供的「实例复用」能力（如 Lambda 的容器重用）：把
redisClient实例声明在 handler 外部，连接后缓存，下次调用直接复用 - 连接时加
socket: { keepAlive: true }和retry_strategy，防止因短暂网络抖动导致整个函数失败 - 别在每次函数调用里
await client.connect()—— 应先检查client.isOpen（ioredis）或client.status === 'ready'（redis-py） - 如果使用连接池（如
redis.createPool），注意 Serverless 环境下连接数上限极低，建议 poolSize = 1～2，避免资源争抢
真正卡住多数人的不是语法，而是混淆了「开发本地能跑通」和「Serverless 环境可交付」——Pub/Sub 的连接模型与函数计算的生命周期天然互斥，绕不开就得换数据结构。Streams 不是“高级替代”，而是 Serverless 下唯一可行路径。
