非精準的LRU

上面提到的LRU（Least Recently Used）策略，實際上Redis實現的LRU並不是可靠的LRU，也就是名義上我們使用LRU演算法淘汰鍵，但是實際上被淘汰的鍵並不一定是真正的最久沒用的，這裡涉及到一個權衡的問題，如果需要在全部鍵空間內搜尋最優解，則必然會增加系統的開銷，Redis是單執行緒的，也就是同一個例項在每一個時刻只能服務於一個客戶端，所以耗時的操作一定要謹慎。為了在一定成本內實現相對的LRU，早期的Redis版本是基於取樣的LRU，也就是放棄全部鍵空間內搜尋解改為取樣空間搜尋最優解。自從Redis3.0版本之後，Redis作者對於基於取樣的LRU進行了一些優化，目的是在一定的成本內讓結果更靠近真實的LRU。

LRU的實現（也是經典的頁面置換演算法），可以用LinkedHashMap來實現，可以通過指定按什麼順序來訪問實現，建構函式中，有一個引數：accessOrder，當被設定為false 時是基於插入順序  true  基於訪問順序（get一個元素後，這個元素被加到最後，使用了LRU  最近最少被使用的排程演算法）。

Redis主從同步原理

和MySQL主從複製的原因一樣，Redis雖然讀取寫入的速度都特別快，但是也會產生讀壓力特別大的情況。為了分擔讀壓力，Redis支援主從複製，另外也是為了保證HA。Redis主從複製可以根據是否是全量分為全量同步和增量同步。

全量同步

Redis全量複製一般發生在Slave初始化階段，這時Slave需要將Master上的所有資料都複製一份。具體步驟如下： 
　　1）從伺服器連線主伺服器，傳送SYNC命令； 
　　2）主伺服器接收到SYNC命名後，開始執行BGSAVE命令生成RDB檔案並使用緩衝區記錄此後執行的所有寫命令； 
　　3）主伺服器BGSAVE執行完後，向所有從伺服器傳送快照檔案，並在傳送期間繼續記錄被執行的寫命令； 
　　4）從伺服器收到快照檔案後丟棄所有舊資料，載入收到的快照； 
　　5）主伺服器快照發送完畢後開始向從伺服器傳送緩衝區中的寫命令； 
　　6）從伺服器完成對快照的載入，開始接收命令請求，並執行來自主伺服器緩衝區的寫命令； 

增量同步

Redis增量複製是指Slave初始化後開始正常工作時主伺服器發生的寫操作同步到從伺服器的過程。 
增量複製的過程主要是主伺服器每執行一個寫命令就會向從伺服器傳送相同的寫命令，從伺服器接收並執行收到的寫命令。
Redis的同步策略是：主從剛剛連線的時候，進行全量同步；全量同步結束後，進行增量同步。當然，如果有需要，slave 在任何時候都可以發起全量同步。redis 策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。

Redis的哨兵機制

Redis-Sentinel也就是哨兵機制，是Redis官方推薦的高可用性(HA)解決方案，當用Redis做Master-slave的高可用方案時，假如master宕機了，Redis本身(包括它的很多客戶端)都沒有實現自動進行主備切換，而Redis-sentinel本身也是一個獨立執行的程序，它能監控多個master-slave叢集，發現master宕機後能進行自動切換。 它的主要功能有以下幾點

• 不時地監控redis是否按照預期良好地執行;
• 如果發現某個redis節點執行出現狀況，能夠通知另外一個程序(例如它的客戶端);
• 能夠進行自動切換（進行主備切換）。當一個master節點不可用時，能夠選舉出master的多個slave(如果有超過一個slave的話)中的一個來作為新的master,其它的slave節點會將它所追隨的master的地址改為被提升為master的slave的新地址。

Sentinel支援叢集
很顯然，只使用單個sentinel程序來監控redis叢集是不可靠的，當sentinel程序宕掉後(sentinel本身也有單點問題，single-point-of-failure)整個集群系統將無法按照預期的方式執行。所以有必要將sentinel叢集，這樣有幾個好處：

1. 即使有一些sentinel程序宕掉了，依然可以進行redis叢集的主備切換；
2. 如果只有一個sentinel程序，如果這個程序執行出錯，或者是網路堵塞，那麼將無法實現redis叢集的主備切換（單點問題）;
3. 如果有多個sentinel，redis的客戶端可以隨意地連線任意一個sentinel來獲得關於redis叢集中的資訊。

看到這，我們會想，Redis提供的哨兵機制和Zookeeper的應用場景類似，利用ZK也可以監控伺服器執行狀態，並在有宕機情況發生時完成master選舉，從而進行故障轉移。

哨兵機制的執行過程

我們可以簡單用圖來表示一下Sentinel的作用：

 如上圖所示，Redis為了保證高可用性，採用Master-slave形式部署，採用AOF或RDB進行持久化，採用叢集culster機制來分散式儲存。多個哨兵,不僅同時監控主從資料庫,而且哨兵之間互為監控，並且哨兵不會存在單點問題。哨兵會監控主從Redis伺服器是否正常，當發現有問題時，會進行通知，並進行故障轉移。當監控到master節點宕機後，會進行maser選舉出新的master節點，並進行主從切換，並將其他節點作為新選舉出的master節點的slave。哨兵Sentinel用到的分散式一致性演算法是Raft分散式演算法。

redis利用比較易於實現的raft協議實現了節點宕機的自動化處理，保障了叢集的高可用性。Raft協議與paxos演算法類似，但比paxos演算法好理解，我們都知道，paxos演算法是經典的分散式一致性演算法，zookeeper的ZAB協議也是在其基礎上設計的。ZAB，paxos，Raft都是採用過半策略。關於相關分散式演算法，我會在後邊的系列，Zookeeper系列進行介紹。對於Redis的監控過程，Leader選舉，主備切換，資料同步等過程，跟Zookeeper類似，我們可以把zookeeper的實現方式與其進行類比。可以把哨兵叢集當做一個Zk叢集？