Redis数据结构以及RDB、AOF原理介绍

1. redis (核心数据结构和应用场景,AOF)

在我们安装了redis之后，所有的配置都是在redis.conf文件中，里面保存了RDB和AOF两种持久化机制的各种配置

数据结构

字符串(string)： 二进制安全的，最大存储512M数据

redis 127.0.0.1:6379> SET runoob "菜鸟教程"
OK
redis 127.0.0.1:6379> GET runoob
"菜鸟教程"

列表(list)： 列表是简单的字符串列表，按照插入顺序排序

redis 127.0.0.1:6379> lpush runoob redis
(integer) 1
redis 127.0.0.1:6379> lpush runoob mongodb
(integer) 2
redis 127.0.0.1:6379> lpush runoob rabitmq
(integer) 3
redis 127.0.0.1:6379> lrange runoob 0 10
1) "rabitmq"
2) "mongodb"
3) "redis"
redis 127.0.0.1:6379>

哈希(hash)： hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象

redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> HMSET runoob field1 "Hello" field2 "World"
"OK"
redis 127.0.0.1:6379> HGET runoob field1
"Hello"
redis 127.0.0.1:6379> HGET runoob field2
"World"

集合(set)： Redis 的 Set 是 string 类型的无序集合，数据具有唯一性，忽略第二次sadd

redis 127.0.0.1:6379> sadd runoob redis
(integer) 1
redis 127.0.0.1:6379> sadd runoob mongodb
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 0
redis 127.0.0.1:6379> smembers runoob
1) "redis"
2) "rabitmq"
3) "mongodb"

有序集合(zset)： zset 和 set 一样也是string类型元素的集合,且不允许重复的成员，不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序，zset的成员是唯一的,但分数(score)却可以重复。

redis 127.0.0.1:6379> zadd runoob 0 redis
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 mongodb
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 0
redis 127.0.0.1:6379> > ZRANGEBYSCORE runoob 0 1000
1) "mongodb"
2) "rabitmq"
3) "redis"

2. Redis中的两种持久化机制：RDB(Redis DataBase)和AOF(Append Only File)

数据保存的五个过程：
（1）客户端向服务端发送写操作(数据在客户端的内存中)。
（2）数据库服务端接收到写请求的数据(数据在服务端的内存中)。
（3）服务端调用write这个系统调用，将数据往磁盘上写(数据在系统内存的缓冲区中)。
（4）操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。
（5）磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。
 
可能产生的问题：
（1）Redis数据库发生故障，只要在上面的第三步执行完毕，那么就可以持久化保存，剩下的两步由操作系统替我们完成。
（2）操作系统发生故障，必须上面5步都完成才可以。
此处只考虑第一种，因为第二种需要一定的操作系统层面的恢复机制

RDB(Redis DataBase)机制

概念： 将Redis数据在指定的时间间隔内，以快照的形式保存到磁盘上，生成dump.rdb。
触发机制：
（1）save触发方式
  手动执行save命令触发。此命令会阻塞Redis服务器，直到命令执行结束

 
（2）bgsave触发
  手动执行bgsave命令触发，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

（3）自动化触发
  redis.conf文件中配置保存机制，

eg：
save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存

save和bgsave的区别

 
RDB的优势和劣势
优势
（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

劣势
RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

AOF(Append Only File)机制

概念： Redis会将所有的写操作通过write函数追加到aof文件中，类似于日志记录。

AOF产生的问题 ：持久化生成的文件会随着时间的推移越来越大。
解决方式
  Redis提供了一个 bgrewriteaof 命
   命令作用：将Redis数据保存到临时文件，并fork除一个子进程，将aof文件重写，重写的数据来源：内存中的数据库内容
 
AOF的三种触发机制
（1）每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
（2）每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失
（3）不同no：从不同步

三者的比较

AOF的优势和劣势
优势
  （1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
  （2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
  （3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
  （4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。

劣势
  （1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
  （2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。
  （3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。

RDB和AOF到底该如何选择

一般结合使用

内容参考：
https://baijiahao.baidu.com/s?id=1654694618189745916&wfr=spider&for=pc
https://www.runoob.com/redis/redis-tutorial.html
https://www.cnblogs.com/ysocean/p/9114268.html