一，reids 数据持久化的三种方式：

Redis 是一个缓存中间件，它的最大特点是使用内存从而使其性能强悍。但是使用内存的方式有一个致命的特点就是数据没办法持久化保存。




Redis 持久化存储有三种持久化方案：

1,RDB（将内存中的数据进行快照存储到磁盘）
  

2,AOF（回放的命令日志记录 redis 内的所有操作）


3,RDB+AOF（推荐，redis4之后支持）

二，三种方式详解

1，RDB

RDB(Redis DataBase)，将 Redis 内存中的数据进行 Snaptshot 快照存储在磁盘内

方式一：
修改配置达到持久化

在 redis.conf 中配置，会以一段时间内有指定次数据（可自定义一下出发时间及次数）

# save 3600 1                一个小时有一个key变化
# save 300 100               5分钟有100个key变化
# save 60 10000              1分钟有10000个key变化

修改的规则触发快照动作，快照文件名为 dump.rdb；
该文件默认使用 LZF 压缩算法 ；每当 Redis 服务重启的时候会从该文件中加载数据进内存。





方式二;
手动触发
[root@\ redis~]# vim /usr/local/redis/etc/redis6380.conf 
... ...
dir /usr/local/redis/data   # 设置触发后保存放数据的目录
... ...

[root@\ redis~]# redis-cli -p 6380
127.0.0.1:6380> set ab bb
OK
127.0.0.1:6380> set name zxx
OK
127.0.0.1:6380> bgsave
Background saving started



#bgsave之前
[root@\ redis~]# cat /usr/local/redis/data/dump.rdb 
REDIS0009   redis-ver6.2.1
redis-bits󿿀򳨭e aused-memÀN񤯬-stream-dbzrepl-id(ff8440c053ad17a25f57172aa4daa37163692126
                                                                                       񤯬-offsetz
   
#bgsave之后                                                                                             aof-preamblem:¥Mtۥ
[root@\ redis~]# cat /usr/local/redis/data/dump.rdb 
REDIS0009   redis-ver6.2.1
redis-bits󿿀򳨭e.aused-memà 񤯬-stream-dbzrepl-id(ff8440c053ad17a25f57172aa4daa37163692126
                                                                                     񤯬-offset�
                                                                                              𮤭preamble~㭡mezxxabbbÿ;6ǀ!





使用save或者bgsave（推荐）
flushdb 命令，会把之前的快照更新成当前的空状态，执行了 flushdb 后更新的快照是没有数据的。


PS:
两者底层原理相同，调用的rdbsave函数
save使用其父进程进行触发，客户端无法访问，会导致阻塞；
bgsave会新开一个子进程，不影响客户端访问
#两者不允许同时进行，避免出现竞争导致rdb数据不准确





停止备份：
在配置文件中就设置 save “”或在命令行中 config






RDB缺点：
  1，可能会存在数据丢失（比如设置的一分钟，数据集100次写；如果停电，在这一分钟的数据就可能会丢失）

  2,需要经常调用fork子进程持久化到硬盘，如果数据量大的话，耗时，cpu性能不好 Redis 会停止服务几毫秒或者几秒


RDB优点：
  速度快，适合于用作备份，主从复制也是基于 RDB 持久化功能实现的。




配置详解：

dbfilename dump.rdb
#rdb 持久化存储数据库文件名，默认为 dump.rdb

stop-write-on-bgsave-error yes
#yes 代表当使用 bgsave 命令持久化出错时候停止写 RDB 快照文件,no 表明忽略错误继续写文件。

rdbchecksum yes
#在写入文件和读取文件时是否开启 rdb 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。

dir "/etc/redis"
#数据文件存放目录，rdb 快照文件和 aof 文件都会存放至该目录，请确保有写权限

rdbcompression yes
#是否开启 RDB 文件压缩，该功能可以节约磁盘

2，AOF

AOF(Append-Only File);记录 Redis 中每次的写命令，服务重启时会重新执行 AOF中的命令将数据恢复到内存中

1、自动触发

修改配置文件：appendonly yes


2、AOF持久化策略

always：每个命令都记录
everysec ： 每秒钟记录一次（推荐使用）
on : 根据系统性能记录



3、AOF重写

AOF重写 : 有可能执行的写操作有可能时存在重复或者无用的，像这些数据可以不记录到AOF，解决这个问题就叫做-----AOF重写。


127.0.0.1:6380> keys *
(empty array)
127.0.0.1:6380> set a b
OK
127.0.0.1:6380> set a c
OK
127.0.0.1:6380> del a
(integer) 1




# 以上keys其实啥也没，但是文件中都有记录
[root@\ redis/usr/local/redis]# cat /usr/local/redis/data/appendonly.aof 
set
$1
a
$1
b
*3
$3
set
$1
a
$1
c
*2
$3
del
$1
a



127.0.0.1:6380> BGREWRITEAOF
Background append only file rewriting started



[root@\ redis/usr/local/redis]# cat /usr/local/redis/data/appendonly.aof 
REDIS0009   redis-ver6.2.1
redis-bits󿿀򳨭used-memHP







4、触发重写机制（可自定义）

64M 第一次触发重写
128M 触发第二次重写

256M 触发第三次重写
512M 触发第四次重写

1. aof_current_size > auto-aof-rewrite-min-size 
2. (aof_current_size - aof_base_size) / aof_base_size > auto-aof-rewrite-percentage
   例如上次触发的文件大小为64g；现在的文件大小是130g；按照以上公式，（128-64）/64是否大于100%；大于则条件成立，触发重写

注：必须触发了重写才能够在appendonly.aof文件中保存rdb数据。









#aof 文件大小比起上次重写时的大小,增长 100%(配置可以大于 100%)时,触发重写。[假如上次重写后大小为
10MB，当 AOF 文件达到 20MB 时也会再次触发重写，以此类推]
auto-aof-rewrite-percentage 100

#aof 文件大小超过 64MB 时,触发重写
auto-aof-rewrite-min-size 64mb

#是否在后台写时同步单写，默认值 no(表示需要同步)
no-appendfsync-on-rewrite no

# 指 redis 在恢复时，会忽略最后一条可能存在问题的指令。默认值 yes。即在 aof 写入时，可能存在指令写
错的问题(突然断电，写了一半)，这种情况下，yes 会 log 并继续，而 no 会直接恢复失败.
aof-load-truncated

3RDB + AOF

#默认开启
[root@\ redis/usr/local/redis]# vim /usr/local/redis/etc/redis6380.conf
aof-use-rdb-preamble yes

会在每次BGSAVE之后以RDB形式存储


示例：
127.0.0.1:6380> keys *
(empty array)
127.0.0.1:6380> set a b
OK
127.0.0.1:6380> set name egon
OK
127.0.0.1:6380>  set age 18
OK

# 可以查看到aof记录的命令
[root@\ redis/usr/local/redis]cat /usr/local/redis/data/appendonly.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$1
a
$1
b
*3
$3
set
$4
name
$4
egon
*3
$3
set
$3
age
$2
18


# 手动触发
127.0.0.1:6380> bgsave
Background saving started


# 查看DOF保存的数据（二级制）
[root@\ redis/usr/local/redis]# cat /usr/local/redis/data/dump.rdb 
REDIS0009   redis-ver6.2.1
redis-bits󿿀򳨭eâcused-memÐP



# 触发重写
127.0.0.1:6380> BGREWRITEAOF
Background append only file rewriting started
127.0.0.1:6380> set aaa bbb
OK


#可以看到aof存放的命令，BGREWRITEAOF之前是二进制，之后记录的还是命令
[root@\ redis/usr/local/redis]# cat /usr/local/redis/data/appendonly.aof 
REDIS0009   redis-ver6.2.1
redis-bits󿿀򳨭eÔcused-memhQ
𮤭preamble󿾁þ🀢xxxyyynameegonage󿾒abcdÿΗþЭ¥3©*2
$6
SELECT
$1
0
*3
$3
set
$3
aaa
$3
bbb


混合优势：
用 RDB 持久化会有数据丢失的风险，但是恢复速度快，
而使用 AOF 持久化可以保证数据完整性，但恢复数据的时候会很慢。
于是从 Redis4 之后新增了混合 AOF和 RDB 的模式，先使用 RDB 进行快照存储，然后使用 AOF 持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的 RDB 记录。这样的话，重启服务的时候会从 RDB 何 AOF 两部分恢复数据，即保证了数据完整性，又提高了恢复的性能。
开启混合模式后，每当 bgrewriteaof 命令之后会在 AOF 文件中以 RDB 格式写入当前最新的数据，之后的新的写操作继续以 AOF 的追加形式追加写命令。当 redis 重启的时候，加载 aof 文件进行恢复数据：先加载 rdb的部分再加载剩余的 aof 部分。

Redis雪崩 与 Redis击穿

Redis雪崩：同一时间或短时间内，大量的Redis数据过期，导致大量的请求在Redis当中获取不到相关数据，间接性造成整体架构运行速度缓慢。


Redis击穿：短时间内有大量的随机请求在redis中获取不到数据，间接性造成整体架构运行速度缓慢。



大key：
key的字段过长，没有设置过期时间，一直积累多个这种大key，
会导致命中率低，比如set a b，第一次get 啊得不到结果，第二次再get ，会得出b；
设置一个时间点，设置过期时间