Redis中的多路複用模型

Redis6用到了多執行緒？那多執行緒應用在哪些地方，引入多執行緒後，又改如何保證執行緒安全性呢？
同時，如何在效能和執行緒安全性方面做好平衡？

關於Redis的單執行緒模型

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

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

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

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

這樣設計的好處：

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

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

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操作。

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

Redis 6.0中將處理過程中最耗時的Socket讀取、請求解析、單獨用一個執行緒來處理，剩下的命令執行操作仍然由單執行緒來完成和記憶體的資料互動，這樣一來，網路IO操作就變成了多執行緒了，但是核心部分仍然是執行緒安全的，如圖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

記憶體回收策略

很多同學瞭解了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操作之後，最近被命中的快取，都會存在連結串列頭部的方向，沒有命中的，都會在連結串列尾部方向，當需要替換內容時，由於連結串列尾部是最少被命中的，我們只需要淘汰連結串列尾部的資料即可。

下面我們通過一段程式碼實現一個簡單的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個以前的元素往前挪一個位置（實際就是淘汰了），然後執行插入操作。

這樣做的目的是能夠選出最真實的最少被訪問的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，隨著訪問次數的增加，頻率不斷遞增。而當前被訪問的元素也會隨著頻率增加進行移動。

持久化機制的實現及原理

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

1. 將redis作為nosql資料庫使用。

2. 將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會自動將記憶體中的資料生成一份副本並存儲在磁碟上，這個過程稱之為“快照”，除了上述規則之外，還有以下幾種方式生成快照。

1. 根據配置規則進行自動快照
2. 使用者執行SAVE或者GBSAVE命令
3. 執行FLUSHALL命令
4. 執行復制(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

使用者執行SAVE或者GBSAVE命令

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

1. save命令

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

   圖4-24

2. 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快照檔案，並將資料從硬碟載入到記憶體。根據資料量大小以及伺服器效能不同，這個載入的時間也不同。

執行FLUSHALL命令

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

執行復制(replication)時

該操作主要是在主從模式下，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中通過如下配置來設定同步機制。

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

由於AOF持久化是Redis不斷將寫命令記錄到 AOF 檔案中，隨著Redis不斷的執行，AOF 的檔案會越來越大，檔案越大，佔用伺服器記憶體越大以及 AOF 恢復要求時間越長。

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

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

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

redis> bgrewriteaof

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過程是比較可靠的。

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

AOF的優劣勢

優點：

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

缺點：

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

2、雖然 AOF 提供了多種同步的頻率，預設情況下，每秒同步一次的頻率也具有較高的效能。在高併發的情況下，RDB 比 AOF 具好更好的效能保證。
關注[跟著Mic學架構]公眾號，獲取更多精品原創