電商緩存設計

前段時間，在和朋友討論和研究緩存的使用，一直對緩存的使用搞的不太清楚，因此此次把和朋友討論過緩存系統的設計的相關問題總結總結。

 

　　對於一個電商系統，緩存是重要組成部分，提高系統性能的主要方式之一就是緩存。它能夠擋掉大部分的數據庫訪問的衝擊，若是沒有它，系統極可能會由於數據庫不可用致使整個系統崩潰。

 

　　可是緩存帶來了另一些棘手的問題： 數據的一致性和實時性。

　　例如，數據庫中的數據狀態已經改變，可是在頁面上看到的仍然是緩存的舊值，直到緩衝時間失效以後，才能從新更新緩存。這個問題怎麼解決？

　　還有就是，緩存數據若是沒有失效的話，是會一直保持在內存中的，因此對服務器的內存也是負擔，那麼什麼數據能夠放緩存，什麼數據不能夠，這是系統設計之初必須考慮的問題。

 

　　什麼數據能夠放緩存？

　　　　1，不須要實時更新可是又極其消耗數據庫的數據。好比網站首頁的商品銷售的排行榜，熱搜商品等等，這些數據基本上都是一天統計一次，用戶不會關注其是不是實時的。

　　　　2，須要實時更新，可是數據更新的頻率不高的數據。

　　　　3，每次獲取這些數據都通過複雜的處理邏輯，好比生成報表。

 

　　什麼數據不該該使用緩存？

　　　　實際上，在電商系統中，大部分數據都是能夠緩存的，不能使用緩存的數據不多。這類數據包括好比涉及到錢、密鑰、業務關鍵性核心數據等。總之，若是你發現，系統裏面的大部分數據都不能使用緩存，這說明架構自己出了問題。

 

　　如何解決一致性和實時性的問題？

　　　　保證一致性和實時性的辦法就是：一旦數據庫更新了，就必須把原來的緩存更新。

 

　　說一說咱們的緩存方案：

　　　　咱們目前的緩存系統：Redis（主從）+ RabbitMQ + 緩存清理服務組成，具體以下圖：

　　　　緩存清理做業訂閱 RabbitMQ消息隊列，一有數據更新進入隊列，就將數據從新更新到Redis緩存服務器。

 　　

 

 

　　　　固然，有些朋友的方案，是數據庫更新完成以後，立馬去更新相關緩存數據。這樣就不須要MQ 和 緩存清理做業。不過，這同時也增長了系統的耦合性。具體得看本身的業務場景和平臺大小。