Redis（二）——Redis高可用、持久化及性能管理

Redis高可用

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

主要的高可用技术

• 持久化：持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
• 主从复制：主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
• 哨兵：在主从复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。
• 集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

Redis 持久化

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

Redis进行持久化的两种方式

•  RDB 持久化：原理是将 Reids在内存中的数据库记录定时保存到磁盘上。
•  AOF 持久化（append only file）：原理是将 Reids 的操作日志以追加的方式写入文件，类似于MySQL的binlog。

RDB持久化

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

触发条件

• 手动触发(生成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. Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回。 bgsave/bgrewriteaof的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
2. 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
3. 父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令
4. 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
5. 子进程发送信号给父进程表示完成，父进程更新统计信息

启动时加载

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

AOF持久化

• RDB持久化是将进程数据写入文件，而AOF持久化，则是将Redis执行的每次写、删除命令记录到单独的日志文件中，查询操作不会记录； 当Redis重启时再次执行AOF文件中的命令来恢复数据。
•  与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

开启AOF

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

vim /etc/redis/6379.conf

#----700行----修改；开启AOF
appendonly yes
#----704行----指定AOF文件名称
appendfilename "appendonly.aof"
#----796行----是否忽略最后一条可能存在问题的指令
aof-load-truncated yes
#指redis在恢复时，会忽略最后一条可能存在问题的指令，默认为yes，即在aof写入时，可能存在指令错误的问题（突然断电导致未执行结束），这种情况下，yes会log并继续，而no会直接恢复失败

/etc/init.d/redis_6379 restart
#需要先取消密码

执行流程

由于需要记录Redis的每条写命令，因此AOF不需要触发， AOF的执行流程包括：

• 命令追加(append)：将Redis的写命令追加到缓冲区aof_buf
• 文件写入(write)和文件同步(sync)：根据不同的同步策略将aof_buf中的内容同步到硬盘
• 文件重写(rewrite)：定期重写AOF文件，达到压缩的目的

Redis 性能管理

查看Redis内存使用

redis-cli -h 192.168.184.10 -p 6379
info memory

内存碎片率

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

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

内存使用率

• redis实例的内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换。
•  避免内存交换发生的方法：
  • 针对缓存数据大小选择安装 Redis 实例
  • 尽可能的使用Hash数据结构存储
  • 设置key的过期时间

内回收key

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

配置文件中修改 maxmemory-policy 属性值：

vim /etc/redis/6379.conf
#----598取消注释----
maxmemory-policy noenviction

volatile-lru	：使用LRU算法从已设置过期时间的数据集合中淘汰数据
volatile-ttl	：从已设置过期时间的数据集合中挑选即将过期的数据淘汰
volatile-random	：从已设置过期时间的数据集合中随机挑选数据淘汰
allkeys-lru		：使用LRU算法从所有数据集合中淘汰数据
allkeys-random	：从数据集合中任意选择数据淘汰
noenviction		：禁止淘汰数据