Redis持久化原理：
Redis支持兩種持久化：RDB和AOF模式
一、名詞解釋：
RDB：持久化可以在指定的時間間隔內生成數據集的時間點快照點快照（point-in-time snapshot)。
snapshot，二進制格式：按事先定製的策略，週期性地將數據保存到磁盤：數據文件默認爲dump.rdb;
客戶端也可顯式使用SAVA或BGSAVE命令啓動快照保存機制；
SAVE：同步，在主線程中保存快照；此時會阻塞所有客戶端請求；
BGSAVE：異步，不會阻塞客戶端請求；
AOF：持久化記錄服務器執行的所有寫操作命令，並在服務器啓動時，通過重新執行這些命令來還原數據集。記錄每一次寫操作至指定的文件尾部實現持久化；當redis重啓時，可通過重新執行文件中的命令在內存重建數據庫；
BGREWRITEAOF：AOF文件重寫；不會讀取正在使用的AOF文件，而通過將內存中的數據以命令的方式保存到臨時文件中，完成之後替換原來的AOF文件；
AOF文件中的命令全部以redis協議的格式來保存，新命令會被追加到文件的尾部。redis還可以在後臺對AOF文件進行重寫（rewrite）
使得AOF文件的體積不會超出保存數據集狀態所需的實際大小。
RDB和AOF的優先級：
如果同時開啓RDB和AOF模式，AOF的優先級要比RDB高；
Redis還可以同時使用RDB和AOF持久化。在這種情況下，當redis重啓時，它會優先使用AOF文件來還原數據集。
因爲AOF文件保存的數據集通常比RDB文件所保存的數據集更完整。
AOF的方式有點像ORCAL的邏輯備庫！
AOF redis還會在後臺對數據進行重寫，比如set key1，set key2，其實set key1沒用，這樣做可以把set key1刪掉。這樣保存下來的數據集就很小了可以壓縮了！
你甚至可以關閉持久化功能，讓數據只在服務器運行時存在。
二、RDB&AOF優缺點
RDB的優缺點：
優點：
1、緊湊易於備份，他就一個文件。
2、RDB可以最大化redis性能、父進程無需做任何操作只需要for一個子進程即可
3、恢復比AOF快
缺點：
1、數據完整性：如果非常注重數據的完整性，那麼RDB就不行，雖然他是一個point-in-tie的快照方式，但是在快照的過程中，redis重啓了，那麼在快照中的這些數據將會丟失；
2、數據非常龐大後，非常耗CPU和時間，那麼redis將可能down掉1秒鐘甚至更長。
AOF的優缺點：
優點：
1、使用AOF持久化會讓redis變得非常耐久，AOF默認的每一秒追加一次也可以修改他的方式，每執行一次命令追加一次，所以你最多丟失1秒鐘的數據。
2、AOF文件是一個只進行追加操作的日誌文件（append only log）。
3、redis可以在AOF文件體積變得過大時，自動地在後臺對AOF進行重寫。
缺點：
1、對於相同的數據集來說，AOF文件的體積通常要大於RDB文件的體積。
2、根據所使用的fsync策略，AOF的速度可能會慢於RDB。
Rdis持久化設置：
默認Redis是開啓的RDB模式的持久化的看下面配置文件：
########################### SNAPSHOTTING ######################## # # Save the DB on disk: # # save <seconds> <changes> # # Will save the DB if both the given number of seconds and the given # number of write operations against the DB occurred. # # In the example below the behaviour will be to save: # after 900 sec (15 min) if at least 1 key changed # after 300 sec (5 min) if at least 10 keys changed # after 60 sec if at least 10000 keys changed # # Note: you can disable saving completely by commenting out all "save" lines. # # It is also possible to remove all the previously configured save # points by adding a save directive with a single empty string argument # like in the following example: # # save "" save 900 1 save 300 10 save 60 10000 =================================================== 上面3個save是或的關係 # save <seconds> <changes> 333格式！ 解釋： # after 900 sec (15 min) if at least 1 key changed # after 300 sec (5 min) if at least 10 keys changed # after 60 sec if at least 10000 keys changed 900 sec內有1個Key發生了改變就做一次快照 或 300 sec內有10個keys發生了改變做一次快照 或 60 sec內有10000 keys發生了改變做一次快照 快照原理： forker出一個進程，是當前進程的一個副本相當於子進程，不會影響你當前運行的進程！當子進程寫的時候會有一個臨時 的文件，當子進程寫完之後會把這個臨時的文件move替換老的文件，所以這個rdb的文件任何時間都是一個完整的可用的 副本！你寫的時候不會影響RDB這個文件，因爲forker出的子進程正在寫的是一個臨時文件！ 但是如果故障了，你這個保存的時間是你開始快照那一刻那個時間，你快照到快照完畢那一段時間的數據就丟失了。 如果想禁用持久化把這三行刪了就行了 save 900 1 save 300 10 save 60 10000 1、快照保存在哪裏呢？ # The filename where to dump the DB dbfilename dump.rdb #如果你啓用了多個快照名稱，可以使用端口來定義；比如：dump_6379.rdb # 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. # # Note that you must specify a directory here, not a file name. dir ./ #不僅僅是RDB模式下的DB存放在這個目錄，AOF模式下也是存放在這個目錄的，建議存放在指定的目錄。 #比如 dir /data/redis #比如我上面指定了： # The filename where to dump the DB dbfilename dump_6379.rdb # Note that you must specify a directory here,not a file name. dir /data/redis/
2、手動在redis中保存
127.0.0.1:6379> SET key 1 OK 127.0.0.1:6379> SAVE OK 127.0.0.1:6379> quit # ll /u01/redis/ 查看文件目錄下面有沒有修改 -rw-r--r--. 1 root root 399 Mar 25 15:55 dump.rdb #當前時間創建 在設置一個key看下： 127.0.0.1:6379> set key 2 OK 127.0.0.1:6379> SAVE OK 127.0.0.1:6379> quit # ll /u01/redis/ -rw-r--r--. 1 root root 399 Mar 25 15:59 dump.rdb 127.0.0.1:6379> BGSAVE Background saving started SAVE和BGSAVE有什麼區別：SAVE是阻塞的當你直接執行SAVE的時候他就不幹活了，BGSAVE是在後臺執行。 forker一個子進程來進行SAVE。 SAVE的使用場景僅限於：當redis需要遷移的時候，redis沒有數據寫入並且可以停的時候使用！ 測試添加一個：key然後停掉看看！不保存： 目前的key是： 127.0.0.1:6379> KEYS * 1) "key" 2) "hello" 127.0.0.1:6379> SET key3 haha OK # kill -9 `pgrep -f redis` 殺掉進程 127.0.0.1:6379> KEYS * #重啓登錄之後發現設置的key丟失了 1) "hello" 2) "key" #所以當redis異常掛掉之後，沒有SAVE數據！
3、啓動AOF後
給這個文件追加，把所有的命令都寫到一個文件裏面，你執行一個我寫一個。恢復的話在執行一遍不就行了嗎！非常簡 單(但是恢復相對RDB模式會慢，他相當於重新把AOF庫裏的記錄重新往內存中寫一遍)可以RDB和AOF同時使用！優點 都佔用了！但是也得根據業務來定！ 開啓方法：修改配置文件 appendonly yes #改成yes appendfilename "appendonly.aof" #文件名 工作原理： forker 一個子進程寫到臨時文件，寫完之後就給父進程發一個信號，開始寫到寫完的這個過程還會有子進程給父進程發信 號。先保存在內存裏，但是他有個好的功能，重寫，他會定時對aof進行更新，這樣文件就會非常小！ 測試：（他會根據redis可識別的方式寫入文件，不過大概人也能看懂） 127.0.0.1:6379> SET sichuan dazhou OK 127.0.0.1:6379> SET beijing beijing OK 127.0.0.1:6379> SET magedu peixunjigou OK 127.0.0.1:6379> SET cengdu sichuan OK 127.0.0.1:6379> KEYS * 1) "magedu" 2) "beijing" 3) "cengdu" 4) "sichuan" # cat /u01/redis/appendonly.aof *2 $6 SELECT $1 0 *3 $3 SET $7 sichuan $6 dazhou *3 $3 SET $7 beijing $7 beijing *3 $3 SET $6 magedu $11 peixunjigou *3 $3 SET $6 cengdu $7 sichuan