redis的高可用及性能管理和雪崩

redis的高可用

redis当中，高可用概念更宽泛一些。

除了正常服务以外，数据量的扩容，数据安全。

实现高可用的方式：

1、持久化 最简单的高可用方法，主要功能就是备份数据。

把内存当中的数据保存到硬盘当中。

2、主从复制

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

4、redis集群

---

一、redis的持久化

内存当中的数据保存到硬盘

开启持久化之后，会有一个持久化的文件，通过文件进行恢复。

redis提供的持久化方式：

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

dbfilename dump.rdb rdb         持久化的文件名

 

save 900 1          当时间到900秒，过redis的数据发生一次变化，就会执行bgsave

save 300 10        当时间到300秒，如果redis的数据发生了10次变化，就会执行bgsave

save 60 10000    当时间到60秒，如果redis的数据发生了10000次变化，就会执行bgsave

save m n ：只是配置文件当中的配置项，redis执行的命令是bgsave

save不能直接在命令行执行，一旦执行save，redis主进程会进入阻塞状态，这时读写都不能进行，直到save完成，才能继续读写，save在生产中时禁用的。

RDB持久化的工作方式：

bgsave就是rdb快照保存的方式。

bgsave在执行关闭redis服务的时候，也会自动执行bgsave

bgsave是主从复制的默认恢复模式，从节点执行全量恢复操作，主节点通过bgsave命令把rdb发送给从节点，除了配置文件save m n ，关闭redis会执行bgsave，开启redis也会执行bgsave。

AOF持久化：（主流）

他是把操作的数据库执行以日志的形式保存在指定的文件当中，文件的后缀名.aof，类似于mysql的binlog。

没有时间，没有位置，只有命令

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

RDB和AOF两者是配合使用。

AOF默认是关闭的，需要开启。

如果同时开启RDB和AOF，哪个优先级高？

一旦开启AOF，系统默认选择AOF进行备份。

appendonly yes 打开AOF的功能

appendfsync everyesc 每秒主动更新一次

no-appendfsync-on-rewrite no 不是每次都一定要对AOF文件进行重写，手动来对AOF文件重写。

aof-load-truncated yes 如果发现AOF文件被截断，redis在启动时会自动修复AOF的文件，尽可能的对数据进行恢复。一旦是NO redis发现文件被截断，redis会拒绝启动。

AOF持久化的工作方式：

重写：

充分非必要条件

一旦开启AOF持久化之后，所有的数据库操作记录必然都会写入AOF持久化文件当中，AOF文件会越来越大，记录的操作越多，一旦要恢复，速度会很慢。

重写的作用：为了压缩AOF持久化文件。

重写就是把原内容压缩，后续新的读写，继续插入AOF文件，不管怎么写入，最后都会在AOF文件

---

RDB持久化和AOF持久化之间的优缺点

RDB文件小，传输的速度很快，适合全量复制，恢复速度比AOF快，性能上影响较小，但是数据安全不如AOF

AOF是秒级持久化，数据量全，兼容性好

缺点：文件大，恢复速度慢，性能影响大

但是支持全量和增量。数据安全大于一切。

---

redis性能管理：

info memory 查看系统占用的内存

userd memory：字节 redis中的数据占用内存的大小

used_memory_rss:字节 redis向系统申请的内存，随着数据占用的大小，自动扩容。

used_memory_peak:937408 占用系统内存的峰值

vim /etc/redis/6379.conf

进入配置文件

在配置文件设置redis占用系统的阈值，一定要设置阈值，不设置阈值会把所有的系统内存都占用了

设置一个阈值，看项目的大小来进行设置，没有一个固定值。

内存碎片化率：

内存碎片化率=redis向系统申请的内存除以(/)redis数据实际占用的内存

redis-cli info-memory | grep ratio 查看碎片化率

allocator frag ratio:1.33

分配器的碎片化比列，值越大，碎片越多，导致内存浪费

allocator rss ratio:6.79

分配器占用物理内存的比例

rss overhead ratio:0.93

表示占用物理内存的额外开销的比例，这个值越小越好，redis实际使用的物理内存比rss更接近

mem fragmentation ratio:12.81

内存的碎片比例，已经分配的内存，但是没有使用，这个值越低越好，内存利用率更高

 

配置文件取消注释自动清理碎片

手动清理 redis-cli memory purge（一般都是手动清理）

---

面试题：

redis常见的问题

缓存雪崩

redis产生了大面积的故障（缓存数据丢失），所有的请求全部转发到了数据库。

数据库不适合高并发，很快集群就会崩溃，然后整个系统瘫痪

产生的原因：

1、人为--------踩缝纫机

2、缓存数据大量的同时过期，新的缓存没有及时生产

3、redis服务集群崩溃

防范机制：

1、redis集群一定要做高可用方案

持久化 主从 哨兵 集群

2、访问量过大，超过redis本身的负载能力。

熔断机制 Hystrix 可以实现熔断，降级，限流来降低雪崩的概率。

缓存击穿

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

防范机制：

热点缓存数据设置为永不过期

持久化，高可用

我发现经常使用的热点语句，查询速度突然变的很慢，查找问题，发现改热点数据对应的缓存键值对消失了。

怎么解决：

简单回答：因为我没有redis的密码，我报告给了数据库的部门。

高级回答：我进入了redis的数据库set 重新创建了这个热点数据的缓存，解决了这个问题

缓存穿透

80%以上都是黑客攻击

利用缓存和数据库都没有的数据，用户一直在发起请求。

利用大量的请求压垮数据库，从而导致整个网站崩溃。

防范：

防火墙 只能起到一定的作用

验证拦截（消息队列）需要手动完成，可以判断是否是攻击行为。

缓存空的数据

把一些空数据也设置缓存，声明生命周期短一点，以防恶意攻击。

---