关于redis:redis学习-redis-持久化

redis 学习 – redis 长久化

无论面试和工作，长久化都是重点。

个别状况下,redis 占用内存超过 20GB 以上的时候，必须思考主从多 redis 实例进行数据同步和备份保障可用性。

rbd 保留的文件都是 dump.rdb，都是配置文件当中的快照配置进行生成的。个别业务状况只须要用 rdb 即可。

aof 默认是不开启的，因为 aof 非常容易产生大文件，尽管官网提供重写然而在文件体积过大的时候还是容易造成阻塞，审慎思考应用

rbd 和 aof 在大数据量别离有各种不同状况的零碎性能影响，具体应用何种解决策略须要依据系统资源以及业务的理论状况决定。

数据设计影响长久化：

https://szthanatos.github.io/…

为什么要长久化？

1. 重用数据
2. 避免系统故障备份重要数据

长久化的形式

1. RDB 快照：将某一个时刻的所有数据写入到磁盘
2. AOF（append-only file）：将所有的命令写入到此判断。

默认状况：RDB，AOF 须要手动开启

redis.conf 长久化配置阐明

在 redis.conf 文件当中，存在如下的选项：

redis.conf当中 RDB 的相干配置

# 是否开启 rdb 压缩 默认开启
rdbcompression yes
#代表 900 秒内有一次写入操作，就记录到 rdb
save 900 1
# rdb 的备份文件名称
dbfilename dump.rdb
# 示意备份文件寄存地位
dir ./

redis.conf当中 AOF 的相干配置

# 是否开启 aof，默认是敞开的
appendonly no
#aof 的文件名称
appendfilename "appendonly.aof"
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
appendfsync everysec
# 在进行 rewrite 的时候不开启 fsync，即不写入缓冲区，间接写入磁盘，这样会造成 IO 阻塞，然而最为平安，如果为 yes 示意写入缓冲区，写入的适宜 redis 宕机会造成数据长久化问题(在 linux 的操作系统的默认设置下，最多会失落 30s 的数据)
no-appendfsync-on-rewrite no
# 上面两个参数要配合应用，代表当 redis 内容大于 64m 同时扩容超过 100% 的时候会执行 bgrewrite，进行长久化
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB

创立 rdb 快照的几种形式：

1. 客户端向 redis 发送 bgsave 的命令（留神 windows 不反对 bgsave），此时 reids 调用 fork 创立子过程，父过程持续解决，子过程将快照写入磁盘，父过程持续解决申请。
2. 客户端发送 save 命令创立快照。留神这种形式会 阻塞 整个父过程。很少应用，非凡状况才应用。
3. redis 通过 shutdown 命令敞开服务器申请的时候，此时 redis 会停下所有工作执行一次 save，阻塞所有客户端不再执行任何命令并且进行磁盘写入，写入实现敞开服务器。
4. redis 集群的时候，会发送 sync 命令进行一次复制操作，如果主服务器 没有执行 或者 刚刚执行完bgsave，则会进行 bgsave。
5. 执行flushall 命令

RDB 快照的一些留神点:

1. 只应用 rdb 的时候，如果创立快照的时候 redis 解体，redis 会留存上一次备份快照，然而具体失落多少数据由备份工夫查看
2. 只实用一些能够容忍肯定数据失落的零碎，否则须要思考 aof 长久化

3. 在大数据量的场景下，特地是内存达到 20GB 以上的适宜，一次同步大概要 4 - 6 秒

   1. 一种形式是用手动同步，在凌晨的适宜进行手动阻塞同步，比 BGSAVE 快一些

一种解决办法：

通过日志记录来复原中断的日志，来进行数据的复原

如何通过批改配置来取得想要的长久化？

1. 批改 save 参数，尽量在开发环境模拟线上环境设置 save，过于频繁造成资源节约，过于稀少有可能失落大量数据
2. 日志进行聚合计算，依照 save 进行计算最多会失落多少工夫的数据，判断容忍性，比方一小时能够设置 save 3600 1

RDB 的优缺点比照：

长处：

1. 适宜大规模的数据恢复
2. 如果数据不小心误删，能够及时复原
3. 复原速度个别状况下快于 aof

毛病：

1. 须要肯定的工夫距离，如果 redis 意外宕机，最初一次批改的数据就没有了，具体失落多少数据须要看长久化策略
2. fork 过程的时候，会占用肯定的内存空间，如果 fork 的内存过于宏大，可能导致秒级别的复原工夫
3. 数据文件通过 redis 压缩，可读性较差

AOF（append only fail）

其实就是把咱们的命令一条条记录下来，相似 linux 的history

默认是不开启的，须要手动开启，开启之后须要重启

如果 aof 文件错位了，能够用redis-check-aof 进行文件修复

文件同步：写入文件的时候，会产生三件事：

1. file.write() 办法将文件存储到缓冲区
2. file.flush() 将缓冲区的内容写入到硬盘
3. sync 文件同步，阻塞直到写入硬盘为止

AOC 的同步策略

剖析：

1. 第一种对于固态的硬盘的挫伤比拟大，咱们都晓得固态的擦写次数的寿命是远远小于机械硬盘的，频繁的 io 是容易对固态造成坑骗认为一次擦写，导致本就寿命不长的固态变得更命短，根本不必，非凡状况下有可能用失去
2. 第二种是默认的形式，也是举荐以及比拟实用的形式，最多只会失落一秒的数据，这种形式比拟好的保证数据的备份可用，举荐应用
3. 第三种对于 CPU 的压力是最小的，因为由零碎决定，然而须要思考能不能承受不定量的数据失落，还有一个起因是硬盘将缓冲区刷新到硬盘不定时，所以 不倡议应用

重写和压缩 AOF 文件：

因为 1 秒一次同步在一直写入之后造成文件内容越来越大，同时同步速度也会变慢，为了解决这个问题，redis 引入了 bgrewriteaof 命令来进行压缩，和 bgsave 创立快照相似，同样会有子过程拖垮的问题，同时会有大文件在重写的时候带来微小的文件系统删除的压力，导致系统阻塞。

命令如下

bgrewriteaof

示例如下：

127.0.0.1:16379> BGREWRITEAOF
Background append only file rewriting started

参数管制：

auto-aof-rewrite-percentage：100

auto-aof-rewrite-min-size：64MB

这里案例配置代表当 AOF 大于 64 并且扩充了 100% 将处罚 bgrewrite 命令

redis aof 的 rewrite 做了那些事？

1. 对于一些冗余的命令进行革除
2. 检测存在谬误的命令，将谬误命令上面的所有命令都进行清理，个别状况是开端因为宕机没有执行完的一些命令清理。

aof 的优缺点比照

长处：

1. 从不同步，效率高
2. 每秒同步一次，可能失落一秒数据
3. 每次批改都同步，文件完整性好

毛病：

1. 绝对于数据文件来说，aof 远远大于 rdb。修复速度慢一些
2. 存在未知的 bug，比方如果重写 aof 文件的时候忽然中断，会有很多奇怪的景象

如何查看 redis 的性能瓶颈：

1. redis-benchmark 官网举荐的性能测试工具，十分弱小，具体的地址为：https://www.runoob.com/redis/…
2. Redis-cli 中调用 slowlog get，作用是返回执行工夫 超过 redis.conf中定义的持续时间的命令列表，留神这个工夫仅仅是申请的解决工夫，不蕴含网络通信的工夫，默认值是一秒，

redis.conf 当中对于慢日志的解释:

The following time is expressed in microseconds, so 1000000 is equivalent to one second. Note that a negative number disables the slow log, while a value of zero forces the logging of every command.

接下来的工夫以微秒为单位，因而 1000000 等于一秒。请留神，正数将禁用慢速日志记录，而零值将强制记录每个命令。（以微秒为单位）

slowlog-log-slower-than 10000

There is no limit to this length. Just be aware that it will consume memory. You can reclaim memory used by the slow log with SLOWLOG RESET.

该长度没有限度。请留神，它将耗费内存。您能够应用 SLOWLOG RESET 回收慢速日志应用的内存。（意思就是说超过 128 条之后的命令会被主动移除）

slowlog-max-len 128

能够用命令 SLOWLOG RESET 分明慢日志占用的内存

127.0.0.1:16379> SLOWLOG reset
OK

== 慢日志是存储在内存当中的，切记 ==

长久化性能倡议

• 因为 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 文件，载入较新的那个。新浪微博 就选用了这种架构。

其余性能优化指南（强烈推荐）：

https://szthanatos.github.io/…

总结比照 rdb 和 aof：

其余拓展常识：

对于 linux 内核开启 transparent_hugepage 会带来的阻塞问题：

集体对于 Linux 学艺不精，就间接援用文章了，侵权请分割删除

Linux 对于 Transparent Hugepages 的介绍

简略说说 THP——记一次数据库服务器阻塞的问题解决

官网解决 aof 和 rdb 对于性能问题的折中解决形式

1. redis4.0 之后有一个参数叫做:aof-use-rdb-preamble yes

参数解释如下：

# When rewriting the AOF file, Redis is able to use an RDB preamble in the
# AOF file for faster rewrites and recoveries. When this option is turned
# on the rewritten AOF file is composed of two different stanzas:
#
#   [RDB file][AOF tail]
#
# When loading, Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, then continues loading the AOF
# tail.
#重写 AOF 文件时，Redis 能够在
#AOF 文件可放慢重写和复原速度。启用此选项时
重写的 AOF 文件上的#由两个不同的节组成：#
#[RDB 文件] [AOF 尾巴]
#
#加载时，Redis 会辨认 AOF 文件以“REDIS”结尾
#字符串并加载带前缀的 RDB 文件，而后持续加载 AOF
# 尾巴。

大抵的内容就是说 redis 会将较早的局部内容转为 RDB 文件进行复原，同时退出近期的数据为 AOF 文件

加载的时候先执行 rdb 文件的复原，而后再加载 aof 命令

如何进行内存清理

在 redis4.0 之后，能够通过将配置里的 activedefrag 设置为 yes 开启主动清理，或者通过 memory purge 命令手动清理。