緩存淘汰和多級管理
在squid中涉及到緩存淘汰算法包括：內存緩存淘汰lru、磁盤緩存淘汰lru。一般做法是：當命中一個緩存後，將lru節點從當前位置刪除，然後移動至隊頭。
淘汰一般是需要在固定的空間個數中淘汰掉某個節點（對於無限節點空間情況下，淘汰算法沒有意義）。上述情況下lru一般爲刪除尾部節點。針對內存緩存，要釋放內存空間，針對磁盤緩存，要刪除磁盤文件。
s4lru
s4lru：https://www.dazhuanlan.com/2019/11/28/5ddf6f34db6a0/ 見facebook公開的一個探討，golang實現版：https://github.com/dgryski/go-s4lru/blob/master/s4lru.go
淘汰算法的好壞對實際緩存命中率的影響需要面向業務來評估，由於水平有限，無法給出一個比較好的數學模型來定量評估s4lru 到底好在哪裏（待谷歌或者論文查找），不會定量分析那就定性分析：我們使用極限的思維方法：普通lru就像一個大雜燴，傾向於對最近訪問的或者新增的有利, 假設某一天 某個客戶大量新增發佈了新的內容，即使後續僅有一次命中， 但使得老的節點被一直往後移動直至淘汰。要想優化大雜燴式就是分級管理，就像CPU 多級cache一樣，只有訪問最頻繁的離他最近速度最快。s4lru還引入了次數維度的多級隊列概念。同一次數級的和同一次數級的PK，高中生和高中生一起進行競爭，小學生和小學生一起競爭。避免小學生擠出高中生的情況。這種思路有點類似熱點遷移等等：多級管理
如何測試效果？直接線上測試統計命中率。
coss
在squid中有兩種文件系統 aufs 和 coss，aufs 和lru結合完全沒有問題，淘汰意爲着刪除文件。但是coss卻不行，因爲coss設計是隻有一個文件。如果無法刪除文件，那麼我們使用標記空洞的方式進行？除非有大量連續空洞，否則將失去順序寫的優勢。也就是說由於磁盤的緩存操作和lru管理上難以達到一致性，coss 不像aufs一樣在內存中有lru管理，只能依賴於磁盤操作的策略來實現lru。coss只有在文件空間寫滿的情況下再討論淘汰纔有意義，否則可以無限緩存。那麼coss的lru怎麼做？coss是直接從頭開始覆蓋，意味着滿足了基本的lru末尾淘汰，但是lru頭部引用的策略沒有做啊，會導致新的文件把訪問次數很多的文件覆蓋了。coss的第二個策略是當讀到某個緩存時，如果它離最新順序寫的位置太遙遠了，就要重新讀出來並寫到末尾，這個和lru的引用插入頭部的策略不是一樣嗎？但是一方面造成了讀寫IO 另一方面 造成了磁盤空間上某份內容的冗餘備份。
