前段時間,在和朋友討論和研究緩存的使用,一直對緩存的使用搞的不太清楚,所以這次把和朋友討論過緩存系統的設計的相關問題總結總結。
對于一個電商系統,緩存是重要組成部分,提升系統性能的主要方式之一就是緩存。它可以擋掉大部分的數據庫訪問的沖擊,如果沒有它,系統很可能會因為數據庫不可用導致整個系統崩潰。
但是緩存帶來了另外一些棘手的問題: 數據的一致性和實時性。
例如,數據庫中的數據狀態已經改變,但是在頁面上看到的仍然是緩存的舊值,直到緩沖時間失效之后,才能重新更新緩存。這個問題怎么解決?
還有就是,緩存數據如果沒有失效的話,是會一直保持在內存中的,所以對服務器的內存也是負擔,那么什么數據可以放緩存,什么數據不可以,這是系統設計之初必須考慮的問題。
什么數據可以放緩存?
1,不需要實時更新但是又極其消耗數據庫的數據。比如網站首頁的商品銷售的排行榜,熱搜商品等等,這些數據基本上都是一天統計一次,用戶不會關注其是否是實時的。
2,需要實時更新,但是數據更新的頻率不高的數據。
3,每次獲取這些數據都經過復雜的處理邏輯,比如生成報表。
什么數據不應該使用緩存?
實際上,在電商系統中,大部分數據都是可以緩存的,不能使用緩存的數據很少。這類數據包括比如涉及到錢、密鑰、業務關鍵性核心數據等。總之,如果你發現,系統里面的大部分數據都不能使用緩存,這說明架構本身出了問題。
如何解決一致性和實時性的問題?
保證一致性和實時性的辦法就是:一旦數據庫更新了,就必須把原來的緩存更新。
說一說我們的緩存方案:
我們目前的緩存系統:Redis(主從)+ RabbitMQ + 緩存清理服務組成,具體如下圖:
緩存清理作業訂閱 RabbitMQ消息隊列,一有數據更新進入隊列,就將數據重新更新到Redis緩存服務器。
當然,有些朋友的方案,是數據庫更新完成之后,立馬去更新相關緩存數據。這樣就不需要MQ 和 緩存清理作業。不過,這同時也增加了系統的耦合性。具體得看自己的業務場景和平臺大小。
不含病毒。www.avast.com |
留言列表