建站
咨詢
售后
建站咨詢
新聞中心
?有一天，產(chǎn)品一哥“林哥”來找我，跟我說：“小李，咱們現(xiàn)在一個需求，商品定時下架的邏輯，這個咱們能做到嗎？”，我一想，今年的績效跟著產(chǎn)品大佬走，當即拍著胸脯說道：“林哥，你就放一百個心，包在我身上~”，然后開始頭腦風暴，畢竟要向前（錢）看。
網(wǎng)站建設哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、小程序制作、集團企業(yè)網(wǎng)站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了銅梁免費建站歡迎大家使用！
案例
商品定時下架
方案一：消息隊列
首先我想到當運營童鞋創(chuàng)建（或修改下架時間）商品后，就把該商品放到消息隊列中，這樣利用 RabbitMQ 的消息 TTL 加死信隊列的特性，這個需求搞定，安排上線~
方案二：定時任務+消息隊列
過了一段時間，架構(gòu)師發(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”，全部都是干貨。
當前文章：Redis：內(nèi)存回收的過期策略
文章來源：http://www.dlmjj.cn/article/djpgied.html
