問題描述

以下類型的sql語句，是否需要緩存，怎么緩存，更新策略比較疑惑，望指點

關聯查詢

條件范圍查詢

動態條件組合

頻繁的數據更新，需要數據實時的系統（CRM）是否適合引入緩存

問題解答

緩存要把控好，沒有十全十美的實現，技術是永不停止的進步。你的數據更新比較頻繁，那就沒有必要緩存了，可考慮加redis隊列，防止堵塞。也可以配合swoole使用異步加載實現。多用非關系型數據庫，這樣性能會提升一些。 如果在高并發情況還是實在不行的話，就再加幾臺服務器，利用負載均衡 lvs 來可實現減輕部分服務器的負載，redis最好部署分布式。

我覺得緩存策略主要還是有業務決定的吧

更新頻繁的數據不適合緩存

頻繁更新數據用redis吧，

redis 擋在mysql前面是為了防止請求量過大給mysql造成過高負載而導致服務性能降低或者直接不可服務

這樣子做主要是大量查詢的情況下，可以直接redis獲取就返回不通過mysql如果新增和更新操作特別頻繁，查詢操作相對較少，那層redis緩存就沒意義了，甚至時累贅。你每次更新/新增都要寫mysql這個是避免不了的，要是加了緩存你還要寫緩存，還要確保緩存mysql數據的一致性。

關于查詢，通常都可以緩存，只是緩存的時間需要把控好，然后就是更新策略，最簡單的策略就是不需要什么策略。請求到達之后先讀緩存（如redis），讀不到就去讀庫或者下一級緩存。然后比較有意思的更新策略是主動更新，就是前端請求只去redis里面讀數據，沒有就返回空，然后后端腳步負責同步數據到緩存中，具體做法可以在每次數據變動之后就記錄一下，然后腳步定時讀取變動項，然后主動刷緩存。熱點數據就那么多，基本上可以滿足，如果擔心數據一直沒更新，前端來讀的時候由于緩存過去沒讀到，那么可以在讀不到的時候也記錄一下，這樣過會兒后端腳步就會刷一份緩存進去，這樣就保證了。

實時的更新，如果不允許有秒級的延遲的話，那么就只能不用緩存了，然后建議是使用非關系型數據庫了，不然關系型數據庫怕是難以支撐。