有一天，产品一哥“林哥”来找我，跟我说：“小李，咱们现在一个需求，商品定时下架的逻辑，这个咱们能做到吗？”，我一想，今年的绩效跟着产品大佬走，当即拍着胸脯说道：“林哥，你就放一百个心，包在我身上~”，然后开始头脑风暴，毕竟要向前（钱）看。
案例
商品定时下架
方案一：消息队列
首先我想到当运营童鞋创建（或修改下架时间）商品后，就把该商品放到消息队列中，这样利用 RabbitMQ 的消息 TTL 加死信队列的特性，这个需求搞定，安排上线~
方案二：定时任务+消息队列
过了一段时间，架构师发哥心急火燎的来找我，我一看这阵势这是有大事吧，发哥不等我开口，说：“小李，快看看系统，运营童鞋来找我说，商品到下架时间还能买到；而且运维童鞋反应过节那天咱们的 RabbitMQ 那台服务器内存和硬盘不够用了，尽快处理下”。
我把两件事串联在一起就想到了出问题的点就是“过期自动下架”功能的问题。
第一个问题：商品到下架时间还能买到，我跟运营童鞋确认问题商品，发现很多商品的过期时间是3个月甚至更久，大致猜测可能是延迟时间过长导致了消息延迟失败，查了查默认在使用RabbitMQ的延迟消息功能时候，它的延迟极限是4294967296毫秒，也就是49.7天，很显然现有的功能是无法满足的运营需求，扑街~。
第二个问题：过节前夕 RabbitMQ 那台服务器内存和硬盘不够用，我去看运营后台发现创建了大量的新商品，那应该是大量延时下架商品放到消息队列中，以至于产生堆积。
基于以上两点，我做出以下两点改造：
- 创建（或修改下架时间）商品的时候，不会放到消息队列中，节约资源利用空间；
- 定时任务每天从商品表中捞取第二天下架的商品放入到消息队列中，缩短延迟时间。
搞定~
从这个案例中我借鉴的是 Redis 的内存回收策略，因为 Redis 所有的数据都是存储到内存中的，所以在某些情况下需要对占用的内存进行回收。
Redis 中同时使用了惰性过期和定期过期两种过期策略。
策略一：惰性过期
只有当访问一个 key 时，才会判断该 key 是否已过期，过期则清除。该策略可以最大化地节省 CPU 资源，却对内存非常不友好。极端情况可能出现大量的过期 key 没有再次被访问，从而不会被清除，占用大量内存。
策略二：定期过期
每隔一定的时间，会扫描一定数量的数据库的 expires 字典中一定数量的 key，并清除其中已过期的 key。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得 CPU 和内存资源达到最优的平衡效果。
END
好兄弟可以点赞并关注我的公众号“javaAnswer”，全部都是干货。
