领导：谁再用 Redis 实现过期订单关闭，立马滚蛋！
<p>作者：finley <br>出处：https://www.cnblogs.com/Finley/p/16395466.html</p>
<p>在电商、支付等领域，往往会有这样的场景，用户下单后放弃支付了，那这笔订单会在指定的时间段后进行关闭操作，细心的你一定发现了像某宝、某东都有这样的逻辑，而且时间很准确，误差在1s内；那他们是怎么实现的呢？</p>
<p>一般实现的方法有几种：</p>
<ol>
<li>使用 rocketmq、rabbitmq、pulsar 等消息队列的延时投递功能</li>
<li>使用 redisson 提供的 DelayedQueue</li>
</ol>
<p>有一些方案虽然广为流传但存在着致命缺陷，不要用来实现延时任务</p>
<ol>
<li>使用 Redis 的过期监听</li>
<li>使用 rabbitmq 的死信队列</li>
<li>使用非持久化的时间轮</li>
</ol>
<h2 id="redis-过期监听">Redis 过期监听</h2>
<p>在 Redis 官方手册的 keyspace-notifications: timing-of-expired-events（https://redis.io/docs/manual/keyspace-notifications/#timing-of-expired-events） 中明确指出：</p>
<blockquote>
<p>Basically expired events are generated when the Redis server deletes the key and not when the time to live theoretically reaches the value of zero</p>
</blockquote>
<p>Redis 自动过期的实现方式是：</p>
<blockquote>
<p>定时任务离线扫描并删除<strong>部分</strong>过期键；在访问键时惰性检查是否过期并删除过期键。Redis 从未保证会在设定的过期时间立即删除并发送过期通知。实际上，过期通知晚于设定的过期时间数分钟的情况也比较常见。</p>
<p>此外键空间通知采用的是发送即忘(fire and forget)策略，并不像消息队列一样保证送达。当订阅事件的客户端会丢失所有在断线期间所有分发给它的事件。</p>
</blockquote>
<p>这是一种比定时扫描数据库更 “LOW” 的解决方案，请不要使用。也有另一位大佬做了测试，请勿过度依赖Redis的过期监听。</p>
<h2 id="rabbitmq-死信">rabbitmq 死信</h2>
<p>死信(Dead Letter) 是 rabbitmq 提供的一种机制。当一条消息满足下列条件之一那么它会成为死信：</p>
<ul>
<li>消息被否定确认（如channel.basicNack) 并且此时requeue 属性被设置为false。</li>
<li>消息在队列的存活时间超过设置的TTL时间</li>
<li>消息队列的消息数量已经超过最大队列长度</li>
</ul>
<p>若配置了死信队列，死信会被 rabbitmq 投到死信队列中。</p>
<p>在 rabbitmq 中创建死信队列的操作流程大概是：</p>
<ul>
<li>创建一个交换机作为死信交换机</li>
<li>在业务队列中配置 x-dead-letter-exchange 和 x-dead-letter-routing-key，将第一步的交换机设为业务队列的死信交换机</li>
<li>在死信交换机上创建队列，并监听此队列</li>
</ul>
<p>死信队列的设计目的是为了存储没有被正常消费的消息，便于排查和重新投递。<strong>死信队列同样也没有对投递时间做出保证，在第一条消息成为死信之前，后面的消息即使过期也不会投递为死信</strong>。</p>
<p>为了解决这个问题，rabbit 官方推出了延迟投递插件 rabbitmq-delayed-message-exchange（https://github.com/rabbitmq/rabbitmq-delayed-message-exchange） ，推荐使用官方插件来做延时消息。</p>
<blockquote>
<p>这里说点题外话，使用 Redis 过期监听或者 rabbitmq 死信队列做延时任务都是以设计者预想之外的方式使用中间件，这种出其不意必自毙的行为通常会存在某些隐患，比如缺乏一致性和可靠性保证，吞吐量较低、资源泄漏等。</p>
<p>比较出名的一个事例是很多人使用 Redis 的 list 作为消息队列，以致于最后作者看不下去写了 disque 并最后演变为 Redis stream。工作中还是尽量不要滥用中间件，用专业的组件做专业的事</p>
</blockquote>
<h2 id="时间轮">时间轮</h2>
<p>时间轮是一种很优秀的定时任务的数据结构，然而绝大多数时间轮实现是纯内存没有持久化的。运行时间轮的进程崩溃之后其中所有的任务都会灰飞烟灭，所以奉劝各位勇士谨慎使用。</p>
<h2 id="redisson-delayqueue">redisson delayqueue</h2>
<p>redisson delayqueue 是一种基于 Redis zset 结构的延时队列实现。delayqueue 中有一个名为 timeoutSetName 的有序集合，其中元素的 score 为投递时间戳。delayqueue 会定时使用 zrangebyscore 扫描已到投递时间的消息，然后把它们移动到就绪消息列表中。</p>
<p>delayqueue 保证 Redis 不崩溃的情况下不会丢失消息，在没有更好的解决方案时不妨一试。</p>
<p>在数据库索引设计良好的情况下，定时扫描数据库中未完成的订单产生的开销并没有想象中那么大。在使用 redisson delayqueue 等定时任务中间件时可以同时使用扫描数据库的方法作为补偿机制，避免中间件故障造成任务丢失。</p>
<h2 id="结论">结论</h2>
<ol>
<li>首先推荐使用 rocketmq、pulsar 等拥有定时投递功能的消息队列。</li>
<li>在不方便获得专业消息队列时可以考虑使用 redisson delayqueue 等基于 Redis 的延时队列方案，但要为 Redis 崩溃等情况设计补偿保护机制。</li>
<li>在无法使用 redisson delayqueue 等方案时可以考虑使用时间轮。由于时间轮重启远比 Redis 重启要频繁，定时扫库等保护机制更为重要。</li>
<li>永远不要使用 Redis 过期监听实现定时任务。</li>
</ol>
<p><strong>更多文章推荐：</strong></p>
<p>1.Spring Boot 3.x 教程，太全了！</p>
<p>2.3,000+ 道 Java面试题及答案整理(最新版)</p>
<p>3.免费获取 IDEA 激活码的 7 种方式（最新版）</p>
<p>4.Java & DeepSeek & AI 学习资料分享</p>
<p>5.程序员精美简历模板分享</p>
<p>觉得不错，别忘了随手点赞+转发哦！</p>
</div>
<div id="MySignature" role="contentinfo">
<div style="clear: both"></div><br><br>
来源：https://www.cnblogs.com/javastack/p/18886140
頁:
[1]