Redis高可用

redis高可用

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

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

实现高可用的方式

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

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

2、主从复制

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

4、redis的集群

redis的持久化

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

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

redis提供的持久化方式

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

存放路径

执行时间

seve 不能直接在命令行执行，一旦执行了save，redis的主程序会进入到阻塞状态，读写都不能进行，知道save完成，才能继续读写，save在生产中严禁使用

bgsave 就是rdb快照保存方式

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

bgsave 是主从复制的默认恢复模式 从节点执行全量恢复操作，主节点通过bgsave命名吧rdb发送给从节点

除了配置文件 save m n 关闭redis会执行bgsave， 开启redis也会执行bgsave

AOF持久化：

操作的数据库指令以日志的形式保存在指定的文件当中，文件的后缀名.aof。类似于mysql的binlog，是通过命令的方式来实现的

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

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

RDB和AOF二者是配合使用

AOF默认是关闭的，需要开启，如果同时开启ROB和AOF，那个优先级高？

一旦开启AOF，系统默认选择AOF进行恢复。

修改配置文件打开
第一个改为yes是打开

第二个指向是文件名称

对文件恢复

然后重启服务 就可以看到生成了一个.aof的文件

在配置文件中吧删除的内容删掉 然后重启服务即可恢复

重写

充分非必要条件

一旦开启AOF持久化之后，所有的数据库操作记录必然都会写入AOF持久化文件当中。

AOF的文件会越来越大

aof的文件越大，记录的操作就越多，一旦要回复，速度会很慢，

重写就是为了压缩aof持久化文件。

变成二进制文件

重点就是把源内容压缩，后续新的读写，继续插入aof文件

bgrewriteaof

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

RDB文件小，传输速度快，适合全量复制

回复速度也比AOF快

性能上影响小

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

缺点：文件大，恢复速度慢，性能形象大

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

redis性能管理

20.0.0.51:6379> info memory
# Memory
used_memory:853464  字节 redis中的数据占用内存大小
used_memory_human:833.46K
used_memory_rss:12877824  字节 redis像系统申请的内存，随着数据占用的大小，自动扩容
used_memory_rss_human:12.28M
used_memory_peak:873928   占用系统内存的峰值
used_memory_peak_human:853.45K
used_memory_peak_perc:97.66%
used_memory_overhead:841254
used_memory_startup:791416

设置占用内存 可自定义（一定要做！！！）

内存碎片化率

内存碎片化率

redis-cli info memory | grep ratio
[root@redis2 opt]# redis-cli info memory | grep ratio
allocator_frag_ratio:1.31  分配器的碎片化比例，值越大碎片越多，导致内存浪费
allocator_rss_ratio:9.25 
分配器占用物理内存的比例
rss_overhead_ratio:0.99
表示占用物理内存的额外的开销比例  这个值越小越好，redis实际使用的物理内存比rss更接近
mem_fragmentation_ratio:16.53
内存的碎片比例，已经分配的内存，但是没有使用的内存，这个值越低越好，内存利用率越高越好

自动清理内存碎片（用的比较少）

如果是初始化设置则需要解锁这些设置

手动清理

redis-cli memory purge
可在命令行进行操作
memory purge 
在redis进行操作

redis常见问题

缓存击穿

缓存雪崩

redis产生了大面积的故障（缓存数据丢失），所有的请求全部转发到了数据库，很快集群就会崩溃，然后整个系统瘫痪。

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

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

3、redis服务集群崩溃 主从 哨兵

怎么防备

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

持久化、主从、哨兵、集群。

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

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

缓存击穿

redis的缓存数据有一部分丢失了，导致请求转发到了数据库。

或者是缓存刚刚过期，新缓存还没有建立，请求都转发到了数据库

防范机制

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

持久化，高可用

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

因为我没有redis的密码，我报告给了数据库的部门

我进入了redis的数据库

set 重新创建了这个热点数据的缓存，解决了这个问题

缓存穿透

80%以上是黑客攻击

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

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

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

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

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