**：
閒話快取：zfs
讀快取深入研究
-arc
（二）solaris zfs arc
的改動（相對於
ibm arc
）如我前面所說，zfs實現的arc和ibm提出的arc淘汰演算法並不是完全一致的。在某些方面，它做了一些擴充套件：
· zfs arc是乙個快取容量可變的快取演算法，它的容量可以根據系統可用記憶體的狀態進行調整。當系統記憶體比較充裕的時候，它的容量可以自動增加。當系統記憶體比較緊張（其它事情需要記憶體）的時候，它的容量可以自動減少。
· zfs arc可以同時支援多種塊大小。原始的實現假設所有的塊都是相同大小的。
· zfs arc允許把一些頁面鎖住，以使它們不會被淘汰。這個特性可以防止快取淘汰一些正在使用的頁面。原始的設計沒有這個特性，所以在zfs arc中，選擇淘汰頁面的演算法要更複雜些。它一般選擇淘汰最舊的可淘汰頁面。
有一些其它的變更，但是我把它們留在對arc.c這個原始檔講解的演講中。
l2arc
l2arc保持著上面幾個段落中沒涉及到的乙個模型。arc並不自動地把那些淘汰的頁面移進l2arc，而是真正淘汰它們。雖然把淘汰頁面自動放入l2arc是乙個看起來正確的邏輯，但是這卻會帶來十分嚴重負面影響。首先，乙個突發的順序讀會覆蓋掉l2arc快取中的很多的頁面，以至於這樣的一次突發順序讀會短時間內淘汰很多l2arc中的頁面。這是我們不期望的動作。
另乙個問題是：讓我們假設一下，你的應用需要大量的堆記憶體。這種更改過的solaris arc能夠調整它自己的容量以提供更多的可用記憶體。當你的應用程式申請記憶體時，arc快取容量必須 變得越來越小。你必須立即淘汰大量的記憶體頁面。如果每個頁面被淘汰的頁面都寫入l2arc，這將會增加大量的延時直到你的系統能夠提供更多的記憶體，因為你必須等待所有淘汰頁面在被淘汰之前寫入l2arc。
l2arc機制用另一種稍微不同的手段來處理這個問題：有乙個叫l2arc_feed_thread會遍歷那些很快就會被淘汰的頁面（lru和lfu鍊錶的末尾一些頁面），並把它們寫入乙個8m的buffer中。從這裡開始，另乙個執行緒write_hand會在乙個寫操作中把它們寫入l2arc。
這個演算法有以下一些好處：釋放記憶體的延時不會因為淘汰頁面而增加。在一次突發的順序讀而引起了大量淘汰頁面的情況下，這些資料塊會被淘汰出去在l2arc——feed_thread遍歷到那兩個鍊錶結尾之前。所以l2arc被這種突發讀汙染的機率會減少（雖然不能完全的避免被汙染）。 結論
adjustable replacement cache的設計比普通的lru快取設計有效很多。megiddo和 modha用它們的adaptive replacement cache得出了更好的命中率。zfs arc利用了它們的基本操作理論，所以命中率的好處應該與原始設計差不多。更重要的是：如果這個快取演算法幫助它們得出更好的命中率時，用ssd做大快取的想法就變得更加切實可行。
1. the theory of arc operation in one up on lru, written by megiddo and modha, ibm almanden research center
2. zfs arc源**：
LRU快取機制演算法實現
就是一種快取淘汰策略。計算機的快取容量有限，如果快取滿了就要刪除一些內容，給新內容騰位置。但問題是，刪除哪些內容呢？我們肯定希望刪掉哪些沒什麼用的快取，而把有用的資料繼續留在快取裡，方便之後繼續使用。那麼，什麼樣的資料，我們判定為 有用的 的資料呢？lru 快取淘汰演算法就是一種常用策略。lru 的...
IOS 開發快取機制 記憶體快取機制
使用快取的目的是為了使用的應用程式能更快速的響應使用者輸入，是程式高效的執行。有時候我們需要將遠端 web伺服器獲取的資料快取起來，減少對同乙個 url多次請求。記憶體快取我們可以使用 sdk中的 nsurlcache類。nsurlrequest需要乙個快取引數來說明它請求的 url何如快取資料的，...
mybatis的快取機制（二級快取）
mybatis提供了快取機制減輕資料庫壓力，提高資料庫效能 mybatis的快取分為兩級 一級快取 二級快取 一級快取是sqlsession級別的快取，快取的資料只在sqlsession內有效 一級快取 mybatis的一級快取是sqlsession級別的快取，在運算元據庫的時候需要先建立sqlse...