?有一天，產(chǎn)品一哥“林哥”來找我，跟我說：“小李，咱們現(xiàn)在一個需求，商品定時下架的邏輯，這個咱們能做到嗎？”，我一想，今年的績效跟著產(chǎn)品大佬走，當即拍著胸脯說道：“林哥，你就放一百個心，包在我身上~”，然后開始頭腦風暴，畢竟要向前（錢）看。

案例

商品定時下架

方案一：消息隊列

首先我想到當運營童鞋創(chuàng)建（或修改下架時間）商品后，就把該商品放到消息隊列中，這樣利用 RabbitMQ 的消息 TTL 加死信隊列的特性，這個需求搞定，安排上線~

方案二：定時任務+消息隊列

過了一段時間，架構師發(fā)哥心急火燎的來找我，我一看這陣勢這是有大事吧，發(fā)哥不等我開口，說：“小李，快看看系統(tǒng)，運營童鞋來找我說，商品到下架時間還能買到；而且運維童鞋反應過節(jié)那天咱們的 RabbitMQ 那臺服務器內(nèi)存和硬盤不夠用了，盡快處理下”。

我把兩件事串聯(lián)在一起就想到了出問題的點就是“過期自動下架”功能的問題。

第一個問題：商品到下架時間還能買到，我跟運營童鞋確認問題商品，發(fā)現(xiàn)很多商品的過期時間是3個月甚至更久，大致猜測可能是延遲時間過長導致了消息延遲失敗，查了查默認在使用RabbitMQ的延遲消息功能時候，它的延遲極限是4294967296毫秒，也就是49.7天，很顯然現(xiàn)有的功能是無法滿足的運營需求，撲街~。

第二個問題：過節(jié)前夕 RabbitMQ 那臺服務器內(nèi)存和硬盤不夠用，我去看運營后臺發(fā)現(xiàn)創(chuàng)建了大量的新商品，那應該是大量延時下架商品放到消息隊列中，以至于產(chǎn)生堆積。

基于以上兩點，我做出以下兩點改造：

• 創(chuàng)建（或修改下架時間）商品的時候，不會放到消息隊列中，節(jié)約資源利用空間；
• 定時任務每天從商品表中撈取第二天下架的商品放入到消息隊列中，縮短延遲時間。

搞定~

從這個案例中我借鑒的是 Redis 的內(nèi)存回收策略，因為 Redis 所有的數(shù)據(jù)都是存儲到內(nèi)存中的，所以在某些情況下需要對占用的內(nèi)存進行回收。

Redis 中同時使用了惰性過期和定期過期兩種過期策略。

策略一：惰性過期

只有當訪問一個 key 時，才會判斷該 key 是否已過期，過期則清除。該策略可以最大化地節(jié)省 CPU 資源，卻對內(nèi)存非常不友好。極端情況可能出現(xiàn)大量的過期 key 沒有再次被訪問，從而不會被清除，占用大量內(nèi)存。

策略二：定期過期

每隔一定的時間，會掃描一定數(shù)量的數(shù)據(jù)庫的 expires 字典中一定數(shù)量的 key，并清除其中已過期的 key。通過調(diào)整定時掃描的時間間隔和每次掃描的限定耗時，可以在不同情況下使得 CPU 和內(nèi)存資源達到最優(yōu)的平衡效果。

END

好兄弟可以點贊并關注我的公眾號“javaAnswer”，全部都是干貨。