redis原理和使用-基本特性

上一篇blog中介绍了redis的分布式安装和集群方式，本文将介绍redis支持的数据结构，持久化方式和数据过期策略。

---

redis支持的数据结构

Redis支持的数据结构类型有:String(字符串)，List(列表)，Set(集合)，Hash(哈希)，Zset(有序集合)。

各种数据类型的操作如下：

	增加	删除	查询	返回长度
String	set或mset	del	get	-
List	lpush, rpush	lpop, rpop	lrange	llen
Hash	hset, hmset	hdel	hget, hkeys, hvals, hgetall	hlen
Set	sadd	srem, spop	smembers/sismember	scard
Zset	zadd	zrem	zrange	zcard

下面是一个简单的例子：

跳表

跳表是redis的一个核心组件，同时也被广泛地运用到了各种缓存的实现中。zset的底层就是通过跳表来实现的。跳表是一种有序的数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。

跳表的演进

跳表是在有序链表的基础上进行演进的。对于有序链表，查找某个元素的时候，是从头结点往后一个一个地查找，时间复杂度为O(n)。如下图有序链表：

既然是有序的，那有没有什么方法可以实现有序链表的二分查找呢？方法就是使用跳跃链表。把一些节点从有序表中提取出来，缓存一级索引，就组成了下面这样的结构：

如果要查找元素11，就从L1层的1开始，向右到6，再向右发现是15，比11大，此路不通。于是跳到L0层，从下面的6往右走，到7，再到11。同样地，一级索引也可以往上再提取一层，组成二级索引，如下：

如果要查找元素17，则只需要经过6、15、17这几个元素就可以找到17了。

总结：跳表在有序链表的基础上，通过空间换取时间，提升了查询效率。查询的时间复杂度为O(logN)。

假设每两个元素往上提取一个元素，形成一个标准跳表，如下所示：

设层级为k，则所需的额外存储空间为:2^1+2^2+...+2^k = 2^(k+1) - 1，其中L1的元素个数为2^k = n/2，则2^(k+1) = n，所需的额外存储空间为n-1，所以空间复杂度为O(n)。

跳表的插入和删除

假如要向上面的跳表中添加一个元素8。首先，随机选取一个层数，决定8要占据的层数，例如L1。然后找到8这个元素在下面两层的前置节点，通过链表的插入操作将其插到后面即可，如下图所示：

删除也是类似的，先找到各层中包含元素x的节点，然后使用标准的链表删除元素即可，如下所示：

Redis中zset为什么用跳表，而不是用红黑树来实现呢？

• 有序集合的主要操作包括：（1）插入元素；（2）删除元素；（3）查找元素；（4）有序输出所有元素；（5）查找区间内的所有元素
• 在这5个操作中，前4个红黑树都可以完成，且时间复杂度跟跳表一致，但最后一项，红黑树的效率就不如跳表高了。此外，相对红黑树来说，跳表实现容易且易读。

Redis持久化

Redis支持RDB和AOF两种持久化机制。
众所周知，redis是一个内存数据库。而内存中的数据会在机器宕机或者进程退出时丢失。有了持久化机制之后，就可以在重启时利用之前持久化的文件进行数据恢复。

RDB持久化

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。它是Redis默认采用的持久化方式。快照文件默认存放在当前执行redis服务的根目录的dump.rdb中。
当redis服务关闭后，内存数据清空。此时再开启redis，就会从dump.rdb持久化文件中恢复数据。如果将dump.rdb删除，重启redis时就无法通过持久化数据文件恢复数据，redis里的数据就会为空。

RDB的相关配置在redis配置文件redis.conf中。在标识SNAPSHOTTING注释的模块下，可以通过修改该配置文件设置触发快照生成的情况。默认的配置为：当900秒内有1个key被修改，或者300秒内有10个key被修改，或者60秒内有10000个key被修改，会触发快照的生成。如下图所示：

如果不希望将数据同步到快照文件中，可以设置为save “”。此外，当执行save，bgsave，flushall，shutdown命令时，也会生成快照文件。

Redis生成RDB快照文件的过程为：

• Fork一个子进程作为主进程的副本。主进程负责接收并处理客户端请求，子进程负责将内存中的数据写入磁盘中的临时文件。待持久化过程结束后，会用此临时文件替换旧的dump.rdb，到此，一次快照生成完毕。

根据RDB持久化机制可知，当一次快照生成完毕而下一次尚未触发时，此时机器发生故障导致宕机，则最后的增量数据就会丢失。

AOF持久化

AOF即append only file，redis将每一个收到的写命令(包括flushall命令)都通过write函数追加到文件appendonly.aof中。

默认情况下redis并未开启AOF，需要将配置文件中的appendonly no项修改为appendonly yes，同时关闭RDB。appendfsync配置项指定了AOF持久化的时机，默认采用appendfsync everysec，表示每秒钟同步。

Redis还对aof文件进行了优化，主要是指当aof文件大小超过所设定的阈值时，会将aof文件进行重写，只保留可以恢复数据的最小指令集(例如删除已过期的数据的相关指令)，以压缩文件大小。当然，也可以通过命令bgrewriteaof进行手动压缩。默认的自动重写触发的配置如下：

混合持久化

实际上，可以将RDB和AOF混合使用。将RDB文件的内容和增量的AOF日志文件存放在一起。这里的AOF日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量AOF日志。

RDB和AOF对比

上文说过，RDB的问题在于：当机器宕机时最后一次快照生成之后的增量数据可能会丢失。而AOF的缺点是：相比于RDB，AOF文件的体积更大。在恢复大数据集时，AOF的恢复速度比RDB慢。另外，根据同步策略的不同，AOF在运行效率上往往慢于RDB，除非使用禁用同步策略。

Redis键过期删除

Redis提供了3中针对过期键值的删除策略。

• 定时删除(主动)
  在设置键的过期时间的同时，创建一个定时器，让定时器在键的过期时间来临时删除这个键。
• 惰性删除(被动)
  查询键的时候判断有没有过期，如果过期则删除，没过期则返回。
• 定期删除(主动)
  每隔一段时间对数据库进行一次检查，删除过期键。

显然，通过定时器的主动删除对内存是友好的，一旦数据过期则删除，但是对cpu是不友好的；惰性删除对内存不够友好，即使数据过期了，在没有查询的时候任然会存在，占用着内存；定期删除则是两种策略的折中方案。通常，将定期删除和惰性删除结合起来使用。通过定期删除来回收一定的内存空间，然后通过惰性删除来回收被查询的过期键所占用的内存空间。

Redis过期键对持久化和主从同步的影响

在redis持久化过程中，RDB模式下过期键不会被写到持久化数据文件中。
Redis通过RDB持久化文件进行数据恢复时，如果是以主服务器模式运行的，则不会载入已经过期的键，否则会载入。
主服务器删除过期键时，会向所有从服务器发一个DEL命令，告知从服务器删除过期键。

Redis Big Key

在redis中，一个字符串最大512M，一个二级数据结构(hash,list,set,zset)可以存大约40亿(2^32 - 1)个元素。

但实际上不会这么做。一旦value值过大，就会出现Big Key问题。对于string类型，超过10kb就是big key，对于其他类型，元素个数超过10240个认为是big key。

big key存在的问题

1.超时堵塞

操作big key通常比较耗时。由于Redis单线程的特性，这个长耗时就可能导致redis阻塞，进而造成客户端阻塞或着引起故障切换。

2.网络拥塞

big key意味着在网络上传输时产生的网络流量较大。假如每个big key为1mb，客户端每秒访问量为1000，则网络流量是1000mb/s。对于小一点的网卡，直接就会堵住。

3.内存使用不均匀

假设在redis集群中，key是均匀分布的。理论上使用的内存空间也应该是均匀的。而big key所在的节点会使用较大的内存空间，也就是内存使用不均匀。

4.过期删除

如果设置了big key的过期时间，则当其过期时会被删除。big key的删除耗时较长，存在阻塞redis的可能性(Redis4.0有异步删除机制，效果更好)。
而且这个删除不会出现在主节点的慢查中(因为不是客户端产生的)，但可以从latency命令中获取或者从slave节点慢查中获取。

5.迁移困难

当需要对big key进行迁移时(如redis cluster的slot迁移)，可能会迁移失败，而且可能会阻塞redis。

处理方式

对big key进行拆分。比如某个list是个big key，可以考虑分桶。例如：list中的元素是int，可以按照后两位数组来拆分，分成00~99这100个桶。

如果不能拆分，可以考虑能否使用其他组件存储。必须要用redis存的话，可以考虑迁移出集群，采用主备的架构来存储。