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

案例

商品定時(shí)下架

方案一：消息隊(duì)列

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

方案二：定時(shí)任務(wù)+消息隊(duì)列

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

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

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

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

基于以上兩點(diǎn)，我做出以下兩點(diǎn)改造：

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

搞定~

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

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

策略一：惰性過期

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

策略二：定期過期

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

END

好兄弟可以點(diǎn)贊并關(guān)注我的公眾號(hào)“javaAnswer”，全部都是干貨。