深度詳解GaussDB bufferpool快取策略

　　一 、GaussDB(for mysql)簡介

　　華為雲GaussDB(for mysql)是華為雲自主研發的最新一代雲原生資料庫，採用計算儲存分離、日誌即資料的架構設計。透過IO解除安裝、日誌壓縮合並、批次處理、軟硬體垂直整合等技術，使資料庫效能方面有了大幅提升。同時儲存層採用多副本，多az部署，增強資料可靠性。具備極致可靠、極致價效比、多為擴充套件、完全可信等諸多特性。

　　GaussDB(for mysql)採用了計算儲存分離、日誌即資料的架構，一部分計算能力下推到儲存層。儲存層需要透過consolidation不斷將寫入的日誌應用到頁面上，從而將日誌回收掉。另外SQL層從儲存層讀取頁面時，也需要將日誌回放到相應的版本從而獲得對應版本的頁面。如果每次都從磁碟讀取頁面，IO時延較大，這裡將成為整個回放流程的瓶頸。

　　根據資料庫一貫的做法，我們需要一個快取(bufferpool)，把經常訪問的頁面放在快取中，從而加快頁面讀取的速度。但是儲存層能夠分配給bufferpool的資源非常有限，我們需要根據bufferpool的使用特點設計一個高效的快取策略。

　　二、一些常見的快取淘汰演算法

　　快取一般從以下三個特徵進行描述：

　　命中率

　　返回正確結果數/請求快取次數，命中率問題是快取中的一個非常重要的問題，它是衡量快取有效性的重要指標。命中率越高，表明快取的使用率越高。

　　最大元素(或最大空間)

　　快取中可以存放的最大元素的數量，一旦快取中元素數量超過這個值(或者快取資料所佔空間超過其最大支援空間)，那麼將會觸發快取啟動清空策略根據不同的場景合理的設定最大元素值往往可以一定程度上提高快取的命中率，從而更有效的時候快取。

　　淘汰(替換)策略

　　如上描述，快取的儲存空間有限制，當快取空間被用滿時，如何保證在穩定服務的同時有效提升命中率?這就由淘汰(替換)策略來處理，設計適合自身資料特徵的淘汰策略能有效提升命中率。

　　因此，選擇一個適合使用場景的淘汰(替換)策略非常重要，能夠大大提升快取命中率，從而加速業務處理。

　　快取的淘汰(替換)根據訪問模式可以分為基於時間或者訪問頻率兩類，下面分別對這兩類進行詳細描述。

　　基於訪問時間：此類演算法按各快取項的被訪問時間來組織快取佇列,決定替換物件，如LRU。

　　基於訪問頻率：此類演算法用快取項的被訪問頻率來組織快取。如LFU、LRU-2、2Q、LIRS。

　　1. LRU

　　基本思想：如果資料最近被訪問過，那麼將來被訪問的機率也更高

　　常見實現方法：

　　一般採用unordered_map+list來實現，訪問資料時，直接從unordered_map透過key在O(1)時間內獲取到所需資料。有新資料時，插入到連結串列的頭部;當快取命中時，也將資料移動到連結串列頭部;當快取滿時將連結串列尾部的資料丟棄。

　　

　　命中率分析

　　當存在熱點資料時，LRU的效率很好，但偶發性的、週期性的批次操作會導致LRU命中率急劇下降，快取汙染情況比較嚴重。

　　Mysql對樸素LRU演算法的改進：

　　由於樸素的LRU演算法會存在快取汙染問題，若直接讀取到的頁放入到LRU的首部，那麼某些SQL操作可能會使緩衝池中的頁被重新整理出，從而影響緩衝池的效率。常見的這類操作為索引或資料的掃描操作。這類操作需要訪問表中的許多頁，甚至是全部的頁，而這些頁通常來說又僅在這次查詢操作中需要，並不是活躍的熱點資料。如果頁被放入LRU列表的首部，那麼非常可能將所需要的熱點資料頁從LRU列表移除，而在下一次需要讀取該頁時，InnoDB儲存引擎需要再次訪問磁碟。

　　解決方案：

　　InnoDB儲存引擎引入了另一個引數來進一步管理LRU列表，這個引數是Innodb_old_blocks_time，用於表示頁讀取到mid位置後需要等待多久才會被加入到LRU列表的熱端。連結串列按照5:3的比例分為young區和old區，新加入的資料放在old區，若old區的資料在LRU連結串列中存在時間超過了1秒，則將其移動到連結串列頭部，如果資料在LRU old區連結串列中存在的時間少於1秒，則保持位置不變，淘汰時優先淘汰old區的資料。這樣可以避免全表掃描對LRU連結串列的汙染，全表掃描的冷資料很快會被淘汰出去。

　　2. LFU

　　基本思想：如果資料過去被訪問多次，那麼將來被訪問的頻率也更高。

　　注意LFU和LRU的區別，LRU的淘汰規則是基於訪問時間，而LFU是基於訪問次數常見實現方法：

　　與LRU類似，LFU一般也採用unordered_map+list來實現，訪問資料時，直接從unordered_map透過key在O(1)時間內獲取到所需資料。有新資料時，插入到連結串列的尾部;

　　當快取命中時，增加該key的引用計數，連結串列按照引用計數排序。為了避免節點在連結串列中頻繁移動，一般會將連結串列劃分為多個區域或者使用多個連結串列，如果引用計數落入某個範圍，將該節點加入到相應的連結串列中，當引用計數超出閾值時將當前節點移動到上一個區間的連結串列。當快取滿時將引用計數最小的區域的資料丟棄。

　　命中率分析

　　LFU命中率要優於LRU，且能夠避免週期性或者偶發性的操作導致快取命中率下降的問題，但LFU需要記錄資料的歷史訪問記錄，一旦資料訪問模式改變，LFU需要更長時間來適用新的訪問模式，即LFU存在歷史資料影響將來資料的"快取汙染"問題。

　　3. LRU-K

　　LRU-K中的K代表最近使用的次數，因此LRU可以認為是LRU-1。LRU-K的主要目的是為了解決LRU演算法"快取汙染"的問題，其核心思想是將"最近使用過1次"的判斷標準擴充套件為"最近使用過K次"

　　常用實現如下：

　　資料第一次被訪問，加入到訪問歷史列表;如果資料在訪問歷史列表裡後沒有達到K次訪問，則按照LRU淘汰;當訪問歷史佇列中的資料訪問次數達到K次後，將資料索引從歷史佇列刪除，將資料移到快取佇列中，並快取此資料，快取佇列重新按照時間排序;快取資料佇列中被再次訪問後，重新排序;需要淘汰資料時，淘汰快取佇列中排在末尾的資料，即淘汰"倒數第K次訪問離現在最久"的資料。

　　命中率分析：

　　LRU-K具有LRU的優點，同時能夠避免LRU的缺點，實際應用中LRU-2是綜合各種因素後最優的選擇，LRU-3或者更大的K值命中率會高，但適應性差，需要大量的資料訪問才能將歷史訪問記錄清除掉。LRU-K降低了"快取汙染"帶來的問題，命中率比LRU要高。

　　4. 2Q

　　演算法類似於LRU-2，不同點在於2Q將LRU-2演算法中的訪問歷史佇列改為一個FIFO佇列，即2Q有兩個快取佇列：FIFO佇列和LRU佇列

　　常見實現方法：

　　當資料第一次訪問時，2Q演算法將資料快取在FIFO佇列裡面，當資料第二次被訪問時，則將資料從FIFO佇列移到LRU佇列裡面，兩個佇列各自按照自己的方法淘汰資料。

　　命中率分析：

　　2Q LRU-K類似，都是LRU的改進版，命中率比LRU要高，可以避免LRU汙染帶來的問題。

　　上面介紹了4個常用的快取淘汰演算法，實現起來也不是很複雜。當然還有一些其他的演算法，這裡就不再介紹了，感興趣的朋友可以查詢資料學習一下。

　　三、 GaussDB(for mysql)bufferpool的快取策略

　　GaussDB(for mysql)目前支援兩種快取淘汰策略：LRU和LFU，這兩種淘汰演算法都是改進過的。

　　1. 改進的LFU演算法：

　　LFU在實現上採用unordered_map+list方式實現，訪問資料時，直接從unordered_map透過key在O(1)時間內獲取到所需資料。為了避免資料在連結串列中頻繁移動，將連結串列按照引用計數分成多個區間，當快取命中時，增加引用計數，若引用計數仍落在原來的區間，保持資料在連結串列中的位置不動，如果引用計數落入新的區間，將資料移動到相應位置。

　　為了避免一些頻繁訪問的資料後面不再訪問，但是引用計數很大，導致不能被淘汰，因此引入“老化”策略，每隔一段時間將引用計數值衰減一下，這樣就可以將一些引用計數較大，但是當前不怎麼訪問的資料淘汰出去。

　　一些被淘汰出去的資料我們還會在歷史記錄裡面保留一段時間其對應的引用計數，下次該資料再次被加入快取時，可以“投胎轉世”，可以在上次的引用計數基礎上開始計數。這樣可以更精確的反應資料被訪問的頻率。

　　LFU的快取命中率較高，但是在“老化”的過程中需要對連結串列加鎖，這樣會阻塞其他地方的訪問。

　　2. 改進的LRU演算法：

　　與mysql的改進LRU演算法類似，也是將連結串列劃分為hot和cold兩個區，資料第一次被加入時先放入cold區，當再次命中時移入hot區。淘汰時優先淘汰cold區的資料。同時我們引入了一個lockfree的佇列，以免在flush page時對連結串列加鎖，增強緩衝操作的併發度。

　　四、下一步的改進

　　雖然我們引入了改進版的LRU和LFU演算法，但是在大資料量時，按照一些模擬分析資料，還有一定的改進空間。後面在兩個演算法的基礎上進一步改進，提升快取的命中率。