mysql - 關于數(shù)據(jù)緩存策略方面的疑惑
問題描述
以下類型的sql語句,是否需要緩存,怎么緩存,更新策略比較疑惑,望指點
關聯(lián)查詢
條件范圍查詢
動態(tài)條件組合
頻繁的數(shù)據(jù)更新,需要數(shù)據(jù)實時的系統(tǒng)(CRM)是否適合引入緩存
問題解答
回答1:緩存要把控好,沒有十全十美的實現(xiàn),技術是永不停止的進步。你的數(shù)據(jù)更新比較頻繁,那就沒有必要緩存了,可考慮加redis隊列,防止堵塞。也可以配合swoole使用異步加載實現(xiàn)。多用非關系型數(shù)據(jù)庫,這樣性能會提升一些。 如果在高并發(fā)情況還是實在不行的話,就再加幾臺服務器,利用負載均衡 lvs 來可實現(xiàn)減輕部分服務器的負載,redis最好部署分布式。
回答2:我覺得緩存策略主要還是有業(yè)務決定的吧
回答3:更新頻繁的數(shù)據(jù)不適合緩存
回答4:頻繁更新數(shù)據(jù)用redis吧,
回答5:redis 擋在mysql前面是為了防止請求量過大給mysql造成過高負載而導致服務性能降低或者直接不可服務
這樣子做主要是大量查詢的情況下,可以直接redis獲取就返回不通過mysql如果新增和更新操作特別頻繁,查詢操作相對較少,那層redis緩存就沒意義了,甚至時累贅。你每次更新/新增都要寫mysql這個是避免不了的,要是加了緩存你還要寫緩存,還要確保緩存mysql數(shù)據(jù)的一致性。
回答6:關于查詢,通常都可以緩存,只是緩存的時間需要把控好,然后就是更新策略,最簡單的策略就是不需要什么策略。請求到達之后先讀緩存(如redis),讀不到就去讀庫或者下一級緩存。然后比較有意思的更新策略是主動更新,就是前端請求只去redis里面讀數(shù)據(jù),沒有就返回空,然后后端腳步負責同步數(shù)據(jù)到緩存中,具體做法可以在每次數(shù)據(jù)變動之后就記錄一下,然后腳步定時讀取變動項,然后主動刷緩存。熱點數(shù)據(jù)就那么多,基本上可以滿足,如果擔心數(shù)據(jù)一直沒更新,前端來讀的時候由于緩存過去沒讀到,那么可以在讀不到的時候也記錄一下,這樣過會兒后端腳步就會刷一份緩存進去,這樣就保證了。
實時的更新,如果不允許有秒級的延遲的話,那么就只能不用緩存了,然后建議是使用非關系型數(shù)據(jù)庫了,不然關系型數(shù)據(jù)庫怕是難以支撐。
相關文章:
1. javascript - 我是做web前端的,公司最近有一個項目關于數(shù)據(jù)統(tǒng)計的!2. MySQL主鍵沖突時的更新操作和替換操作在功能上有什么差別(如圖)3. javascript - vue過渡效果 css過渡 類名的先后順序4. javascript - 如何使用loadash對[object,object,object]形式的數(shù)組進行比較5. ios - 類似微博首頁,一張圖的時候是如何確定圖大小的?6. node.js - 微信小程序websocket連接問題7. javascript - 在ie下為什么會出現(xiàn)這種情況呢 《 無法獲取未定義或 null 引用的屬性“l(fā)ength”》 ?請大神指教。8. javascript - vuejs+elementui 購物車價格計算,點擊加減號修改數(shù)量總價都不會改變,但是計算執(zhí)行了9. html5和Flash對抗是什么情況?10. 數(shù)據(jù)庫 - Mysql的存儲過程真的是個坑!求助下面的存儲過程哪里錯啦,實在是找不到哪里的問題了。
