Redis中的多路複用模型

Redis6用到了多線程？那多線程應用在哪些地方，引入多線程後，又改如何保證線程安全性呢？

同時，如何在性能和線程安全性方面做好平衡？

關于Redis的單線程模型

在Redis6.0之前，我們一直說Redis是單線程，是以并不會存線上程安全問題，而這個單線程，實際上就是在做資料IO進行中，是用的主線程來串行執行，如圖4-7所示。

Redis基于Reactor模式設計開發了自己的一套高效事件處理模型，這個事件處理模型對應的就是Redis中的檔案事件處理器，這個檔案事件處理器是單線程運作的，這也是為什麼我們一直強調Redis是線程安全的。

既然Redis是基于Reactor模型實作，那它必然用了I/O多路複用機制來監聽多個用戶端連接配接，然後把感興趣的事件（READ/ACCEPT/CLOSE/WRITE）注冊到多路複用器中。

檔案事件處理器中使用I/O多路複用模型同時監聽多個用戶端連接配接，并且根據目前連接配接執行的任務類型關聯不同的事件處理器（連接配接應答處理器、指令請求處理器、指令回複處理器）來處理這些事件。

這樣設計的好處：

檔案事件處理器實作了高性能的網絡IO通信模型
通過單線程的方式執行指令，避免同步機制的性能開銷、避免過多的上下文切換、整體實作比較簡單，不需要考慮多線程場景中的各種資料結構的線程安全問題。

圖4-7

其實嚴格意義上來說，在Redis4.x版本就支援了多線程，隻是，負責用戶端請求的IO處理使用的是單線程。但是針對那些非常耗時的指令，Redis4.x提供了異步化的指令來處理，避免因為IO時間過長影響到用戶端請求IO處理的線程。比如在 Redis v4.0 之後增加了一些的非阻塞指令如

UNLINK

（del指令的異步版本）、

FLUSHALL ASYNC

、

FLUSHDB ASYNC

。

Redis6.0之後的多線程？

在Redis6.0中引入了多線程，可能很多同學會誤以為redis原本的單線程資料IO變成了多線程IO，那作者不就是在打自己的臉嗎？

對于Redis來說，CPU通常不是瓶頸，因為大多數請求不是屬于CPU密集型，而是I/O密集型。而在Redis中除了資料的持久化方案之外，它是完全的純記憶體操作，是以執行速度是非常快的，是以資料的IO并不是Redis的性能瓶頸，Redis真正的性能瓶頸是在網絡I/O，也就是用戶端和服務端之間的網絡傳輸延遲，是以Redis選擇了單線程的IO多路複用來實作它的核心網絡模型。

前面我們說過，單線程設計對于Redis來說有很多好處。

避免過多的上上下文切換開銷
避免同步機制的開銷，涉及到資料同步和事務操作時，避免多線程影響是以必然需要加同步機制保證線程安全性。但是加鎖同時也會影響到程式的執行性能。
維護簡單，引入多線程之後，不管是對資料結構的設計，還是在程式代碼的維護上，都會變得很複雜。

是以既然Redis的資料I/O不是瓶頸，同時單線程又有這麼多好處，那Redis自然就采用單線程了。既然是這樣，那麼Redis 6.0引入多線程，一定不是優化資料IO性能，那麼我們先來分析一下Redis性能瓶頸主要展現在哪些方面，無非就是三個方面。

網絡IO
CPU核心數
記憶體

由于CPU核心數并不是redis的瓶頸，是以影響Redis性能的因素隻有網絡IO和記憶體，而記憶體屬于硬體範疇，比如采用容量更大、吞吐量更高的記憶體進行優化就行，是以也不是屬于Redis可優化的空間，是以最終我們發現Redis的性能瓶頸還是在網絡IO上。

而在Redis6.0之前，使用的是單線程Reactor模型，單線程模型是指對于用戶端的請求，主線程需要負責對這個請求的完整IO過程進行處理，如圖4-8所示，從socket中讀取資料和往socket中寫資料都是比較耗時的網絡IO操作，解析請求和記憶體互動耗時可能遠小于這個網絡IO操作。

圖4-8

按照前面我們對多Reactor多線程的了解，那我們能不能改成主從多Reactor多線程模型呢？主Reactor負責接收用戶端連接配接，然後分發給多個Reactor進行網絡IO操作。很顯然，這樣做就會導緻Redis程式設計了一個多線程模型，這對Redis的影響較大，因為多線程帶來的線程安全問題和底層複雜的資料結構的操作都非常棘手，是以Redis 6.0并沒有這麼做。

Redis 6.0中将處理過程中最耗時的Socket讀取、請求解析、單獨用一個線程來處理，剩下的指令執行操作仍然由單線程來完成和記憶體的資料互動，這樣一來，網絡IO操作就變成了多線程了，但是核心部分仍然是線程安全的，如圖4-9所示。

圖4-9

為什麼說Redis6.0是一個特殊的多線程，原因就在這裡，Redis主要針對網絡IO這塊引入了多線程的方式來提升了網絡IO性能，但是真正執行指令的操作仍然是由主線程來完成。是以，總的來說，我們仍然可以說Redis是單線程模型。

Redis 6.0如何開啟多線程

Redis 6.0預設多線程是禁止的，也就是仍然隻是使用主線程來完成網絡IO，如果需要開啟，則修改redis.conf配置檔案中的如下屬性

# 預設是關閉，設定為yes打開
io-threads-do-reads no
#預設線程數量是4，官方建議是4核機器上設定為2~3個，8核機器上設定6個
io-threads 4

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

圖4-20是美團技術團隊使用阿裡雲伺服器壓測GET/SET指令在4個線程IO時性能上的對比結果，可以明顯的看到，Redis 在使用多線程模式之後性能大幅提升，達到了一倍。

Redis Server 阿裡雲 Ubuntu 18.04 ， 8CPU 2.5GHZ，8G記憶體，主機型号： ecs.ic5.2xlarge
Redis Benchmark client: 阿裡雲 Unbuntu 18.04 , 8CPU 2.5GHZ，8G記憶體，主機型号：ecs.ic5.2xlarge

圖4-20

記憶體回收政策

很多同學了解了Redis的好處之後，于是把任何資料都往Redis中放，如果使用不合理很容易導緻資料超過Redis的記憶體，這種情況會出現什麼問題呢？

Redis中有很多無效的緩存，這些緩存資料會降低資料IO的性能，因為不同的資料類型時間複雜度算法不同，資料越多可能會造成性能下降
随着系統的運作，redis的資料越來越多，會導緻實體記憶體不足。通過使用虛拟記憶體（VM），将很少通路的資料交換到磁盤上，騰出記憶體空間的方法來解決實體記憶體不足的情況。雖然能夠解決實體記憶體不足導緻的問題，但是由于這部分資料是存儲在磁盤上，如果在高并發場景中，頻繁通路虛拟記憶體空間會嚴重降低系統性能。

是以遇到這類問題的時候，我們一般有幾種方法。

對每個存儲到redis中的key設定過期時間，這個根據實際業務場景來決定。否則，再大的記憶體都會雖則系統運作被消耗完。
增加記憶體
使用記憶體淘汰政策。

設定Redis能夠使用的最大記憶體

在實際生産環境中，伺服器不僅僅隻有Redis，為了避免Redis記憶體使用過多對其他程式造成影響，我們一般會設定最大記憶體。

Redis預設的最大記憶體

maxmemory=0

，表示不限制Redis記憶體的使用。我們可以修改

redis.conf

檔案，設定Redis最大使用的記憶體。

# 機關為byte
maxmemory <bytes>  2147483648（2G）

如何檢視目前Redis最大記憶體設定呢，進入到Redis-Cli控制台，輸入下面這個指令。

config get maxmemory

當Redis中存儲的記憶體超過maxmemory時，會怎麼樣呢？下面我們做一個實驗

在redis-cli控制台輸入下面這個指令，把最大記憶體設定為1個位元組。
```
config set maxmemory 1
           
```
通過下面的指令存儲一個string類型的資料
```
set name mic
           
```
此時，控制台會得到下面這個錯誤資訊

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

使用記憶體淘汰政策釋放記憶體

設定了maxmemory的選項，redis記憶體使用達到上限。可以通過設定LRU算法來删除部分key，釋放空間。預設是按照過期時間的，如果set時候沒有加上過期時間就會導緻資料寫滿maxmemory。

Redis中提供了一種記憶體淘汰政策，當記憶體不足時，Redis會根據相應的淘汰規則對key資料進行淘汰。 Redis一共提供了8種淘汰政策，預設的政策為noeviction，當記憶體使用達到門檻值的時候，

所有引起申請記憶體的指令會報錯。

volatile-lru，針對設定了過期時間的key，使用lru算法進行淘汰。
allkeys-lru，針對所有key使用lru算法進行淘汰。
volatile-lfu，針對設定了過期時間的key，使用lfu算法進行淘汰。
allkeys-lfu，針對所有key使用lfu算法進行淘汰。
volatile-random，從所有設定了過期時間的key中使用随機淘汰的方式進行淘汰。
allkeys-random，針對所有的key使用随機淘汰機制進行淘汰。
volatile-ttl，删除生存時間最近的一個鍵。
noeviction，不删除鍵，值傳回錯誤。

字首為volatile-和allkeys-的差別在于二者選擇要清除的鍵時的字典不同，volatile-字首的政策代表從redisDb中的expire字典中選擇鍵進行清除；allkeys-開頭的政策代表從dict字典中選擇鍵進行清除。

記憶體淘汰算法的具體工作原理是：

用戶端執行一條新指令，導緻資料庫需要增加資料（比如set key value）
Redis會檢查記憶體使用，如果記憶體使用超過 maxmemory，就會按照置換政策删除一些 key
新的指令執行成功

了解并手寫LRU算法

LRU是Least Recently Used的縮寫，也就是表示最近很少使用，也可以了解成最久沒有使用。也就是說當記憶體不夠的時候，每次添加一條資料，都需要抛棄一條最久時間沒有使用的舊資料。

标準的LRU算法為了降低查找和删除元素的時間複雜度，一般采用Hash表和雙向連結清單結合的資料結構，hash表可以賦予連結清單快速查找到某個key是否存在連結清單中，同時可以快速删除、添加節點，如圖4-21所示。

雙向連結清單的查找時間複雜度是O(n)，删除和插入是O(1)，借助HashMap結構，可以使得查找的時間複雜度變成O(1)

Hash表用來查詢在連結清單中的資料位置，連結清單負責資料的插入，當新資料插入到連結清單頭部時有兩種情況。

連結清單滿了，把連結清單尾部的資料丢棄掉，新加入的緩存直接加入到連結清單頭中。
當連結清單中的某個緩存被命中時，直接把資料移到連結清單頭部，原本在頭節點的緩存就向連結清單尾部移動

這樣，經過多次Cache操作之後，最近被命中的緩存，都會存在連結清單頭部的方向，沒有命中的，都會在連結清單尾部方向，當需要替換内容時，由于連結清單尾部是最少被命中的，我們隻需要淘汰連結清單尾部的資料即可。

圖4-21

下面我們通過一段代碼實作一個簡單的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;
    }
    //當連結清單中的某個緩存被命中時，直接把資料移到連結清單頭部，原本在頭節點的緩存就向連結清單尾部移動
    public void moveNodeToHead(Node node){

        removeNode(node);
        addNodeToHead(node);
    }

    public String get(String key){
        Node node=nodeHashMap.get(key);
        if(node==null){
            return null;
        }
        //重新整理目前節點的位置
        moveNodeToHead(node);
        //傳回value值
        return node.value;
    }
    public void put(String key,String value){
        Node node=nodeHashMap.get(key);
        if(node==null){ //不存在
            //如果目前存儲的資料量達到了門檻值，則需要淘汰掉通路較少的資料
            if(nodeHashMap.size()>=capacity){
                removeNode(tail); //移除尾部節點
                nodeHashMap.remove(tail.key);
            }
            node=new Node(key,value);
            nodeHashMap.put(key,node);
            addNodeToTail(node);
        }else{
            node.value=value;
            //重新整理目前節點的位置
            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"); // 增加一個通路次數之後，被清理的元素就會發生變化
        System.out.println(lruCache.nodeHashMap);
        lruCache.put("4","4");
        System.out.println(lruCache.nodeHashMap);
    }
}
class Node{
    //雙向連結清單中的節點類，存儲key是因為我們在雙向連結清單删除表尾的值時，隻是傳回了一個節點，
    //是以這個節點要包括key值，這樣我們的哈希表才可以删除對應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算法

實際上，Redis使用的LRU算法其實是一種不可靠的LRU算法，它實際淘汰的鍵并不一定是真正最少使用的資料，它的工作機制是：

随機采集淘汰的key，每次随機選出5個key
然後淘汰這5個key中最少使用的key

這5個key是預設的個數，具體的數值可以在redis.conf中配置

maxmemory-samples 5

當近似LRU算法取值越大的時候就會越接近真實的LRU算法，因為取值越大擷取的資料越完整，淘汰中的資料就更加接近最少使用的資料。這裡其實涉及一個權衡問題，

如果需要在所有的資料中搜尋最符合條件的資料，那麼一定會增加系統的開銷，Redis是單線程的，是以耗時的操作會謹慎一些。

為了在一定成本内實作相對的LRU，早期的Redis版本是基于采樣的LRU，也就是放棄了從所有資料中搜尋解改為采樣空間搜尋最優解。Redis3.0版本之後，Redis作者對于基于采樣的LRU進行了一些優化：

Redis中維護一個大小為16的候選池，當第一次随機選取采用資料時，會把資料放入到候選池中，并且候選池中的資料會更具時間進行排序。
當第二次以後選取資料時，隻有小于候選池内最小時間的才會被放進候選池。
當候選池的資料滿了之後，那麼時間最大的key就會被擠出候選池。當執行淘汰時，直接從候選池中選取最近通路時間小的key進行淘汰。

如圖4-22所示，首先從目标字典中采集出maxmemory-samples個鍵，緩存在一個samples數組中，然後從samples數組中一個個取出來，和回收池中以後的鍵進行鍵的空閑時間，進而更新回收池。

在更新過程中，首先利用周遊找到的每個鍵的實際插入位置x，然後根據不同情況進行處理。

回收池滿了，并且目前插入的key的空閑時間最小（也就是回收池中的所有key都比目前插入的key的空閑時間都要大），則不作任何操作。
回收池未滿，并且插入的位置x沒有鍵，則直接插入即可
回收池未滿，且插入的位置x原本已經存在要淘汰的鍵，則把第x個以後的元素都往後挪一個位置，然後再執行插入操作。
回收池滿了，将目前第x個以前的元素往前挪一個位置（實際就是淘汰了），然後執行插入操作。

圖4-22

這樣做的目的是能夠選出最真實的最少被通路的key，能夠正确不常使用的key。因為在Redis3.0之前是随機選取樣本，這樣的方式很有可能不是真正意義上的最少通路的key。

LRU算法有一個弊端，加入一個key值通路頻率很低，但是最近一次被通路到了，那LRU會認為它是熱點資料，不會被淘汰。同樣，

經常被通路的資料，最近一段時間沒有被通路，這樣會導緻這些資料被淘汰掉，導緻誤判而淘汰掉熱點資料，于是在Redis 4.0中，新加了一種LFU算法。

LFU算法

LFU（Least Frequently Used），表示最近最少使用，它和key的使用次數有關，其思想是：根據key最近被通路的頻率進行淘汰，比較少通路的key優先淘汰，反之則保留。

LRU的原理是使用計數器來對key進行排序，每次key被通路時，計數器會增大，當計數器越大，意味着目前key的通路越頻繁，也就是意味着它是熱點資料。它很好的解決了LRU算法的缺陷：一個很久沒有被通路的key，偶爾被通路一次，導緻被誤認為是熱點資料的問題。

LFU的實作原理如圖4-23所示，LFU維護了兩個連結清單，橫向組成的連結清單用來存儲通路頻率，每個通路頻率的節點下存儲另外一個具有相同通路頻率的緩存資料。具體的工作原理是：

當添加元素時，找到相同通路頻次的節點，然後添加到該節點的資料連結清單的頭部。如果該資料連結清單滿了，則移除連結清單尾部的節點
當擷取元素或者修改元素是，都會增加對應key的通路頻次，并把目前節點移動到下一個頻次節點。

添加元素時，通路頻率預設為1，随着通路次數的增加，頻率不斷遞增。而目前被通路的元素也會随着頻率增加進行移動。

圖4-23

持久化機制的實作及原理

Redis的強勁性能很大程度上是由于它所有的資料都存儲在記憶體中，當然如果redis重新開機或者伺服器故障導緻redis重新開機，所有存儲在記憶體中的資料就會丢失。但是在某些情況下，我們希望Redis在重新開機後能夠保證資料不會丢失。

将redis作為nosql資料庫使用。
将Redis作為高效緩存伺服器，緩存被擊穿後對後端資料庫層面的瞬時壓力是特别大的，所有緩存同時失效可能會導緻雪崩。

這時我們希望Redis能将資料從記憶體中以某種形式同步到硬碟上，使得重新開機後可以根據硬碟中的記錄來恢複資料。

Redis支援兩種方式的持久化，一種是RDB方式、另一種是AOF（append-only-file）方式，兩種持久化方式可以單獨使用其中一種，也可以将這兩種方式結合使用。

RDB：根據指定的規則“定時”将記憶體中的資料存儲在硬碟上，
AOF：每次執行指令後将指令本身記錄下來。

4.3.1 RDB模式

RDB的持久化方式是通過快照（snapshotting）完成的，它是Redis預設的持久化方式，配置如下。

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

Redis允許使用者自定義快照條件，當符合快照條件時，Redis會自動執行快照操作。快照的條件可以由使用者在配置檔案中配置。配置格式如下

save <seconds> <changes>

第一個參數是時間視窗，第二個是鍵的個數，也就是說，在第一個時間參數配置範圍内被更改的鍵的個數大于後面的changes時，即符合快照條件。當觸發條件時，Redis會自動将記憶體中的資料生成一份副本并存儲在磁盤上，這個過程稱之為“快照”，除了上述規則之外，還有以下幾種方式生成快照。

根據配置規則進行自動快照
使用者執行SAVE或者GBSAVE指令
執行FLUSHALL指令
執行複制(replication)時

修改redis.conf檔案，表示5秒内，有一個key發生變化，就會生成rdb檔案。

save 5 1                # 表示3600s以内至少發生1個key變化（新增、修改、删除），則重寫rdb檔案
  save 300 100
  save 60 10000

修改檔案存儲路徑
```
dir /data/program/redis/bin
           
```

其他參數配置說明

參數	說明
dir	rdb檔案預設在啟動目錄下（相對路徑） `config get dir` 擷取
dbfilename	檔案名稱
rdbcompression	開啟壓縮可以節省存儲空間，但是會消耗一些CPU的計算時間，預設開啟
rdbchecksum	使用CRC64算法來進行資料校驗，但是這樣做會增加大約10%的性能消耗，如果希望擷取到最大的性能提升，可以關閉此功能。

如果需要關閉RDB的持久化機制，可以參考如下配置，開啟

save

，并注釋其他規則即可

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

除了讓Redis自動進行快照以外，當我們對服務進行重新開機或者伺服器遷移我們需要人工去幹預備份。redis提供了兩條指令來完成這個任務

save指令

如圖4-24所示，當執行save指令時，Redis同步做快照操作，在快照執行過程中會阻塞所有來自用戶端的請求。當redis記憶體中的資料較多時，通過該指令将導緻Redis較長時間的不響應。是以不建議在生産環境上使用這個指令，而是推薦使用bgsave指令

1萬字長文詳解Redis6中記憶體淘汰算法/持久化機制/多線程模型
圖4-24
bgsave指令

如圖4-25所示，bgsave指令可以在背景異步地進行快照操作，快照的同時伺服器還可以繼續響應來自用戶端的請求。執行BGSAVE後，Redis會立即傳回ok表示開始執行快照操作，在redis-cli終端，通過下面這個指令可以擷取最近一次成功執行快照的時間（以 UNIX 時間戳格式表示）。
```
LASTSAVE
           
```

1：redis使用fork函數複制一份目前程序的副本(子程序)

2：父程序繼續接收并處理用戶端發來的指令，而子程序開始将記憶體中的資料寫入硬碟中的臨時檔案

3：當子程序寫入完所有資料後會用該臨時檔案替換舊的RDB檔案，至此，一次快照操作完成。

注意：redis在進行快照的過程中不會修改RDB檔案，隻有快照結束後才會将舊的檔案替換成新的，也就是說任何時候RDB檔案都是完整的。這就使得我們可以通過定時備份RDB檔案來實作redis資料庫的備份， RDB檔案是經過壓縮的二進制檔案，占用的空間會小于記憶體中的資料，更加利于傳輸。

bgsave是異步執行快照的，bgsave寫入的資料就是for程序時redis的資料狀态，一旦完成fork，後續執行的新的用戶端指令對資料産生的變更都不會反應到本次快照

Redis啟動後會讀取RDB快照檔案，并将資料從硬碟載入到記憶體。根據資料量大小以及伺服器性能不同，這個載入的時間也不同。

圖4-25

該指令在前面講過，會清除redis在記憶體中的所有資料。執行該指令後，隻要redis中配置的快照規則不為空，也就是save 的規則存在。redis就會執行一次快照操作。不管規則是什麼樣的都會執行。如果沒有定義快照規則，就不會執行快照操作。

該操作主要是在主從模式下，redis會在複制初始化時進行自動快照。這個會在後面講到；

這裡隻需要了解當執行複制操作時，即時沒有定義自動快照規則，并且沒有手動執行過快照操作，它仍然會生成RDB快照檔案。

RDB資料恢複示範

準備初始資料

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

通過shutdown指令關閉觸發save
```
redis> shutdown
           
```
備份dump.rdb檔案(用來後續恢複)
```
cp dump.rdb dump.rdb.bak
           
```
接着再啟動redis-server(systemctl restart redis_6379)，通過keys指令檢視，發現資料還在
```
keys *
           
```

模拟資料丢失

執行flushall
```
redis> flushall
           
```
shutdown(重新生成沒有資料的快照，用來模拟後續的資料恢複)
```
redis> shutdown
           
```
再次啟動redis, 通過keys 指令檢視，此時rdb中沒有任何資料。
恢複之前備份的rdb檔案（之前儲存了資料的rdb快照）
```
mv dump.rdb.bak dump.rdb
           
```
再次重新開機redis，可以看到之前快照儲存的資料
```
keys *
           
```

RDB檔案的優勢和劣勢

一、優勢

　　1.RDB是一個非常緊湊(compact)的檔案，它儲存了redis 在某個時間點上的資料集，這種檔案非常适合用于進行備份和災難恢複。

　　2.生成RDB檔案的時候，redis主程序會fork()一個子程序來處理所有儲存工作，主程序不需要進行任何磁盤IO操作。

　　3.RDB 在恢複大資料集時的速度比AOF的恢複速度要快。

二、劣勢

1、RDB方式資料沒辦法做到實時持久化/秒級持久化。因為bgsave每次運作都要執行fork操作建立子程序，頻繁執行成本過高
2、在一定間隔時間做一次備份，是以如果redis意外down掉的話，就會丢失最後一次快照之後的所有修改（資料有丢失）。

如果資料相對來說比較重要，希望将損失降到最小，則可以使用AOF方式進行持久化。

4.3.2 AOF模式

AOF(Append Only File)：Redis 預設不開啟。AOF采用日志的形式來記錄每個寫操作，并追加到檔案中。開啟後，執行更改Redis資料的指令時，就會把指令寫入到AOF檔案中。

Redis 重新開機時會根據日志檔案的内容把寫指令從前到後執行一次以完成資料的恢複工作。

AOF配置開關

# 開關
appendonly no  /yes
# 檔案名
appendfilename "appendonly.aof"

通過修改redis.conf重新開機redis之後：systemctl restart redis_6379。

再次運作redis的相關操作指令，會發現在指定的

dir

目錄下生成appendonly.aof檔案，通過vim檢視該檔案内容如下

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

AOF配置相關問題解答

問題1：資料都是實時持久化到磁盤嗎？

雖然每次執行更改Redis資料庫内容的操作時，AOF都會将指令記錄在AOF檔案中，但是事實上，由于作業系統的緩存機制，資料并沒有真正地寫入硬碟，而是進入了系統的硬碟緩存。在預設情況下系統每30秒會執行一次同步操作。以便将硬碟緩存中的内容真正地寫入硬碟。

在這30秒的過程中如果系統異常退出則會導緻硬碟緩存中的資料丢失。一般來說能夠啟用AOF的前提是業務場景不能容忍這樣的資料損失，這個時候就需要Redis在寫入AOF檔案後主動要求系統将緩存内容同步到硬碟中。在redis.conf中通過如下配置來設定同步機制。


appendfsync everysec	AOF持久化政策（硬碟緩存到磁盤），預設everysec 1 no 表示不執行fsync，由作業系統保證資料同步到磁盤，速度最快，但是不太安全； 2 always 表示每次寫入都執行fsync，以保證資料同步到磁盤，效率很低； 3 everysec表示每秒執行一次fsync，可能會導緻丢失這1s資料。通常選擇 everysec ，兼顧安全性和效率。

appendfsync everysec

AOF持久化政策（硬碟緩存到磁盤），預設everysec

1 no 表示不執行fsync，由作業系統保證資料同步到磁盤，速度最快，但是不太安全；

2 always 表示每次寫入都執行fsync，以保證資料同步到磁盤，效率很低；

3 everysec表示每秒執行一次fsync，可能會導緻丢失這1s資料。通常選擇 everysec ，兼顧安全性和效率。

問題2：檔案越來越大，怎麼辦？

由于AOF持久化是Redis不斷将寫指令記錄到 AOF 檔案中，随着Redis不斷的運作，AOF 的檔案會越來越大，檔案越大，占用伺服器記憶體越大以及 AOF 恢複要求時間越長。

例如set gupao 666，執行1000次，結果都是gupao=666。

為了解決這個問題，Redis新增了重寫機制，當AOF檔案的大小超過所設定的門檻值時，Redis就會啟動AOF檔案的内容壓縮，隻保留可以恢複資料的最小指令集。

可以使用指令下面這個指令主動觸發重寫

redis> bgrewriteaof

AOF 檔案重寫并不是對原檔案進行重新整理，而是直接讀取伺服器現有的鍵值對，然後用一條指令去代替之前記錄這個鍵值對的多條指令，生成一個新的檔案後去替換原來的 AOF 檔案。

重寫觸發機制如下


auto-aof-rewrite-percentage	預設值為100。表示的是當目前的AOF檔案大小超過上一次重寫時的AOF檔案大小的百分之多少時會再次進行重寫，如果之前沒有重寫過，則以啟動時AOF檔案大小為依據
auto-aof-rewrite-min-size	預設64M。表示限制了允許重寫的最小AOF檔案大小，通常在AOF檔案很小的情況下即使其中有很多備援的指令我們也并不太關心

在啟動時，Redis會逐個執行AOF檔案中的指令來将硬碟中的資料載入到記憶體中，載入的速度相對于RDB會慢一些

問題：重寫過程中，AOF檔案被更改了怎麼辦？

Redis 可以在 AOF 檔案體積變得過大時，自動地在背景對 AOF 進行重寫：重寫後的新 AOF 檔案包含了恢複目前資料集所需的最小指令集合。

重寫的流程是這樣，

主程序會fork一個子程序出來進行AOF重寫，這個重寫過程并不是基于原有的aof檔案來做的，而是有點類似于快照的方式，全量周遊記憶體中的資料，然後逐個序列到aof檔案中。
在fork子程序這個過程中，服務端仍然可以對外提供服務，那這個時候重寫的aof檔案的資料和redis記憶體資料不一緻了怎麼辦？不用擔心，這個過程中，主程序的資料更新操作，會緩存到aof_rewrite_buf中，也就是單獨開辟一塊緩存來存儲重寫期間收到的指令，當子程序重寫完以後再把緩存中的資料追加到新的aof檔案。
當所有的資料全部追加到新的aof檔案中後，把新的aof檔案重命名正式的檔案名字，此後所有的操作都會被寫入新的aof檔案。
如果在rewrite過程中出現故障，不會影響原來aof檔案的正常工作，隻有當rewrite完成後才會切換檔案。是以這個rewrite過程是比較可靠的。

圖4-26

Redis允許同時開啟AOF和RDB，既保證了資料安全又使得進行備份等操作十分容易。如果同時開啟後，Redis重新開機會使用AOF檔案來恢複資料，因為AOF方式的持久化可能丢失的資料更少。

AOF的優劣勢

優點：

1、AOF 持久化的方法提供了多種的同步頻率，即使使用預設的同步頻率每秒同步一次，Redis 最多也就丢失 1 秒的資料而已。

缺點：

1、對于具有相同資料的的Redis，AOF 檔案通常會比 RDB 檔案體積更大（RDB存的是資料快照）。

2、雖然 AOF 提供了多種同步的頻率，預設情況下，每秒同步一次的頻率也具有較高的性能。在高并發的情況下，RDB 比 AOF 具好更好的性能保證。

關注[跟着Mic學架構]公衆号，擷取更多精品原創

1萬字長文詳解Redis6中記憶體淘汰算法/持久化機制/多線程模型

Redis中的多路複用模型

關于Redis的單線程模型

Redis6.0之後的多線程？

Redis 6.0如何開啟多線程

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

記憶體回收政策

設定Redis能夠使用的最大記憶體

使用記憶體淘汰政策釋放記憶體

了解并手寫LRU算法

Redis中的LRU算法

LFU算法

持久化機制的實作及原理

4.3.1 RDB模式

RDB資料恢複示範

RDB檔案的優勢和劣勢

4.3.2 AOF模式

AOF配置開關

AOF配置相關問題解答

AOF的優劣勢

繼續閱讀

秒懂JVM的三大參數類型，就靠這十個小實驗了初級—中級—進階三個級别的大廠面試真題阿裡雲——Java 實習生/初級美團——Java 中級螞蟻金服——Java 進階基礎篇JVM 篇MySQL 篇Redis 篇

CentOs7 安裝redis4.0 遇到的坑一、CentOs7連接配接網絡二、make檔案的時候出錯三、安裝ruby的redis插件時候報錯最後

docker 搭建Redis 問題解決

如何解決Redis緩存擊穿、雪崩、穿透問題

java 版本的redis-stat不能運作在背景和daemon

redis管理常用指令

django短信驗證碼的後端實作

Redis訂閱了一段時間後訂閱失效了（ redisTemplate.convertAndSend）

2022秋招面試總結（cpp+java+測開）百度測開一面位元組後端一面蝦皮後端一面蝦皮後端二面

資料遷移方法資料遷移原則資料遷移之雙寫方案資料遷移之級聯同步方案

微服務-性能壓測\緩存redis和分布式鎖redisson和SpringCache

Nacos 2.0 更新前後性能對比壓測

Spring資料和Redis

redis叢集資料一緻性_RedisRaft為Redis叢集帶來強大的資料一緻性

supervisor 管理redis 和httpd 環境centos7

Redis簡介一(單機版)發展曆程Redis