最新消息，日前，宜家的控股公司Interogo Holding AG斥資17億瑞典克朗(約1.90億美元)買入海恩斯莫里斯(H&M)集團0.6%的股份，并擁持有了后者0.3%的投票權。這是Interogo Holding AG第一次擁有快時尚公司的股份。前段時間，在和朋友討論和研究緩存的使用，一直對緩存的使用搞的不太清楚，所以這次把和朋友討論過緩存系統的設計的相關問題總結總結。

對于一個電商系統，緩存是重要組成部分，提升系統性能的主要方式之一就是緩存。它可以擋掉大部分的數據庫訪問的沖擊，如果沒有它，系統很可能會因為數據庫不可用導致整個系統崩潰。

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

例如，數據庫中的數據狀態已經改變，但是在頁面上看到的仍然是緩存的舊值，直到緩沖時間失效之后，才能重新更新緩存。這個問題怎么解決？

還有就是，緩存數據如果沒有失效的話，是會一直保持在內存中的，所以對服務器的內存也是負擔，那么什么數據可以放緩存，什么數據不可以，這是系統設計之初必須考慮的問題。

什么數據可以放緩存？

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

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

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

什么數據不應該使用緩存？

實際上，在電商系統中，大部分數據都是可以緩存的，不能使用緩存的數據很少。這類數據包括比如涉及到錢、密鑰、業務關鍵性核心數據等。總之，如果你發現，系統里面的大部分數據都不能使用緩存，這說明架構本身出了問題。

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

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

說一說我們的緩存方案：

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

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

當然，有些朋友的方案，是數據庫更新完成之后，立馬去更新相關緩存數據。這樣就不需要MQ 和 緩存清理作業。不過，這同時也增加了系統的耦合性。具體得看自己的業務場景和平臺大小。

<hishop（www.gstsqh.com.cn）是國內知名企業級電商平臺提供商，為企業級商家提供最佳的系統開發（多種模式電商平臺搭建：B2B/B2B2C/B2C/O2O/新零售等）、供應鏈系統搭建及電商行業解決方案服務>

<本文由himall原創，商業轉載請聯系作者獲得授權，非商業轉載請標明：himall原創>