Redis(*╹▽╹*)加深了解--持久化及性能管理

Posted 2021-09-04 可乐卷儿

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

• 一、Redis高可用
• • 1、持久化
  • 2、主从复制
  • 3、哨兵
  • 4、集群(cluster)
• 二、Redis持久化
• • 1、RDB持久化
  • • 1.1、触发条件
    • 1.2、执行流程
    • 1.3.启动时加载
  • 2、AOF持久化
  • • 2.1、开启AOF
    • 2.2、执行流程
    • 2.3、文件重写的触发分类
    • 2.4、启动时加载
• 三、Redis性能管理
• • 1、查看Redis内存使用
  • 2、内存碎片率
  • 3、内存使用率
  • 4、内回收key
• 四、总结

一、Redis高可用

从redis非关系型数据库而言，除了保证提供正常服务(如主从分离、快速容灾技术)，还需要考虑数据容量的扩展，数据安全不会丢失等；那么实现高可用的技术主要包括持久化、主从复制、哨兵和集群

1、持久化

主要作用是数据备份，即把数据保存在一个位置或者磁盘中

2、主从复制

• 主从复制是高可用Redis的基础，主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复
• 缺陷
  • 故障恢复无法自动化写操作无法负载均衡
  • 单机的原因限制了存储能力

3、哨兵

• 需要在主从复制的基础上实现自动化的故障恢复
• 缺陷
  • 写操作无法实现负载均衡
  • 单机的原因限制了存储能力

4、集群(cluster)

• 写操作无法实现负载均衡这一问题，通过Redis集群解决掉了
• 针对单机的原因限制了存储能力，也实现了相对较为完善的方案(高可用)

二、Redis持久化

Redis是内存数据库，数据都是存储在内存中，为了避免服务器因断电等其他原因导致进程异常退出后，导致的数据的永久丢失，需要定期将Redis中的数据从内存保存到硬盘，在我们再次重启Redis时，通过持久化文件来实现数据恢复

Redis进行持久化的两种方式

1. RDB持久化
   原理是将Reids在内存中的数据库记录定时保存到磁盘上(类似于快照) ；
2. AOF持久化(append only file)-目前主流的持久化方式
   原理是将Reids的操作日志以追加的方式写入文件，类似于mysql的binlog。 (基于日志持久化方式)

1、RDB持久化

又称快照持久化；指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘，用二进制压缩存储，保存的文件后缀是rdb；当Redis重新启动时，可以读取快照文件恢复数据

1.1、触发条件

• 手动触发(生成RDB文件：save命令、bgsave命令)
  • save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求
  • bgsave命令——>派生子进程——>子进程来创建RDB文件并阻塞服务器——>父进程(主进程)则继续处理请求
• 自动触发
  • 在自动触发RDB持久化时，Redis会选择bgsave来进行持久化
  • save m n ##自动触发通常是在配置文件中此命令触发bgsave
    • m：多少s内；n：发生多少次

vim /etc/redis/6379.conf
以下三个save条件满足任意一个时，都会引起bgsave的调用
219 save 900 1 	##当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
220 save 300 10 ##当时间到300秒时， 如果redis数据发生了至少10次变化， 则执行bgsave
221 save 60 10000 :当时间到60秒时，如果redis数据发生了至少10000次变化， 则执行bgsave

242 rdbcompression yes		##是否开启RDB文件压缩
254 dbfilename dump.rdb		##指定RDB文件名
264 dir /var/lib/redis/6379		##指定RDB文件和AOF文件所在目录

• 其他自动触发机制
  • 在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点
  • 执行shutdown命令时，自动执行rdb持久化

1.2、执行流程

• Redis父进程首先判断:当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回bgsave/bgrewriteaof
• 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
• 父进程fork后，bgsave命令返回”Background saving started" 信息并不再阻塞父进程，并可以响应其他命令
• 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
• 子进程发送信号给父进程表示完成，父进程更新统计信息

1.3.启动时加载

• RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令
• 优先级：AOF>RDB，因此当AOF开启时，默认先载入AOF文件，仅当AOF关闭，才会载入RDB文件
• Redis载入RDB文件时(即启动过程中)，会对RDB 文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败

2、AOF持久化

是将Redis执行的每次写、删除命令记录到单独的日志文件中，查询操作不会记录；当Redis重启时优先执行AOF文件中的命令来恢复数据。

2.1、开启AOF

Redis服务器默认开启RDB，关闭AOF
要开启AOF，需要在配置文件中配置

vim /etc/redis/6379.conf
700 appendonly yes		##修改成yes，开启AOF
704 appendfilename "appendonly.aof"		##指定A0F文件名称
796 aof-load-truncated yes		##是否忽略最后一条可能存在问题的指令

/etc/ init.d/redis_ 6379 restart		##重启redis

2.2、执行流程

由于需要记录Redis的每条写命令，因此A0F不需要触发，下面介绍AOF的执行流程。
AOF的执行流程包括:

1. 命令追加(append)
   将Redis的写命令追加到缓冲区aof_buf; (为了尽量不因为持久化而影响redis性能)
2. 文件写入(write)和文件同步(sync)
   根据不同的同步策略将aof_buf中的内容同步到硬盘，所以Redis系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

AOF缓存区的同步文件策略存在三种同步方式，它们分别是

vim /etc/redis/6379.conf
729 appendfsync always		
##命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到A0F文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘(SSD)，每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。
729 appendfsync no
命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步;同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。
729 appendfsync everysec(默认配置)
命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

3. 文件重写(rewrite)
   定期重写AOF文件，达到压缩的目的

2.3、文件重写的触发分类

文件重写的触发，分为手动触发和自动触发

1. 手动触发
   直接调用bgrewriteaof命令；通过fork子进程进行具体的工作，且只有在fork时阻塞。
2. 自动触发
   通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREWRITEA0F，且两个选项同时满足时，才会自动触发AOF重写，即bgrewriteaof操作

vim /etc/ redis/ 6379. conf
AOF同步的策略
729 # appendfsync always
730 appendfsync everysec
731 # appendfsync no
771	auto-aof-rewrite-percentage 100		##当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作
772 auto-aof-rewrite -min-size 64mb		##当前A0F文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEA0F

2.4、启动时加载

• 当AOF开启时，Redis启动时会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会载入RDB文件恢复数据。
• 当AOF开启，但AOF文件不存在时，即使RDB文件存在也不会加载。
• Redis载入AOF文件时，会对AOF文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。但如果是AOF文件结尾不完整(机器突然宕机等容易导致文件尾部不完整)，且aof-load-truncated参数开启，则日志中会输出警告，Redis忽略掉AOF文件的尾部，启动成功。
• aof-load-t runcated参数默认是开启的

三、Redis性能管理

1、查看Redis内存使用

127.0.0.1:6379> info memory

2、内存碎片率

操作系统分配的内存值used_memory_rss除以Redis使用的内存值used_memory计算得出内存碎片是由操作系统低效的分配/回收物理内存导致的(不连续的物理内存分配)
跟踪内存碎片率对理解Redis实例的资源性能是非常重要的:

• 内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低
• 内存碎片率超过1.5，说明Redis消耗了实际需要物理内存的150号，其中50号是内存碎片率。需要在redis-cli工具上输入shutdown save命令，并重启Redis服务器。
• 内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换。需要增加可用物理内存或减少Redis内存占用

3、内存使用率

redis实例的内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换

避免内存交换发生的方法:

• 针对缓存数据大小选择安装Redis实例(云平台里面使用RDS服务，ECS云主机选择内存、缓存型配置)
• 尽可能的使用Hash数据结构存储
• 设置key的过期时间

4、内回收key

保证合理分配redis有限的内存资源。
当达到设置的最大阀值时，需选择–种key的回收策略，默认情况下回收策略是禁止删除。
配置文件中修改maxmemory- policy属性值

vim /etc/redis/6379.conf
598 maxmemory-policy noenviction
volatile-lru	##使用LRU算法从已设置过期时间的数据集合中淘汰数据
volatile-ttl	 ##从已设置过期时间的数据集合中挑选即将过期的数据淘汰
volatile-random	##从已设置过期时间的数据集合中随机挑选数据淘汰
allkeys-lru 	##使用LRU算法从所有数据集合中淘汰数据
allkeys-random 	##从数据集合中任意选择数据淘汰

四、总结

高可用中的持久化
RDB和AOF；RDB是默认开启的，AOF需要手动开启
1、持久化方式
①：RDB:周期性的快照；二进制压缩格式
②：A0F:接近实时的持久化(以everysec方式)基于日志文件持久化；还有一个文件重写功能，可以帮助AOF减少持久化文件的大小

2、redis 启用的优先级
AOF>RDB，同时仅当AOF功能关闭的情况下，redis才会在重新启动时使用RDB的方式进行恢复

3、RDB和AOF中持久化模式
①：RDB
由redis主进程( 周期性) fork 派生出子进程对redis内存中的数据进行持久化(二进制压缩)，生成到.rd文件中，自动触发的方式是使用的bgsave持久化
②：AOF
根据持久化策略(alawys、no、everysec(默认) )，先将redis中的语句保存在缓冲区中，再从缓冲区同步到.aof文件中；bgrewriteaeof