閑話Cache：始篇
Caching（緩存）在現代的計算機系統中是一項最古老最基本的技術。它存在於計算機各種硬件和軟件系統中，比如各種CPU, 存儲系統（IBM ESS， EMC Symmetrix…），數據庫，Web服務器，中間件等。它的一個重要的作用就是用於彌補不同速度的硬件之間的存取速度的差距，cache可以完全通過硬件實現（算法也是通過硬件實現的），也可以通過在更快硬件上通過軟件控制來實現。
EMC Symmetrix之所以如此的昂貴，就是因為在這個系統中，提供了一個640G全相連的高速數據緩存（DRAM緩存），完全用硬件實現，就像一個放大版的CPU一級緩存。
Caching技術對於現代計算機系統之所以如此重要，就是在於，任何一個小的改進都會對整個計算機系統產生巨大的影響。因為cache具備一個特性，用最高的性價比可以實現我們希望得到的系統整體性能。
比如，磁盤和內存相比，磁盤具有大容量的特性，而內存具有高性能，但是對於同等容量，磁盤相比於內存來說非常廉價。這也就是我們不可能把所有磁盤都替換成內存（先不考慮永久存儲的特性），即便這樣我們可以獲得非常高的I/O速度。那么如何解決這兩者之間的不匹配？就是利用緩存技術。利用內存介質為磁盤做一層緩存。這樣就可以在不多花額外費用的同時，得到速度和容量的平衡。
同樣的道理存在於內存和CPU緩存之間。下圖是Intel Core i7 5500系列各部件的訪問速度：
|
|
訪問速度 |
| L1 Cache Hit |
4 cycles |
| L2 Cache hit |
10 cycles |
| L3 Cache hit, line unshared |
40 cycles |
| L3 Cache hit, shared line in another core |
65 cycles |
| L3 Cache hit, modified in another core |
75 cycles |
| Remote L3 cache |
100~300 cycles |
| Local RAM |
60 ns |
| Remote RAM |
100 ns |
從這里我們可以看到緩存對於系統性能的重要性。但是我們要達到理想的性能，還必須提高緩存的命中率，這樣緩存才可以最大限度的得到利用。
接下來，我們將會詳細地描述緩存算法。並且通過對比，來看看各種算法的優劣。
閑話緩存：概述
每當我們討論緩存時，總是會對如下幾個詞比較熟悉，
Write-back, write-through, write-around
似乎，緩存主要是為“寫”設計的，其實這是錯誤的理解，寫從緩存中獲得的好處是非常有限的，緩存主要是為“讀”服務的。
之所以我們要順帶提一下，在一個緩存系統中，如何處理寫的順序，是因為，在寫的過程中，需要動態的更新緩存（否則就會產生數據不一致性的問題），以及后端主存。這三個詞都是用來表示如何處理寫更新的。就是用什么方式來處理寫。
在一個有緩存的層次結構中，如何理解緩存是為“讀”服務的？這涉及到讀請求的處理序列。對於每一個讀請求，我們都會用如下的操作序列去處理它：
1. 在緩存中查找請求對應的數據
a. 如果找到，則直接返回給客戶
b. 如果沒找到，則把請求的數據讀入緩存（更新緩存），然后把數據返回給客戶
既然緩存主要是為讀服務的（后面的文章，我們會討論，用什么方式來改善寫的性能），那么為了提高讀的性能，或者說減少讀的響應時間，我們就要提高緩存的命中率，減少緩存的miss 率。這也是我們緩存算法設計的目標。
那么我們來想想，在設計緩存時，我們應該從哪幾方面考慮來達到這個緩存的設計目標呢？根據我們上面提到的讀請求的操作序列，我們可以從如下幾個方面來思考：
1. 我們應該盡量多的用有用的數據填滿緩存。也就是說，我們要充分利用緩存。
a. 這是緩存模塊和其它模塊不同的地方，並不是說緩存中的數據越少越好，而是有用的數據越多越好。
b. 這里有個非常好的列子，就是Windows的內存占用率總是非常高，很多人都表示過不滿。其實這是一個非常好的設計。Windows總是試圖盡量利用那些空閑的內存，用來緩存磁盤上的數據，以此來提高系統的整體性能。否則你那么大的內存，就為了拿來好看？
2. 如何獲取“有用”的數據。這里，“有用”的數據的定義就是可能在不久的將來會被client用到的數據。為了得到有用的數據，我們需要預估客戶端應用的I/O 模式，比如順序讀寫，隨機讀寫等等。這里就涉及到了“pre-fetch”算法。
a. Pre-fetch（預取算法）：是一種預測客戶端應用下次讀寫的數據在哪里的算法，並且把客戶要用的數據提前放入緩存中，以此來提高讀的響應速度。
3. 問題來了，如果緩存已經滿了，那么如何存放新的需要緩存的單元呢？這就牽涉到緩存設計的另一端：淘汰算法。
a. 相比於pre-fetch，淘汰算法（replacement policy）更加重要。因為對於隨機的I/O， 預取算法是無能為力的。
b. 淘汰算法的關鍵是如何判斷一個單元的數據比另一個單元的數據更加重要。但需要淘汰一個數據單元時，丟棄掉最不重要的那個數據單元，並且用它來存放新的數據。
4. 緩存算法設計的另外一個重要的考慮因素是算法的復雜度。或者說是實現或運行算法帶來的額外開銷。我們希望算法容易實現，並且額外開銷不隨着緩存大小的改變而改變。包括容量的額外開銷和計算的額外開銷。
接下來的文章，我們會詳細討論預取算法和淘汰算法。
閑話緩存：算法
從前面的文章中，我們已經了解到了緩存設計的目標，緩存設計應該考慮的因素。今天我們來看看一系列緩存算法以及它們如何去解決問題的。同時，我們也會涉及到各種緩存算法的優缺點。
這里我並不想討論與預取（pre-fetch）相關的算法，主要是考慮各種淘汰算法。因為相比於預取算法，淘汰算法具有更大的通用性，對緩存好壞影響更大。
1. 時間（完全從最近使用的時間角度考慮）
a. LRU（least recently used）：這種策略就是永遠替換掉最近最少使用的緩存單元。它是最古老，應用最廣泛的的一種淘汰算法。它的致命的缺陷就是沒有考慮緩存單元的使用頻率，在某些I/O 模式中，會把一些有價值的緩存單元替換出去。比如，假設我們有10個緩存單元，客戶端應用來了一次順序讀寫，這樣可能把這10個現有的緩存單元替換出去，而把這次順序讀寫的數據緩存起來。但是，這種順序讀寫的數據在以后都不會被再次用到。反而，那些因為順序讀而被替換出去的緩存單元卻是更有價值的。為此，有了各種各樣的基於LRU的優化策略被提出來。
2. 頻率（完全從使用頻率的角度考慮）
a. LFU（least frequently used）: IRM(獨立的引用模型)提供了一種用來獲取頻率的負載特性。它趨向於淘汰最近使用頻率最少的緩存單元。這種策略的弊端是：
i. 它的實現復雜度於緩存大小成對數關系（logarithmic）;
ii. 對最近的緩存單元的訪問情況基本沒考慮；
iii. 對訪問模式的改變基本上沒有應變的策略。
3. LRU-2（LRU-K）：一種對LRU的改進型策略 （頻率）
a. LRU-2於LFU很相似，如果我們不考慮它對緩存單元引用頻率進化分布的自適應性。它的基本思想是對每一個緩存單元，記住最近兩次訪問的時間。總是淘汰最近兩次時間間隔最長的緩存單元。在IRM的假設下，對於任何知道最多兩次最近引用緩存單元的在線算法，我們可以得出LRU-2具有最高的命中率。
b. 但是LRU-2也有一些實際的限制：
i. 它需要維護一個優先級隊列。也就是說它具有對數的實現復雜度；
ii. 它需要一個可調參數：CIP（correlated information period）。
c. 在現實中，對數的實現復雜度是一個非常嚴重的overhead（負擔）。所以另外一個策略2Q被提了出來。
4. 2Q：對LRU-2的改進策略 （頻率）
a. 相對於LRU-2，2Q的主要改進是用一個簡單的LRU list取代了LRU-2中的優先級隊列。其它的2Q和LRU-2基本相同。
b. 但是在2Q中，LRU-2的第二個不足還是存在，並且更嚴重了。因為它需要兩個可調參數：Kin和Kout。
c. 為什么可調參數一個很嚴重的限制？這是我們在實施一個系統時，必須確定這些參數，而且不可更改。一旦確定了一組參數，這個緩存系統往往只能對某一類workload表現很好。也就是這種緩存系統缺少了自適應性。
5. LIRS（Low Inter-reference Recency Set）（頻率）
a. 詳細描述參考：“LIRS： An efficient low inter-reference recency set replacement policy to improve buffer cache performance”
b. 第一個不足在於需要兩個可調參數Llirs 和Lhirs ；
c. 它的第二個缺點在於，在最壞的情況下，它需要一個“棧修剪”。這個操作需要遍歷數量龐大的緩存單元。
6. 時間和頻率（同時考慮時間和頻率的算法：LRU和LFU）
a. FBR（Frequency-based replacement）:詳細描述請參考“Data cache management using frequency-based replacement”。這個算法的不足之處在於：
i. 需要可調參數：緩存中三塊的大小，Cmax 和Amax：大小調整的時間周期。
ii. Cache pollution（解決cache污染的機制）
b. LRFU（Least Recently/Frequently Used）: 參考“LRFU： A spectrum of policies that subsumes the least recently used and least frequently used policies”
c. ALRFU(adaptive LRFU): 參考“On the existence of a spectrum of policies that subsumes the least recently used and least frequently used policies”
7. 臨時距離分布（Temporal distance distribution）
a. MQ(multi-queue replacement policy MQ ): 參考“The multi-queue replacement algorithm for second level buffer caches”
8. ARC: adaptive replacement cache(IBM), adjusted replacement cache(ZFS)
a. 一種自適應，低成本的淘汰算法
b. 它集合了LRU和LFU的優點，並且沒有額外的使用和實現成本。
c. 它可以更具workload的改變而自動的改變淘汰策略。
ARC是目前應用非常廣泛的一種淘汰算法。我們應該詳細的研究它，並實現它。在ZFS源碼中就是它的完整實現。當然，ZFS中的實現和IBM當初提出的內容有點改變。這個我們留在下篇文章中講述。
閑話緩存：ZFS 讀緩存深入研究-ARC（一）
在Solaris ZFS 中實現的ARC(Adjustable Replacement Cache)讀緩存淘汰算法真是很有意義的一塊軟件代碼。它是基於IBM的Megiddo和Modha提出的ARC（Adaptive Replacement Cache）淘汰算法演化而來的。但是ZFS的開發者們對IBM 的ARC算法做了一些擴展，以更適用於ZFS的應用場景。ZFS ARC的最早實現展現在FAST 2003的會議上，並在雜志《;Login:》的一篇文章中被詳細描述。
注：關於雜志《；Login:》，可參考這個鏈接：https://www.usenix.org/publications/login/2003-08/index.html
ZFS ARC真是一個優美的設計。在接下來的描述中，我將盡量簡化一些機制，以便於大家更容易理解ZFS ARC的工作原理。關於ZFS ARC的權威描述，可以參考這個鏈接：http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c。在接下來的段落中，我將試着給大家深入講解一下ZFS 讀緩存的內部工作原理。我將關注點放在數據如何進入緩存，緩存如何調整它自己以適應I/O模式的變化，以及“Adjustable Replacement Cache”這個名字是如何來的。
緩存
嗯,在一些文件系統緩存中實現的標准的LRU淘汰算法是有一些缺點的。例如，它們對掃描讀模式是沒有抵抗性的。但你一次順序讀取大量的數據塊時，這些數據塊就會填滿整個緩存空間，即使它們只是被讀一次。當緩存空間滿了之后，你如果想向緩存放入新的數據，那些最近最少被使用的頁面將會被淘汰出去。在這種大量順序讀的情況下，我們的緩存將會只包含這些新讀的數據，而不是那些真正被經常使用的數據。在這些順序讀出的數據僅僅只被使用一次的情況下，從緩存的角度來看，它將被這些無用的數據填滿。
另外一個挑戰是：一個緩存可以根據時間進行優化（緩存那些最近使用的頁面），也可以根據頻率進行優化（緩存那些最頻繁使用的頁面）。但是這兩種方法都不能適應所有的workload。而一個好的緩存設計是能自動根據workload來調整它的優化策略。
ARC的內部工作原理
在ARC原始的實現（IBM的實現）和ZFS中的擴展實現都解決了這些挑戰，或者說現存問題。我將描述由Megiddo和Modha提出的Adaptive Replacement Cache的一些基本概念，ZFS的實現版本作為這個實現機制的一個擴展來介紹。這兩種實現（原始的Adaptive Replacement Cache和ZFS Adjustable Replacement Cache）共享一些基本的操作原理，所以我認為這種簡化是一種用來解釋ZFS ARC切實可行的途徑。
首先，假設我們的緩存中有一個固定的頁面數量。簡單起見，假設我們有一個8個頁面大小的緩存。為了是ARC可以工作，在緩存中，它需要一個2倍大小的管理表。
這個管理表分成4個鏈表。頭兩個鏈表是顯而易見的：
· 最近最多使用的頁面鏈表 （LRU list）
· 最近最頻繁使用的頁面鏈表（LFU list）
另外兩個鏈表在它們的角色上有些奇怪。它們被稱作ghost鏈表。那些最近被淘汰出去的頁面信息被存儲在這兩個鏈表中：
· 存儲那些最近從最近最多使用鏈表中淘汰的頁面信息 （Ghost list for LRU）
· 存儲那些最近從最近最頻繁使用鏈表中淘汰的頁面信息（Ghost list for LFU）
這兩個ghost鏈表不儲存數據（僅僅儲存頁面信息，比如offset，dev-id），但是在它們之中的命中對ARC緩存工作的行為具有重要的影響，我將在后面介紹。那么在緩存中都發生了什么呢？
假設我們從磁盤上讀取一個頁面，並把它放入cache中。這個頁面會放入LRU 鏈表中。
接下來我們讀取另外一個不同的頁面。它也會被放入緩存。顯然，他也會被放入LRU 鏈表的最近最多使用的位置（位置1）：
好，現在我們再讀一次第一個頁面。我們可以看到，這個頁面在緩存中將會被移到LFU鏈表中。所有進入LRU鏈表中的頁面都必須至少被訪問兩次。無論什么時候，一個已經在LFU鏈表中的頁面被再次訪問，它都會被放到LFU鏈表的開始位置（most frequently used）。這么做，那些真正被頻繁訪問的頁面將永遠呆在緩存中，不經常訪問的頁面會向鏈表尾部移動，最終被淘汰出去。
隨着時間的推移，這兩個鏈表不斷的被填充，緩存也相應的被填充。這時，緩存已經滿了，而你讀進了一個沒有被緩存的頁面。所以，我們必須從緩存中淘汰一個頁面，為這個新的數據頁提供位置。這個數據頁可能剛剛才被從緩存中淘汰出去，也就是說它不被緩存中任何的非ghost鏈表引用着。
假設LRU鏈表已經滿了：
這時在LRU鏈表中，最近最少使用的頁面將會被淘汰出去。這個頁面的信息會被放進LRU ghost鏈表中。
現在這個被淘汰的頁面不再被緩存引用，所以我們可以把這個數據頁的數據釋放掉。新的數據頁將會被緩存表引用。
隨着更多的頁面被淘汰，這個在LRU ghost中的頁面信息也會向ghost鏈表尾部移動。在隨后的一個時間點，這個被淘汰頁面的信息也會到達鏈表尾部，LRU鏈表的下一次的淘汰過程發生之后，這個頁面信息也會從LRU ghost鏈表中移除，那是就再也沒有任何對它的引用了。
好的，如果這個頁面在被從LRU ghost鏈表中移除之前，被再一次訪問了，將會發生什么？這樣的一個讀將會引起一次幽靈（phantom）命中。由於這個頁面的數據已經從緩存中移除了，所以系統還是必須從后端存儲媒介中再讀一次，但是由於這個幽靈命中，系統知道，這是一個剛剛淘汰的頁面，而不是第一次讀取或者說很久之前讀取的一個頁面。ARC用這個信息來調整它自己，以適應當前的I/O模式（workload）。
很顯然，這個跡象說明我們的LRU緩存太小了。在這種情況下，LRU鏈表的長度將會被增加一。顯然，LFU鏈表的長度將會被減一。
但是同樣的機制存在於LFU這邊。如果一次命中發生在LFU ghost 鏈表中，它會減少LRU鏈表的長度（減一），以此在LFU 鏈表中加一個可用空間。
利用這種行為，ARC使它自己自適應於工作負載。如果工作負載趨向於訪問最近訪問過的文件，將會有更多的命中發生在LRU Ghost鏈表中，也就是說這樣會增加LRU的緩存空間。反過來一樣，如果工作負載趨向於訪問最近頻繁訪問的文件，更多的命中將會發生在LFU Ghost鏈表中，這樣LFU的緩存空間將會增大。
進一步，這種行為開啟了一個靈活的特性：假設你為處理log文件而讀取了大量的文件。你只需要每個文件一次。一個LRU 緩存將會把所有的數據緩存住，這樣也就把經常訪問的數據也淘汰出去了。但是由於你僅僅訪問這些文件一次，它們不會為你帶來任何價值一旦它們填滿了緩存。
一個ARC緩存的行為是不同的。顯然這樣的工作負載僅僅會很快填滿LRU鏈表空間，而這些頁面很快就會被淘汰出去。但是由於每個這樣的頁面僅僅被訪問一次，它們基本不太可能在為最近訪問的文件而設計的ghost鏈表中命中。這樣，LRU的緩存空間不會因為這些僅讀一次的頁面而增加。
假如你把這些log文件與一個大的數據塊聯系在一起（為了簡單起見，我們假設這個數據塊沒有自己的緩存機制）。數據文件中的數據頁應該會被頻繁的訪問。被LFU ghost鏈表引用的正在被訪問的頁面就很有可能大大的高於LRU ghost鏈表。這樣，經常被訪問的數據庫頁面的緩存空間就會增加。最終，我們的緩存機制就會向緩存數據塊頁面優化，而不是用log文件來污染我們的緩存空間。
閑話緩存：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源代碼：http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c