使用 redis 实现消息队列

    • [方案1: 使用list做消息队列](#方案1: 使用list做消息队列)
        • [问题1: 如何保证消息不丢失](#问题1: 如何保证消息不丢失)
        • [问题 2: 重复消费/幂等](#问题 2: 重复消费/幂等)
    • [方案 2: zset实现消息队列](#方案 2: zset实现消息队列)
    • [方案 3: 发布/订阅(pub/sub)](#方案 3: 发布/订阅(pub/sub))
        • [问题1: 如何保证消息不丢失](#问题1: 如何保证消息不丢失)
        • [问题 2: 重复消费/幂等](#问题 2: 重复消费/幂等)
    • [方案 4: Stream 实现消息队列](#方案 4: Stream 实现消息队列)
        • [问题1: 如何保证消息不丢失](#问题1: 如何保证消息不丢失)
        • [问题 2: 重复消费/幂等](#问题 2: 重复消费/幂等)

方案1: 使用list做消息队列

  • 生产消息: LPUSH
  • 消费消息: RPOP
问题1: 如何保证消息不丢失
  1. 生产者不丢失: 失败重试
  2. 消费者不丢失: POP同时储存到另一个(zset: score 为当前时间的时间戳)做临时备份,ACK 后删除临时备份的数据;定时将超时没有 ACK 的消息重新投入消息队列(做一个定时任务)
  3. redis 不丢失: 使用 kafka 类似的逻辑,集群所有从节(冗余节点)点写成功才算成功.
问题 2: 重复消费/幂等
  • 唯一 Id 做去重(消费者)

方案 2: zset实现消息队列

  • zset 与 list 的核心区别

    • 消费后消息不会自动在 zset 中删除,需要手动删除
    • 排序方式: list 是根据加入消息的先后顺序排的;而 zset 根据 score 进行排序的
  • zset 适合做延时消息队列(比如到一段时间消费的任务)

方案 3: 发布/订阅(pub/sub)

  • 生产: PUBLISH 命令
  • 消费(订阅): SUBSCRIBE 命令
问题1: 如何保证消息不丢失
  1. 生产者不丢失: 发送失败重试
  2. 消费者不丢失: 消费者没有接收到消息(网络问题/之前没有消费的消息)就会丢失,无法找回!
  3. redis 不丢失: 使用 kafka 类似的逻辑,集群所有从节(冗余节点)点写成功才算成功.
问题 2: 重复消费/幂等
  • 唯一 Id 做去重(消费者)

  • 发布/订阅的方式可以有多个消费者,多次消费; 但是有消息丢失的风险

方案 4: Stream 实现消息队列

  • 生产: XADD
  • 普通消费: XREAD
  • 消费者组消费:XREADGROUP GROUP

具体参考:https://www.runoob.com/redis/redis-stream.html

问题1: 如何保证消息不丢失
  1. 生产者不丢失: 失败重试
  2. 消费者不丢失: 有 ack 机制;在消费逻辑执行完成后再 ack,保证 "最少一次" 消费
问题 2: 重复消费/幂等
  • 生产的时候使用唯一 Id 作为消息的 key
  • 消费者使用唯一 Id 做去重
相关推荐
NineData3 小时前
NineData 迁移评估功能正式上线
数据库·dba
雨中飘荡的记忆7 小时前
大流量下库存扣减的数据库瓶颈:Redis分片缓存解决方案
java·redis·后端
NineData8 小时前
数据库迁移总踩坑?用 NineData 迁移评估,提前识别所有兼容性风险
数据库·程序员·云计算
赵渝强老师10 小时前
【赵渝强老师】PostgreSQL中表的碎片
数据库·postgresql
全栈老石14 小时前
拆解低代码引擎核心:元数据驱动的"万能表"架构
数据库·低代码
曲幽16 小时前
FastAPI分布式系统实战:拆解分布式系统中常见问题及解决方案
redis·python·fastapi·web·httpx·lock·asyncio
倔强的石头_1 天前
kingbase备份与恢复实战(二)—— sys_dump库级逻辑备份与恢复(Windows详细步骤)
数据库
jiayou643 天前
KingbaseES 实战:深度解析数据库对象访问权限管理
数据库
李广坤3 天前
MySQL 大表字段变更实践(改名 + 改类型 + 改长度)
数据库
爱可生开源社区4 天前
2026 年,优秀的 DBA 需要具备哪些素质?
数据库·人工智能·dba