如何將所有worker進程的內存緩存清空？

xiaopi 2025-02-25

問題描述

webman中，為了加快處理的效率并減少IO，做了內存緩存。即根據(jù)請求的數(shù)據(jù)，從數(shù)據(jù)庫中查詢到數(shù)據(jù)后加載到了靜態(tài)數(shù)組LoadData::$data中，供下次請求直接使用。
請問如何解決用戶刪除了對應數(shù)據(jù)后，內存緩存也要刪除的問題，需要每個worker進程都清理，請問該如何處理？
由于考慮到性能因素，所以沒使用apcu等共享內存機制。在不使用共享內存存放$data的前提下，怎么處理呢？

為此你搜索到了哪些方案及不適用的原因

考慮每個worker進程訂閱redis的頻道，然后推送，但是可能存在不穩(wěn)定的情況。

 652  4 1

4個回答

故人重來 2025-02-26

你這不是脫褲子放屁嗎？在乎這點點性能還不如好好優(yōu)化下SQL語句和數(shù)據(jù)表設計加緩存來得快。你這樣有可能會造成內存泄漏
架構師眼里：沒有是加一層解決不了問題，一層不夠就加二層。
給你一個多級緩存思路；

采用 OpenResty+Lua
- 一級緩存放在 nginx 這一層
- 二級緩存放在 redis 這一層，去更新一級緩存
- 三級才直接查詢數(shù)據(jù)庫，去更新一二級緩存
  當然這樣優(yōu)化在不是超高頻率訪問下，有可能還不如直接webman+cache性能
  后期上面那種多級緩存維護起來還是有點點麻煩的（特別是做了負載均衡）

xiaopi 2025-02-26

并發(fā)大概2000 request/sec ,主要是業(yè)務上會審核數(shù)據(jù)，數(shù)據(jù)審核以后就固定了，所以才考慮采用這種內存緩存方式，確實太過于設計了。
故人重來 2025-02-26

沒必要用apcu，直接redis緩存吧。成熟方案，還支持持久化。
xiaopi 2025-02-26

感謝，用redis設計上會簡單不少

六次元 2025-02-26

如果對數(shù)據(jù)過期不是很敏感，可以定時從數(shù)據(jù)庫讀，然后緩存到內存。
如果敏感感覺用apcu最好。apcu性能絕對夠用，我們公司測試過，每秒讀寫上千萬次。

xiaopi 2025-02-26

確實，都加載到worker進程中，太浪費內存了

qqxxr 2025-02-26

就redis就好了啊，

暫無評論

超高級的稻姬 2025-03-11

虛假的減少io：無腦將數(shù)據(jù)填入本地內存
真實的減少io：合理分析自己的應用場景，為每一類數(shù)據(jù)選擇合適的緩存方式
枚舉類數(shù)據(jù)是可以直接加載到內存的，用戶token，熱門商品詳情可以加載到redis這類緩存當中(使用更快的io而并非減少)，文章詳情這類本身內容多的數(shù)據(jù)，但是查詢條件只有id的場景，緩存的意義幾乎沒有。
LoadData::$data這種數(shù)據(jù)，如果遇到頻繁更新其中某個數(shù)據(jù)的場景每次變動一行重載整個緩存往往得不償失

xiaopi 2025-03-13

我的業(yè)務場景是用戶添加自己的問答庫，包括關鍵詞、回答等，問答庫審核通過后進行發(fā)布，發(fā)布實際就是把問答庫所有內存加載到文件xxx.json中。使用就是有很多請求攜帶問答庫的ID進來走不同的問答庫邏輯?，F(xiàn)在實現(xiàn)的事：當咨詢請求進入后，加載對應的問答庫內容到內存中，并進行問答庫分支邏輯，直到用戶結束咨詢。自動釋放：當該問答庫在20分鐘內沒有被咨詢時，系統(tǒng)自動釋放這部分內存。手動釋放：當重新發(fā)布后，手動釋放回答庫的內存。每個worker進程都釋放的是通過在afterWorker中添加定時器，定時掃描。