redis高级篇(1)----redis的持久化

分布式缓存

单节点redis的问题:

1)数据丢失的问题，redis是基于内存来进行存储的，当服务器重启的时候可能会丢失数据

2)无法满足高并发场景

3)如果redis宕机，那么这个服务不可用，所以就需要有一种自动的故障恢复手段，必须保证redis集群中的某一个服务出现故障，是不能影响其他集群的使用的，边服务边修复；

4)Redis是基于内存来进行存储的，单个节点存储的数据是很难满足海量数据的需求的；

4.1)数据丢失问题:实现Redis持久化

4.2)并发能力问题:搭建主从集群，实现读写分离，从节点是具有很多个的，那么从节点之间就是一种负载均衡的策略，而主从之间又需要做读写分离，是应对数据库中读和写的这种互斥，读和写之间就不会相互影响，还要依靠哨兵机制来做健康检测和故障恢复；

4.3)存储能力问题:搭建分片集群，利用插槽机制来实现动态扩容

Redis是一种内存数据库，我们运行使用的时候数据是在内存的，如果我们的缓存在内存里面突然因为服务器断电缓存消失了，那么所有的数据都打到MYSQL上面；

一)Redis持久化方式---RDB

RDB全称为Redis Database Backup file也被称之为是Redis数据快照和Redis备份文件，简单来说就是把内存中的所有数据都保存到磁盘里面，当Redis进行实例故障重启之后，再从磁盘读取快照文件，恢复数据，磁盘文件被称为快照文件又被称为是RDB文件，默认是保存在Redis的当前运行目录，这个快照文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时Redis中的数据

1)save:此命令就成功完成了RDB操作，这个操作是由Redis的主进程来执行命令的，此时主进程会阻塞所有命令，这个时候如果由用户来进行读操作，无法执行成功，RDB是将数据写入到磁盘里面，但是磁盘的IO往往是比较慢，如果你的数据量比较大，那么执行这个操作的耗时就会比较久，等待它执行完成，最终才会返回一个OK，此时才算结束，主进程才有能力处理其他的命令，主要是适用于Redis进程用完了，进程终止，马上就要停机，不想玩了，****redis在停机之前及时会自动进行RDB操作，保存在运行目录，当进行启动redis，自动执行恢复数据；

2)bgsave:异步持久化，redis此时会立即返回一个Background saving started，后台保存开始了，异步执行，redis会是开启一个子进程来进行执行RDB操作，避免主进程受到影响，这种方式比较适用于Redis在进行运行的过程时候去做；

如果redis服务器突然宕机了，来不及做数据备份怎么办呢？

3)Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下:

save 5 1代表5s内只要有一个Key被修改就会自动执行RDB操作，这样每隔一段时间就进行一次RDB，那么数据的持久性就可以得到保障了，在服务器关机前会执行RDB操作，时间设置怎么办？

4)但是如果说在5s之内进行数据的保存工作，这时刚好没持久化，服务器宕机，那么数据会丢失，如果你RDB设置时间太长你没有及时在服务器宕机之前进行持久化操作，那么数据会丢失，但是太短也不行，RDB执行频率过高，如果数据量特别大，数据量如果是10G，那么写入到磁盘，时间IO会吃满，所以使用RDB是存在问题的；

5)RDB中的其他配置也是可以在redis.conf中进行配置的

1)这里有一个小坑，就是如果你修改完毕dbfilename之后，你再次重启你的Redis你会发现你的数据都消失了，原因是因为Redis会去配置文件中的dbfilename中查找他的RDB文件，根据这个名称去寻找这个文件，如果找到了就从中读取数据进行数据恢复，而由于你修改了这个名称，所以你再次重启的时候Redis发现没有这个文件，因此Redis会创建这个文件，并重新开始向其中记录数据，因此你原有的数据还在dump.rdb这个文件中，只不过新的数据都会记录到新的RDB文件中

2)载入RDB文件的目的是为了在Redis服务器进程重新启动之后还原之前存储在Redis中的数据，并且Redis并没有提供从RDB文件中读取数据的命令，而是每次启动Redis他都会从当前配置文件中对应的RDB文件中进行数据读取，Redis也已经在启动Redis服务的时候告诉你这一点了

当然，Redis服务器启动时是否会载入RDB文件还取决于服务器是否启用了AOF持久化功能，具体判断逻辑为：

1)只有在AOF持久化功能处于关闭状态时，Redis才会使用RDB文件来还原数据
2)如果服务器开启了AOF持久化功能，那么Redis会优先使用AOF文件来还原数据
当然，AOF持久化功能默认是关闭的，因此默认情况下Redis都是通过RDB文件来载入数据

1)在bgsave开始的时候，会fork主进程得到子进程，子进程共享主进程中的内存数据，完成fork之后子进程会读取内存数据写入到RDB文件里面，主进程会开启一个子进程来完成对内存数据的读取并写入到RDB文件中，因为它是异步操作，几乎做到对主进程的0阻塞，fork主进程得到子进程的过程是阻塞的，此时主进程只能创建子进程，不能接受用户发送的其他命令，所以说fork的速度要足够快才能让主进程，避免阻塞太长时间，才能让主进程尽快地去完成用户的请求；

2)在Linux系统中，所有的进程都无法直接操作物理内存，而是由操作系统给每一块物理内存分配虚拟内存空间，而主内存只能操作虚拟内存，而操作系统本身会维护一个虚拟内存和物理内存之间的映射关系表，就称之为是页表

3)在我们进行fork的时候，父进程会创建出子进程，然后父进程会把这个页表拷贝给子进程，这样父进程和子进程操作的是同一块虚拟内存空间

4)既然是异步操作，那么子进程在进行写RDB操作的时候，父进程也是可以接受用户的请求来去修改内存中的数据，那么如果此时父进程再进行修改，而子进程在进行读取，那么父子进程之间的读和写就会产生互斥，甚至可能会出现脏数据；

5)在fork里面采用的是copy-on-write技术，任何一个进程只能读取物理内存的数据，任何进程不能进行修改操作；

5.1)当主进程进行执行读操作的时候，会进行访问共享内存

5.2)挡住进程进行写操作的时候，会拷贝一份数据，再去执行写操作

5.3)假设主进程在进行写操作的时候，想要写B，就会将B的内存数据在物理内存中拷贝一份，写B的话，直接在新的物理内存中写，读取的话，也是在新的物理内存中读，这时页表的映射关系就发生了改变；

5.4)假设RDB子进程写的速度比较慢，耗时比较久，而在子进程写的过程中，不断有新的请求发送到父进程，不断的有请求想要进行修改redis的操作，那么就意味着所有的数据要拷贝一份新的，那么redis对于内存的占用就会翻倍，极端情况下，所以一般时候redis会留出出一些内存空间；

1)RDB方式的bgsave的执行流程:

1)fork主进程得到一个新的子进程，会拷贝一份页表，这时主进程和子进程会共享同一份内存空间;

2)子进程会读取内存数据并写入到新的RDB文件里面，进行异步的写到磁盘空间中；

3)使用新的RDB文件替换旧的RDB文件；

2)RDB会在什么时候执行？

1)save的执行是在服务停机的那一刻去执行，它是阻塞式的；

2)使用bgsave，save 60 100指的是60s内至少执行1000次修改操作触发RDB，bgsave

3)RDB的缺点

3.1)save 60 100，那么如果你的redis服务器在还没有进行RDB操作的时候宕机了怎么办？时间设置太长会出现在指定时间内如果redis服务器宕机就会导致这段时间之内的写操作全部失效，间隔时间太长就会导致两次RDB操作写入数据有丢失的风险

3.2)如果时间太短如果数据量过大就会造成磁盘IO吃满的情况；

3.3)fork子进程，压缩，写入RDB文件都是比较耗时的；

二)Redis持久化方式---AOF

AOF操作又被称之为是Append Only File也被称之为是追加文件，Redis中的接收每一个命令和命令的长度都会记录在AOF文件中，可以看作是命令日志文件，因为它是在不断记录新的命令而不是像RDB一样从头开始把整个内存都去写一下，所以这种文件逐渐累积；

如果将来Redis出现了故障，要进行恢复，我们就可以直接读取AOF文件，AOF中所有的命令再次执行一遍，那么数据一定是可以恢复到原来的状态了，但是这种方式默认是关闭的

AOP命令记录的频率也是可以通过redis.conf这个文件来进行配置:

1)表示每Redis执行一次写内存操作，就立即记录到AOF文件中:appendfsync always

这个操作都是由redis的主进程来进行完成的，主进程执行完命令之后，先进行写内存，在把命令写磁盘，这两个动作必须一起完成，那么这个请求才算处理完毕，才可以返回给用户；

这种操作数据安全性是可以得到绝对的保障的，写内存和写磁盘是在同步进行的，性能最差

2)写命令执行完要先放到AOF缓冲区，然后表示每隔1S钟将缓冲区数据写入到AOF文件中，默认方案:appendfsync everysec；

也就是说当我们的主进程接收到redis命令的时候，不会把这个命令立即写入到磁盘里面，而是先处理完这个命令，把它放到缓冲区里面去，每隔1s钟写一次，仍然是内存的方式读写，效果还是比第一种方式要好的，但是在这1S间隔之间，有服务出现了宕机的情况，那么数据就丢失了，那么他最多会丢失1s钟之内的操作，牺牲了一定的内存可靠性，但是性能方面会有很大的提升；

3)写命令执行完先放到AOF缓冲区，再由操作系统决定何时将缓冲区内容写入到磁盘里面

我们的主进程只是进行处理内存数据，然后写到AOF缓冲区，操作系统会定期的把AOF缓冲区里面的数据写入到磁盘里面，频率往往会低一点，每隔很长时间才会写一次，写磁盘的次数越低，那么效率也会越高，所以说性能最好，但是安全性最低

appendfsync everysec:no

进行演示一下AOF的配置

1)先暂时禁止使用RDB，save ""；

2)先将appendonly yes开启AOF方式；

3)使用appendfsync everysec；

4)重启redis；

5)通过cat命令就可以查看AOF文件了；

通过find / -name appendonly.aof可以帮助我们快速的找到aof文件

1)AOF文件确实可以做到将每一个文件都记录下来，但是set name zhangsan，set name lisi是记录了两次，因为AOF是命令我就会记录，那么假设如果我针对name设置了N次，AOF文件里面就会记录N次，但是只是最后一次修改是有效的，前面的操作没什么卵用，但是RDB文件只是记录了内存中的值，要是RDB文件的话，只是记录一个name=666，所以总结RDB文件一定比AOF文件小很多，AOF记录的是操作，针对一个变量可以进行多次操作，但是RDB记录的是值，一个变量只能有一个值；

2)因为是记录命令，所以AOF文件要比RDB文件大的很多，而且AOF会进行记录针对于同一个Key的多次写操作，但是只是最后一次写操作才是有效的，才会有意义，所以可以通过执行bgrewriteof命令来开启一个独立进程进行让AOF执行重写命令，可以让AOF文件执行重写功能，用最少的命令来达到相同的效果，编码处理和压缩，所以让文件体积变小了很多，即便如此AOF的文件仍然比RDB要大

3)同时Redis也会在出发阈值的时候去重写AOF文件，与之也是可以在redis.conf中进行配置

3.1)AOF文件相比于上次文件增长百分比超过多少会触发重写操作

auto-aof-rewrite-percentage 100

3.2)AOF文件体积最小多大以上会触发重写操作

auto-aof-rewrite-min-size 64mb

3.3)RDB和AOF各有自己的优缺点，如果对数据安全性比较高，往往在实际开发中结合两者来进行使用；

1)对于持久化方式来说，RDB会针对整个内存做快照，内存什么样子，就写什么样子，写入到磁盘，而AOF记录的仅仅就是命令，会记录每一次Redis执行的命令，因为命令所占用的内存空间要大于数据，所以AOF的文件大小往往大于RDB；

2)RDB宕机启动速度比较快，因为RDB文件中存放的是二进制数据，那么在开机之后直接将RDB中的文件加载内存里面就可以了，而AOF执行的是命令，宕机重启之后会把所有的命令执行一遍，所以启动速度和恢复速度比较慢；

3)针对于数据恢复优先级来说，就是意味着同时启用了RDB和AOF，Redis同时拥有这两个RDB和AOF文件，那么Redis在进行启动的时候，会以AOF优先来进行恢复，RDB只是做一个备份，如果AOF不存在，才使用RDB；

4)在针对于系统调用来说，内存和CPU资源都会消耗极高，在做fork的时候，CPU消耗比较大，还有做数据的拷贝；对于AOF来说要进行大量的磁盘写入操作，磁盘IO比较多，也是一个异步；

1)关系型数据库MYSQL通常都是执行命令前记录日志，方便于故障恢复，但是RedisAOF持久化机制是在执行完命令之后再去记录日志；

2)为什么是在执行完命令之后再去记录日志呢？

2.1)避免额外的检查开销，AOF记录日志不会对命令做语法检查

2.2)在命令执行完成之后进行记录，不会阻塞当前的命令执行

但是这样也会存在一定的风险，如果刚执行完命令Redis就宕机会导致对应的修改丢失，还有可能会导致阻塞后续其他命令的执行，因为AOF记录日志是在主线程中执行的

3)由于AOF是记录命令，因此AOF文件会比RDB文件大得多。而且AOF会记录对同一个key的多次写操作，即使其实只有最后一次写操作有意义,通过bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到一样的效果
例如对同一个name的操作，使用bgrewriteaof之后，本来记录三次的命令，直接会变成记录最后一次的命令

4)因为AOF文件要比RDB文件要大得多，所以AOF提供了一种重写机制，当AOF文件太大的时候，Redis可以在后台自动重写AOF来产生一个新的AOF文件，这个新的AOF文件和原来的AOF文件所保存的数据库文件相同，但是体积更小

5)AOF重写功能是独立开启一个子进程来进行来进行读取数据库中的键值对来实现的，程序无需对现有的AOF文件进行任何的读入，分析或者写入操作，

AOF 重写过程是由后台进程 bgrewriteaof 来完成的，主线程 fork 出后台的 bgrewriteaof 子进程，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据，然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志，所以 AOF 在重写时，在 fork 进程时是会阻塞住主线程的

6)在我们进行执行bgrewriteaof命令操作的时候，Redis服务器会维护一个AOF重写缓冲区，该缓冲区会在AOF进行执行创建新的AOF文件期间，会进行记录服务器执行的所有写命令，当子进程进行完成创建新的AOF的保存工作，服务器会将重写缓冲区中的所有内容给追加到AOF的末尾，使得新的AOF文件保存的数据库状态和现有的数据库状态是一致的，最后，服务器用新的 AOF 文件替换旧的 AOF 文件，以此来完成 AOF 文件重写操作；

7)因为AOF文件包含了重建数据库所需的所有写命令，所以Redis服务器只要读入并重新执行一遍AOF文件里面保存的写命令，就可以还原Redis服务器关闭之前的数据；

8)假设我们向list集合里面新增了1 2 3 4 5

lpush list 1 2 3 4 5

lpop list---出来的元素是 5

lpop list----出来的元素是4

lpop list----出来的元素是3

lpush 6 7，现在集合中的元素就是7 6 1 2 3

那么此时的AOF文件只需要进行记录rpush 7 6 1 2 3就可以了，那么就一下子把多余的几条命令给去除了；

9)AOF文件后台重写的步骤如下所示：

9.1)服务器进程创建子进程，子进程开始AOF文件重写
9.2)从创建子进程开始，服务器进程执行的所有写命令不仅要写入AOF缓冲区，还要写入AOF重写缓冲区，写入AOF缓冲区的目的是为了同步到原有的AOF文件
9.3)写入AOF重写缓冲区的目的是因为子进程在进行AOF文件重写期间，服务器进程还在继续处理命令请求，而新的命令可能会对现有的数据库进行修改，从而使得服务器当前的数据库数据和重写后的AOF文件所保存的数据库数据不一致,这也就是上面说的在Redis7.0之前会有两份的数据
9.4)子进程完成AOF重写工作，向父进程发送一个信号，父进程在接收到该信号后，会执行以下操作：
1)将AOF重写缓冲区中的所有内容写入到新AOF文件中，这样就保证了新AOF文件所保存的数据库数据和服务器当前的数据库数据是一致的
2)对新的AOF文件进行改名，原子地覆盖现有的AOF文件，完成新旧两个AOF文件的替换。
Redis提供了BGREWRITEAOF命令来执行以上步骤

redis混合持久化:

http://t.csdn.cn/8kZv8

通过下面命令来进行开启混合持久化:config get aof-use-rdb-preamble

其中 yes 表示已经开启混合持久化，no 表示关闭，Redis 5.0 默认值为 yes。如果是其他版本的 Redis 首先需要检查一下，是否已经开启了混合持久化，如果关闭的情况下，可以通过以下两种方式开启：

1)通过命令行开启

2)通过修改 Redis 配置文件开启

在 Redis 的根路径下找到 redis.conf 文件，把配置文件中的 aof-use-rdb-preamble no 改为 aof-use-rdb-preamble yes 如下图所示