百行代码实现基于Redis的可靠延迟队列

在之前探讨延时队列的文章中我们提到了 redisson delayqueue 使用 redis 的有序集合结构实现延时队列，遗憾的是 go 语言社区中并无类似的库。不过问题不大，没有轮子我们自己造????。

本文的完整代码实现在hdt3213/delayqueue，可以直接 go get 安装使用。

使用有序集合结构实现延时队列的方法已经广为人知，无非是将消息作为有序集合的 member, 投递时间戳作为 score 使用 zrangebyscore 命令搜索已到投递时间的消息然后将其发给消费者。

然而消息队列不是将消息发给消费者就万事大吉，它们还有一个重要职责是确保送达和消费。通常的实现方式是当消费者收到消息后向消息队列返回确认(ack)，若消费者返回否定确认(nack)或超时未返回，消息队列则会按照预定规则重新发送，直到到达最大重试次数后停止。如何实现 ack 和重试机制是我们要重点考虑的问题。

我们的消息队列允许分布式地部署多个生产者和消费者，消费者实例定时执行 lua 脚本驱动消息在队列中的流转无需部署额外组件。由于 Redis 保证了 lua 脚本执行的原子性，整个流程无需加锁。

消费者采用拉模式获得消息，保证每条消息至少投递一次，消息队列会重试超时或者被否定确认的消息(nack) 直至到达最大重试次数。一条消息最多有一个消费者正在处理，减少了要考虑的并发问题。

请注意：若消费时间超过了 MaxConsumeDuration 消息队列会认为消费超时并重新投递，此时可能有多个消费者同时消费。

具体使用也非常简单，只需要注册处理消息的回调函数并调用 start() 即可：

由于数据存储在 redis 中所以我们最多能保证在 redis 无故障且消息队列相关 key 未被外部篡改的情况下不会丢失消息。

原理详解

消息队列涉及几个关键的 redis 数据结构：

msgKey: 为了避免两条内容完全相同的消息造成意外的影响，我们将每条消息放到一个字符串类型的键中，并分配一个 UUID 作为它的唯一标识。其它数据结构中只存储 UUID 而不存储完整的消息内容。每个 msg 拥有一个独立的 key 而不是将所有消息放到一个哈希表是为了利用 TTL 机制避免pendingKey: 有序集合类型，member 为消息 ID, score 为投递时间的 unix 时间戳。readyKey: 列表类型，需要投递的消息 ID。unAckKey: 有序集合类型，member 为消息 ID, score 为重试时间的 unix 时间戳。retryKey: 列表类型，已到重试时间的消息 IDgarbageKey: 集合类型，用于暂存已达重试上线的消息 IDretryCountKey: 哈希表类型，键为消息 ID, 值为剩余的重试次数

流程如下图所示：

由于我们允许分布式地部署多个消费者，每个消费者都在定时执行 lua 脚本，所以多个消费者可能处于上述流程中不同状态，我们无法预知（或控制）上图中五个操作发生的先后顺序，也无法控制有多少实例正在执行同一个操作。

因此我们需要保证上图中五个操作满足三个条件：

都是原子性的不会重复处理同一条消息操作前后消息队列始终处于正确的状态

只要满足这三个条件，我们就可以部署多个实例且不需要使用分布式锁等技术来进行状态同步。

是不是听起来有点吓人？???? 其实简单的很，让我们一起来详细看看吧~

pending2ReadyScript

pending2ReadyScript 使用 zrangebyscore 扫描已到投递时间的消息ID并把它们移动到 ready 中:

ready2UnackScript

ready2UnackScript 从 ready 或者 retry 中取出一条消息发送给消费者并放入 unack 中，类似于 RPopLPush：

unack2RetryScript

unack2RetryScript 从 retry 中找出所有已到重试时间的消息并把它们移动到 unack 中：

因为 redis 要求 lua 脚本必须在执行前在 KEYS 参数中声明自己要访问的 key, 而我们将每个 msg 有一个独立的 key，我们在执行 unack2RetryScript 之前是不知道哪些 msg key 需要被删除。所以 lua 脚本只将需要删除的消息记在 garbage key 中，脚本执行完后再通过 del 命令将他们删除:

之前提到的 lua 脚本都是原子性执行的，不会有其它命令插入其中。 gc 函数由 3 条 redis 命令组成，在执行过程中可能会有其它命令插入执行过程中，不过考虑到一条消息进入垃圾回收流程之后不会复活所以不需要保证 3 条命令原子性。

ack

ack 只需要将消息彻底删除即可:

否定确认只需要将 unack key 中消息的重试时间改为现在，随后执行的 unack2RetryScript 会立即将它移动到 retry key

consume

消息队列的核心逻辑是每秒执行一次的 consume 函数，它负责调用上述脚本将消息转移到正确的集合中并回调 consumer 来消费消息：

至此一个简单可靠的延时队列就做好了，何不赶紧开始试用呢????????？

到此这篇关于百行代码实现基于Redis的可靠延迟队列的文章就介绍到这了,更多相关百行代码实现基于Redis的可靠延迟队列内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！