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（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操作，

按照前面我們對多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=https://www.cnblogs.com/mic112/p/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 = https://www.cnblogs.com/mic112/p/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學架構]公眾號，獲取更多精品原創

標籤：Java

上一篇：如何在Xamarin中找到DataTemplate內部的控制元件

下一篇：別再糾結執行緒池大小了，沒有固定公式的！終于有人說清楚了。。