問(wèn)題描述

以下類(lèi)型的sql語(yǔ)句，是否需要緩存，怎么緩存，更新策略比較疑惑，望指點(diǎn)

關(guān)聯(lián)查詢(xún)

條件范圍查詢(xún)

動(dòng)態(tài)條件組合

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

問(wèn)題解答

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

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

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

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

redis 擋在mysql前面是為了防止請(qǐng)求量過(guò)大給mysql造成過(guò)高負(fù)載而導(dǎo)致服務(wù)性能降低或者直接不可服務(wù)

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

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

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