redis持久化

除了正常服务以外，数据量的扩容，数据安全也属于高可用的范畴之内。

实现redis高可用的方式

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

2.主从复制

3.哨兵模式

4.redis的集群

持久化概念

是把内存当中的数据保存到硬盘当中。开启持久化之后，会有一个持久化的文件。通过文件进行恢复。

面试题：

redis提供的持久化方式

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

2.AOF持久化

它是把操作的数据库指令以日志的形式保存在指定的文件当中，文件的后缀名 .aof 。类似与mysql的binlog。它没有时间和位置，只有命令。AOF持久化的实时性更好，只要是操作了都会记录在日志文件中，进程出现意外时，丢失的数据更少。AOF是主流的持久化方式。

RDB和AOF两者是配合使用。

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

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

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

重写：

充分非必要条件

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

AOF的文件越大，记录的操作就越多，一旦要恢复，速度就会很慢。重写的作用就是为了压缩AOF持久化文件。重写就是把原内容压缩，后续新的读写，继续插入aof文件

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

bgsave就是rdb快照保存的方式

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

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

rdb的工作方式

AOF的工作方式

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

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

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

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

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

redis性能管理

命令：info memory

重要指标：

used_memory:853400  单位是字节，是redis中的数据占用内存的大小

内存碎片化率：

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

命令：redis-cli info memory | grep ratio

指标：

allocator_frag_ratio:1.23     分配器的碎片化比例，值越大，碎片越多，导致内存越浪费
allocator_rss_ratio:6.38      分配器占用物理内存的比例
rss_overhead_ratio:1.24     表示占用物理内存的额外的开销的比例，这个值越小越好。redis实际使用的物理内存比rss更接近
mem_fragmentation_ratio:13.26  内存的碎片比例，已经分配点的内存，

redis-cli memory purge 手动清理内存碎片

redis常见的问题

缓存击穿

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

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

原因：1.人为

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

           3.redis服务集群崩溃 

怎么防备：

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

2.访问量过大，超过‘Redis本身的负载能力

    解决方案：’