NoSQL 之Redis 的服务优化

一、Redis 持久化

持久化概述

• Redis是运行在内存中，内存中的数据断电丢失
• 为了能后重用Redis数据，或者防止系统故障，我们需要将Redis中的数据写入到磁盘空间中，即持久化

持久化分类

• RDB方式：创建快照的方式获取某一时刻Redis中所有数据的副本
• AOF方式：将执行的写命令写到文件的末尾，以日志的方式来记录数据的变化

1.1、RDB 持久化

• Redis默认的持久化方式
• 默认文件名为dump.rdb

[root@redis utils]# cd /var/lib/redis/6379/
[root@redis 6379]# ls
dump.rdb

触发条件

• 在指定的时间间隔内，执行指定次数的写操作（配置文件控制）
• 执行save或者是bgsave（异步）命令
• 执行flushall命令，清空数据库所有数据
• 执行shutdown命令，保证服务器正常关闭且不丢失任何数据

优缺点

• 适合大规模的数据恢复
• 如果业务对数据完整性和一致性要求不高，RDB是很好的选择
• 数据的完整性和一致性不高
• 备份时占用内存

通过RDB文件恢复数据
将dump.rdb文件拷贝到redis的安装目录的bin目录下，重启redis服务即可

配置文件选项

[root@redis 6379]# vim /etc/redis/6379.conf 	'//修改配置文件'
    '//搜索save，找到如下'
save 900 1	'//900秒之内至少一次写操作'
save 300 10	'//300秒内至少10次写操作'
save 60 10000	'//60秒内至少10000次写操作'
'//只要满足其一都会触发快照操作，注释所有的save项表示关闭RDB'
dbfilename dump.rdb	'//RDB文件名称'
dir /var/lib/redis/6379	'//RDB文件路径'
rdbcompression yes	'//开启了压缩功能'

1.2、AOF 持久化

• Redis默认不开启
• 弥补RDB的不足（数据的不一致性）
• 采用日志的形式来记录每个写操作，并追加到文件中
• Redis重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

根据AOF文件恢复数据
将appendonly.aof文件拷贝到redis安装目录的bin目录下，重启redis服务即可

配置文件选项

[root@redis 6379]# vim /etc/redis/6379.conf 
appendonly no	'//修改为yes即可开启AOF持久化'
appendfilename "appendonly.aof"	'//AOF文件名称'
# appendfsync always	'//always:同步持久化，每次发生数据变化会立刻写入磁盘'
appendfsync everysec	'//everysec:默认推荐，每秒异步记录次(默认值)'
# appendfsync no	'//no:不同步，交给操作系统决定如何同步'
'//取消注释的时候注意前方空格，一定要删掉'
aof-load-truncated yes	'//忽略最后一条可能存在问题的指令'

AOF的重写机制

• AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多
• 当AOF文件的大小超过所设定的阀值时，Redis就会对AOF文件的内容压缩

AOF重写的原理
Redis会fork出一条新进程，读取内存中的数据(并没有读取旧文件)，并重新写到一个临时文件中，最后替换旧的aof文件

AOF的重写配置

[root@redis 6379]# vim /etc/redis/6379.conf 
no-appendfsync-on-rewrite no	'//在日志进行BGREWRITEAOF时， 如果设置为yes表示新写操作不进行同步fsync,只暂存在缓冲区里，避免造成磁盘I0操作冲突，等重写完成后在写入。redis中默认为no'
auto-aof-rewrite-percentage 100	'//当前AOF文件大小是上次日志重写时AOF文件大小两倍时，发生BGREWRITEAOF操作'
auto-aof-rewrite-min-size 64mb	'//当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF.当AOF文件到达64M的时候，发生BGREWRITEAOF操作'

二、Redis 性能管理

查看Redis内存使用

[root@redis 6379]# /usr/local/redis/bin/redis-cli 
127.0.0.1:6379> INFO memory
...省略内容

2.1、内存碎片率

• 操系统分配的内存值used_ memory _rss除以redis使用的内存值used_memory计算得出

• 内存碎片是由操作系统低效的分配/回收物理内存导致的

  • 不连续的物理内存分配

• 跟踪内存碎片率对理解redis实例的资源性能是非常重要的

  • 内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低
  • 内存碎片率超过1.5,说明redis消耗了实际需要物理内存的150%，其中50%是内存碎片率
  • 内存碎片率低于1的，说明Redis内存分配超出了物理内存,操作系统正在进行内存交换

2.2、内存使用率

• redis实例的内存使用率超过可用最大内存，操作系统将开始进行
• 避免内存交换
  • 针对缓存数据大小选择
  • 尽可能的使用Hash数据结构
  • 设置key的过期时间

2.3、回收key

• 保证合理分配redis有限的内存资源

• 当内存使用达到设置的最大阀值时，需要选择一种key的回收策略

  • 默认情况下回收策略是禁止删除

  • redis.conf配置文件中修改maxmemory-policy属性值

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