使用 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 做去重
相关推荐
倔强的石头_20 小时前
KingbaseES 新版MySQL 兼容版体验:旧版迁移 + 功能实测
数据库
用户3169353811834 天前
Java连接Redis
redis
倔强的石头_4 天前
《Kingbase护城河》——数据库存储空间全景探测与精细化瘦身实战
数据库
冬奇Lab4 天前
每日一个开源项目(第134篇):Zvec - 阿里开源的嵌入式向量数据库,向量搜索界的 SQLite
数据库·人工智能·llm
ClouGence5 天前
Oracle CDC 架构优化:从主库直连到 DataGuard 备库同步
数据库·后端·oracle
无响应de神5 天前
三、用户与权限管理
数据库·mysql
小小工匠6 天前
Redis - 事务机制:能实现 ACID 属性吗
数据结构·redis·性能优化·并发·持久化
麦聪聊数据6 天前
数据服务化时代:企业数据能力输出的核心路径
数据库
shushangyun_6 天前
2026年快消品B2B系统推荐:支持终端门店订货、促销政策自动化的工具?
java·运维·网络·数据库·人工智能·spring·自动化
DARLING Zero two♡6 天前
【MySQL数据库】数据类型与表约束
数据库·mysql