redis高持久化、RDB、AOF

redis高可用

redis当中，高可用概念会更宽泛一些。
除了正常服务以外，数据量的扩容，数据安全。

实现高可用的方式：
1、持久化 最简单的高可用方法 主要功能：备份数据
把内存的数据保存到硬盘当中。

2、主从复制

3、哨兵模式 建立在主从复制的基础上，部署哨兵模式。

4、redis集群

redis的持久化

内存当中的数据保存到硬盘中。
开启持久化之后，会有持久化文件，通过文件进行恢复。
redis提供的持久化方式：

RDB持久化：

定时的将内存当中的数据保存到硬盘，类似于快照的形式用二进制压缩存储。后缀名为 .rdb
每次redis重启时，都会读取快照文件，进行恢复。默认的持久化方式。

 219 save 900 1
 220 # 当时间到900秒，如果redis的数据发生一次变化，就会执行bgsave
 221 save 300 10
 222 #当时间到达300秒之内，如果redis的数据发生十次变化，就会执行bgsave
 223 save 60 10000
 224 #当时间到60,如果redis的数据发生了10000次变化，就会执行bgsave
#save n m 只能配置文件当中的配置项，redis执行命令bgsave

save不能直接在命令行执行，一旦执行save，redis的主进程就会进入阻塞状态，读写都不能进行，直到save完成才能读写。save在生产中禁用。
bgsave 就是RDB快照保存的方式
bgsave 在执行关闭redis服务的时候，也会自动执行bgsave
bgsave是主从复制的默认恢复模式，从节点执行全量恢复操作。主节点通过bgsave命令把rdb发送给从节点
除了配置文件的save m n 关闭redis会执行bgsave，开启redis也会执行bgsave文件**（cd /var/lib/redis/6379 dump.rdb）**

AOF持久化：

AOF持久化：把操作的数据库执行以日志的形式保存到指定的文件当中，文件后缀名为 .aof。类似于MySQL的（binlog）

AOF持久化的实时性更好，只要是操作了就会记录在日志文件中，进程出现意外，丢失的数据更少，AOF是主流的持久化方式

AOF是主流，RDB和AOF配合使用

AOF默认关闭，需要开启。如果同时开启RDB和AOF，哪个优先级高？
一旦开启AOF，系统默认选择AOF进行恢复。

[root@myslq4 ~]# vim /etc/redis/6379.conf 
 571  maxmemory  2gb        一定要设置
 572 #设置redis占用系统的阀值
 704 appendonly yes   默认关闭，yes开启
 734 appendfsync everysec
 735 #每秒自动更新一次
 757 no-appendfsync-on-rewrite no
 758 #不是每次都一定要对AOF文件进行重写，手动来对AOF文件进行重写
 801 aof-load-truncated yes
 802 #如果发现AOF文件被截断，redis在启动时自动修复AOF的文件，尽可能对数据进行恢复
 803 #一旦变成no redis发现文件截断，redis会拒绝启动

重写：
充分非必要条件
一旦开启AOF持久化之后，所有的数据库操作记录，必然都会写入AOF持久化文件当中。
AOF文件越来越大。
aof文件越大，记录的操作越多，一旦要回复，速度会很慢。
重写就是为了压缩AOF持久化文件。大大减小
重写就是把源内容压缩，后续新的读写，继续插入aof文件，

192.168.11.144:6379> BGREWRITEAOF

RDB持久化 与 AOF持久化之间的优缺点：
RDB：文件小，传输速度快，主从复制的默认模式，适合全量复制，恢复速度比AOF快、性能影响较小
AOF优点：秒级的持久化，数据量全，而且兼容性好，通用
缺点：文件大，恢复速度慢，性能影响大，
但是AOF，支持全量和增量。数据安全大于一切。

redis性能管理

1、

192.168.11.144:6379> info memory
used_memory:874480 字节   #redis中的数据占用内存的大小
used_memory_rss:12832768   #redis向系统申请的内存。随着数据的大小自动扩容
used_memory_peak_human:894.88K  #占用系统内存的峰值

2、内存碎片化率
内存碎片化率=redis向系统申请的内存/redis数据实际占用的内存 越接近1越好

[root@myslq4 ~]# redis-cli info memory | grep ratio   #查看碎片化利用率
allocator_frag_ratio:1.26         #分配器的碎片化比例，值越大碎片越多，导致内存浪费
allocator_rss_ratio:6.47          #分配器占用物理内存的比例
rss_overhead_ratio:1.22           #占用物理内存的额外的开销的比例   越小越好
mem_fragmentation_ratio:15.42     #内存的碎片比例Redis进程占据操作系统的内存与Redis分配器分配的内存总量之间的比值，值越低                                    越好 

[root@myslq4 ~]# redis-cli  memory purge   #手动清理
[root@myslq4 ~]# vim /etc/redis/6379.conf
1360  activedefrag yes
1361 #自动清理碎片
1362 # Minimum amount of fragmentation waste to start active defrag
1363  active-defrag-ignore-bytes 100mb
1364 
1365 # Minimum percentage of fragmentation to start active defrag
1366  active-defrag-threshold-lower 10
1367 
1368 # Maximum percentage of fragmentation at which we use maximum effort
1369  active-defrag-threshold-upper 100
1370 
1371 # Minimal effort for defrag in CPU percentage
1372  active-defrag-cycle-min 5
1373 
1374 # Maximal effort for defrag in CPU percentage
1375  active-defrag-cycle-max 75

面试：redis常见的问题：

缓存击穿：

1、缓存雪崩：

redis 产生了大面积的故障（缓存数据丢失）所有的请求全部转发到数据库。
数据库不适合高并发，很快集群就会崩溃，然后整个系统瘫痪。
1、人为
2、缓存数据大量的同时过期，新的缓存没有及时生成
3、redis服务集群崩溃
怎么防备缓存雪崩：
1、redis必须高可用方案
持久化、主从、哨兵、集群
2、访问量过大，超过redis本身的负载能力
熔断机制：Hystrix可以实现熔断，降级，限流，降低雪崩的概率

2、缓存击穿：

redis的缓存数据一部分丢失，导致请求转发到了数据库。
或者缓存刚刚过期，新缓存没有建立，请求都转发到数据库

防范机制

热点缓存数据设置为永不过期
持久化，高可用

我发现经常使用的热点语句，忽然就变的很慢，之后持续的变慢，查找问题，发现该热点数据对应的缓存键值对消失。
**解决办法：**因为没有redis密码，报告给了数据库的部门。
我进入了redis的数据库 set 重新创建了这个热点数据的缓存，解决了这个问题。

3、缓存穿透：

80%黑客在攻击。
利用缓存和数据库都没有的数据，用户一直在发起请求。
利用大量的请求压垮数据库，从而导致整个网站崩溃。

防御手段

防火墙 只能起到一定的作用
验证拦截（消息队列）需要手动完成，可以判断是否攻击行为。
缓存空数据
新创建了这个热点数据的缓存，解决了这个问题。

3、缓存穿透：

80%黑客在攻击。
利用缓存和数据库都没有的数据，用户一直在发起请求。
利用大量的请求压垮数据库，从而导致整个网站崩溃。

防御手段

防火墙 只能起到一定的作用
验证拦截（消息队列）需要手动完成，可以判断是否攻击行为。
缓存空数据
把一些空数据，也设置缓存，声明周期短一些