redis的持久化怎么理解

這篇文章主要講解了“redis的持久化怎么理解”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“redis的持久化怎么理解”吧！

redis的持久化：

    概念：將內存中的數據保存到磁盤，在機器宕機或重啟時可以保證數據不丟失。
    
    說明：建議RDB和AOF同時開啟，若二者同時開啟，則redis在啟動時優先使用aof文件來恢復數據，若讀取aof文件失敗，則讀取rdb文件來恢復數據。

    RDB(Redis DataBase)
        概念：
            將內存中的數據進行快照并且存儲到磁盤上，即在指定目錄下生成一個dump.rdb文件。RDB是redis默認的持久化方式。
            redis啟動后可用通過讀取rdb文件，將數據再次載入到內存中，一般情況下1G的rdb文件載入到內存的時間大概為20~30秒。
            
        過程：把所有的數據都寫到一個臨時文件中，然后用這個臨時文件替換掉之前的rdb文件。
        
        觸發機制：
            手動觸發：
                save命令：阻塞Redis當前的進程，直到RDB過程完成為止。若實例占用的內存比較大，則會造成redis服務長時間的不可用。(不建議使用)
                bgsave命令：redis當前進程執行fork操作創建子進程，RDB持久化過程由子進程負責，父進程繼續接收并處理客戶端發出的請求。阻塞只發生在fork階段，一般時間很短。
                    注意：fork一個進程時，子進程占用的內存空間與父進程相同。
            自動觸發：
                達到配置的條件時，自動觸發bgsave命令。
                在執行shutdown命令后會自動觸發bgsave命令。
        
            配置文件redis.conf：

                # 設置觸發快照的條件(Will save the DB if both the given number of seconds and the given number of write operations against the DB occurred.)
                # 格式：save <seconds> <changes>
                save 900 1         # 900秒內，如果有1個以上(包括1個)的key被修改了，則觸發快照。
                save 300 10        # 300秒內，如果有10個以上(包括10個)的key被修改了，則觸發快照。
                save 60 10000    # 60秒內，如果有10000個以上(包括10000個)的key被修改了，則觸發快照。
                
                # RDB默認會開啟，關閉RDB方式的持久化
                save ""
                
                # 設置rdb文件的名稱
                dbfilename dump.rdb

                # 設置redis的工作目錄，即rdb文件、aof文件所在的目錄
                # The working directory.
                # The DB will be written inside this directory, with the filename specified above using the 'dbfilename' configuration directive.
                # The Append Only File will also be created inside this directory.
                dir ./
                
                # 設置rdb文件是否進行壓縮，默認為yes。注：壓縮rdb文件可以減少磁盤空間的占用，但是需要消耗額外的cpu。
                rdbcompression yes
    
        優點：適合大規模的數據恢復，且數據加載的速度比較快。
        缺點：無法做到數據實時的(秒級)持久化。故數據備份的完整性不高。

    AOF(Append Only File)
        概念：
            將發送到redis服務端的每一條寫操作都存儲到磁盤上，即在指定目錄下生成一個appendonly.aof文件，并且將每次的寫操作追加到aof文件的末尾。
            redis啟動后通過讀取aof文件，將aof文件中的寫操作依次再執行一遍，以此來達到數據恢復的效果。
        
        過程：命令寫入(append)到緩存區、將緩存區的數據同步到aof文件中(sync)、重新aof文件(rewrite)
            重寫aof文件：
                目的：去除數據的中間執行過程，保留最終數據的命令，可大大減小aof文件的大小，從而可以加快數據恢復的速度。
                過程：redis當前進程執行fork操作創建子進程(開銷等同于bgsave過程)，子進程根據命令合并規則將內存中的數據寫入到新的AOF文件中，最后用新的aof文件替換掉現有的aof文件。
        
        觸發機制：
            手動觸發：
                BGREWRITEAOF
                若aof文件格式異常，則需要修復aof文件：redis-check-aof --fix appendonly.aof
            自動觸發：
                達到配置的條件時，自動觸發更新aof文件 或 重新aof文件 的操作。
        
        3)配置文件redis.conf：

            # AOF和RDB可以同時存在，AOF方式的持久化擁有更好的數據完整性和一致性。
            # AOF and RDB persistence can be enabled at the same time without problems. 
            # If the AOF is enabled on startup Redis will load the AOF, that is the file with the better durability guarantees.
    
            # 開啟AOF (AOF默認是關閉的appendonly no)
            appendonly yes
            
            # 設置觸發更新aof文件的條件
            # appendfsync always    # 同步持久化，即每次執行寫操作后都會去更新aof文件。數據完整性好，但是性能較差。
            appendfsync everysec    # 每秒同步一次，是AOP默認觸發更新日志的條件。
            # appendfsync no        # 不主動同步，由操作系統來決定什么時候同步(一般為30s)，性能最好但是持久化得不到保障，故不推薦使用該配置。
            
            # 設置觸發重寫aof文件的條件，多個條件是"與"的關系。
            # redis在重寫aof文件后會將aof文件的大小記錄下來(若沒有重寫過aof文件，則這個大小默認是redis啟動時aof文件的大小)
            auto-aof-rewrite-percentage 100        # 當前aof文件的大小 超過 上一次重寫后記錄的大小 的 100%。
            auto-aof-rewrite-min-size 64mb        # 當前aof文件大于等于64mb。注一般不會設置的這么小，看情況設為ngb比較合理。
            
            # 設置aof文件的名稱
            # appendfilename appendonly.aof

            # 設置redis的工作目錄，即rdb文件、aof文件所在的目錄
            dir ./
            
        優點：可以做到數據實時的(秒級)持久化，故數據備份的完整性很高。
        缺點：AOF記錄的內容多，文件會越來越大，數據恢復也會越來越慢，故redis在AOF中引入了重寫aof文件的機制。

    持久化給redis帶來的開銷：
        概念：子進程在重寫RDB文件和重寫AOF文件時會消耗cpu、內存、硬盤等資源。
        
            cpu：子進程負責把進程內的數據分批寫入文件，這個過程屬于CPU密集操作，通常子進程對單核CPU利用率接近90%。
            
            內存：父進程fork子進程時，子進程默認占用的內存同父進程一樣。我們可以修改Linux內存分配的配置，避免物理內存不足導致fork進程失敗。
            
            硬盤：往rdb文件或aof文件中寫數據的過程中，磁盤io的壓力比較大。
                說明：開啟AOF的Redis在高流量寫入時，如果使用普通機械磁盤，寫入吞吐一般在100MB/s左右，這時Redis實例的瓶頸主要在AOF同步硬盤上。

        注意：redis實例不應該和其它對cpu、內存、硬盤敏感的服務混部。

感謝各位的閱讀，以上就是“redis的持久化怎么理解”的內容了，經過本文的學習后，相信大家對redis的持久化怎么理解這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！