2、redis的持久化
redis的持久化
在redist当中，高可用的技术包括持久化，主从复制，哨兵模式，集群。
持久化是最简单的高可用的方法，作用就是备份数据。即将数据保存到硬盘，防止进程退出导致数据丢失。
redis持久化方式：
1、RDB持久化：人工或者定时的把内存当中的数据保存到硬盘，这是一种冷备份的方式（备份的时候不用关闭服务，恢复的时候需要关闭），默认的持久化方式。
2、AOF持久化：类似于mysql的二进制日志，把所有redis的操作记录在二进制日志当中，恢复的时候从二进制的内容进行恢复。全热备份，服务要重启。
AOF的持久化的实时性更好，进程意外丢失，恢复的数据是最多的，AOF是主流的持久化方式。
RDB持久化
RDB持久化：快照持久化，文件的后缀名是.rdb，redis每次重启时都会读取rdb文件进行恢复。有save和bgsave
save：可以在配置文件声明，也可以手动
- 执行save之后，主进程会进入阻塞。
- 读写都不能执行
- 主进程创建rdb文件，直到rdb文件创建完成之后，进程的阻塞才能结束。
bgsave：向主进程发送一个信号，主进程fork（后台）新建一个子进程，在fork的过程中，主进程阻塞，创建完子进程之后，阻塞结束，子进程来创建rdb文件。
redis配置文件/etc/redis/redis.conf
进入redis命令行模式，执行bgsave命令，生产新的rdb文件/var/lib/redis/dump.rdp文件，复制保存到别的目录下，恢复的话，删除新的rdb文件，把旧的rdb文件再复制过来就行。恢复过程中要先关闭redis，恢复好了之后再重启。
AOF持久化
一旦开启AOF持久化，redis会默认选择aof作为持久化方式，并且立刻读取二进制文件。
开启AOF，一定要在初始化时开启。
redis配置文件/etc/redis/redis.conf ，启用二进制日志文件。
- 启用二进制日志文件，之前的数据都会被清空，适合初始化使用。
生产二进制日志文件/var/lib/redis/appendonly.aof，我们所有操作都记录在这个文件里，如果想要恢复日志，直接vim进去操作即可。
优化项截断
- 当发现aof文件被截断时，如果是yes，redis在重启时发现被截断，redis会尽可能的恢复数据，继续运行；如果时no，redis在重启时发现被截断，redis会拒绝启动。
- 截断：写入的过程中出现异常，内存当中有，但是没有完整的写入到磁盘。
AOF的rewrite机制：重写
重写表示的是压缩，当这个二进制日志文件越来越多，文件越来越大，于是就有了重写的功能，对二进制日志文件进行压缩。
bgrewriteaof进程来进行处理
redis-cli bgrewriteaof
如果涉及到数据迁移，rewrite只支持向上兼容（redis 5—>redis 6）。
RDB和AOF之间的优缺点
1、RDB的文件体积比AOF文件小，适合全量备份，速度也比AOF快。
2、RDB不能实时持久化，数据如此重要，不能够丢失。
3、RBD的兼容性比AOF要差，新老版本之间不能兼容。
4、AOF的实时持久化的，兼容性好，文本格式保存命令。
5、AOF的日志文件比较大，恢复速度比较慢，对磁盘的I/O性能要求也高。
生产中，redis的版本一定要一致，目前最稳定的是5.0.7版本
redis的性能管理
查看redis内存使用情况
- used_memory:914128：redis数据占用的内存
- used_memory_rss:11403264：redis向操作系统申请的内存
- used_memory_peak:976192：redis使用系统内存的峰值（最大值）
- allocator_frag_ratio:1.26：分配器的碎片比例，分配器的碎片越多，浪费的内存越多，这个值越小越好。
- allocator_rss_ratio:2.60：分配器使用多少系统的内存
- rss_overhead_ratio:2.68：rss的开销比例，占用系统的物理内存的额外开销，这个值越小越好。
- mem_fragmentation_ratio:13.38：内存的碎片（系统分配之后，但不能利用的内存）比例，越低，内存的利用率越高
设置阈值
配置redis的初始化，必须要给redis的内存设置阈值，如果不设置阈值，只要有需要，redis会占满整个内存，而且会继续占用交换分区的空间。
设置阈值后，不会使用交换分区了，到达阈值，系统会自动回收生命周期不足的key。
设置阈值
设置回收机制
回收机制算法
volatile-lru：根据算法lru，从过期时间的数据集合当中淘汰键值，主要针对设置了ttl的键值。
volatile-ttl：根据算法，淘汰即将过期的数据，也是针对设置生命周期的数据
一直删除到小于或者等于内存阈值，才不会继续删除。
redis的雪崩、击穿和穿透
缓存雪崩：整个作为数据库缓存的键值对，全部失效，redis没有办法处理缓存，所有的请求全部集中到数据库上。
redis的雪崩的原因：
- redis集群大面积故障
- 所有的缓存键值对全部被删除（作为数据库缓存的键值对是不会设置生命周期）
- 大量redis请求失败，所有的请求直接到了数据库
redis的击穿：热点数据的缓存失效，大量的热点请求全部转发到了数据库，会导致数据库的性能大幅下降。
最简单的方法是热点数据设置成永不过期。
遇到redis的击穿处理方法：
- 我通过mysql的慢查询日志，发现sql执行的速度突然大幅下降
- 查询redis，发现缓存的键值对消失了
- 我没有redis的密码，由专门负责数据库的人处理。
redis的缓存穿透：缓存的键值对对数据库当中都没有数据，但是依然有客户端不断在请求，黑客在利用漏洞，把大量请求绕过radis，去压垮数据库。