导航在左侧的网站欣赏,google play store,wordpress如何登录界面,店铺装修公司怎么找分布式锁#xff1a;通过 Redis 来做分布式锁是一种比较常见的方式。通常情况下#xff0c;我们都是基于 Redisson 来实现分布式锁。关于 Redis 实现分布式锁的详细介绍#xff0c;可以看这篇文章#xff1a;分布式锁详解open in new window 。限流#xff1a;一般是通过 …分布式锁通过 Redis 来做分布式锁是一种比较常见的方式。通常情况下我们都是基于 Redisson 来实现分布式锁。关于 Redis 实现分布式锁的详细介绍可以看这篇文章分布式锁详解open in new window 。限流一般是通过 Redis Lua 脚本的方式来实现限流。相关阅读《我司用了 6 年的 Redis 分布式限流器可以说是非常厉害了》open in new window。消息队列Redis 自带的 List 数据结构可以作为一个简单的队列使用。Redis 5.0 中增加的 Stream 类型的数据结构更加适合用来做消息队列。它比较类似于 Kafka有主题和消费组的概念支持消息持久化以及 ACK 机制。延时队列Redisson 内置了延时队列基于 Sorted Set 实现的。分布式 Session 利用 String 或者 Hash 数据类型保存 Session 数据所有的服务器都可以访问。复杂业务场景通过 Redis 以及 Redis 扩展比如 Redisson提供的数据结构我们可以很方便地完成很多复杂的业务场景比如通过 Bitmap 统计活跃用户、通过 Sorted Set 维护排行榜。
Redis 可以做消息队列么 实际项目中也没见谁使用 Redis 来做消息队列对于这部分知识点大家了解就好了。 先说结论可以是可以但不建议使用 Redis 来做消息队列。和专业的消息队列相比还是有很多欠缺的地方。
Redis 2.0 之前如果想要使用 Redis 来做消息队列的话只能通过 List 来实现。
通过 RPUSH/LPOP 或者 LPUSH/RPOP即可实现简易版消息队列
# 生产者生产消息
RPUSH myList msg1 msg2
(integer) 2
RPUSH myList msg3
(integer) 3
# 消费者消费消息
LPOP myList
msg1不过通过 RPUSH/LPOP 或者 LPUSH/RPOP这样的方式存在性能问题我们需要不断轮询去调用 RPOP 或 LPOP 来消费消息。当 List 为空时大部分的轮询的请求都是无效请求这种方式大量浪费了系统资源。
# 超时时间为 10s
# 如果有数据立刻返回否则最多等待10秒
BRPOP myList 10
nullList 实现消息队列功能太简单像消息确认机制等功能还需要我们自己实现最要命的是没有广播机制消息也只能被消费一次。
Redis 2.0 引入了发布订阅 (pub/sub) 功能解决了 List 实现消息队列没有广播机制的问题。 pub/sub 中引入了一个概念叫 channel频道发布订阅机制的实现就是基于这个 channel 来做的。
pub/sub 涉及发布者Publisher和订阅者Subscriber也叫消费者两个角色
发布者通过 PUBLISH 投递消息给指定 channel。订阅者通过SUBSCRIBE订阅它关心的 channel。并且订阅者可以订阅一个或者多个 channel。
我们这里启动 3 个 Redis 客户端来简单演示一下 pub/sub 实现消息队列演示
pub/sub 既能单播又能广播还支持 channel 的简单正则匹配。不过消息丢失客户端断开连接或者 Redis 宕机都会导致消息丢失、消息堆积发布者发布消息的时候不会管消费者的具体消费能力如何等问题依然没有一个比较好的解决办法。
为此Redis 5.0 新增加的一个数据结构 Stream 来做消息队列。Stream 支持
发布 / 订阅模式按照消费者组进行消费借鉴了 Kafka 消费者组的概念消息持久化 RDB 和 AOFACK 机制通过确认机制来告知已经成功处理了消息阻塞式获取消息 Stream 的结构如下 这是一个有序的消息链表每个消息都有一个唯一的 ID 和对应的内容。ID 是一个时间戳和序列号的组合用来保证消息的唯一性和递增性。内容是一个或多个键值对类似 Hash 基本数据类型用来存储消息的数据。
这里再对图中涉及到的一些概念进行简单解释
Consumer Group消费者组用于组织和管理多个消费者。消费者组本身不处理消息而是再将消息分发给消费者由消费者进行真正的消费last_delivered_id标识消费者组当前消费位置的游标消费者组中任意一个消费者读取了消息都会使 last_delivered_id 往前移动。pending_ids记录已经被客户端消费但没有 ack 的消息的 ID。
下面是Stream 用作消息队列时常用的命令
XADD向流中添加新的消息。XREAD从流中读取消息。XREADGROUP从消费组中读取消息。XRANGE根据消息 ID 范围读取流中的消息。XREVRANGE与 XRANGE 类似但以相反顺序返回结果。XDEL从流中删除消息。XTRIM修剪流的长度可以指定修建策略MAXLEN/MINID。XLEN获取流的长度。XGROUP CREATE创建消费者组。XGROUP DESTROY 删除消费者组XGROUP DELCONSUMER从消费者组中删除一个消费者。XGROUP SETID为消费者组设置新的最后递送消息 IDXACK确认消费组中的消息已被处理。XPENDING查询消费组中挂起未确认的消息。XCLAIM将挂起的消息从一个消费者转移到另一个消费者。XINFO获取流(XINFO STREAM)、消费组(XINFO GROUPS)或消费者(XINFO CONSUMERS)的详细信息。
总的来说Stream 已经可以满足一个消息队列的基本要求了。不过Stream 在实际使用中依然会有一些小问题不太好解决比如在 Redis 发生故障恢复后不能保证消息至少被消费一次。
综上和专业的消息队列相比使用 Redis 来实现消息队列还是有很多欠缺的地方比如消息丢失和堆积问题不好解决。因此我们通常建议不要使用 Redis 来做消息队列你完全可以选择市面上比较成熟的一些消息队列比如 RocketMQ、Kafka。不过如果你就是想要用 Redis 来做消息队列的话那我建议你优先考虑 Stream这是目前相对最优的 Redis 消息队列实现。
