01-redis篇 两种数据储存持久化方式

目录

1. 背景:

2. 两种数据持久化方式

2.1 RDB存储机制

-> (1) 配置docker版redis 

-> (2) rdb默认开启, 配置如下 redis.conf 打开

 ->(3)安全退出的模式

->(4) save与bgsave 

 2.2 AOF持久化机制

->(1) 修改redis.conf 开启aof储存机制

 ->(2) 为什么要开启rewrite操作

 3. RDB与AOF的优缺点

3.1 RDB优缺点

-> (1) rdb优点: 

->(2) rdb 缺点: 

 3.2 AOF 优缺点

->(1)优点

->(2)缺点

---

1. 背景:

Redis是一种内存数据库，异常中断时数据可能会丢失。如果通过持久化将数据存储到磁盘，定期同步到云存储服务，那么就可以保证一些数据不丢失，进而保证数据的可靠性。

2. 两种数据持久化方式

生产环境全部开启 保证数据安全

2.1 RDB存储机制

-> (1) 配置docker版redis 

04 Docker 安装常用软件 (mysql,redis)_pingzhuyan

-> (2) rdb默认开启, 配置如下 redis.conf 打开

#例子: 60秒内 1000个key发生变化 保存 上面类同

save 900 1
save 300 10
save 60 1000

 翻译: 持久化rdb文件时出现异常  yes表示立即停止写入  no继续

# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes

翻译1:  生成快照是否需要压缩  yes: 需要增加cpu消耗  no: 不压缩 需要更大的磁盘

翻译2: crc64校验 存储/加载rdb文件时时会有10%的性能下降, 所以可以为了最大的性能取消

翻译3: 生成的快照名 

# Compress string objects using LZF when dump .rdb databases?
# By default compression is enabled as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes
 
# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes
 
# The filename where to dump the DB
dbfilename dump.rdb

 

 ->(3)安全退出的模式

   如果使用安全的关闭指令 shutdown , 数据不会丢失 完整的rdb快照

->(4) save与bgsave 

save: 阻塞式持久化

bgsave: 异步方式持久化

(redis6以后支持多线程:  --> redis 6.0之多线程，深入解读)

---

 2.2 AOF持久化机制

->(1) 修改redis.conf 开启aof储存机制

1 是否开启aof 默认no  yes开启

2 aof的文件名 默认appendonly.aof

appendonly yes
 
# The name of the append only file (default: "appendonly.aof")
 
appendfilename "appendonly.aof"

 储存方式: 默认everysec(不确定也选它)  每秒写入磁盘一次(性能平衡)

# appendfsync always #只要收到命令就写入磁盘, 性能最差(最安全)
appendfsync everysec
# appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐

 #在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。 #设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes

AOF文件大小是上次日志重写得到AOF文件大小的100%(2倍)，自启动新的日志重写过程。

 AOF文件启动新的日志重写过程最小值(64兆)，避免刚启动Reids时文件尺寸较小导致频繁的重写

no-appendfsync-on-rewrite yes
 
# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.
 
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

 ->(2) 为什么要开启rewrite操作

redis中的可以存储的数据是有限的，很多数据可能会自动过期，也可能会被用户删除或被redis用缓存清除的算法清理掉,可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，不断的膨胀导致文件很大。
AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了，但redis内存现在10万数据; 于是，基于内存中当前的10万数据构建一套最新的日志，然后到AOF文件中; 覆盖之前的老日志，从而，确保AOF日志文件不会过大，保持跟redis内存数据量一致。

---

 3. RDB与AOF的优缺点

3.1 RDB优缺点

-> (1) rdb优点: 

RDB 文件是经过压缩的二进制文件，占用空间很小，它保存了 Redis 某个时间点的数据集，很适合做冷备.
RDB 非常适用于灾难恢复,它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。
RDB 方式持久化性能较好，执行持久化时可以fork 一个子进程，由子进程处理保存工作，父进程无须执行任何磁盘 I/O 操作。

->(2) rdb 缺点: 

RDB方式在服务器故障时容易造成数据的丢失。若储存的频率太频繁，可能会对 Redis 性能产生影响。所以通常可能设置至少5分钟才保存一次快照,断电丢失5分钟数据

RDB 方式使用 fork 子进程进行数据的持久化，子进程的内存是在fork操作时父进程中数据快照的大小，如果数据快照比较大的话，fork 时开辟内存会比较耗时，同时这个fork是同步操作，所以，这个过程会导致父进程无法对外提供服务。

3.RDB持久化过程中的fork操作，可能会导致内存占用加倍，Linux系统fork 子进程采用的是 copy-on-write 的方式（写时复制，修改前先复制），在 Redis 执行 RDB 持久化期间，如果 client 写入数据很频繁，那么将增加 Redis 占用的内存，最坏情况下，内存的占用将达到原先的2倍。
 

 3.2 AOF 优缺点

->(1)优点

AOF 比 RDB更加可靠。你可以设置不同的 fsync 策略（no、everysec 和 always）。默认是 everysec，在这种配置下，redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。

AOF文件是一个基于纯追加模式的日志文件。即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机等等）， 我们也可以使用 redis-check-aof 工具也可以轻易地修复这种问题。

当 AOF文件太大时，Redis 会自动在后台进行重写。重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写是绝对安全，因为重写是在一个新的文件上进行，同时 Redis 会继续往旧的文件追加数据。当新文件重写完毕，Redis 会把新旧文件进行切换，然后开始把数据写到新文件上。

AOF 文件有序地保存了对数据库执行的所有写入操作，以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析也很轻松。如果你不小心执行了 FLUSHALL 命令把所有数据刷掉了，但只要 AOF 文件没有被重写，那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

->(2)缺点

对于相同的数据集，AOF 文件的大小一般会比 RDB 文件大。根据所使用的 fsync 策略，AOF 的速度可能会比 RDB 慢。通常 fsync 设置为每秒一次就能获得比较高的性能，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快。AOF 可能会因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。