問題描述

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

關聯(lián)查詢

條件范圍查詢

動態(tài)條件組合

頻繁的數(shù)據(jù)更新，需要數(shù)據(jù)實時的系統(tǒng)（CRM）是否適合引入緩存

問題解答

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

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

更新頻繁的數(shù)據(jù)不適合緩存

頻繁更新數(shù)據(jù)用redis吧，

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

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

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

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