如何將所有worker進(jìn)程的內(nèi)存緩存清空？
問題描述
webman中，為了加快處理的效率并減少IO，做了內(nèi)存緩存。即根據(jù)請(qǐng)求的數(shù)據(jù)，從數(shù)據(jù)庫中查詢到數(shù)據(jù)后加載到了靜態(tài)數(shù)組LoadData::$data中，供下次請(qǐng)求直接使用。
請(qǐng)問如何解決用戶刪除了對(duì)應(yīng)數(shù)據(jù)后，內(nèi)存緩存也要?jiǎng)h除的問題， 需要每個(gè)worker進(jìn)程都清理，請(qǐng)問該如何處理？
由于考慮到性能因素，所以沒使用apcu等共享內(nèi)存機(jī)制。在不使用共享內(nèi)存存放$data的前提下，怎么處理呢？
為此你搜索到了哪些方案及不適用的原因
考慮每個(gè)worker進(jìn)程訂閱redis的頻道，然后推送，但是可能存在不穩(wěn)定的情況。
4個(gè)回答
你這不是脫褲子放屁嗎？在乎這點(diǎn)點(diǎn)性能還不如好好優(yōu)化下SQL語句和數(shù)據(jù)表設(shè)計(jì)加緩存來得快。你這樣有可能會(huì)造成內(nèi)存泄漏
架構(gòu)師眼里：沒有是加一層解決不了問題，一層不夠就加二層。
給你一個(gè)多級(jí)緩存思路；
- 采用 OpenResty+Lua
- 一級(jí)緩存放在 nginx 這一層
- 二級(jí)緩存放在 redis 這一層，去更新 一級(jí)緩存
- 三級(jí)才直接查詢數(shù)據(jù)庫，去更新 一二級(jí)緩存
當(dāng)然這樣優(yōu)化在不是超高頻率訪問下，有可能還不如直接webman+cache性能
后期上面那種多級(jí)緩存維護(hù)起來還是有點(diǎn)點(diǎn)麻煩的（特別是做了負(fù)載均衡）
虛假的減少io：無腦將數(shù)據(jù)填入本地內(nèi)存
真實(shí)的減少io：合理分析自己的應(yīng)用場(chǎng)景，為每一類數(shù)據(jù)選擇合適的緩存方式
枚舉類數(shù)據(jù)是可以直接加載到內(nèi)存的，用戶token，熱門商品詳情可以加載到redis這類緩存當(dāng)中(使用更快的io而并非減少)，文章詳情這類本身內(nèi)容多的數(shù)據(jù)，但是查詢條件只有id的場(chǎng)景，緩存的意義幾乎沒有。
LoadData::$data這種數(shù)據(jù)，如果遇到頻繁更新其中某個(gè)數(shù)據(jù)的場(chǎng)景每次變動(dòng)一行重載整個(gè)緩存往往得不償失
-
xiaopi 2025-03-13我的業(yè)務(wù)場(chǎng)景是用戶添加自己的問答庫，包括關(guān)鍵詞、回答等，問答庫審核通過后進(jìn)行發(fā)布，發(fā)布實(shí)際就是把問答庫所有內(nèi)存加載到文件xxx.json中。 使用就是有很多請(qǐng)求攜帶問答庫的ID進(jìn)來走不同的問答庫邏輯?，F(xiàn)在實(shí)現(xiàn)的事：當(dāng)咨詢請(qǐng)求進(jìn)入后，加載對(duì)應(yīng)的問答庫內(nèi)容到內(nèi)存中，并進(jìn)行問答庫分支邏輯，直到用戶結(jié)束咨詢。自動(dòng)釋放： 當(dāng)該問答庫在20分鐘內(nèi)沒有被咨詢時(shí)，系統(tǒng)自動(dòng)釋放這部分內(nèi)存。手動(dòng)釋放：當(dāng)重新發(fā)布后，手動(dòng)釋放回答庫的內(nèi)存。 每個(gè)worker進(jìn)程都釋放的是通過在afterWorker中添加定時(shí)器，定時(shí)掃描。
