使用 Redis List 实现不丢数据的任务队列，推荐采用 BRPOPLPUSH 命令或将消息先备份到处理中列表再确认删除。该方案适合对可靠性要求中等、允许少量延迟的内部任务场景，主要风险边界在于 Redis 服务端宕机且未开启持久化时仍可能丢失数据。
先说结论：单纯使用 BRPOP 无法避免客户端崩溃导致的数据丢失，必须配合备份机制或 ACK 确认流程。
- 适合：内部异步任务、日志处理、对绝对一致性要求不高的业务场景。
- 先看：Redis 持久化配置（AOF/RDB）是否开启，网络超时设置是否合理。
- 建议：采用 BRPOPLPUSH 原子操作或将消息暂存到 Hash/ZSet 做 ACK 确认，处理成功后再删除。
命令速用版
直接使用 BRPOP 存在客户端拿到消息后崩溃导致消息消失的风险，建议使用 BRPOPLPUSH 将消息原子性地移动到备份列表。
BRPOPLPUSH source destination timeout LREM destination 0 value
source 是任务队列，destination 是处理中备份队列，timeout 设为具体秒数避免连接闲置断开。
为什么会这样
BRPOP 命令的特性是移除列表元素并返回给客户端，此时 Redis 服务端不再持有该数据。如果客户端在处理元素的过程中崩溃，那么这个元素就永远丢失了，因为它只存在于客户端的上下文中。解决方案的核心在于在获取任务时保存任务到备份结构，处理成功后再删除备份，确保任务在处理失败或崩溃时可找回。
分步处理
第一步，开启 Redis 持久化以防止服务端宕机丢失数据，根据实际需求选择 RDB 或 AOF 策略，高可靠性场景建议配置每次变更同步写入磁盘。第二步，消费者使用 BRPOPLPUSH 命令从源队列取出消息并推送到“处理中”队列，这一步是原子操作，保证消息不会在转移过程中丢失。第三步，业务逻辑处理消息，处理成功后使用 LREM 命令从“处理中”队列删除该消息。第四步，实现定时任务扫描“处理中”队列，将超时未确认的消息重新投入源队列，防止消费者死锁导致任务积压。
怎么验证是否生效
检查“处理中”队列的长度，正常空闲状态下该队列长度应接近零。模拟消费者进程在处理消息时强制崩溃，观察“处理中”队列是否残留消息，并确认定时任务是否能将残留消息重新放回源队列。查看 Redis 日志确认持久化策略是否生效，验证重启 Redis 服务后队列数据是否依然存在。
常见坑
BRPOP 的 timeout 参数必须显式设置，不能依赖默认值，否则 ctx 超时机制可能失效且闲置连接过久会被服务器主动断开。消费者未实现 ACK 确认机制，直接弹出消息后处理，一旦程序奔溃消息无法找回。Redis 服务端未开启持久化，断电或重启后内存中的数据全部丢失。多线程或多端并发处理时未加锁或未使用原子命令，可能导致消息重复消费或状态不一致。
常见问题
BRPOP 和 BRPOPLPUSH 有什么区别？
BRPOP 直接弹出并返回消息，消息离开 Redis 管控；BRPOPLPUSH 将消息从源列表弹出并推入目标列表，消息仍在 Redis 管控中，适合做安全队列备份。
Redis 队列能保证消息百分百不丢吗？
不能绝对保证，除非配置实时持久化且消费端实现事务和重发机制，但这会严重影响性能，通常互联网业务容忍极短时间内少量数据丢失以换取更高性能。
超时时间 timeout 应该设多少？
必须显式设置具体秒数，例如 30 秒，避免设为 0 导致无限阻塞连接闲置，具体数值需根据业务处理耗时和网络稳定性调整。
参考来源
- redis brpop 如何避免消息丢失
- Redis 实现队列 - 程序员老徐 - 博客园
- redis 消息队列如何防止数据丢失
- Golang 怎么用 Redis 实现消息队列_Golang 如何用 List 或 Stream 做轻量级任务队列【实战】
- 使用 redis 实现消息队列