溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“redis持久化的方式”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“redis持久化的方式”吧!
首先，我們應該明確持久化的數據有什么用，答案是用于重啟后的數據恢復。
Redis是一個內存數據庫，無論是RDB還是AOF，都只是其保證數據恢復的措施。
所以Redis在利用RDB和AOF進行恢復的時候，都會讀取RDB或AOF文件，重新加載到內存中。
RDB
AOF
RDB就是Snapshot快照存儲，是默認的持久化方式。 可理解為半持久化模式，即按照一定的策略周期性的將數據保存到磁盤。 對應產生的數據文件為dump.rdb，通過配置文件中的save參數來定義快照的周期。
下面是默認的快照設置：
save 900 1 #當有一條Keys數據被改變時，900秒刷新到Disk一次
save 300 10 #當有10條Keys數據被改變時，300秒刷新到Disk一次
save 60 10000#當有10000條Keys數據被改變時，60秒刷新到Disk一次
Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的。 當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然后通過原子性rename系統調用將臨時文件重命名為RDB文件。 這樣在任何時候出現故障，Redis的RDB文件都總是可用的。 同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。
第一次Slave向Master同步的實現是： * Slave向Master發出同步請求，Master先dump出rdb文件，然后將rdb文件全量傳輸給slave，然后Master把緩存的命令轉發給Slave，初次同步完成。
第二次以及以后的同步實現是： * Master將變量的快照直接實時依次發送給各個Slave。但不管什么原因導致Slave和Master斷開重連都會重復以上兩個步驟的過程。
Redis的主從復制是建立在內存快照的持久化基礎上的，只要有Slave就一定會有內存快照發生。
可以很明顯的看到，RDB有它的不足，就是一旦數據庫出現問題，那么我們的RDB文件中保存的數據并不是全新的。
從上次RDB文件生成到Redis停機這段時間的數據全部丟掉了。
AOF(Append-Only File)比RDB方式有更好的持久化性。
由于在使用AOF持久化方式時，Redis會將每一個收到的寫命令都通過Write函數追加到文件中，類似于MySQL的binlog。
當Redis重啟是會通過重新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。
對應的設置參數為： $ vim /opt/redis/etc/redis_6379.conf
appendonly yes 啟用AOF持久化方式
appendfilename appendonly.aof #AOF文件的名稱，默認為appendonly.aof
appendfsync always 每次收到寫命令就立即強制寫入磁盤，是最有保證的完全的持久化，但速度也是最慢的，一般不推薦使用。
appendfsync everysec 每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，是受推薦的方式。
appendfsync no #完全依賴OS的寫入，一般為30秒左右一次，性能最好但是持久化最沒有保證，不被推薦。
AOF的完全持久化方式同時也帶來了另一個問題，持久化文件會變得越來越大。
比如我們調用INCR test命令100次，文件中就必須保存全部的100條命令，但其實99條都是多余的。
因為要恢復數據庫的狀態其實文件中保存一條SET test 100就夠了。
為了壓縮AOF的持久化文件，Redis提供了bgrewriteaof命令。
收到此命令后Redis將使用與快照類似的方式將內存中的數據以命令的方式保存到臨時文件中，最后替換原來的文件，以此來實現控制AOF文件的增長。
由于是模擬快照的過程，因此在重寫AOF文件時并沒有讀取舊的AOF文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的AOF文件。
對應的設置參數為: $ vim /opt/redis/etc/redis_6379.conf
no-appendfsync-on-rewrite yes
在日志重寫時，不進行命令追加操作，而只是將其放在緩沖區里，避免與命令的追加造成DISK IO上的沖突。 auto-aof-rewrite-percentage 100
當前AOF文件大小是上次日志重寫得到AOF文件大小的二倍時，自動啟動新的日志重寫過程。 auto-aof-rewrite-min-size 64mb #當前AOF文件啟動新的日志重寫過程的最小值，避免剛剛啟動Reids時由于文件尺寸較小導致頻繁的重寫。
到底選擇什么呢？下面是來自官方的建議：
通常，如果你要想提供很高的數據保障性，那么建議你同時使用兩種持久化方式。 如果你可以接受災難帶來的幾分鐘的數據丟失，那么你可以僅使用RDB。 很多用戶僅使用了AOF，但是我們建議，既然RDB可以時不時的給數據做個完整的快照，并且提供更快的重啟，所以最好還是也使用RDB。 因此，我們希望可以在未來（長遠計劃）統一AOF和RDB成一種持久化模式。
RDB的啟動時間會更短，原因有兩個：
是RDB文件中每一條數據只有一條記錄，不會像AOF日志那樣可能有一條數據的多次操作記錄。所以每條數據只需要寫一次就行了。 另一個原因是RDB文件的存儲格式和Redis數據在內存中的編碼格式是一致的，不需要再進行數據編碼工作，所以在CPU消耗上要遠小于AOF日志的加載。
災難恢復模擬 既然持久化的數據的作用是用于重啟后的數據恢復，那么我們就非常有必要進行一次這樣的災難恢復模擬了。 據稱如果數據要做持久化又想保證穩定性，則建議留空一半的物理內存。因為在進行快照的時候，fork出來進行dump操作的子進程會占用與父進程一樣的內存，真正的copy-on-write，對性能的影響和內存的耗用都是比較大的。 目前，通常的設計思路是利用Replication機制來彌補aof、snapshot性能上的不足，達到了數據可持久化。
即Master上Snapshot和AOF都不做，來保證Master的讀寫性能，而Slave上則同時開啟Snapshot和AOF來進行持久化，保證數據的安全性。
首先，修改Master上的如下配置：
sudo vim /opt/redis/etc/redis_6379.conf
save 900 1 #禁用Snapshot
save 300 10
save 60 10000
appendonly no #禁用AOF
接著，修改Slave上的如下配置：
sudo vim /opt/redis/etc/redis_6379.conf
save 900 1 #啟用Snapshot
save 300 10
save 60 10000
appendonly yes #啟用AOF
appendfilename appendonly.aof #AOF文件的名稱
appendfsync always
appendfsync everysec #每秒鐘強制寫入磁盤一次
appendfsync no
no-appendfsync-on-rewrite yes #在日志重寫時，不進行命令追加操作
auto-aof-rewrite-percentage 100 #自動啟動新的日志重寫過程
auto-aof-rewrite-min-size 64mb #啟動新的日志重寫過程的最小值
分別啟動Master與Slave
$ /etc/init.d/redis start
啟動完成后在Master中確認未啟動Snapshot參數
redis 127.0.0.1:6379> CONFIG GET save
"save"
""
然后通過以下腳本在Master中生成25萬條數據：
dongguo@redis:/opt/redis/data/6379$ cat redis-cli-generate.temp.sh
#!/bin/bash REDISCLI="redis-cli -a slavepass -n 1 SET" ID=1 while(($ID<50001)) do INSTANCE_NAME="i-2-$ID-VM" UUID=`cat /proc/sys/kernel/random/uuid` PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`\ CREATED=`date "+%Y-%m-%d %H:%M:%S"` $REDISCLI vm_instance:$ID:instance_name "$INSTANCE_NAME" $REDISCLI vm_instance:$ID:uuid "$UUID" $REDISCLI vm_instance:$ID:private_ip_address "$PRIVATE_IP_ADDRESS" $REDISCLI vm_instance:$ID:created "$CREATED" $REDISCLI vm_instance:$INSTANCE_NAME:id "$ID" ID=$(($ID+1)) done
dongguo@redis:/opt/redis/data/6379$ ./redis-cli-generate.temp.sh
在數據的生成過程中，可以很清楚的看到Master上僅在第一次做Slave同步時創建了dump.rdb文件，之后就通過增量傳輸命令的方式給Slave了。 dump.rdb文件沒有再增大。
dongguo@redis:/opt/redis/data/6379$ ls -lh
total 4.0K
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb
而Slave上則可以看到dump.rdb文件和AOF文件在不斷的增大，并且AOF文件的增長速度明顯大于dump.rdb文件。
dongguo@redis-slave:/opt/redis/data/6379$ ls -lh
total 24M
-rw-r--r-- 1 root root 15M Sep 27 12:06 appendonly.aof
-rw-r--r-- 1 root root 9.2M Sep 27 12:06 dump.rdb
等待數據插入完成以后，首先確認當前的數據量。
redis 127.0.0.1:6379> info
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:27623 run_id:e00757f7b2d6885fa9811540df9dfed39430b642 uptime_in_seconds:1541 uptime_in_days:0 lru_clock:650187 used_cpu_sys:69.28 used_cpu_user:7.67 used_cpu_sys_children:0.00 used_cpu_user_children:0.00 connected_clients:1 connected_slaves:1 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33055824 used_memory_human:31.52M used_memory_rss:34717696 used_memory_peak:33055800 used_memory_peak_human:31.52M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:0 changes_since_last_save:250000 bgsave_in_progress:0 last_save_time:1348677645 bgrewriteaof_in_progress:0 total_connections_received:250007 total_commands_processed:750019 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:246 vm_enabled:0 role:master slave0:10.6.1.144,6379,online db1:keys=250000,expires=0
當前的數據量為25萬條key，占用內存31.52M。
然后我們直接Kill掉Master的Redis進程，模擬災難。
dongguo@redis:/opt/redis/data/6379$ sudo killall -9 redis-server
我們到Slave中查看狀態：
redis 127.0.0.1:6379> info
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:13003 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 uptime_in_seconds:1627 uptime_in_days:0 lru_clock:654181 used_cpu_sys:29.69 used_cpu_user:1.21 used_cpu_sys_children:1.70 used_cpu_user_children:1.23 connected_clients:1 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33047696 used_memory_human:31.52M used_memory_rss:34775040 used_memory_peak:33064400 used_memory_peak_human:31.53M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:1 changes_since_last_save:3308 bgsave_in_progress:0 last_save_time:1348718951 bgrewriteaof_in_progress:0 total_connections_received:4 total_commands_processed:250308 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:694 vm_enabled:0 role:slave aof_current_size:17908619 aof_base_size:16787337 aof_pending_rewrite:0 aof_buffer_length:0 aof_pending_bio_fsync:0 master_host:10.6.1.143 master_port:6379 master_link_status:down master_last_io_seconds_ago:-1 master_sync_in_progress:0 master_link_down_since_seconds:25 slave_priority:100 db1:keys=250000,expires=0
可以看到master_link_status的狀態已經是down了，Master已經不可訪問了。
而此時，Slave依然運行良好，并且保留有AOF與RDB文件。
下面我們將通過Slave上保存好的AOF與RDB文件來恢復Master上的數據。
首先，將Slave上的同步狀態取消，避免主庫在未完成數據恢復前就重啟，進而直接覆蓋掉從庫上的數據，導致所有的數據丟失。
redis 127.0.0.1:6379> SLAVEOF NO ONE
OK
確認一下已經沒有了master相關的配置信息：
redis 127.0.0.1:6379> INFO
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:13003 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 uptime_in_seconds:1961 uptime_in_days:0 lru_clock:654215 used_cpu_sys:29.98 used_cpu_user:1.22 used_cpu_sys_children:1.76 used_cpu_user_children:1.42 connected_clients:1 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33047696 used_memory_human:31.52M used_memory_rss:34779136 used_memory_peak:33064400 used_memory_peak_human:31.53M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:1 changes_since_last_save:0 bgsave_in_progress:0 last_save_time:1348719252 bgrewriteaof_in_progress:0 total_connections_received:4 total_commands_processed:250311 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:1119 vm_enabled:0 role:master aof_current_size:17908619 aof_base_size:16787337 aof_pending_rewrite:0 aof_buffer_length:0 aof_pending_bio_fsync:0 db1:keys=250000,expires=0
在Slave上復制數據文件：
dongguo@redis-slave:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *
appendonly.aof
dump.rdb
將data.tar上傳到Master上，嘗試恢復數據:
可以看到Master目錄下有一個初始化Slave的數據文件，很小，將其刪除。
dongguo@redis:/opt/redis/data/6379$ ls -l
total 4
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb
dongguo@redis:/opt/redis/data/6379$ sudo rm -f dump.rdb
然后解壓縮數據文件：
dongguo@redis:/opt/redis/data/6379$ sudo tar xf /home/dongguo/data.tar
dongguo@redis:/opt/redis/data/6379$ ls -lh
total 29M
-rw-r--r-- 1 root root 18M Sep 27 01:22 appendonly.aof
-rw-r--r-- 1 root root 12M Sep 27 01:22 dump.rdb
啟動Master上的Redis；
dongguo@redis:/opt/redis/data/6379$ sudo /etc/init.d/redis start
Starting Redis server...
查看數據是否恢復：
redis 127.0.0.1:6379> INFO
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:16959 run_id:6e5ba6c053583414e75353b283597ea404494926 uptime_in_seconds:22 uptime_in_days:0 lru_clock:650292 used_cpu_sys:0.18 used_cpu_user:0.20 used_cpu_sys_children:0.00 used_cpu_user_children:0.00 connected_clients:1 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33047216 used_memory_human:31.52M used_memory_rss:34623488 used_memory_peak:33047192 used_memory_peak_human:31.52M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:0 changes_since_last_save:0 bgsave_in_progress:0 last_save_time:1348680180 bgrewriteaof_in_progress:0 total_connections_received:1 total_commands_processed:1 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:0 vm_enabled:0 role:master db1:keys=250000,expires=0
可以看到25萬條數據已經完整恢復到了Master上。
此時，可以放心的恢復Slave的同步設置了。
redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379
OK
查看同步狀態：
redis 127.0.0.1:6379> INFO
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:13003 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 uptime_in_seconds:2652 uptime_in_days:0 lru_clock:654284 used_cpu_sys:30.01 used_cpu_user:2.12 used_cpu_sys_children:1.76 used_cpu_user_children:1.42 connected_clients:2 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33056288 used_memory_human:31.52M used_memory_rss:34766848 used_memory_peak:33064400 used_memory_peak_human:31.53M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:1 changes_since_last_save:0 bgsave_in_progress:0 last_save_time:1348719252 bgrewriteaof_in_progress:1 total_connections_received:6 total_commands_processed:250313 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:12217 vm_enabled:0 role:slave aof_current_size:17908619 aof_base_size:16787337 aof_pending_rewrite:0 aof_buffer_length:0 aof_pending_bio_fsync:0 master_host:10.6.1.143 master_port:6379 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_priority:100 db1:keys=250000,expires=0
master_link_status顯示為up，同步狀態正常。
在此次恢復的過程中，我們同時復制了AOF與RDB文件，那么到底是哪一個文件完成了數據的恢復呢？
實際上，當Redis服務器掛掉時，重啟時將按照以下優先級恢復數據到內存：
如果只配置AOF,重啟時加載AOF文件恢復數據；
如果同時 配置了RDB和AOF,啟動是只加載AOF文件恢復數據;
如果只配置RDB,啟動是將加載dump文件恢復數據。
也就是說，AOF的優先級要高于RDB，這也很好理解，因為AOF本身對數據的完整性保障要高于RDB。
在此次的案例中，我們通過在Slave上啟用了AOF與RDB來保障了數據，并恢復了Master。
但在我們目前的線上環境中，由于數據都設置有過期時間，采用AOF的方式會不太實用，過于頻繁的寫操作會使AOF文件增長到異常的龐大，大大超過了我們實際的數據量，這也會導致在進行數據恢復時耗用大量的時間。 因此，可以在Slave上僅開啟Snapshot來進行本地化，同時可以考慮將save中的頻率調高一些或者調用一個計劃任務來進行定期bgsave的快照存儲，來盡可能的保障本地化數據的完整性。
在這樣的架構下，如果僅僅是Master掛掉，Slave完整，數據恢復可達到100%。 如果Master與Slave同時掛掉的話，數據的恢復也可以達到一個可接受的程度。
到此，相信大家對“redis持久化的方式”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
