Redis持久化怎麼實現

Redis是一種高階key-value資料庫。它跟memcached類似，不過資料可以持久化，而且支援的資料型態很豐富。有字串，鍊錶，集 合和有序集合。支援在伺服器端計算集合的並，交和補集(difference)等，也支援多種排序功能。

Redis支援RDB與AOF兩種持久化機制，持久化可以避免因進程異常退出或down機導致的資料遺失問題，在下次重啟時能利用之前的持久化檔案實現資料復原。

RDB持久化

RDB持久化是一種持久化方式，它透過建立壓縮的二進位檔案快照，保存特定時間點的完整資料。 RDB持久化是Redis預設的持久化方式。 RDB持久化的觸發包括手動觸發與自動觸發兩種方式。

手動觸發

save， 在命令列執行save命令，將以同步的方式建立rdb檔案保存快照，會阻塞伺服器的主進程，生產環境中不要用bgsave, 在命令行執行bgsave指令，將透過fork一個子程序以非同步的方式建立rdb檔保存快照，除了fork時有阻塞，子程序在建立rdb檔時，主程序可繼續處理請求

自動觸發

在redis.conf中配置save m n 定時觸發，如save 900 1表示在900s內至少存在一次更新就觸發主從複製時，如果從節點執行全量複製操作，主節點自動執行bgsave生成RDB檔案並傳送給從節點執行debug reload指令重新載入Redis時執行shutdown且沒有開啟AOF持久化redis.conf中RDB持久化配置

# 只要满足下列条件之一，则会执行bgsave命令save 900 1 # 在900s内存在至少一次写操作save 300 10
save 60 10000# 禁用RBD持久化，可在最后加 save ""# 当备份进程出错时主进程是否停止写入操作stop-writes-on-bgsave-error yes# 是否压缩rdb文件 推荐no 相对于硬盘成本cpu资源更贵rdbcompression no

AOF持久化

#AOF（Append- Only-File）持久化即記錄所有變更資料庫狀態的指令，以append的形式追加儲存到AOF檔案中。一種重寫方式為： 當伺服器重新啟動時，可以使用AOF檔案中記錄的命令來恢復先前關閉時的資料庫狀態。

redis.conf中AOF持久化設定如下

# 默认关闭AOF，若要开启将no改为yesappendonly no# append文件的名字appendfilename "appendonly.aof"# 每隔一秒将缓存区内容写入文件 默认开启的写入方式appendfsync everysec# 当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。auto-aof-rewrite-percentage 100# 当AOF文件大小大于该配置项时自动开启重写auto-aof-rewrite-min-size 64mb

AOF持久化的實作包括3個步驟:

指令追加：將指令追加到AOF緩衝區檔案寫入：緩衝區內容寫入AOF檔案檔案保存：AOF檔案儲存到磁碟其中後兩步驟的頻率透過appendfsync來配置，appendfsync的選項包括

always， 每執行一個指令就儲存一次，安全性最高，最多只丟失一個命令的數據，但是性能也最低（頻繁的磁碟IO） everysec，每一秒保存一次，推薦使用，在安全性與性能之間折中，最多丟失一秒的數據no，依賴作業系統來執行（一般大概30s一次的樣子），安全性最低，性能最高，丟失操作系統最後一次對AOF文件觸發SAVE操作之後的數據AOF通過保存命令來持久化，隨著時間的推移，AOF文件會越來越大，Redis透過AOF檔案重寫來解決AOF檔案不斷增大的問題（可以減少檔案的磁碟佔有量，加快資料復原的速度），原理如下：

呼叫fork，創建一個子程序

子程序讀取當前資料庫的狀態來“重寫”一個新的AOF檔（這裡雖然叫“重寫”，但實際上並沒有對舊文件進行任何讀取，而是根據資料庫的目前狀態來形成指令）

主程序持續將新的變動同時寫到AOF重寫緩衝區與原來的AOF緩衝區中

主程序取得到子程序重寫AOF完成的訊號，呼叫訊號處理函數將AOF重寫緩衝區內容寫入新的AOF文件中，並對新文件進行重命名，原子地覆蓋原有AOF文件，完成新舊文件的替換

AOF的重寫也分為手動觸發與自動觸發

手动触发： 直接调用bgrewriteaof命令
自动触发： 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小（aof_current_size）和上一次重写后AOF文件大小（aof_base_size）的比值。自动触发时机为 aof_current_size > auto-aof-rewrite-min-size &&（aof_current_size - aof_base_size）/aof_base_size> = auto-aof-rewrite-percentage

RDB vs AOF

RDB與AOF兩種方式各有優缺點。

RDB的優點：與AOF相比，RDB檔案相對較小，恢復資料比較快（原因見資料復原部分） RDB的缺點：伺服器宕機，RBD方式會遺失掉上一次RDB持久化後的資料；使用bgsave fork子程序時會耗費記憶體。 AOF的優點： AOF只是追加文件，對伺服器效能影響較小，速度比RDB快，消耗記憶體也少，同時可讀性高。使用AOF會帶來兩個缺點：產生的檔案相對較大，即使透過AOF重寫，仍然會比較大；同時，恢復資料的速度也比RDB慢。資料庫的復原

如果沒有開啟AOF持久化功能，在伺服器啟動時，將會阻塞主進程期間自動載入RDB檔案。如果開啟了AOF持久化功能，伺服器則會優先使用AOF檔案來還原資料庫狀態，因為AOF檔案的更新頻率通常比RDB檔案的更新頻率高，儲存的資料更完整。

redis資料庫復原的處理流程如下，

在資料復原方面，RDB的啟動時間會更短，原因有兩個：

在RDB 檔案中，每個資料項只有一個記錄，不像AOF 日誌可能存在一個資料項有多個操作記錄的情況。所以每個資料只需要寫一次就行了，檔案相對較小。

RDB 文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。

但是在进行RDB持久化时，fork出来进行dump操作的子进程会占用与父进程一样的内存，采用的copy-on-write机制，对性能的影响和内存的消耗都是比较大的。比如16G内存，Redis已经使用了10G，这时save的话会再生成10G，变成20G，大于系统的16G。这时候会发生交换，要是虚拟内存不够则会崩溃，导致数据丢失。所以在用redis的时候一定对系统内存做好容量规划。

RDB、AOF混合持久化

Redis从4.0版开始支持RDB与AOF的混合持久化方案。首先由RDB定期完成内存快照的备份，然后再由AOF完成两次RDB之间的数据备份，由这两部分共同构成持久化文件。这个方案的优势在于其充分利用了RDB加载速度快、备份体积小以及AOF记录数据丢失几率尽可能低的特点。缺点是兼容性差，一旦开启了混合持久化，在4.0之前的版本都不识别该持久化文件，同时由于前部分是RDB格式，阅读性较低。

开启混合持久化

aof-use-rdb-preamble yes

数据恢复加载过程就是先按照RDB进行加载，然后把AOF命令追加写入。

持久化方案的建议 如果Redis只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。建议同时采用两种持久化方式，以提高数据的安全性。如果你可以容忍在灾难发生时数据丢失几分钟，那么可以仅使用RDB。一般的设计方法是 使用主从复制机制以解决持久化时所带来的性能影响。即Master上RDB、AOF都不做，保证Master的读写性能，而Slave上则同时开启RDB和AOF（或4.0以上版本的混合持久化方式）来进行持久化，保证数据的安全性。

以上是Redis持久化怎麼實現的詳細內容。更多資訊請關注PHP中文網其他相關文章！