持久化

在redis当中，高可用的技术包括持久化，主从复制，哨兵式，集群。

持久化是最简单的高可用的方法，作用就是备份数据。即将数据保存到硬盘。防止进程退出导致数据丢失。

redis_8">redis的持久化方式

1. RDB持久化----->人工或者是定时的把内存当中的数据保存到磁盘，这是一种冷备份的方式。（备份的时候不用关闭服务，恢复的时候需要关闭），默认的持久化方式。
2. AOF持久化----->类似于mysql的二进制日志，把所有redis的操作记录在二进制日志当中，恢复的时候从二进制日志的内容进行恢复。全热备份。服务要重启。

RDB持久化
快照持久化，文件的后缀名是.rdb，redis每次重启时都会读取rdb文件进行恢复。

AOF的持久化的实时性更好，进程意外丢失，恢复的数据是最多的，AOF是主流的持久化方式。

触发RDB持久化的命令save和bgsave

• save：生产中禁用save，执行save之后，主进程进入阻塞读写都不能执行，主进程创建rdb文件，直到rdb文件创建完成之后，进程的阻塞才会解除。

• bgsave：向主进程发送一个信号，主进程fork(后台)新建一个子进程，在fork的过程中，主进程阻塞，创建完子进程之后，阻塞接触，子进程来创建rdb文件。

#RDB与AOF文件存放位置
root@u1:~# cd /var/lib/redis/
root@u1:/var/lib/redis# ls
dump.rdb   appendonly.aof

开启RDB

vim /etc/redis/redis.conf

systemctl restart redis

rootaredis1:/var/lib/redis# redis-cli -h 192.168.246.6 -p
6379
192.168.233.7:6379> BGSAVE
Background saving startedroot@u1:/var/lib/redis# cp -a dump.rdb /opt/
root@u1:/var/lib/redis# rm -rf dump.rdb
root@u1:/var/lib/redis# systemctl stop redis
root@u1:/var/lib/redis# cp -a /opt/dump.rdb /var/lib/redis
root@u1:/var/lib/redis# systemctl start redis

开启AOF

vim /etc/redis/redis.conf
#1094行
appendonly no 改为 appendonly yes#AOF优化
#1192行
aof-load-truncated yes
#当发现aof文件被截断时，如果是yes，redis在重启时发现被截断，redis会尽可能的恢复数据，继续运行。
#no，如果发现AOF文件被截断，redis会拒绝启动
#截断: 写入的过程中出现异常，内存当中有，但是没有完整的写入到磁盘systemctl restart redis

一旦开启AOF持久化，redis会默认选择aof作为持久化方式，并且立刻读取二进制文件，所有内容将全部为空。

AOF的rewrite机制

重写(表示的是压缩)，当这个二进制日志文件内容越来越多，文件越来越大，于是就有了重写的功能对二进制文件进行压缩。
bgrewriteaof进程来进行处理
命令 redis-cli bgrewriteaof

vim /etc/redis/redis.conf
1167行

1、如果涉及到数据迁移
A—aof-----B
2、redis5 A与redis4 B无法兼容
3、redis5只能与高版本redis5.1，redis6兼容

rdb和aof之间的优缺点

1. RDB的文件体积比aof小，适合全量备份，速度也快AOF快。
2. rdb不能实时持久化，数据重要，不能够丢失
3. RDB的兼容性比AOF要差，新老版本之间不能兼容

生产中：redis的一定要一致，目前最稳定的版本为5.0.7

AOF的优点：实时持久化的测了，兼容性也好，文本格式保存的命令
缺点：文件比较大，恢复速度比较慢，对磁盘的I/O性能也比较高

redis_110">redis的性能管理

redis_111">查看redis内存使用的情况

root@u1:/var/lib/redis# redis-cli -h 192.168.246.6 -p 6379
192.168.246.6:6379> info memory
# Memory
used_memory:872416   #redis数据占用的内存
used_memory_human:851.97K   #human人性化展示
used_memory_rss:11403264   #redis向操作系统申请的内存
used_memory_rss_human:10.88M
used_memory_peak:934560   #redis使用系统内存的峰值
used_memory_peak_human:912.66Kroot@u1:/var/lib/redis# redis-cli info memory | grep ratio
allocator_frag_ratio:1.26
#分配器的碎片比例，分配器的碎片越多，浪费的内存越多，这个值越小越好
allocator_rss_ratio:2.76
#分配器使用多少系统的内存
rss_overhead_ratio:2.82
#RSS的开销比例，占用系统的物理内存的额外开销，这个值越低越好，越接近0，redis的实际的使用比就越高。
mem_fragmentation_ratio:14.07
#内存的碎皮比例，内存碎片，系统分配之后，但是不能被利用的内存。越低，内存的利用率越高

配置redis的初始化，必须要给redis的内存设置阈值，不设置阈值，只要有需要，redis会占满整个内存，而且会继续占用交换分区的空间

设置阈值后，不会使用交换分区了，到达阈值，系统会自动回收生命周期不足的key。

设置阈值

vim /etc/redis/redis.conf

#设定为2G
maxmemory 2gb

设置回收

• volatile-lru
  根据算法lru，从过期时间的数据集合当中淘汰键值，主要是针对设置了ttl的键值对
• volatile-ttl
  根据算法，淘汰即将多起的数据(也是针对设置生命周期的数据)
• alkeys-lru
  lru算法淘汰最近很少使用的数据
• allkeys-random
  淘汰任意的数据。

一直删除到小于或者等于内存闽值，才不会继续删除。

redis_165">redis的雪崩

缓存雪崩:整个作为数据库缓存的键值对，全部失效，redis没有办法处理缓存，所有的请求全部集中到数据库上数据库很快就崩溃。

1. redis集群大面积故障
2. 所有的缓存键值对全部被删除（作为数据库缓存的键值对是不会设置生命周期的）
3. 大量的redis请求失败，所有的请求直接到了数据库

redis_171">redis的击穿

缓存击穿:热点数据的缓存失效，大量的热点请求全部转发到了数据库，会导致数据库的性能大幅下降。
热点数据设置成永不过期。

redisd_175">redisd的穿透

缓存的键值对和数据库当中都没有数据，但是依然有客户端不断在请求，黑客在利用漏洞，把大量请求绕过redis，去压垮数据库。