【黑马redis高级篇】长期化

//来源[01,05]分布式缓存
除了黑马，还参考了别的。

  
1.单点redis问题及解决方案

数据丢失问题：实现redis数据长期化
并发本领问题：搭建主从集群，实现读写分离
故障恢复问题：使用Redis哨兵，实现健康检测和主动恢复
存储本领问题：搭建分片集群，使用插槽机制进举措态扩容
2.为什么必要长期化？

Redis是个基于内存的数据库。服务一旦宕机，内存中的数据将全部丢失。
通常的解决方案是从后端数据库恢复这些数据，但后端数据库有性能瓶颈，如果是大数据量的恢复，1、会对数据库带来巨大的压力，2、数据库的性能不如Redis。导致步伐响应慢。
所以对Redis来说，实现数据的长期化，克制从后端数据库中恢复数据，是至关紧张的。
3.Redis长期化有哪些方式呢？为什么我们必要重点学RDB和AOF？

从严酷意义上说，Redis服务提供四种长期化存储方案：RDB、AOF、虚拟内存（VM）和　DISK STORE。但现在官方明确支持的只有前两种方案。
4.RDB

4.1 界说

RDB：redis数据备份文件，redis数据快照。
把内存中的全部数据都记录到磁盘中，当redis实例故障重启后，从磁盘中读取快照文件，恢复数据。
快照文件称为RDB文件，默认是保存在当前运行目录。再次启动时主动读取rdb文件。
4.2 触发方式

4.2.1手动触发save

save下令：由redis主进程实行rdb，会阻塞全部进程。
默认是服务停止时才会实行。
4.2.2被动触发bgsave

开启子进程背景实行rdb，克制影响主进程。
配置

在redis.conf配置文件中写：save x y (在x秒内，如果至少有y个key被修改，则实行bgsave)；
如果是save ”"则表示禁用rdb。

配置文件中也可以配置rdb的其他配置。
bgsave的流程

bgsave开始时，fork主进程得到子进程，子进程共享主进程的内存，完成fork后读取内存数据并写入rdb文件（替换旧的rdb）。
共享：子进程拷贝主进程的页表，子进程操作自己的虚拟内存时，映射到跟主进程雷同的物理内存区域。只有fork时，必要对主进程阻塞（拷贝虚拟页表）。

如果子进程读取数据时，主进程在修改数据怎么办？
fork采取的是copy-on-write技术。主进程要写一块数据时，拷贝一份原数据的副本，子进程读取副本数据，同时主进程可以在原来的数据上写。
极度情况下，全部数据都要修改，都有拷贝，占用极大的内存。

什么时间会实行bgsave？

在快照时服务崩溃怎么办？

在快照操作过程中不能影响上一次的备份数据。Redis服务会在磁盘上创建一个临时文件进行数据操作，待操作成功后才会用这个临时文件替换掉上一次的备份。
4.3 rdb的缺点

RDB方式实时性不够，无法做到秒级的长期化（只能恢复快照之前的数据）；
每次调用bgsave都必要fork子进程，fork子进程属于重量级操作，频仍实行成本较高；
4.4 rdb的优点

快照使用的算法大大压缩了文件大小，用于备份、全量复制等场景；
Redis加载RDB文件恢复数据要远远快于AOF方式；
5.AOF长期化

5.1界说

Append only file（追加文件）。Redis处理的每一个写下令都会追加在aof文件，可以看作是下令的日记文件。恢复时读取aof的下令并实行。
5.2 配置

在配置文件中开启

先写到缓冲区，缓冲区在内存中，到时间再写到磁盘中。
5.3 为相识决AOF文件体积膨胀的问题，Redis提供AOF文件重写机制

因为记录下令，所以aof文件比rdb大很多。
实行bg rewrite aof，消除冗余下令，用最少的下令完成一样的结果。比如对同一个key的多次写，只有最后一次写是有意义的。
实行过程：AOF重写过程是由背景子进程完成的。主线程fork出背景的bgrewriteaof子进程，bgrewriteaof子进程拷贝一份主进程的内存，这里包含了最新数据。然后，bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日记。

6.RDB和AOF对比

总结：rdb文件体积小，启动快，数据不完整，占用资源多。
7.RDB和AOF混合方式

Redis 4.0 中提出了一个混合使用 AOF 日记和内存快照的方法。
简单来说，内存快照以肯定的频率实行，在两次快照之间，使用 AOF 日记记录这期间的全部下令操作。

8.两者都有时，怎样从长期化中恢复数据？

优先加载aof。因为AOF保存的数据更完整。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。