Redis持久化机制
1、Redis持久化
问题
问：把服务端关闭了，再重新开启服务器，数据会不会丢失？
会部分丢失，因为默认redis服务器每隔一段时间写入一次内存中数据到硬盘上。
概述
什么是Redis的持久化：
Redis是一个内存存储的数据库，内存必须在通电的情况下才能够对数据进行存储。如果 ，在使用redis的过程中突然发生断电，数据就会丢失。为了防止数据丢失，redis提供了数据持久化的支持。
持久化：把内存中的数据保存到硬盘上。
作用：防止数据在断电的情况下丢失。
redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持两种持久化方式，一种是RDB(快照)也是默认方式，另一种是Append Only File(缩写AOF)的方式。下面分别介绍：
注意：redis将内存中数据，写在硬盘文件上。服务器关闭，电脑重启数据也不会丢失。
Redis持久化的两种方式：
- RDB：Redis DataBase 默认的持久化方式，以二进制的方式将数据写入文件中。每隔一段时间写入一次。
- AOF：Append Only File 以文本文件的方式记录用户的每次操作，数据还原时候，读取AOF文件，模拟用户的操作，将数据还原。
2、RDB持久化介绍[了解]
RDB是默认的持久化方式。这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为：dump.rdb。
补充：快照：当前内存中数据的状态。
可以通过配置设置自动做快照持久化的方式。如下面配置的是RDB方式数据持久化时机，必须两个条件都满足的情况下才进行持久化的操作：
| 关键字 | 时间(秒) | 修改键数 | 解释 |
|---|---|---|---|
| save | 900 | 1 | 到了15分钟修改了1个键，则发起快照保存 |
| save | 300 | 10 | 到了5分钟修改了10个键，则发起快照保存 |
| save | 60 | 10000 | 到了1分钟，修改了1万个键，则发起快照保存 |
缺点:
可能导致数据丢失。因为RDB是每隔一段时间写入数据，所以系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
优点:
持久化效率高,持久化的是内存中的数据
数据库宕机后，数据恢复的效率要更高；
3、AOF的存储方式[了解]
AOF持久化简介
由于快照方式是在一定间隔时间做一次的，所以如果redis宕机，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用AOF持久化方式。
AOF指的是Append only file,使用AOF持久化方式时，redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof).当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。也可以通过该文件完成数据的重建。该机制可以带来更高的数据安全性，所有的操作都是异步完成的。
| Redis中提供了3种同步策略 | 说明 |
|---|---|
| 每秒同步 | 每过一秒记录一次 |
| 每修改同步 | 每次修改(增删改)都会记录一次 |
| 不同步 | 由系统记录操作 |
AOF持久化机制配置
开启AOF持久化
AOF默认是关闭的，首先需要开启AOF模式
| 参数配置 | 说明 |
|---|---|
| appendonly no/yes | 默认是no，关闭。如果要打开，设置成yes。 |
AOF持久化时机
| 关键字 | 持久化时机 | 解释 |
|---|---|---|
| appendfsync | everysec | 每秒记录 |
| appendfsync | always | 每修改记录 |
| appendfsync | no | 完全依赖操作系统，性能最好，持久化无法保证 |
everysec：每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中。
always：收到写命令就立即写入磁盘，最慢，但是保证完全的持久化。
no：完全依赖操作系统，性能最好，持久化无法保证。
演示：AOF的持久化
-
打开AOF的配置文件redis.conf，设置appendonly yes
-
通过./redis-server redis.conf启动服务器，在服务器目录下出现appendonly.aof文件。大小是0个字节。
-
添加3个键和值
-
打开appendonly.aof文件，查看文件的变化。会发现文件记录了所有操作的过程。
说明：
1.*2表示有两个命令 select 0 选择第一个数据库
2.$6表示select 有六个字符 1 表示0有一个字符
小结
- AOF是的格式：文本文件
- 文件名: appendonly.aof
- 三种配置策略
- 每秒记录
- 每修改记录
- 不记录
4.Redis持久化机制RDB和AOF的区别
1.RDB持久化机制优点和缺点
优点
-
方便备份与恢复
-
启动效率更高
相比于AOF机制，如果数据集很大，RDB的启动效率会更高。因为RDB文件中存储的是数据，启动的时候直接加载数据即可，而AOF是将操作数据库的命令存放到AOF文件中，然后启动redis数据库服务器的时候会将很多个命令执行加载数据。如果数据量特别大的时候，那么RDB由于直接加载数据启动效率会比AOF执行命令加载数据更高。
- 性能最大化
对于Redis的服务进程而言，在开始持久化时，会在后台开辟子线程，由子线程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
缺点
- 不能完全避免数据丢失
因为RDB是每隔一段时间写入数据，所以系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
- 会导致服务器暂停的现象
由于RDB是通过子线程来协助完成数据持久化工作的，因此当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
就是数据量过大，会开辟过多的子线程进行持久化操作，那么会占用服务器端的大量资源，那么有可能会造成服务器端卡顿。同时会造成服务器停止几百毫秒甚至一秒。
2.AOF持久化机制优点和缺点
优点
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。也可以通过该文件完成数据的重建。该机制可以带来更高的数据安全性，所有的操作都是异步完成的。
缺点
-
运行效率比RDB更慢：根据同步策略的不同，AOF在运行效率上往往会慢于RDB。
-
文件比RDB更大：对于相同数量的数据集而言，AOF文件通常要大于RDB文件。
一般在企业开发中两种持久化机制会配合着使用。