Redis

@Author:hanguixian
@Email:hn_hanguixian@163.com

五 redis的持久化

官网介绍：https://redis.io/topics/persistence
- RDB的优势（google翻译）
  - RDB是Redis数据的一个非常紧凑的单文件时间点表示。RDB文件非常适合备份。例如，您可能希望在最近24小时内每小时归档您的RDB文件，并且每天保存RDB快照30天。这使您可以在发生灾难时轻松恢复不同版本的数据集。
  - RDB非常适合灾难恢复，可以将单个压缩文件传输到远端数据中心，也可以传输到Amazon S3（可能是加密的）。
  - RDB最大限度地提高了Redis的性能，因为Redis父进程为了坚持而需要做的唯一工作是分配一个将完成所有其余工作的孩子。父实例永远不会执行磁盘I / O或类似操作。
  - 与AOF相比，RDB允许使用大数据集更快地重启。
- RDB的缺点（google翻译）
  - 如果您需要在Redis停止工作时（例如断电后）将数据丢失的可能性降至最低，则RDB并不好。您可以配置生成RDB的不同保存点（例如，在对数据集进行至少五分钟和100次写入之后，您可以拥有多个保存点）。但是，您通常每五分钟或更长时间创建一个RDB快照，因此如果Redis因任何原因停止工作而没有正确关闭，您应该准备丢失最新的数据分钟。
  - RDB经常需要fork（）才能使用子进程持久存储在磁盘上。如果数据集很大，Fork（）可能会很耗时，如果数据集非常大且CPU性能不佳，可能会导致Redis停止服务客户端几毫秒甚至一秒钟。AOF也需要fork（），但你可以调整你想要重写日志的频率，而不需要对耐久性进行任何权衡。

1 RDB（Redis DataBase）

1.1 是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

1.2 Fork

fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

1.3 rdb的保存

rdb 保存的是dump.rdb文件
配置位置：redis.conf的SNAPSHOTTING中

1.4 如何触发RDB快照

冷拷贝后重新使用：可以cp dump.rdb dump_new.rdb
命令save或者是bgsave
- Save：save时只管保存，其它不管，全部阻塞
- BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间
执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

1.5 如何恢复

将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可
CONFIG GET dir获取目录

1.6 优势

适合大规模的数据恢复
对数据完整性和一致性要求不高

1.7 劣势

在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

1.8 如何停止

动态所有停止RDB保存规则的方法：redis-cli config set save “”

1.9 示例

[root@xxxmmm bin]# ll
total 32636
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[root@xxxmmm bin]# redis-server /hanguixian/myredis/redis.conf
7621:C 03 Dec 2018 17:56:23.248 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7621:C 03 Dec 2018 17:56:23.248 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=7621, just started
7621:C 03 Dec 2018 17:56:23.248 # Configuration loaded
[root@xxxmmm bin]# redis-cli
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5
OK
127.0.0.1:6379> set k6 v6
OK
127.0.0.1:6379> set k7 v7
OK
127.0.0.1:6379> set k8 v8
OK
127.0.0.1:6379> set k9 v9
OK
127.0.0.1:6379> set k10 v10
OK
127.0.0.1:6379> set k11 v11
OK
127.0.0.1:6379> save
OK
127.0.0.1:6379> SHUTDOWN
not connected> exit
[root@xxxmmm bin]# redis-server /hanguixian/myredis/redis.conf
7627:C 03 Dec 2018 17:58:22.816 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7627:C 03 Dec 2018 17:58:22.816 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=7627, just started
7627:C 03 Dec 2018 17:58:22.816 # Configuration loaded
[root@xxxmmm bin]# redis-cli
127.0.0.1:6379> KEYS *1) "k7"2) "k4"3) "k10"4) "k8"5) "k2"6) "k6"7) "k5"8) "k11"9) "k3"
10) "k9"
11) "k1"
127.0.0.1:6379> SHUTDOWN
not connected> exit
[root@xxxmmm bin]# ll
total 32640
-rw-r--r-- 1 root root     178 Dec  3 17:58 dump.rdb
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[root@xxxmmm bin]# cp dump.rdb dump_new.rdb
[root@xxxmmm bin]# rm dump.rdb
rm: remove regular file ‘dump.rdb’? y
[root@xxxmmm bin]# redis-server /hanguixian/myredis/redis.conf
7636:C 03 Dec 2018 17:59:15.810 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7636:C 03 Dec 2018 17:59:15.810 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=7636, just started
7636:C 03 Dec 2018 17:59:15.810 # Configuration loaded
[root@xxxmmm bin]# redis-cli
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> exit
[root@xxxmmm bin]# cp dump_new.rdb dump
dump_new.rdb  dump.rdb
[root@xxxmmm bin]# ll
total 32644
-rw-r--r-- 1 root root     178 Dec  3 17:58 dump_new.rdb
-rw-r--r-- 1 root root      92 Dec  3 17:59 dump.rdb
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[root@xxxmmm bin]# rm -f dump.rdb
[root@xxxmmm bin]# cp dump_new.rdb dump.rdb
[root@xxxmmm bin]# redis-server /hanguixian/myredis/redis.conf
7650:C 03 Dec 2018 18:00:29.051 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7650:C 03 Dec 2018 18:00:29.051 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=7650, just started
7650:C 03 Dec 2018 18:00:29.051 # Configuration loaded
[root@xxxmmm bin]# redis-cli
127.0.0.1:6379> KEYS *1) "k2"2) "k6"3) "k4"4) "k5"5) "k10"6) "k8"7) "k11"8) "k7"9) "k1"
10) "k9"
11) "k3"
127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/usr/local/bin"

2 AOF（Append Only File）

官网介绍：https://redis.io/topics/persistence
AOF优势
- 使用AOF Redis更持久：您可以使用不同的fsync策略：根本没有fsync，每秒fsync，每次查询都有fsync。使用fsync的默认策略，每秒写入性能仍然很好（fsync使用后台线程执行，主线程将在没有fsync正在进行时努力执行写入。）但是您只能丢失一秒的写入。
- AOF日志是仅附加日志，因此如果停电则没有搜索，也没有腐败问题。即使日志由于某种原因（磁盘已满或其他原因）以半写命令结束，redis-check-aof工具也能够轻松修复它。
- 当Redis太大时，Redis能够在后台自动重写AOF。重写是完全安全的，因为当Redis继续附加到旧文件时，使用创建当前数据集所需的最小操作集生成一个全新的文件，并且一旦第二个文件准备就绪，Redis将切换两个并开始附加到新的那一个。
- AOF以易于理解和解析的格式一个接一个地包含所有操作的日志。您甚至可以轻松导出AOF文件。例如，即使您使用FLUSHALL命令刷新了所有错误，如果在此期间未执行日志重写，您仍然可以保存数据集，只需停止服务器，删除最新命令，然后再次重新启动Redis。
AOF的缺点
- AOF文件通常比同一数据集的等效RDB文件大。
- 根据确切的fsync策略，AOF可能比RDB慢。通常将fsync设置为每秒性能仍然非常高，并且在禁用fsync的情况下，即使在高负载下，它也应该与RDB一样快。即使在大量写入负载的情况下，RDB仍能够提供有关最大延迟的更多保证。
- 在过去，我们遇到了特定命令中的罕见错误（例如，有一个涉及阻塞命令，如BRPOPLPUSH）导致生成的AOF在重新加载时不会重现完全相同的数据集。这个错误很少见，我们在测试套件中进行测试，自动创建随机复杂数据集并重新加载它们以检查一切是否正常，但RDB持久性几乎不可能出现这种错误。为了更清楚地说明这一点：Redis AOF逐步更新现有状态，如MySQL或MongoDB，而RDB快照一次又一次地创建所有内容，这在概念上更加健壮。
  - 1）应该注意的是，每次通过Redis重写AOF时，都会从数据集中包含的实际数据开始重新创建，与总是附加的AOF文件（或者重写旧的AOF而不是读取内存中的数据）相比，对bug的抵抗力更强。
  - 2）我们从未向用户提供过关于在现实世界中检测到的AOF损坏的单一报告。

2.1 是什么

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

2.2 AOF的保存

Aof保存的是appendonly.aof文件
配置位置：redis.conf的APPEND ONLY MODE模块

2.3 AOF启动/修复/恢复

2.3.1 正常恢复

启动：设置Yes
- 修改默认的appendonly no，改为yes
将有数据的aof文件复制一份保存到对应目录(config get dir)
恢复：重启redis然后重新加载

#前置：设置redis.conf的appendonly yes
#操作
[root@xxxmmm bin]# ps -ef|grep redis
root      8869  8563  0 15:34 pts/2    00:00:00 grep --color=auto redis
[root@xxxmmm bin]# rm -f dump.rdb
[root@xxxmmm bin]# rm -f dump_new.rdb
[root@xxxmmm bin]# ll
total 32636
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[root@xxxmmm bin]# redis-server /hanguixian/myredis/redis_aof.conf
8874:C 04 Dec 2018 15:35:28.588 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8874:C 04 Dec 2018 15:35:28.588 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=8874, just started
8874:C 04 Dec 2018 15:35:28.588 # Configuration loaded
[root@xxxmmm bin]# ll
total 32636
-rw-r--r-- 1 root root       0 Dec  4 15:35 appendonly.aof
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[root@xxxmmm bin]# vim appendonly.aof
[root@xxxmmm bin]# redis-cli
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set k1 v2
OK
127.0.0.1:6379> set k2 22
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> SHUTDOWN
not connected> exit
[root@xxxmmm bin]# cp appendonly.aof appendonly_bk.aof
[root@xxxmmm bin]# ll
total 32648
-rw-r--r-- 1 root root     139 Dec  4 15:36 appendonly.aof
-rw-r--r-- 1 root root     139 Dec  4 15:39 appendonly_bk.aof
-rw-r--r-- 1 root root     124 Dec  4 15:36 dump.rdb
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[root@xxxmmm bin]# rm -f appendonly.aof
[root@xxxmmm bin]# rm -f dump.rdb
[root@xxxmmm bin]# ps -ef|grep redis
root      8895  8563  0 15:40 pts/2    00:00:00 grep --color=auto redis
[root@xxxmmm bin]# redis-server /hanguixian/myredis/redis_aof.conf
8896:C 04 Dec 2018 15:40:40.025 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8896:C 04 Dec 2018 15:40:40.025 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=8896, just started
8896:C 04 Dec 2018 15:40:40.025 # Configuration loaded
[root@xxxmmm bin]# redis-cli
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> EXIT
[root@xxxmmm bin]# cp appendonly_bk.aof appendonly.aof
cp: overwrite ‘appendonly.aof’? y
[root@xxxmmm bin]# redis-server /hanguixian/myredis/redis_aof.conf
8903:C 04 Dec 2018 15:41:50.717 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8903:C 04 Dec 2018 15:41:50.717 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=8903, just started
8903:C 04 Dec 2018 15:41:50.717 # Configuration loaded
[root@xxxmmm bin]# redis-cli
127.0.0.1:6379> keys *
1) "k1"
2) "k3"
3) "k2"
4) "k4"

2.3.2 异常恢复

启动：设置Yes
- 修改默认的appendonly no，改为yes
备份被写坏的AOF文件
修复：redis-check-aof --fix进行修复
恢复：重启redis然后重新加载

#当发生异常，appendonly.aof 损坏，模拟：人为的在后面添加乱七八糟的东西
*2
$6
SELECT
$1
0
*3
$3
set
$2
k1
$2
v2
*3
$3
set
$2
k2
$2
22
*3
$3
set
$2
k3
$2
v3
*3
$3
set
$2
k4
$2
v4
sdjkfkhsfsd oipj er3r4r asod /psdcfg s
odwe s ogy70d rhesdb dfg es; hp g7es lhse rghe rkh irjhs eriokg

appendonly.aof 损坏，redis启动失败，同时可以看出dump.rdb，appendonly.aof同时存在的情况下，appendonly.aof优先

[root@xxxmmm bin]# ps -ef|grep redis
root      8916  8563  0 15:54 pts/2    00:00:00 grep --color=auto redis
[root@xxxmmm bin]# ll
total 32648
-rw-r--r-- 1 root root     139 Dec  4 15:41 appendonly.aof
-rw-r--r-- 1 root root     139 Dec  4 15:39 appendonly_bk.aof
-rw-r--r-- 1 root root     124 Dec  4 15:54 dump.rdb
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[root@xxxmmm bin]# vim appendonly.aof
[root@xxxmmm bin]# redis-server /hanguixian/myredis/redis_aof.conf
8919:C 04 Dec 2018 15:55:52.439 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8919:C 04 Dec 2018 15:55:52.439 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=8919, just started
8919:C 04 Dec 2018 15:55:52.439 # Configuration loaded
[root@xxxmmm bin]# redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> exit

appendonly.aof修复

[root@xxxmmm bin]# ps -ef|grep redis
root      8916  8563  0 15:54 pts/2    00:00:00 grep --color=auto redis
[root@xxxmmm bin]# ll
total 32648
-rw-r--r-- 1 root root     139 Dec  4 15:41 appendonly.aof
-rw-r--r-- 1 root root     139 Dec  4 15:39 appendonly_bk.aof
-rw-r--r-- 1 root root     124 Dec  4 15:54 dump.rdb
-rwxr-xr-x 1 root root 4365264 Nov 26 21:52 redis-benchmark
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-aof
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-check-rdb
-rwxr-xr-x 1 root root 4782296 Nov 26 21:52 redis-cli
lrwxrwxrwx 1 root root      12 Nov 26 21:52 redis-sentinel -> redis-server
-rwxr-xr-x 1 root root 8086264 Nov 26 21:52 redis-server
[root@xxxmmm bin]# redis-server /hanguixian/myredis/redis_aof.conf
8919:C 04 Dec 2018 15:55:52.439 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8919:C 04 Dec 2018 15:55:52.439 # Redis version=5.0.0, bits=64, commit=00000000, modified=0, pid=8919, just started
8919:C 04 Dec 2018 15:55:52.439 # Configuration loaded
[root@xxxmmm bin]# redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> exit
[root@xxxmmm bin]# vim appendonly.aof
[root@xxxmmm bin]# redis-check-aof --fix appendonly.aof
0x              8b: Expected prefix '*', got: 's'
AOF analyzed: size=244, ok_up_to=139, diff=105
This will shrink the AOF from 244 bytes, with 105 bytes, to 139 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@xxxmmm bin]# vim appendonly.aof

修复后的appendonly.aof

*2
$6
SELECT
$1
0
*3
$3
set
$2
k1
$2
v2
*3
$3
set
$2
k2
$2
22
*3
$3
set
$2
k3
$2
v3
*3
$3
set
$2
k4
$2
v4

2.4 rewite 重写

2.4.1 是什么

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

2.4.2 重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

2.4.3 触发机制

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

2.5 优势和劣势

优势
- 每修改同步：appendfsync always 同步持久化每次发生数据变更会被立即记录到磁盘性能较差但数据完整性比较好
- 每秒同步：appendfsync everysec 异步操作，每秒记录如果一秒内宕机，有数据丢失
- 不同步：appendfsync no 从不同步
劣势
- 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
- aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

3 小总结

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
同时开启两种持久化方式
- 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
- RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
性能建议
- 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只留save 900 1这条规则。
- 如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
- 如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构

Redis 5. redis的持久化相关推荐

redis 数据结构内存管理持久化
为什么80%的码农都做不了架构师?>>> Redis 内存数据结构与编码 OBJECT encoding key.DEBUG OBJECT key 简单动态字符串(simple ...
【带你重拾Redis】Redis持久化
Redis持久化 Redis有2种持久化策略: RDB和AOF. RDB(Redis Data Base) RDB是Redis默认的持久化策略,这种策略是把数据库的快照以二进制形式的副本保存在磁盘上. ...
Redis进阶-Redis持久化原理
文章目录 Pre 快照原理 fork( 多进程) AOF 原理 AOF 重写 fsync 运维 Redis 4.0 混合持久化 Pre Redis-16Redis备份(持久化) Redis 的数据全部 ...
Redis的两种持久化机制RDB和AOF
目录 RDB 原理触发时机 AOF 原理开启AOF aof日志文件说明触发时机 aof的重写机制 redis4.0的混合持久化机制总结 rdb持久化文件的名称:dump.rdb.存储在配置文件 ...
redis 硬件要求_Redis持久化机制
介绍 Redis所有的数据都保存在内存中,数据的更新将异步的保存到硬盘上,当需要恢复数据时,从硬盘上将数据再读取到内存中,这就是Redis的持久化过程.主流的持久化方式有两种: 快照:MySQL的Du ...
Redis数据库（二）——Redis高可用、持久化及性能管理
Redis数据库(二)--Redis高可用.持久化及性能管理一.Redis 高可用主要的高可用技术二.Redis 持久化 1.持久化的功能 2.两种持久化方式 3.RDB 和 AOF 的区别 ① ...
Redis面试 - Redis的持久化机制
Redis面试 - Redis的持久化机制面试题 redis 的持久化有哪几种方式?不同的持久化机制都有什么优缺点?持久化机制具体底层是如何实现的? 面试官心理分析 redis 如果仅仅只是将数据缓 ...
redis内存淘汰和持久化_REDIS的淘汰机制与持久化
1. 理解淘汰机制 1.1. 内存回收策略 Redis内存回收机制主要体现在以下两个方面: 1. 删除到达时间的键对象. 2. 内存使用达到maxmemory上限时触发内存溢出控制策略. 1.1.1. ...
redis系列-redis的持久化
redis对数据的持久化有两种方式:RDB(快照保存)和AOF(命令日志). RDB 介绍:将内存快照保存到磁盘,dump.rdb二进制文件触发:满足"N 秒内数据集至少有 M 个改动&q ...
Redis 中两种持久化机制详解
Redis 持久化机制(快照.AOF) 快照 (Snapshot) 1. 客户端方式之 BGSAVE(多线程执行) 2. 客户端方式之 SAVE(单线程执行) 3. 服务器配置方式之配置快照触发条件 ...

Redis 5. redis的持久化

Redis

五 redis的持久化

1 RDB（Redis DataBase）

1.1 是什么

1.2 Fork

1.3 rdb的保存

1.4 如何触发RDB快照

1.5 如何恢复

1.6 优势

1.7 劣势

1.8 如何停止

1.9 示例

2 AOF（Append Only File）

2.1 是什么

2.2 AOF的保存

2.3 AOF启动/修复/恢复

2.3.1 正常恢复

2.3.2 异常恢复

2.4 rewite 重写

2.4.1 是什么

2.4.2 重写原理

2.4.3 触发机制

2.5 优势和劣势

3 小总结

Redis 5. redis的持久化相关推荐

最新文章

热门文章