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秒内有一次写入操作，就记录到rdbsave 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 100auto-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的同步策略

选项同步频率
always每次命令都写入磁盘，重大升高redis速度
everysec每秒执行一次，显示将多个命令写入到磁盘
no操作系统决定，佛系

剖析：

  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：

RDBAOF
存储内容数据写操作日志
性能影响小大
复原速度高低
存储空间小大
可读性低高
平安水平较低，保留频率低较高，保留频率高
默认开启是否
存储策略save 900 1：九百秒内一次批改即保留 save 300 10：三百秒内十次批改即保留 save 60 10000：六十秒内一万次批改即保留 容许自定义always：逐条保留 or everysec：每秒保留 or no：零碎本人决定什么时候保留

其余拓展常识：

对于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命令手动清理。