Redis高可用

Redis高可用

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

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

1、实现高可用的方式

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

2、主从复制

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

4、redis的集群

2、Redis的持久化

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

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

2.1RDB持久化

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

vim /etc/redis/6379.conf

254行 
dbfilename dump.rdb
#rdb持久化的文件名

265行
dir /var/lib/redis/6379
#RDB文件的默认存放路径

219行 
save 900 1
#当时间到900秒，如果redis的数据发生1次变化，就会执行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在生产时是禁用的。
bgsave是rdb快照保存的方式
bgsave在执行关闭redis服务的时候，也会自动执行bgsave
bgsave是主从复制的默认恢复模式，从节点执行全量恢复操作，主节点通过bgsave命令把rdb文件发送给从节点
除了配置文件save m n，关闭redis会执行bgsave，开启redis也会执行bgsave

2.2AOF持久化

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

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

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

RDB和AOF两者配合使用

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

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

vim /etc/redis/6379.conf

700行
appendonly yes
#开启AOF

730行
appendfsync everysec
#每秒都会主动更新一次

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

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

2.3重写

充分非必要条件

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

AOF的文件会越来越大，记录的操作越多，一旦要恢复，速度会很慢

重写就是为了压缩AOF持久化文件，大大减小AOF文件的大小

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

2.4RDB持久化和AOF持久化的优缺点

RDB：文件小，传输速度快，适合全量复制，恢复速度比AOF快。性能上影响较小

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

文件大，恢复速度慢，性能影响大，但是支持全量和增量。数据安全大于一切

3、Redis性能管理

#查看redis内存使用情况
info memory

used_memory:895448
#redis中的数据占用内存的大小

used_memory_rss:10489856
#redis相系统申请的内存，随着数据占用的大小，自动扩容

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

vim /etc/redis/6379.conf
573行
maxmemory 2gb
#设置redis占用系统的阈值

4、内存碎片化率

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

#查看
redis-cli info-memory | grep ratio

allocator_frog_ratio:1.33
#分配器的碎片化率，值越大，碎片越多，导致内存浪费

allocator_rss_ratio:6.69
#分配器占用物理内存的比例

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

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

#手动清理碎片：
redis-cli memory purge
或者进入redis
redis-cli -h 192.168.230.21 -p 6379
memory purge

vim /etc/redis/6379.conf
1364行
activefrag yes 取消注释
#自动进行碎片清理

5、Redis常见的问题

5.1缓存击穿

5.1.1概念

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

5.1.2防范机制

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

2、持久化、高可用

5.2缓存雪崩

5.2.1概念

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

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

5.2.2产生的原因

1、人为

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

3、redis服务集群崩溃

5.2.3如何防备

1、redis集群一定要做高可用方案，持久化、主从、哨兵、集群

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

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

5.2.4场景及解决方法

场景：

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

方法：

因为我没有redis的密码，所以将问题报告给了数据库的部门

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

5.3缓存穿透

5.3.1概念

出现缓存穿透，80%以上是黑客攻击

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

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

5.3.2解决方案

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

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

3、缓存空的数据

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

缓存，解决了这个问题

5.3缓存穿透

5.3.1概念

出现缓存穿透，80%以上是黑客攻击

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

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

5.3.2解决方案

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

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

3、缓存空的数据

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