Redis Pub/Sub 不能传输大文件分片内容，仅适合广播轻量状态变更和协调信号；因其纯内存、无持久化、无ACK、不支持断点续传，且单消息建议≤1MB，超限易截断或阻塞。
Redis 的 Pub/Sub 不能直接用于传输大文件分片数据，但能高效同步分片上传的「状态变更」和「协调信号」。用它传文件内容本身是错的——内存溢出、消息丢失、无重试、不支持二进制，这些坑踩过就明白。
为什么不能用 PUBLISH 发送分片文件本身
Pub/Sub 是纯内存广播机制，消息不持久、不保证送达、无 ACK、单条消息最大默认 512MB（实际建议 ≤1MB）。分片文件动辄几 MB，一发就可能触发 ERR wrong number of arguments 或直接被 Redis 截断；更关键的是，订阅者离线期间消息全丢，无法支撑断点续传这种强状态场景。
- 分片数据必须走 MinIO/S3 等对象存储，
PUBLISH只能发元数据 - 典型错误：把
chunkBytes直接塞进PUBLISH file:upload:status "{...}"→ 内存暴涨 + 频道阻塞 - 正确做法：只发轻量事件，如
{"file_id":"abc123","chunk_index":5,"status":"uploaded"}
PUB/SUB 在分片上传中真正该承担的角色
它适合做「轻量状态广播」和「跨服务协调」，比如通知合并服务开始校验、触发清理任务、或让多个上传节点感知彼此进度。核心是解耦，不是搬运。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 发布频道建议按语义分层：
file:upload:progress（实时进度）、file:upload:complete（所有分片就绪）、file:merge:trigger（合并指令） - 订阅方收到
file:upload:complete后，再主动调用GET file_upload:abc123从 Hash 中拉取完整状态，而不是依赖 Pub/Sub 消息里带全字段 - 避免在频道名里拼接动态 ID（如
file:upload:abc123），否则订阅端要动态监听无数频道，管理成本爆炸
如何避免 pubsub 消息丢失导致状态不同步
Pub/Sub 本身不提供可靠性保障，所以关键状态变更必须「双写」：先落 Redis Hash（持久化可查），再 PUBLISH 广播事件。订阅方收到后，仍需回查 Hash 确认最新状态，而非盲目信任消息内容。
- 例如：分片 7 上传成功 → 先执行
HSET file_upload:abc123 chunk_7 "done"，再PUBLISH file:upload:progress "{...}" - 合并服务监听
file:upload:complete，但真正执行前必须HGETALL file_upload:abc123校验全部分片是否存在且status=done - 如果合并失败，不要删 Hash 数据——下次重试时仍可复用，而 Pub/Sub 消息已不可追溯
并发上传下如何用 INCR + PUBLISH 做进度聚合
多个前端实例/线程并发上传同一文件的不同分片时，可用 INCR 原子计数 + PUBLISH 推送当前进度，比轮询更实时，又比每个分片都发一次更轻量。
- 初始化：
SET file_progress:abc123 0+EXPIRE file_progress:abc123 86400 - 每完成一个分片：
INCR file_progress:abc123，然后PUBLISH file:upload:progress "{"file_id":"abc123","current":N,"total":20}" - 注意：不要用
INCR替代 Hash 存储分片明细——它没法告诉你哪个分片缺了，只能看总数
真正容易被忽略的是：Pub/Sub 的「广播」特性在多实例部署时会引发重复处理。比如 3 个合并服务实例都订阅了 file:upload:complete，一条消息就会触发 3 次合并。解决方法不是关掉 Pub/Sub，而是加分布式锁（SET lock:merge:abc123 "1" NX EX 30）或用唯一消费者组（Redis Stream 更合适，但那是另一套方案了）。
