Redis数据结构和持久化

参考资料：
https://www.cnblogs.com/ciel717/p/16466230.html
https://www.cnblogs.com/lzh1995/p/16757991.html

Redis数据类型

Redis 是 key-value 存储数据库，所有的 key 都是字符串，谈论的数据类型是 value 的类型。基础数据类型有以下五种：

String

定义：String 是redis最基本的类型，一个键最大能存储512MB,value 不仅可以是 String,也可以是数字；使用 Strings 类型,可以完全实现目前 Memcached 的功能,并且效率更高。还可以享受 Redis 的定时持久化(可以选择 RDB 模式或者 AOF 模式)；

应用场景：缓存对象、常规计数、分布式锁、共享 session 信息等。

常用命令：

• SET key value ：设置指定 key 的值
• SETNX key value ：只有在 key 不存在时才设置
• GET key：获取指定 key 的值
• MSET key1 value1 key2 value2 ...：一次性设置多个键的值
• MGET key1 key2 ...：一次获取多个键的值
• EXISTS key：判断指定的 key 是否存在
• DEL key：删除指定的 key
• EXPIRE key seconds：给指定 key 设置过期时间

Hash 哈希

定义：哈希类型是指v（值）本身又是一个键值对（k-v）结构，Redis hash 是一个string类型的field和value的映射表，适合用于存储对象；Redis中每个hash可以存储2的32次方-1个键值对（40多亿）

应用场景：缓存对象、购物车等。

常用方法：

• HSET/HSETNX key filed value：设置 哈希表 key 中指定键的值 / 只有指定键不存在时才设置

• HMSET key filed1 value1 field2 value2：在哈希表 key 中设置若干个键值对

• HGET key field：获取 哈希表 key 中字段 field 的值

• HMGET key field1 field2：获取哈希表 key 中多个字段的值

• HGETALL key：获取哈希表 key 中 所有的键值对

• HEXISTS key field：查看哈希表 key 中字段 field 的值 是否存在

• HDEL key field1 field2：删除 哈希表 key 中若干个字段

• HLEN key：获取哈希表 key 中 字段的数量

List 列表

定义：列表类型可以存储一个有序的字符串列表，常用的操作是向列表两端添加元素，或者获得列表的某一个片段；列表类型内部是使用双向链表实现的，所以向列表两端添加元素的时间复杂度为O（I），获取越接近两端的元素，速度就越快。

应用场景：消息队列（但是有两个问题：1. 生产者需要自行实现全局唯一 ID；2. 不能以消费组形式消费数据）等。

常用命令：

• RPUSH/LPUSH key value1 value2：在列表 key 的尾部 / 头部添加若干个元素

• LSET key index value：将列表 key 的 index 位置的值设置为 value

• LPOP/RPOP key：移除并获取指定列表的头部 / 尾部元素

• LLEN key：获取列表元素的数量

• LRANGE key start end：获取列表 key 的区间 [start, end] 之间的元素（-1 表示最后一个元素）

• 用作队列：RPUSH/LPOP，或者 LPUSH/RPOP

• 用作栈：RPUSH/RPOP，或者 LPUSH/LPOP

Set 集合

定义：在集合中的每个元素都是不同的，且没有顺序。集合类型的常用操作是向集合中加入或删除元素、判断某个元素是否存在（List 没有该方法）等，由于集合类型在Redis内部是使用值为空的散列表（hash table）实现，所以这些操作的时间复杂度都是O(I)
集合与列表的区别：列表具有有序性，集合具有唯一性。

应用场景：聚合计算（并集、交集、差集）场景，比如点赞、共同关注、抽奖活动等

常用方法：

• SADD key elem1 elem2：向集合 key 添加 若干元素

• SMEMBERS key：获取集合 key 中 所有元素

• SCARD key：获取指定集合中的 元素数量

• SISMEMBER key elem：判断指定元素 是否存在 于集合中

• SINTER/SUNION/SDIFF key1 key2 ...：求若干个集合的 交集 / 并集 / 差集

• SINTERSTORE/SUNIONSTORE/SDIFFSTORE destination key1 key2 ...：将若干个集合的交集 / 并集 / 差集存储到 destination 中

• SPOP key count：随机移除并获取 集合中 count 个元素

• SRANDMEMBER key count：随机获取 集合中 count 个元素

Zset（Sorted set：有序集合）

定义：在集合类型的基础上有序集合类型为集合中的每个元素都关联了一个分数，这使得我们不仅可以完成插入，删除和判断元素是否存在等集合类型支持的操作，还能够获得分数最高（或最低）的前N个元素，获得指定分数范围内的元素等与分数有关的操作。虽然集合中每个元素不同，但是他们的分数可以相同。

有序集合与列表比较：
1、相似处：
    1、二者都是有序的。
    2、二者都可以获得某一范围的元素。

2、区别：
    1、列表类型是通过链表实现，获取靠近两端的数据速度快，当元素增加后，访问中间数据的速度会变慢。
    2、有序集合类型是使用散列和跳跃表实现的，所以即使读取位于中间部分的数据速度也很快（时间复杂度O（log（N）））。
    3、列表中不能简单的调整某个元素的位置，但是有序集合可以
    4、有序集合要比列表类型更消耗内存。

应用场景：排序场景，比如排行榜、电话和姓名排序等。

常用方法：

• ZADD key score1 elem1 score2 elem2：向有序集合 key 中添加若干元素（同时为每个元素指定 score）

• ZCARD key：获取元素数量

• ZSCORE key elem：获取指定元素的 score 值

• ZRANGE/ZREVRANGE key start end：获取排名在 [start, end] 之间的元素，升序 / 降序排列

• ZRANK/ZREVRANK key elem：获取指定元素的排名（分别在升序 / 降序排列情况下）

• ZINTERSTORE/ZUNIONSTORE/ZDIFFSTORE dest numkeys key1 key2：将给定的 numkeys 个有序集合的交集 / 并集 / 差集存储到 dest 中，同时对相同元素的 score 相加。

Redis持久化

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。 Redis的持久化机制有两种：

• RDB(Redis DataBase) 内存快照
• AOF(Append Only File) 增量日志

RDB（内存快照）

RDB是在指定的时间间隔内,以内存快照（内存数据的二进制序列化形式）的方式持久化，每次都是从Redis中生成一个快照进行数据的全量备份。

1、简介

RDB持久化方案进行备份时，Redis会单独fork一个子进程来进行持久化，会将数据写入一个临时文件中，持久化完成后替换旧的RDB文件。在整个持久化过程中，主进程（为客户端提供服务的进程）不参与IO操作，这样能确保Redis服务的高性能，RDB持久化机制适合对数据完整性要求不高但追求高效恢复的使用场景。

2、Fork

RDB持久化过程中，主进程会fork一个子进程来负责RDB的备份，这里简单介绍一下fork。

• Linux操作系统中的程序，fork会产生一个和父进程完全相同的子进程。子进程与父进程所有的数据均一致，但是子进程是一个全新的进程，与原进程是父子进程关系
• 出于效率考虑，Linux操作系统中使用COW(Copy On Write)写时复制机制，fork子进程一般情况下与父进程共同使用一段物理内存，只有在进程空间中的内存发生修改时，内存空间才会复制一份出来。

Redis在RDB持久化时调用glibc函数fork一个子进程，全权负责持久化工作，这样父进程仍然能继续给客户端提供服务。fork的子进程初始时与父进程（Redis的主进程）共享同一块内存；当持久化过程中，客户端的请求对内存中的数据进行修改，此时就会通过COW机制对数据段页面进行分离，也就是复制一块内存出来给主进程去修改。

3、触发规则

RDB有手动触发和自动触发：

• 自动触发：

  • 配置触发规则
  • shutdown触发
  • flushall触发

• 手动触发：

  • save命令
  • bgsave命令

自动触发

配置规则触发
在Redis安装目录下的redis.conf配置文件中，默认注释了下面三行数据，通过配置规则来触发RDB的持久化

# RDB核心规则配置
# 满足条件就将内存中的数据同步到硬盘中。若不想用RDB方案，可以把`save ""`的注释打开，下面三个注释
# save ""
# save <指定时间间隔> <执行指定次数更新操作>
save 3600 1 -> 3600 秒内有1个key被修改，触发RDB
save 300 100 -> 300 秒内有100个key被修改，触发RDB
save 60 10000 -> 60 秒内有10000个key被修改，触发RDB

配置RDB文件的存储路径

#数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
dir /usr/local/redis/var

shutdown触发
shutdown触发Redis的RDB持久化机制非常简单，在客户端执行shutdown即可。

flushall触发
flushall命令是清空redis内存中的数据，并且同时清空dump.rdb文件。所以这个命令就相当于删库跑路，此处只是说明该命令会触发rdb，实际使用中千万不要执行。

手动触发

手动触发RDB持久化的方式可以使用save命令和bgsave命令，这两个命令的区别如下。

• save：执行save指令，阻塞Redis的其他操作，会导致Redis无法响应客户端请求，不建议使用。
• bgsave：执行bgsave指令，Redis后台异步进行快照的保存操作，此时Redis仍然能响应客户端的请求。

RDB优缺点

优点 ：

• 存储紧凑，节省内存空间
• 恢复速度非常快
• 适合全量备份、全量复制的场景，经常用于灾难恢复（对数据的完整性和一致性要求相对较低的场合）

缺点：

• 容易丢失数据，容易丢失两次快照之间Redis服务器中变化的数据。
• RDB通过fork子进程对内存快照进行全量备份，是一个重量级操作，频繁执行成本高。
• fork子进程，虽然共享内存，但是如果备份时内存被修改，最大可能膨胀到2倍大小。

AOF(增量日志)

AOF(Append Only File)是把所有对内存进行修改的指令（写操作）以独立日志文件的方式进行记录，重启时通过执行AOF文件中的Redis命令来恢复数据。

简介

Redis配置文件中开启AOF持久化方案进行备份时，客户端所有请求的写命令都会被追加到AOF缓冲区中，缓冲区中的数据会根据Redis配置文件中配置的同步策略来同步到磁盘上的AOF文件中，同时当AOF的文件达到重写策略配置的阈值时，Redis会对AOF日志文件进行重写，给AOF日志文件瘦身。Redis服务重启的时候，通过加载AOF日志文件来恢复数据。

AOF日志是以文件的形式存在的，当程序对AOF日志文件进行写操作时，实际上将内容写到了内核为文件描述符分配的一个内存缓冲区中，随后内核会异步的将缓冲区中的数据刷新到磁盘中。如果缓冲区中的数据没来得及刷回磁盘时，服务器宕机了，这些数据就会丢失。

因此Redis通过调用Linux操作系统的glibc提供的fsync(int fid)来将指定文件的内容强制从内核缓冲区刷回磁盘，以此来保证缓冲区中的数据不会丢失。不过这是一个IO操作，相比Redis的性能来说它是非常慢的，所以不能频繁的执行。

Redis配置文件中有三种刷新缓冲区的配置：

• appendfsync always
  每次Redis写操作，都写入AOF日志，这种配置理论上Linux操作系统扛不住，因为Redis的并发远远超过了Linux操作系统提供的最大刷新频率，就算Redis写操作比较少的情况，这种配置也是非常耗性能的，因为涉及到IO操作，所以这个配置基本上不会用

• appendfsync everysec
  每秒刷新一次缓冲区中的数据到AOF文件，这个Redis配置文件中默认的策略，兼容了性能和数据完整性的折中方案，这种配置，理论上丢失的数据在一秒钟左右

• appendfsync no
  Redis进程不会主动的去刷新缓冲区中的数据到AOF文件中，而是直接交给操作系统去判断，这种操作也是不推荐的，丢失数据的可能性非常大。

AOF配置

AOF默认不开启，默认为 appendonly no，开启则需要修改为 appendonly yes

AOF配置文件的名称默认为appendonly.aof

AOF重写

AOF属于日志追加的形式来存储Redis的写指令，这会导致大量冗余的指令存储，从而使得AOF日志文件非常庞大，比如同一个key被写了10000次，最后却被删除了，这种情况不仅占内存，也会导致恢复的时候非常缓慢，因此Redis提供重写机制来解决这个问题。Redis的AOF持久化机制执行重写后，保存的只是恢复数据的最小指令集，我们如果想手动触发可以使用如下指令：

bgrewriteaof

由于重写AOF文件时，会对Redis的性能带来一定的影响，因此也不能随便的进行自动重写，Redis提供两个配置用于自动进行AOF重写的指标，只有这两个指标同时满足的时候才会发生重写：

auto-aof-rewrite-percentage 100：指的是当文件的内存达到原先内存的两倍
auto-aof-rewrite-min-size 64mb：指的是文件重写的最小内存大小

AOF重写流程如下：

• 1、bgrewriteaof触发重写，判断是否存在bgsave或者bgrewriteaof正在执行，存在则等待其执行结束再执行。

• 2、主进程fork子进程，防止主进程阻塞无法提供服务，类似RDB。

• 3、子进程遍历Redis内存快照中数据写入临时AOF文件，同时会将新的写指令写入aof_buf和aof_rewrite_buf两个重写缓冲区，前者是为了写会旧的AOF文件，后者是为了后续刷新到临时AOF文件中，防止快照内存遍历时新的写入操作丢失。

• 4、子进程结束临时AOF文件写入后，通知主进程。

• 5、主进程会将上面3中的aof_rewirte_buf缓冲区中的数据写入到子进程生成的临时AOF文件中。

• 6、主进程使用临时AOF文件替换旧AOF文件，完成整个重写过程。

AOF优缺点

优点：

• 数据的备份更加完整，丢失数据的概率更低，适合对数据完整性要求高的场景
• 日志文件可读，AOF可操作性更强，可通过操作日志文件进行修复

缺点：

• AOF日志记录在长期运行中逐渐庞大，恢复起来非常耗时，需要定期对AOF日志进行瘦身处理
• 恢复备份速度比较慢
• 同步写操作频繁会带来性能压力