redis持久化的方式

本篇內(nèi)容主要講解“redis持久化的方式”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“redis持久化的方式”吧!

創(chuàng)新互聯(lián)建站主打移動網(wǎng)站、成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、網(wǎng)站改版、網(wǎng)絡(luò)推廣、網(wǎng)站維護、域名注冊、等互聯(lián)網(wǎng)信息服務(wù)，為各行業(yè)提供服務(wù)。在技術(shù)實力的保障下，我們?yōu)榭蛻舫兄Z穩(wěn)定，放心的服務(wù)，根據(jù)網(wǎng)站的內(nèi)容與功能再決定采用什么樣的設(shè)計。最后，要實現(xiàn)符合網(wǎng)站需求的內(nèi)容、功能與設(shè)計，我們還會規(guī)劃穩(wěn)定安全的技術(shù)方案做保障。

介紹

首先，我們應(yīng)該明確持久化的數(shù)據(jù)有什么用，答案是用于重啟后的數(shù)據(jù)恢復(fù)。
Redis是一個內(nèi)存數(shù)據(jù)庫，無論是RDB還是AOF，都只是其保證數(shù)據(jù)恢復(fù)的措施。
所以Redis在利用RDB和AOF進行恢復(fù)的時候，都會讀取RDB或AOF文件，重新加載到內(nèi)存中。

Redis持久化的方式

RDB
AOF

RDB

RDB就是Snapshot快照存儲，是默認的持久化方式。可理解為半持久化模式，即按照一定的策略周期性的將數(shù)據(jù)保存到磁盤。對應(yīng)產(chǎn)生的數(shù)據(jù)文件為dump.rdb，通過配置文件中的save參數(shù)來定義快照的周期。
下面是默認的快照設(shè)置：

save 900 1 #當(dāng)有一條Keys數(shù)據(jù)被改變時，900秒刷新到Disk一次
save 300 10 #當(dāng)有10條Keys數(shù)據(jù)被改變時，300秒刷新到Disk一次
save 60 10000#當(dāng)有10000條Keys數(shù)據(jù)被改變時，60秒刷新到Disk一次

Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的。當(dāng)生成一個新的RDB文件時，Redis生成的子進程會先將數(shù)據(jù)寫到一個臨時文件中，然后通過原子性rename系統(tǒng)調(diào)用將臨時文件重命名為RDB文件。這樣在任何時候出現(xiàn)故障，Redis的RDB文件都總是可用的。同時，Redis的RDB文件也是Redis主從同步內(nèi)部實現(xiàn)中的一環(huán)。

第一次Slave向Master同步的實現(xiàn)是： * Slave向Master發(fā)出同步請求，Master先dump出rdb文件，然后將rdb文件全量傳輸給slave，然后Master把緩存的命令轉(zhuǎn)發(fā)給Slave，初次同步完成。

第二次以及以后的同步實現(xiàn)是： * Master將變量的快照直接實時依次發(fā)送給各個Slave。但不管什么原因?qū)е耂lave和Master斷開重連都會重復(fù)以上兩個步驟的過程。

Redis的主從復(fù)制是建立在內(nèi)存快照的持久化基礎(chǔ)上的，只要有Slave就一定會有內(nèi)存快照發(fā)生。

可以很明顯的看到，RDB有它的不足，就是一旦數(shù)據(jù)庫出現(xiàn)問題，那么我們的RDB文件中保存的數(shù)據(jù)并不是全新的。

從上次RDB文件生成到Redis停機這段時間的數(shù)據(jù)全部丟掉了。

AOF

AOF(Append-Only File)比RDB方式有更好的持久化性。

由于在使用AOF持久化方式時，Redis會將每一個收到的寫命令都通過Write函數(shù)追加到文件中，類似于MySQL的binlog。

當(dāng)Redis重啟是會通過重新執(zhí)行文件中保存的寫命令來在內(nèi)存中重建整個數(shù)據(jù)庫的內(nèi)容。

對應(yīng)的設(shè)置參數(shù)為： $ 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的完全持久化方式同時也帶來了另一個問題，持久化文件會變得越來越大。

比如我們調(diào)用INCR test命令100次，文件中就必須保存全部的100條命令，但其實99條都是多余的。

因為要恢復(fù)數(shù)據(jù)庫的狀態(tài)其實文件中保存一條SET test 100就夠了。

為了壓縮AOF的持久化文件，Redis提供了bgrewriteaof命令。

收到此命令后Redis將使用與快照類似的方式將內(nèi)存中的數(shù)據(jù)以命令的方式保存到臨時文件中，最后替換原來的文件，以此來實現(xiàn)控制AOF文件的增長。

由于是模擬快照的過程，因此在重寫AOF文件時并沒有讀取舊的AOF文件，而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的AOF文件。

對應(yīng)的設(shè)置參數(shù)為: $ vim /opt/redis/etc/redis_6379.conf

no-appendfsync-on-rewrite yes

在日志重寫時，不進行命令追加操作，而只是將其放在緩沖區(qū)里，避免與命令的追加造成DISK IO上的沖突。 auto-aof-rewrite-percentage 100

當(dāng)前AOF文件大小是上次日志重寫得到AOF文件大小的二倍時，自動啟動新的日志重寫過程。 auto-aof-rewrite-min-size 64mb #當(dāng)前AOF文件啟動新的日志重寫過程的最小值，避免剛剛啟動Reids時由于文件尺寸較小導(dǎo)致頻繁的重寫。

選擇

到底選擇什么呢？下面是來自官方的建議：

通常，如果你要想提供很高的數(shù)據(jù)保障性，那么建議你同時使用兩種持久化方式。如果你可以接受災(zāi)難帶來的幾分鐘的數(shù)據(jù)丟失，那么你可以僅使用RDB。很多用戶僅使用了AOF，但是我們建議，既然RDB可以時不時的給數(shù)據(jù)做個完整的快照，并且提供更快的重啟，所以最好還是也使用RDB。因此，我們希望可以在未來（長遠計劃）統(tǒng)一AOF和RDB成一種持久化模式。

在數(shù)據(jù)恢復(fù)方面

RDB的啟動時間會更短，原因有兩個：

是RDB文件中每一條數(shù)據(jù)只有一條記錄，不會像AOF日志那樣可能有一條數(shù)據(jù)的多次操作記錄。所以每條數(shù)據(jù)只需要寫一次就行了。另一個原因是RDB文件的存儲格式和Redis數(shù)據(jù)在內(nèi)存中的編碼格式是一致的，不需要再進行數(shù)據(jù)編碼工作，所以在CPU消耗上要遠小于AOF日志的加載。
災(zāi)難恢復(fù)模擬既然持久化的數(shù)據(jù)的作用是用于重啟后的數(shù)據(jù)恢復(fù)，那么我們就非常有必要進行一次這樣的災(zāi)難恢復(fù)模擬了。據(jù)稱如果數(shù)據(jù)要做持久化又想保證穩(wěn)定性，則建議留空一半的物理內(nèi)存。因為在進行快照的時候，fork出來進行dump操作的子進程會占用與父進程一樣的內(nèi)存，真正的copy-on-write，對性能的影響和內(nèi)存的耗用都是比較大的。目前，通常的設(shè)計思路是利用Replication機制來彌補aof、snapshot性能上的不足，達到了數(shù)據(jù)可持久化。

即Master上Snapshot和AOF都不做，來保證Master的讀寫性能，而Slave上則同時開啟Snapshot和AOF來進行持久化，保證數(shù)據(jù)的安全性。

首先，修改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參數(shù)

redis 127.0.0.1:6379> CONFIG GET save

"save"
""

然后通過以下腳本在Master中生成25萬條數(shù)據(jù)：

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

在數(shù)據(jù)的生成過程中，可以很清楚的看到Master上僅在第一次做Slave同步時創(chuàng)建了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

等待數(shù)據(jù)插入完成以后，首先確認當(dāng)前的數(shù)據(jù)量。

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

當(dāng)前的數(shù)據(jù)量為25萬條key，占用內(nèi)存31.52M。

然后我們直接Kill掉Master的Redis進程，模擬災(zāi)難。

dongguo@redis:/opt/redis/data/6379$ sudo killall -9 redis-server

我們到Slave中查看狀態(tài)：

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的狀態(tài)已經(jīng)是down了，Master已經(jīng)不可訪問了。

而此時，Slave依然運行良好，并且保留有AOF與RDB文件。

下面我們將通過Slave上保存好的AOF與RDB文件來恢復(fù)Master上的數(shù)據(jù)。

首先，將Slave上的同步狀態(tài)取消，避免主庫在未完成數(shù)據(jù)恢復(fù)前就重啟，進而直接覆蓋掉從庫上的數(shù)據(jù)，導(dǎo)致所有的數(shù)據(jù)丟失。

redis 127.0.0.1:6379> SLAVEOF NO ONE

確認一下已經(jīng)沒有了master相關(guān)的配置信息：

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上復(fù)制數(shù)據(jù)文件：

dongguo@redis-slave:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *

appendonly.aof

dump.rdb

將data.tar上傳到Master上，嘗試恢復(fù)數(shù)據(jù):

可以看到Master目錄下有一個初始化Slave的數(shù)據(jù)文件，很小，將其刪除。

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

然后解壓縮數(shù)據(jù)文件：

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...

查看數(shù)據(jù)是否恢復(fù)：

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萬條數(shù)據(jù)已經(jīng)完整恢復(fù)到了Master上。

此時，可以放心的恢復(fù)Slave的同步設(shè)置了。

redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379

查看同步狀態(tài)：

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，同步狀態(tài)正常。

在此次恢復(fù)的過程中，我們同時復(fù)制了AOF與RDB文件，那么到底是哪一個文件完成了數(shù)據(jù)的恢復(fù)呢？

實際上，當(dāng)Redis服務(wù)器掛掉時，重啟時將按照以下優(yōu)先級恢復(fù)數(shù)據(jù)到內(nèi)存：

如果只配置AOF,重啟時加載AOF文件恢復(fù)數(shù)據(jù)；
如果同時配置了RDB和AOF,啟動是只加載AOF文件恢復(fù)數(shù)據(jù);
如果只配置RDB,啟動是將加載dump文件恢復(fù)數(shù)據(jù)。

也就是說，AOF的優(yōu)先級要高于RDB，這也很好理解，因為AOF本身對數(shù)據(jù)的完整性保障要高于RDB。

在此次的案例中，我們通過在Slave上啟用了AOF與RDB來保障了數(shù)據(jù)，并恢復(fù)了Master。

但在我們目前的線上環(huán)境中，由于數(shù)據(jù)都設(shè)置有過期時間，采用AOF的方式會不太實用，過于頻繁的寫操作會使AOF文件增長到異常的龐大，大大超過了我們實際的數(shù)據(jù)量，這也會導(dǎo)致在進行數(shù)據(jù)恢復(fù)時耗用大量的時間。因此，可以在Slave上僅開啟Snapshot來進行本地化，同時可以考慮將save中的頻率調(diào)高一些或者調(diào)用一個計劃任務(wù)來進行定期bgsave的快照存儲，來盡可能的保障本地化數(shù)據(jù)的完整性。

在這樣的架構(gòu)下，如果僅僅是Master掛掉，Slave完整，數(shù)據(jù)恢復(fù)可達到100%。如果Master與Slave同時掛掉的話，數(shù)據(jù)的恢復(fù)也可以達到一個可接受的程度。

到此，相信大家對“redis持久化的方式”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

新聞標題：redis持久化的方式
網(wǎng)頁路徑：http://muchs.cn/article40/jojpeo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、品牌網(wǎng)站制作、動態(tài)網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站策劃、ChatGPT

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容