Redis中的多路復(fù)用模型

Redis6用到了多線程言沐？那多線程應(yīng)用在哪些地方邓嘹，引入多線程后，又改如何保證線程安全性呢险胰？
同時(shí)吴超，如何在性能和線程安全性方面做好平衡？

關(guān)于Redis的單線程模型

在Redis6.0之前鸯乃，我們一直說Redis是單線程鲸阻，所以并不會存在線程安全問題跋涣，而這個(gè)單線程，實(shí)際上就是在做數(shù)據(jù)IO處理中鸟悴，是用的主線程來串行執(zhí)行陈辱，如圖4-7所示。

Redis基于Reactor模式設(shè)計(jì)開發(fā)了自己的一套高效事件處理模型细诸，這個(gè)事件處理模型對應(yīng)的就是Redis中的文件事件處理器沛贪，這個(gè)文件事件處理器是單線程運(yùn)行的，這也是為什么我們一直強(qiáng)調(diào)Redis是線程安全的震贵。

既然Redis是基于Reactor模型實(shí)現(xiàn)利赋，那它必然用了I/O多路復(fù)用機(jī)制來監(jiān)聽多個(gè)客戶端連接，然后把感興趣的事件（READ/ACCEPT/CLOSE/WRITE）注冊到多路復(fù)用器中猩系。

文件事件處理器中使用I/O多路復(fù)用模型同時(shí)監(jiān)聽多個(gè)客戶端連接媚送，并且根據(jù)當(dāng)前連接執(zhí)行的任務(wù)類型關(guān)聯(lián)不同的事件處理器（連接應(yīng)答處理器、命令請求處理器寇甸、命令回復(fù)處理器）來處理這些事件塘偎。

這樣設(shè)計(jì)的好處：

• 文件事件處理器實(shí)現(xiàn)了高性能的網(wǎng)絡(luò)IO通信模型
• 通過單線程的方式執(zhí)行指令，避免同步機(jī)制的性能開銷拿霉、避免過多的上下文切換吟秩、整體實(shí)現(xiàn)比較簡單，不需要考慮多線程場景中的各種數(shù)據(jù)結(jié)構(gòu)的線程安全問題绽淘。

image-20210708232804607

<center>圖4-7</center>

其實(shí)嚴(yán)格意義上來說涵防，在Redis4.x版本就支持了多線程，只是沪铭，負(fù)責(zé)客戶端請求的IO處理使用的是單線程壮池。但是針對那些非常耗時(shí)的命令，Redis4.x提供了異步化的指令來處理伦意，避免因?yàn)镮O時(shí)間過長影響到客戶端請求IO處理的線程火窒。比如在 Redis v4.0 之后增加了一些的非阻塞命令如 UNLINK（del命令的異步版本）硼补、FLUSHALL ASYNC驮肉、FLUSHDB ASYNC。

Redis6.0之后的多線程已骇？

在Redis6.0中引入了多線程离钝，可能很多同學(xué)會誤以為redis原本的單線程數(shù)據(jù)IO變成了多線程IO，那作者不就是在打自己的臉嗎褪储？

對于Redis來說卵渴，CPU通常不是瓶頸，因?yàn)榇蠖鄶?shù)請求不是屬于CPU密集型鲤竹，而是I/O密集型浪读。而在Redis中除了數(shù)據(jù)的持久化方案之外昔榴，它是完全的純內(nèi)存操作，因此執(zhí)行速度是非车忾伲快的互订，所以數(shù)據(jù)的IO并不是Redis的性能瓶頸，Redis真正的性能瓶頸是在網(wǎng)絡(luò)I/O痘拆，也就是客戶端和服務(wù)端之間的網(wǎng)絡(luò)傳輸延遲仰禽，所以Redis選擇了單線程的IO多路復(fù)用來實(shí)現(xiàn)它的核心網(wǎng)絡(luò)模型。

前面我們說過纺蛆，單線程設(shè)計(jì)對于Redis來說有很多好處吐葵。

• 避免過多的上上下文切換開銷
• 避免同步機(jī)制的開銷，涉及到數(shù)據(jù)同步和事務(wù)操作時(shí)桥氏，避免多線程影響所以必然需要加同步機(jī)制保證線程安全性温峭。但是加鎖同時(shí)也會影響到程序的執(zhí)行性能。
• 維護(hù)簡單识颊，引入多線程之后诚镰，不管是對數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)，還是在程序代碼的維護(hù)上祥款，都會變得很復(fù)雜清笨。

所以既然Redis的數(shù)據(jù)I/O不是瓶頸，同時(shí)單線程又有這么多好處刃跛，那Redis自然就采用單線程了抠艾。既然是這樣，那么Redis 6.0引入多線程桨昙，一定不是優(yōu)化數(shù)據(jù)IO性能检号，那么我們先來分析一下Redis性能瓶頸主要體現(xiàn)在哪些方面，無非就是三個(gè)方面蛙酪。

• 網(wǎng)絡(luò)IO
• CPU核心數(shù)
• 內(nèi)存

由于CPU核心數(shù)并不是redis的瓶頸齐苛，所以影響Redis性能的因素只有網(wǎng)絡(luò)IO和內(nèi)存，而內(nèi)存屬于硬件范疇桂塞，比如采用容量更大凹蜂、吞吐量更高的內(nèi)存進(jìn)行優(yōu)化就行，因此也不是屬于Redis可優(yōu)化的空間阁危，所以最終我們發(fā)現(xiàn)Redis的性能瓶頸還是在網(wǎng)絡(luò)IO上玛痊。

而在Redis6.0之前，使用的是單線程Reactor模型狂打，單線程模型是指對于客戶端的請求擂煞，主線程需要負(fù)責(zé)對這個(gè)請求的完整IO過程進(jìn)行處理，如圖4-8所示趴乡，從socket中讀取數(shù)據(jù)和往socket中寫數(shù)據(jù)都是比較耗時(shí)的網(wǎng)絡(luò)IO操作对省，解析請求和內(nèi)存交互耗時(shí)可能遠(yuǎn)小于這個(gè)網(wǎng)絡(luò)IO操作蝗拿。

image-20210710153215329

<center>圖4-8</center>

按照前面我們對多Reactor多線程的理解，那我們能不能改成主從多Reactor多線程模型呢蒿涎？主Reactor負(fù)責(zé)接收客戶端連接蛹磺，然后分發(fā)給多個(gè)Reactor進(jìn)行網(wǎng)絡(luò)IO操作。很顯然同仆，這樣做就會導(dǎo)致Redis編程了一個(gè)多線程模型萤捆，這對Redis的影響較大，因?yàn)槎嗑€程帶來的線程安全問題和底層復(fù)雜的數(shù)據(jù)結(jié)構(gòu)的操作都非常棘手俗批，所以Redis 6.0并沒有這么做俗或。

Redis 6.0中將處理過程中最耗時(shí)的Socket讀取、請求解析岁忘、單獨(dú)用一個(gè)線程來處理辛慰，剩下的命令執(zhí)行操作仍然由單線程來完成和內(nèi)存的數(shù)據(jù)交互，這樣一來干像，網(wǎng)絡(luò)IO操作就變成了多線程了帅腌，但是核心部分仍然是線程安全的，如圖4-9所示麻汰。

image-20210710154600353

<center>圖4-9</center>

為什么說Redis6.0是一個(gè)特殊的多線程速客，原因就在這里，Redis主要針對網(wǎng)絡(luò)IO這塊引入了多線程的方式來提升了網(wǎng)絡(luò)IO性能五鲫，但是真正執(zhí)行命令的操作仍然是由主線程來完成溺职。因此，總的來說位喂，我們?nèi)匀豢梢哉fRedis是單線程模型浪耘。

Redis 6.0如何開啟多線程

Redis 6.0默認(rèn)多線程是禁止的，也就是仍然只是使用主線程來完成網(wǎng)絡(luò)IO塑崖，如果需要開啟七冲，則修改redis.conf配置文件中的如下屬性

# 默認(rèn)是關(guān)閉，設(shè)置為yes打開
io-threads-do-reads no
#默認(rèn)線程數(shù)量是4规婆，官方建議是4核機(jī)器上設(shè)置為2~3個(gè)澜躺，8核機(jī)器上設(shè)置6個(gè)
io-threads 4

引入多線程之后的性能提升

圖4-20是美團(tuán)技術(shù)團(tuán)隊(duì)使用阿里云服務(wù)器壓測GET/SET命令在4個(gè)線程IO時(shí)性能上的對比結(jié)果，可以明顯的看到聋呢，Redis 在使用多線程模式之后性能大幅提升苗踪，達(dá)到了一倍颠区。

• Redis Server 阿里云 Ubuntu 18.04 削锰， 8CPU 2.5GHZ，8G內(nèi)存毕莱，主機(jī)型號： ecs.ic5.2xlarge
• Redis Benchmark client: 阿里云 Unbuntu 18.04 , 8CPU 2.5GHZ器贩，8G內(nèi)存颅夺，主機(jī)型號：ecs.ic5.2xlarge

preview

preview

<center>圖4-20</center>

內(nèi)存回收策略

很多同學(xué)了解了Redis的好處之后，于是把任何數(shù)據(jù)都往Redis中放蛹稍，如果使用不合理很容易導(dǎo)致數(shù)據(jù)超過Redis的內(nèi)存吧黄，這種情況會出現(xiàn)什么問題呢？

• Redis中有很多無效的緩存唆姐，這些緩存數(shù)據(jù)會降低數(shù)據(jù)IO的性能拗慨，因?yàn)椴煌臄?shù)據(jù)類型時(shí)間復(fù)雜度算法不同，數(shù)據(jù)越多可能會造成性能下降
• 隨著系統(tǒng)的運(yùn)行奉芦，redis的數(shù)據(jù)越來越多赵抢，會導(dǎo)致物理內(nèi)存不足。通過使用虛擬內(nèi)存（VM）声功，將很少訪問的數(shù)據(jù)交換到磁盤上烦却，騰出內(nèi)存空間的方法來解決物理內(nèi)存不足的情況。雖然能夠解決物理內(nèi)存不足導(dǎo)致的問題先巴，但是由于這部分?jǐn)?shù)據(jù)是存儲在磁盤上其爵，如果在高并發(fā)場景中，頻繁訪問虛擬內(nèi)存空間會嚴(yán)重降低系統(tǒng)性能伸蚯。

所以遇到這類問題的時(shí)候摩渺，我們一般有幾種方法。

• 對每個(gè)存儲到redis中的key設(shè)置過期時(shí)間剂邮，這個(gè)根據(jù)實(shí)際業(yè)務(wù)場景來決定证逻。否則，再大的內(nèi)存都會雖則系統(tǒng)運(yùn)行被消耗完抗斤。
• 增加內(nèi)存
• 使用內(nèi)存淘汰策略囚企。

設(shè)置Redis能夠使用的最大內(nèi)存

在實(shí)際生產(chǎn)環(huán)境中，服務(wù)器不僅僅只有Redis瑞眼，為了避免Redis內(nèi)存使用過多對其他程序造成影響龙宏，我們一般會設(shè)置最大內(nèi)存。

Redis默認(rèn)的最大內(nèi)存maxmemory=0伤疙，表示不限制Redis內(nèi)存的使用银酗。我們可以修改redis.conf文件，設(shè)置Redis最大使用的內(nèi)存徒像。

# 單位為byte
maxmemory <bytes>  2147483648（2G）

如何查看當(dāng)前Redis最大內(nèi)存設(shè)置呢黍特，進(jìn)入到Redis-Cli控制臺，輸入下面這個(gè)命令锯蛀。

config get maxmemory

當(dāng)Redis中存儲的內(nèi)存超過maxmemory時(shí)灭衷，會怎么樣呢？下面我們做一個(gè)實(shí)驗(yàn)

• 在redis-cli控制臺輸入下面這個(gè)命令旁涤，把最大內(nèi)存設(shè)置為1個(gè)字節(jié)翔曲。

  config set maxmemory 1
  

• 通過下面的命令存儲一個(gè)string類型的數(shù)據(jù)

  set name mic
  

• 此時(shí)迫像，控制臺會得到下面這個(gè)錯(cuò)誤信息

  (error) OOM command not allowed when used memory > 'maxmemory'.

使用內(nèi)存淘汰策略釋放內(nèi)存

設(shè)置了maxmemory的選項(xiàng)，redis內(nèi)存使用達(dá)到上限瞳遍∥偶耍可以通過設(shè)置LRU算法來刪除部分key，釋放空間掠械。默認(rèn)是按照過期時(shí)間的由缆，如果set時(shí)候沒有加上過期時(shí)間就會導(dǎo)致數(shù)據(jù)寫滿maxmemory。

Redis中提供了一種內(nèi)存淘汰策略猾蒂，當(dāng)內(nèi)存不足時(shí)犁功，Redis會根據(jù)相應(yīng)的淘汰規(guī)則對key數(shù)據(jù)進(jìn)行淘汰。 Redis一共提供了8種淘汰策略婚夫，默認(rèn)的策略為noeviction浸卦，當(dāng)內(nèi)存使用達(dá)到閾值的時(shí)候，

所有引起申請內(nèi)存的命令會報(bào)錯(cuò)案糙。

• volatile-lru限嫌，針對設(shè)置了過期時(shí)間的key，使用lru算法進(jìn)行淘汰时捌。
• allkeys-lru怒医，針對所有key使用lru算法進(jìn)行淘汰。
• volatile-lfu奢讨，針對設(shè)置了過期時(shí)間的key稚叹，使用lfu算法進(jìn)行淘汰。
• allkeys-lfu拿诸，針對所有key使用lfu算法進(jìn)行淘汰扒袖。
• volatile-random，從所有設(shè)置了過期時(shí)間的key中使用隨機(jī)淘汰的方式進(jìn)行淘汰亩码。
• allkeys-random季率，針對所有的key使用隨機(jī)淘汰機(jī)制進(jìn)行淘汰。
• volatile-ttl描沟，刪除生存時(shí)間最近的一個(gè)鍵飒泻。
• noeviction，不刪除鍵，值返回錯(cuò)誤。

前綴為volatile-和allkeys-的區(qū)別在于二者選擇要清除的鍵時(shí)的字典不同看幼，volatile-前綴的策略代表從redisDb中的expire字典中選擇鍵進(jìn)行清除；allkeys-開頭的策略代表從dict字典中選擇鍵進(jìn)行清除史辙。

內(nèi)存淘汰算法的具體工作原理是：

• 客戶端執(zhí)行一條新命令，導(dǎo)致數(shù)據(jù)庫需要增加數(shù)據(jù)（比如set key value）
• Redis會檢查內(nèi)存使用，如果內(nèi)存使用超過 maxmemory髓霞，就會按照置換策略刪除一些 key
• 新的命令執(zhí)行成功

了解并手寫LRU算法

LRU是Least Recently Used的縮寫，也就是表示最近很少使用畦戒，也可以理解成最久沒有使用方库。也就是說當(dāng)內(nèi)存不夠的時(shí)候，每次添加一條數(shù)據(jù)障斋，都需要拋棄一條最久時(shí)間沒有使用的舊數(shù)據(jù)纵潦。

標(biāo)準(zhǔn)的LRU算法為了降低查找和刪除元素的時(shí)間復(fù)雜度，一般采用Hash表和雙向鏈表結(jié)合的數(shù)據(jù)結(jié)構(gòu)垃环，hash表可以賦予鏈表快速查找到某個(gè)key是否存在鏈表中邀层，同時(shí)可以快速刪除、添加節(jié)點(diǎn)遂庄，如圖4-21所示寥院。

雙向鏈表的查找時(shí)間復(fù)雜度是O(n)，刪除和插入是O(1)涛目，借助HashMap結(jié)構(gòu)秸谢，可以使得查找的時(shí)間復(fù)雜度變成O(1)

Hash表用來查詢在鏈表中的數(shù)據(jù)位置，鏈表負(fù)責(zé)數(shù)據(jù)的插入霹肝，當(dāng)新數(shù)據(jù)插入到鏈表頭部時(shí)有兩種情況估蹄。

• 鏈表滿了，把鏈表尾部的數(shù)據(jù)丟棄掉沫换，新加入的緩存直接加入到鏈表頭中臭蚁。
• 當(dāng)鏈表中的某個(gè)緩存被命中時(shí)，直接把數(shù)據(jù)移到鏈表頭部讯赏，原本在頭節(jié)點(diǎn)的緩存就向鏈表尾部移動

這樣垮兑，經(jīng)過多次Cache操作之后，最近被命中的緩存漱挎，都會存在鏈表頭部的方向甥角，沒有命中的，都會在鏈表尾部方向识樱，當(dāng)需要替換內(nèi)容時(shí)嗤无，由于鏈表尾部是最少被命中的，我們只需要淘汰鏈表尾部的數(shù)據(jù)即可怜庸。

image-20210710205446429

<center>圖4-21</center>

下面我們通過一段代碼實(shí)現(xiàn)一個(gè)簡單的LRU算法当犯，加深大家對于LRU算法的理解。

public class LRUCache {

    private Node head;
    private Node tail;

    private final HashMap<String,Node> nodeHashMap;
    private int capacity;

    public LRUCache(int capacity){
        this.capacity=capacity;
        nodeHashMap=new HashMap<>();
        head=new Node();
        tail=new Node();
        head.next=tail;
        tail.prev=head;
    }
    private void removeNode(Node node){
        if(node==tail){
            tail=tail.prev;
            tail.next=null;
        }else if(node==head){
            head=head.next;
            head.prev=null;
        }else {
            node.prev.next=node.next;
            node.next.prev=node.prev;
        }
    }

    private void addNodeToHead(Node node){
        node.next=head.next;
        head.next.prev=node;
        node.prev=head;
        head.next=node;
    }
    private void addNodeToTail(Node node){
        node.prev=tail.prev;
        node.prev.next=node;
        node.next=tail;
        tail.prev=node;
    }
    //當(dāng)鏈表中的某個(gè)緩存被命中時(shí)割疾，直接把數(shù)據(jù)移到鏈表頭部嚎卫，原本在頭節(jié)點(diǎn)的緩存就向鏈表尾部移動
    public void moveNodeToHead(Node node){

        removeNode(node);
        addNodeToHead(node);
    }

    public String get(String key){
        Node node=nodeHashMap.get(key);
        if(node==null){
            return null;
        }
        //刷新當(dāng)前節(jié)點(diǎn)的位置
        moveNodeToHead(node);
        //返回value值
        return node.value;
    }
    public void put(String key,String value){
        Node node=nodeHashMap.get(key);
        if(node==null){ //不存在
            //如果當(dāng)前存儲的數(shù)據(jù)量達(dá)到了閾值，則需要淘汰掉訪問較少的數(shù)據(jù)
            if(nodeHashMap.size()>=capacity){
                removeNode(tail); //移除尾部節(jié)點(diǎn)
                nodeHashMap.remove(tail.key);
            }
            node=new Node(key,value);
            nodeHashMap.put(key,node);
            addNodeToTail(node);
        }else{
            node.value=value;
            //刷新當(dāng)前節(jié)點(diǎn)的位置
            moveNodeToHead(node);
        }
    }

    public static void main(String[] args) {
        LRUCache lruCache=new LRUCache(3);
        lruCache.put("1","1");
        lruCache.put("2","2");
        lruCache.put("3","3");
//        lruCache.get("3"); // 增加一個(gè)訪問次數(shù)之后，被清理的元素就會發(fā)生變化
        System.out.println(lruCache.nodeHashMap);
        lruCache.put("4","4");
        System.out.println(lruCache.nodeHashMap);
    }
}
class Node{
    //雙向鏈表中的節(jié)點(diǎn)類拓诸，存儲key是因?yàn)槲覀冊陔p向鏈表刪除表尾的值時(shí)侵佃，只是返回了一個(gè)節(jié)點(diǎn)，
    //所以這個(gè)節(jié)點(diǎn)要包括key值奠支，這樣我們的哈希表才可以刪除對應(yīng)key值的映射
    public String key;
    public String value;
    Node prev;
    Node next;

    public Node(){}

    public Node(String key, String value) {
        this.key = key;
        this.value = value;
    }
}

Redis中的LRU算法

實(shí)際上馋辈，Redis使用的LRU算法其實(shí)是一種不可靠的LRU算法，它實(shí)際淘汰的鍵并不一定是真正最少使用的數(shù)據(jù)倍谜，它的工作機(jī)制是：

• 隨機(jī)采集淘汰的key迈螟，每次隨機(jī)選出5個(gè)key
• 然后淘汰這5個(gè)key中最少使用的key

這5個(gè)key是默認(rèn)的個(gè)數(shù)，具體的數(shù)值可以在redis.conf中配置

maxmemory-samples 5

當(dāng)近似LRU算法取值越大的時(shí)候就會越接近真實(shí)的LRU算法尔崔，因?yàn)槿≈翟酱螳@取的數(shù)據(jù)越完整答毫，淘汰中的數(shù)據(jù)就更加接近最少使用的數(shù)據(jù)。這里其實(shí)涉及一個(gè)權(quán)衡問題季春，

如果需要在所有的數(shù)據(jù)中搜索最符合條件的數(shù)據(jù)洗搂，那么一定會增加系統(tǒng)的開銷，Redis是單線程的载弄，所以耗時(shí)的操作會謹(jǐn)慎一些蚕脏。

為了在一定成本內(nèi)實(shí)現(xiàn)相對的LRU，早期的Redis版本是基于采樣的LRU侦锯，也就是放棄了從所有數(shù)據(jù)中搜索解改為采樣空間搜索最優(yōu)解驼鞭。Redis3.0版本之后，Redis作者對于基于采樣的LRU進(jìn)行了一些優(yōu)化：

• Redis中維護(hù)一個(gè)大小為16的候選池尺碰，當(dāng)?shù)谝淮坞S機(jī)選取采用數(shù)據(jù)時(shí)挣棕，會把數(shù)據(jù)放入到候選池中，并且候選池中的數(shù)據(jù)會更具時(shí)間進(jìn)行排序亲桥。
• 當(dāng)?shù)诙我院筮x取數(shù)據(jù)時(shí)洛心，只有小于候選池內(nèi)最小時(shí)間的才會被放進(jìn)候選池。
• 當(dāng)候選池的數(shù)據(jù)滿了之后题篷，那么時(shí)間最大的key就會被擠出候選池词身。當(dāng)執(zhí)行淘汰時(shí)，直接從候選池中選取最近訪問時(shí)間小的key進(jìn)行淘汰番枚。

如圖4-22所示法严，首先從目標(biāo)字典中采集出maxmemory-samples個(gè)鍵，緩存在一個(gè)samples數(shù)組中葫笼，然后從samples數(shù)組中一個(gè)個(gè)取出來深啤，和回收池中以后的鍵進(jìn)行鍵的空閑時(shí)間，從而更新回收池路星。

在更新過程中溯街，首先利用遍歷找到的每個(gè)鍵的實(shí)際插入位置x，然后根據(jù)不同情況進(jìn)行處理。

• 回收池滿了呈昔，并且當(dāng)前插入的key的空閑時(shí)間最谢拥取（也就是回收池中的所有key都比當(dāng)前插入的key的空閑時(shí)間都要大），則不作任何操作堤尾。
• 回收池未滿肝劲，并且插入的位置x沒有鍵，則直接插入即可
• 回收池未滿哀峻，且插入的位置x原本已經(jīng)存在要淘汰的鍵涡相，則把第x個(gè)以后的元素都往后挪一個(gè)位置哲泊，然后再執(zhí)行插入操作剩蟀。
• 回收池滿了，將當(dāng)前第x個(gè)以前的元素往前挪一個(gè)位置（實(shí)際就是淘汰了）切威，然后執(zhí)行插入操作育特。

image-20210710203108453

<center>圖4-22</center>

這樣做的目的是能夠選出最真實(shí)的最少被訪問的key，能夠正確不常使用的key先朦。因?yàn)樵赗edis3.0之前是隨機(jī)選取樣本缰冤，這樣的方式很有可能不是真正意義上的最少訪問的key。

LRU算法有一個(gè)弊端喳魏，加入一個(gè)key值訪問頻率很低棉浸，但是最近一次被訪問到了，那LRU會認(rèn)為它是熱點(diǎn)數(shù)據(jù)刺彩，不會被淘汰迷郑。同樣，

經(jīng)常被訪問的數(shù)據(jù)创倔，最近一段時(shí)間沒有被訪問嗡害，這樣會導(dǎo)致這些數(shù)據(jù)被淘汰掉，導(dǎo)致誤判而淘汰掉熱點(diǎn)數(shù)據(jù)畦攘，于是在Redis 4.0中霸妹，新加了一種LFU算法。

LFU算法

LFU（Least Frequently Used）知押，表示最近最少使用叹螟，它和key的使用次數(shù)有關(guān)，其思想是：根據(jù)key最近被訪問的頻率進(jìn)行淘汰台盯，比較少訪問的key優(yōu)先淘汰首妖，反之則保留。

LRU的原理是使用計(jì)數(shù)器來對key進(jìn)行排序爷恳，每次key被訪問時(shí)有缆，計(jì)數(shù)器會增大，當(dāng)計(jì)數(shù)器越大，意味著當(dāng)前key的訪問越頻繁棚壁，也就是意味著它是熱點(diǎn)數(shù)據(jù)杯矩。 它很好的解決了LRU算法的缺陷：一個(gè)很久沒有被訪問的key，偶爾被訪問一次袖外，導(dǎo)致被誤認(rèn)為是熱點(diǎn)數(shù)據(jù)的問題史隆。

LFU的實(shí)現(xiàn)原理如圖4-23所示，LFU維護(hù)了兩個(gè)鏈表曼验，橫向組成的鏈表用來存儲訪問頻率泌射，每個(gè)訪問頻率的節(jié)點(diǎn)下存儲另外一個(gè)具有相同訪問頻率的緩存數(shù)據(jù)。具體的工作原理是：

• 當(dāng)添加元素時(shí)鬓照，找到相同訪問頻次的節(jié)點(diǎn)熔酷，然后添加到該節(jié)點(diǎn)的數(shù)據(jù)鏈表的頭部。如果該數(shù)據(jù)鏈表滿了豺裆，則移除鏈表尾部的節(jié)點(diǎn)
• 當(dāng)獲取元素或者修改元素是拒秘，都會增加對應(yīng)key的訪問頻次，并把當(dāng)前節(jié)點(diǎn)移動到下一個(gè)頻次節(jié)點(diǎn)臭猜。

添加元素時(shí)躺酒，訪問頻率默認(rèn)為1，隨著訪問次數(shù)的增加蔑歌，頻率不斷遞增羹应。而當(dāng)前被訪問的元素也會隨著頻率增加進(jìn)行移動。

image-20210710213258901

<center>圖4-23</center>

持久化機(jī)制的實(shí)現(xiàn)及原理

Redis的強(qiáng)勁性能很大程度上是由于它所有的數(shù)據(jù)都存儲在內(nèi)存中次屠，當(dāng)然如果redis重啟或者服務(wù)器故障導(dǎo)致redis重啟园匹，所有存儲在內(nèi)存中的數(shù)據(jù)就會丟失。但是在某些情況下帅矗，我們希望Redis在重啟后能夠保證數(shù)據(jù)不會丟失偎肃。

1. 將redis作為nosql數(shù)據(jù)庫使用。

2. 將Redis作為高效緩存服務(wù)器浑此，緩存被擊穿后對后端數(shù)據(jù)庫層面的瞬時(shí)壓力是特別大的累颂，所有緩存同時(shí)失效可能會導(dǎo)致雪崩。

這時(shí)我們希望Redis能將數(shù)據(jù)從內(nèi)存中以某種形式同步到硬盤上凛俱，使得重啟后可以根據(jù)硬盤中的記錄來恢復(fù)數(shù)據(jù)紊馏。

Redis支持兩種方式的持久化，一種是RDB方式蒲犬、另一種是AOF（append-only-file）方式朱监，兩種持久化方式可以單獨(dú)使用其中一種，也可以將這兩種方式結(jié)合使用原叮。

• RDB：根據(jù)指定的規(guī)則“定時(shí)”將內(nèi)存中的數(shù)據(jù)存儲在硬盤上赫编，
• AOF：每次執(zhí)行命令后將命令本身記錄下來巡蘸。

4.3.1 RDB模式

RDB的持久化方式是通過快照（snapshotting）完成的，它是Redis默認(rèn)的持久化方式擂送，配置如下悦荒。

# save 3600 1
# save 300 100
# save 60 10000

Redis允許用戶自定義快照條件，當(dāng)符合快照條件時(shí)嘹吨，Redis會自動執(zhí)行快照操作搬味。快照的條件可以由用戶在配置文件中配置蟀拷。配置格式如下

save <seconds> <changes>

第一個(gè)參數(shù)是時(shí)間窗口碰纬，第二個(gè)是鍵的個(gè)數(shù)，也就是說问芬，在第一個(gè)時(shí)間參數(shù)配置范圍內(nèi)被更改的鍵的個(gè)數(shù)大于后面的changes時(shí)悦析，即符合快照條件。當(dāng)觸發(fā)條件時(shí)愈诚，Redis會自動將內(nèi)存中的數(shù)據(jù)生成一份副本并存儲在磁盤上她按，這個(gè)過程稱之為“快照”牛隅，除了上述規(guī)則之外炕柔，還有以下幾種方式生成快照。

1. 根據(jù)配置規(guī)則進(jìn)行自動快照
2. 用戶執(zhí)行SAVE或者GBSAVE命令
3. 執(zhí)行FLUSHALL命令
4. 執(zhí)行復(fù)制(replication)時(shí)

根據(jù)配置規(guī)則進(jìn)行自動快照

• 修改redis.conf文件媒佣，表示5秒內(nèi)匕累，有一個(gè)key發(fā)生變化，就會生成rdb文件默伍。

  save 5 1                # 表示3600s以內(nèi)至少發(fā)生1個(gè)key變化（新增欢嘿、修改、刪除）也糊，則重寫rdb文件
  save 300 100
  save 60 10000

• 修改文件存儲路徑

  dir /data/program/redis/bin
  

• 其他參數(shù)配置說明

  參數(shù)	說明
  dir	rdb文件默認(rèn)在啟動目錄下（相對路徑） config get dir 獲取
  dbfilename	文件名稱
  rdbcompression	開啟壓縮可以節(jié)省存儲空間炼蹦，但是會消耗一些CPU的計(jì)算時(shí)間，默認(rèn)開啟
  rdbchecksum	使用CRC64算法來進(jìn)行數(shù)據(jù)校驗(yàn)狸剃，但是這樣做會增加大約10%的性能消耗掐隐，如果希望獲取到最大的性能提升，可以關(guān)閉此功能钞馁。

如果需要關(guān)閉RDB的持久化機(jī)制虑省，可以參考如下配置，開啟save僧凰，并注釋其他規(guī)則即可

save ""
#save 900 1
#save 300 10
#save 60 10000

用戶執(zhí)行SAVE或者GBSAVE命令

除了讓Redis自動進(jìn)行快照以外探颈，當(dāng)我們對服務(wù)進(jìn)行重啟或者服務(wù)器遷移我們需要人工去干預(yù)備份。redis提供了兩條命令來完成這個(gè)任務(wù)

1. save命令

   如圖4-24所示训措，當(dāng)執(zhí)行save命令時(shí)伪节，Redis同步做快照操作光羞，在快照執(zhí)行過程中會阻塞所有來自客戶端的請求。當(dāng)redis內(nèi)存中的數(shù)據(jù)較多時(shí)怀大，通過該命令將導(dǎo)致Redis較長時(shí)間的不響應(yīng)狞山。所以不建議在生產(chǎn)環(huán)境上使用這個(gè)命令，而是推薦使用bgsave命令

   image-20210712184050955

   <center>圖4-24</center>

2. bgsave命令

   如圖4-25所示叉寂，bgsave命令可以在后臺異步地進(jìn)行快照操作萍启，快照的同時(shí)服務(wù)器還可以繼續(xù)響應(yīng)來自客戶端的請求。執(zhí)行BGSAVE后屏鳍，Redis會立即返回ok表示開始執(zhí)行快照操作勘纯，在redis-cli終端，通過下面這個(gè)命令可以獲取最近一次成功執(zhí)行快照的時(shí)間（以 UNIX 時(shí)間戳格式表示）钓瞭。

   LASTSAVE
   

1：redis使用fork函數(shù)復(fù)制一份當(dāng)前進(jìn)程的副本(子進(jìn)程)

2：父進(jìn)程繼續(xù)接收并處理客戶端發(fā)來的命令驳遵，而子進(jìn)程開始將內(nèi)存中的數(shù)據(jù)寫入硬盤中的臨時(shí)文件

3：當(dāng)子進(jìn)程寫入完所有數(shù)據(jù)后會用該臨時(shí)文件替換舊的RDB文件，至此山涡，一次快照操作完成堤结。

注意：redis在進(jìn)行快照的過程中不會修改RDB文件，只有快照結(jié)束后才會將舊的文件替換成新的鸭丛，也就是說任何時(shí)候RDB文件都是完整的竞穷。 這就使得我們可以通過定時(shí)備份RDB文件來實(shí)現(xiàn)redis數(shù)據(jù)庫的備份， RDB文件是經(jīng)過壓縮的二進(jìn)制文件鳞溉，占用的空間會小于內(nèi)存中的數(shù)據(jù)瘾带，更加利于傳輸。

bgsave是異步執(zhí)行快照的熟菲，bgsave寫入的數(shù)據(jù)就是for進(jìn)程時(shí)redis的數(shù)據(jù)狀態(tài)看政，一旦完成fork，后續(xù)執(zhí)行的新的客戶端命令對數(shù)據(jù)產(chǎn)生的變更都不會反應(yīng)到本次快照

Redis啟動后會讀取RDB快照文件抄罕，并將數(shù)據(jù)從硬盤載入到內(nèi)存允蚣。根據(jù)數(shù)據(jù)量大小以及服務(wù)器性能不同，這個(gè)載入的時(shí)間也不同呆贿。

image-20210712183559812

<center>圖4-25</center>

執(zhí)行FLUSHALL命令

該命令在前面講過嚷兔，會清除redis在內(nèi)存中的所有數(shù)據(jù)。執(zhí)行該命令后榨崩，只要redis中配置的快照規(guī)則不為空谴垫，也就是save 的規(guī)則存在。redis就會執(zhí)行一次快照操作母蛛。不管規(guī)則是什么樣的都會執(zhí)行翩剪。如果沒有定義快照規(guī)則，就不會執(zhí)行快照操作彩郊。

執(zhí)行復(fù)制(replication)時(shí)

該操作主要是在主從模式下前弯，redis會在復(fù)制初始化時(shí)進(jìn)行自動快照蚪缀。這個(gè)會在后面講到；

這里只需要了解當(dāng)執(zhí)行復(fù)制操作時(shí)恕出，即時(shí)沒有定義自動快照規(guī)則询枚，并且沒有手動執(zhí)行過快照操作，它仍然會生成RDB快照文件浙巫。

RDB數(shù)據(jù)恢復(fù)演示

• 準(zhǔn)備初始數(shù)據(jù)

  redis> set k1 1
  redis> set k2 2
  redis> set k3 3
  redis> set k4 4
  redis> set k5 5

• 通過shutdown命令關(guān)閉觸發(fā)save

  redis> shutdown
  

• 備份dump.rdb文件(用來后續(xù)恢復(fù))

  cp dump.rdb dump.rdb.bak
  

• 接著再啟動redis-server(systemctl restart redis_6379)金蜀，通過keys命令查看，發(fā)現(xiàn)數(shù)據(jù)還在

  keys *
  

模擬數(shù)據(jù)丟失

• 執(zhí)行flushall

  redis> flushall
  

• shutdown(重新生成沒有數(shù)據(jù)的快照的畴，用來模擬后續(xù)的數(shù)據(jù)恢復(fù))

  redis> shutdown
  

• 再次啟動redis, 通過keys 命令查看渊抄，此時(shí)rdb中沒有任何數(shù)據(jù)。

• 恢復(fù)之前備份的rdb文件（之前保存了數(shù)據(jù)的rdb快照）

  mv dump.rdb.bak dump.rdb
  

• 再次重啟redis丧裁，可以看到之前快照保存的數(shù)據(jù)

  keys *
  

RDB文件的優(yōu)勢和劣勢

一护桦、優(yōu)勢

1.RDB是一個(gè)非常緊湊(compact)的文件，它保存了redis 在某個(gè)時(shí)間點(diǎn)上的數(shù)據(jù)集煎娇，這種文件非常適合用于進(jìn)行備份和災(zāi)難恢復(fù)二庵。

2.生成RDB文件的時(shí)候，redis主進(jìn)程會fork()一個(gè)子進(jìn)程來處理所有保存工作缓呛，主進(jìn)程不需要進(jìn)行任何磁盤IO操作催享。

3.RDB 在恢復(fù)大數(shù)據(jù)集時(shí)的速度比AOF的恢復(fù)速度要快。

二强经、劣勢

• 1睡陪、RDB方式數(shù)據(jù)沒辦法做到實(shí)時(shí)持久化/秒級持久化寺渗。因?yàn)閎gsave每次運(yùn)行都要執(zhí)行fork操作創(chuàng)建子進(jìn)程匿情，頻繁執(zhí)行成本過高

• 2、在一定間隔時(shí)間做一次備份信殊，所以如果redis意外down掉的話炬称，就會丟失最后一次快照之后的所有修改（數(shù)據(jù)有丟失）。

如果數(shù)據(jù)相對來說比較重要涡拘，希望將損失降到最小玲躯，則可以使用AOF方式進(jìn)行持久化。

4.3.2 AOF模式

AOF(Append Only File)：Redis 默認(rèn)不開啟鳄乏。AOF采用日志的形式來記錄每個(gè)寫操作跷车，并追加到文件中。開啟后橱野，執(zhí)行更改Redis數(shù)據(jù)的命令時(shí)朽缴，就會把命令寫入到AOF文件中。

Redis 重啟時(shí)會根據(jù)日志文件的內(nèi)容把寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作水援。

AOF配置開關(guān)

# 開關(guān)
appendonly no  /yes
# 文件名
appendfilename "appendonly.aof"

通過修改redis.conf重啟redis之后：systemctl restart redis_6379密强。

再次運(yùn)行redis的相關(guān)操作命令茅郎，會發(fā)現(xiàn)在指定的dir目錄下生成appendonly.aof文件，通過vim查看該文件內(nèi)容如下

*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$3
mic
*3
$3
set
$4
name
$3
123

AOF配置相關(guān)問題解答

問題1：數(shù)據(jù)都是實(shí)時(shí)持久化到磁盤嗎或渤？

雖然每次執(zhí)行更改Redis數(shù)據(jù)庫內(nèi)容的操作時(shí)系冗，AOF都會將命令記錄在AOF文件中，但是事實(shí)上薪鹦，由于操作系統(tǒng)的緩存機(jī)制掌敬，數(shù)據(jù)并沒有真正地寫入硬盤，而是進(jìn)入了系統(tǒng)的硬盤緩存池磁。在默認(rèn)情況下系統(tǒng)每30秒會執(zhí)行一次同步操作涝开。以便將硬盤緩存中的內(nèi)容真正地寫入硬盤。

在這30秒的過程中如果系統(tǒng)異常退出則會導(dǎo)致硬盤緩存中的數(shù)據(jù)丟失框仔。一般來說能夠啟用AOF的前提是業(yè)務(wù)場景不能容忍這樣的數(shù)據(jù)損失舀武，這個(gè)時(shí)候就需要Redis在寫入AOF文件后主動要求系統(tǒng)將緩存內(nèi)容同步到硬盤中。在redis.conf中通過如下配置來設(shè)置同步機(jī)制离斩。

問題2：文件越來越大左腔，怎么辦？

由于AOF持久化是Redis不斷將寫命令記錄到 AOF 文件中捅儒，隨著Redis不斷的運(yùn)行液样，AOF 的文件會越來越大，文件越大巧还，占用服務(wù)器內(nèi)存越大以及 AOF 恢復(fù)要求時(shí)間越長鞭莽。

例如set gupao 666，執(zhí)行1000次麸祷，結(jié)果都是gupao=666澎怒。

為了解決這個(gè)問題，Redis新增了重寫機(jī)制摇锋，當(dāng)AOF文件的大小超過所設(shè)定的閾值時(shí)丹拯，Redis就會啟動AOF文件的內(nèi)容壓縮站超，只保留可以恢復(fù)數(shù)據(jù)的最小指令集。

可以使用命令下面這個(gè)命令主動觸發(fā)重寫

redis> bgrewriteaof

AOF 文件重寫并不是對原文件進(jìn)行重新整理乖酬，而是直接讀取服務(wù)器現(xiàn)有的鍵值對死相，然后用一條命令去代替之前記錄這個(gè)鍵值對的多條命令，生成一個(gè)新的文件后去替換原來的 AOF 文件咬像。

重寫觸發(fā)機(jī)制如下

在啟動時(shí)倒彰，Redis會逐個(gè)執(zhí)行AOF文件中的命令來將硬盤中的數(shù)據(jù)載入到內(nèi)存中审洞，載入的速度相對于RDB會慢一些

問題：重寫過程中，AOF文件被更改了怎么辦待讳？

Redis 可以在 AOF 文件體積變得過大時(shí)芒澜，自動地在后臺對 AOF 進(jìn)行重寫： 重寫后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。

重寫的流程是這樣创淡，

• 主進(jìn)程會fork一個(gè)子進(jìn)程出來進(jìn)行AOF重寫痴晦，這個(gè)重寫過程并不是基于原有的aof文件來做的，而是有點(diǎn)類似于快照的方式琳彩，全量遍歷內(nèi)存中的數(shù)據(jù)誊酌，然后逐個(gè)序列到aof文件中。
• 在fork子進(jìn)程這個(gè)過程中露乏，服務(wù)端仍然可以對外提供服務(wù)碧浊，那這個(gè)時(shí)候重寫的aof文件的數(shù)據(jù)和redis內(nèi)存數(shù)據(jù)不一致了怎么辦？不用擔(dān)心施无，這個(gè)過程中辉词，主進(jìn)程的數(shù)據(jù)更新操作，會緩存到aof_rewrite_buf中猾骡，也就是單獨(dú)開辟一塊緩存來存儲重寫期間收到的命令，當(dāng)子進(jìn)程重寫完以后再把緩存中的數(shù)據(jù)追加到新的aof文件敷搪。
• 當(dāng)所有的數(shù)據(jù)全部追加到新的aof文件中后兴想，把新的aof文件重命名正式的文件名字，此后所有的操作都會被寫入新的aof文件赡勘。
• 如果在rewrite過程中出現(xiàn)故障嫂便，不會影響原來aof文件的正常工作，只有當(dāng)rewrite完成后才會切換文件闸与。因此這個(gè)rewrite過程是比較可靠的毙替。

img

<center>圖4-26</center>

Redis允許同時(shí)開啟AOF和RDB岸售，既保證了數(shù)據(jù)安全又使得進(jìn)行備份等操作十分容易。如果同時(shí)開啟后厂画，Redis重啟會使用AOF文件來恢復(fù)數(shù)據(jù)凸丸，因?yàn)锳OF方式的持久化可能丟失的數(shù)據(jù)更少。

AOF的優(yōu)劣勢

優(yōu)點(diǎn)：

1袱院、AOF 持久化的方法提供了多種的同步頻率屎慢，即使使用默認(rèn)的同步頻率每秒同步一次，Redis 最多也就丟失 1 秒的數(shù)據(jù)而已忽洛。

缺點(diǎn)：

1腻惠、對于具有相同數(shù)據(jù)的的Redis，AOF 文件通常會比 RDB 文件體積更大（RDB存的是數(shù)據(jù)快照）欲虚。

2集灌、雖然 AOF 提供了多種同步的頻率，默認(rèn)情況下复哆，每秒同步一次的頻率也具有較高的性能绝页。在高并發(fā)的情況下，RDB 比 AOF 具好更好的性能保證寂恬。