redis持久化

redis高可用

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

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

实现高可用的方式：

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

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

2、主从复制

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

4、redis集群

redis的持久化：

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

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

*redis提供的持久化方式：

1、RDB持久化：

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

2、AOF持久化：

把操作的数据库指令以日志的形式保存在指定的文件当中，后缀名为.aof。类似于mysql的binlog。没有时间，没有位置，只有命令

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

RDB和AOF两者是配合使用

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

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

开启：配置文件/etc/redis/6370.conf中700行 改为yes

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

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

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

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

重写：

充分非必要条件

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

aof的文件会越来越大。

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

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

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

redis性能管理

used_memory:874504：字节，redis中的数据占用内存的大小

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

used_memory_peak:874504：占用系统内存的峰值

内存碎片化率：

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

allocator_frag_ratio:1.29

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

allocator_rss_ratio:3.66

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

rss_overhead_ratio:1.99

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

mem_fragmentation_ratio:15.44

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

命令行中手动清理碎片:redis-cli memory purge 

redis中清理碎片：memory purge

*redis常见的问题：

*缓存击穿：

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

防范机制：

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

持久化、高可用

缓存雪崩：

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

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

产生的原因：

1、人为

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

3、redis服务集群崩溃

如何防备：

1、redis集群必须做高可用方案，持久化、主从、哨兵、集群

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

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

缓存穿透：

80%是遇到黑客攻击

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

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

如何防备：

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

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

缓存空的数据

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