（尊重劳动成果，转载请注明出处：https://yangwenqiang.blog.csdn.net/article/details/90321396冷血之心的博客）
关注微信公众号（文强的技术小屋），学习更多技术知识，一起遨游知识海洋~
快速导航：
Redis入门总结（一）：redis配置文件，五种数据结构，线程模型和持久化方式
这篇文章主要总结了：什么是redis，redis的特点，配置文件，五种数据结构以及其底层实现原理，线程模型，缓存穿透，缓存雪崩以及缓存与数据库的读写不一致的问题；在此基础上，介绍了RDB和AOF两种数据持久化模式。
-
Redis：REmote DIctionary Server(远程字典服务)
-
定义：
-
由意大利人Salvatore Sanfilippo（网名：antirez）开发的一款内存高速缓存数据库。是完全开源免费的，用C语言编写的，遵守BSD协议，高性能的(key/value)分布式内存数据库，基于内存运行并支持持久化的NoSQL数据库。
-
-
优点（特点）：
-
速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
-
支持丰富数据类型，支持String，List，Set，Sorted Set，Hash
-
支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
-
丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除
-
-
Redis配置文件（redis.conf）：
-
在Redis的解压目录下有个很重要的配置文件 redis.conf，我们来依次阐述各部分的重要配置。
-
include：
-
可以将多个配置文件引入
-
-
modules:
-
通过loadmodule配置可以将自定义模块引入
-
-
network:
-
bind：绑定redis服务器网卡IP，默认为127.0.0.1,即本地回环地址。这样的话，访问redis服务只能通过本机的客户端连接，而无法通过远程连接。如果bind选项为空的话，那会接受所有来自于可用网络接口的连接。
-
port：指定redis运行的端口，默认是6379。由于Redis是单线程模型，因此单机开多个Redis进程的时候会修改端口。
-
timeout：设置客户端连接时的超时时间，单位为秒。当客户端在这段时间内没有发出任何指令，那么关闭该连接。默认值为0，表示不关闭。
-
tcp-keepalive ：单位是秒，表示将周期性的使用SO_KEEPALIVE检测客户端是否还处于健康状态，避免服务器一直阻塞，官方给出的建议值是300s，如果设置为0，则不会周期性的检测。
-
-
general：
-
daemonize：设置为yes表示指定Redis以守护进程的方式启动（后台启动）。默认值为 no
-
pidfile：配置PID文件路径，当redis作为守护进程运行的时候，它会把 pid 默认写到 /var/redis/run/redis_6379.pid 文件里面
-
loglevel ：定义日志级别。默认值为notice，有如下4种取值：
-
debug（记录大量日志信息，适用于开发、测试阶段）
-
verbose（较多日志信息）
-
notice（适量日志信息，使用于生产环境）
-
warning（仅有部分重要、关键信息才会被记录）
-
-
logfile ：配置log文件地址,默认打印在命令行终端的窗口上
-
databases：设置数据库的数目。默认的数据库是DB 0 ，可以在每个连接上使用select <dbid> 命令选择一个不同的数据库，dbid是一个介于0到databases - 1 之间的数值。默认值是 16，也就是说默认Redis有16个数据库。
-
-
snapshotting：（持久化相关配置）
-
save：这里是用来配置触发 Redis的持久化条件，也就是什么时候将内存中的数据保存到硬盘。默认如下配置：
-
save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
-
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
-
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存
-
如果你只是用Redis的缓存功能，不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。
-
可以直接一个空字符串来实现停用：save ""
-
-
stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了
-
rdbcompression ；默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。
-
rdbchecksum ：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
-
dbfilename ：设置快照的文件名，默认是 dump.rdb
-
dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。使用上面的 dbfilename 作为保存的文件名。
-
-
replication：
-
slave-serve-stale-data：默认值为yes。当一个 slave 与 master 失去联系，或者复制正在进行的时候，slave 可能会有两种表现：
-
如果为 yes ，slave 仍然会应答客户端请求，但返回的数据可能是过时，或者数据可能是空的在第一次同步的时候
-
如果为 no ，在你执行除了 info he salveof 之外的其他命令时，slave 都将返回一个 "SYNC with master in progress" 的错误
-
-
slave-read-only：配置Redis的Slave实例是否接受写操作，即Slave是否为只读Redis。默认值为yes。
-
repl-diskless-sync：主从数据复制是否使用无硬盘复制功能。默认值为no。
-
repl-diskless-sync-delay：当启用无硬盘备份，服务器等待一段时间后才会通过套接字向从站传送RDB文件，这个等待时间是可配置的。这一点很重要，因为一旦传送开始，就不可能再为一个新到达的从站服务。从站则要排队等待下一次RDB传送。因此服务器等待一段时间以期更多的从站到达。延迟时间以秒为单位，默认为5秒。要关掉这一功能，只需将它设置为0秒，传送会立即启动。默认值为5。
-
repl-disable-tcp-nodelay：同步之后是否禁用从站上的TCP_NODELAY 如果你选择yes，redis会使用较少量的TCP包和带宽向从站发送数据。但这会导致在从站增加一点数据的延时。 Linux内核默认配置情况下最多40毫秒的延时。如果选择no，从站的数据延时不会那么多，但备份需要的带宽相对较多。默认情况下我们将潜在因素优化，但在高负载情况下或者在主从站都跳的情况下，把它切换为yes是个好主意。默认值为no。
-
-
security：
-
rename-command：命令重命名，对于一些危险命令例如：
-
flushdb（清空数据库）
-
flushall（清空所有记录）
-
config（客户端连接后可配置服务器）
-
keys（客户端连接后可查看所有存在的键）
-
-
作为服务端redis-server，常常需要禁用以上命令来使得服务器更加安全，禁用的具体做法是是：
-
rename-command FLUSHALL ""
-
也可以保留命令但是不能轻易使用，重命名这个命令即可：
-
-
rename-command FLUSHALL abcdefg
-
重启服务器后则需要使用新命令来执行操作，否则服务器会报错unknown command。
-
-
-
-
clients：
-
maxclients ：设置客户端最大并发连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件。 描述符数-32（redis server自身会使用一些），如果设置 maxclients为0 ，表示不作限制。
-
当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息。
-
-
memory management（内存管理）：
-
maxmemory：设置客户端最大并发连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件。描述符数-32（redis server自身会使用一些），如果设置 maxclients为0 。表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息。
-
maxmemory-policy ：当内存使用达到最大值时，redis使用的清除策略。
-
volatile-lru 利用LRU算法移除设置过过期时间的key (LRU:最近使用 Least Recently Used )
-
allkeys-lru 利用LRU算法移除任何key
-
volatile-random 移除设置过过期时间的随机key
-
allkeys-random 移除随机key
-
volatile-ttl 移除即将过期的key(minor TTL)
-
noeviction noeviction 不移除任何key，只是返回一个写错误 ，默认选项
-
-
maxmemory-samples ：LRU 和 minimal TTL 算法都不是精准的算法，但是相对精确的算法(为了节省内存)。随意你可以选择样本大小进行检，redis默认选择3个样本进行检测，你可以通过maxmemory-samples进行设置样本数。
-
-
APPEND ONLY MODE：
-
appendonly：默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化，Append Only File是另一种持久化方式， 可以提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入appendonly.aof文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认值为no。
-
appendfilename ：aof文件名，默认是"appendonly.aof"
-
appendfsync：aof持久化策略的配置；no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快；always表示每次写入都执行fsync，以保证数据同步到磁盘；everysec表示每秒执行一次fsync，可能会导致丢失这1s数据
-
no-appendfsync-on-rewrite：在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。默认值为no。
-
auto-aof-rewrite-percentage：默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
-
auto-aof-rewrite-min-size：64mb。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。
-
aof-load-truncated：aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项，出现这种现象 redis宕机或者异常终止不会造成尾部不完整现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为 yes。
-
-
LUA SCRIPTING：
-
lua-time-limit：一个lua脚本执行的最大时间，单位为ms。默认值为5000.
-
-
REDIS CLUSTER：
-
cluster-enabled：集群开关，默认是不开启集群模式。
-
cluster-config-file：集群配置文件的名称，每个节点都有一个集群相关的配置文件，持久化保存集群的信息。 这个文件并不需要手动配置，这个配置文件有Redis生成并更新，每个Redis集群节点需要一个单独的配置文件。请确保与实例运行的系统中配置文件名称不冲突。默认配置为nodes-6379.conf。
-
cluster-node-timeout ：可以配置值为15000。节点互连超时的阀值，集群节点超时毫秒数
-
cluster-slave-validity-factor ：可以配置值为10。在进行故障转移的时候，全部slave都会请求申请为master，但是有些slave可能与master断开连接一段时间了，导致数据过于陈旧，这样的slave不应该被提升为master。该参数就是用来判断slave节点与master断线的时间是否过长。判断方法是：比较slave断开连接的时间和(node-timeout * slave-validity-factor) + repl-ping-slave-period 如果节点超时时间为三十秒, 并且slave-validity-factor为10,假设默认的repl-ping-slave-period是10秒，即如果超过310秒slave将不会尝试进行故障转移
-
cluster-migration-barrier ：可以配置值为1。master的slave数量大于该值，slave才能迁移到其他孤立master上，如这个参数若被设为2，那么只有当一个主节点拥有2 个可工作的从节点时，它的一个从节点会尝试迁移。
-
cluster-require-full-coverage：默认情况下，集群全部的slot有节点负责，集群状态才为ok，才能提供服务。 设置为no，可以在slot没有全部分配的时候提供服务。不建议打开该配置，这样会造成分区的时候，小分区的master一直在接受写请求，而造成很长时间数据不一致。
-
-
-
redis线程安全问题：
-
单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性）
-
redis实际上是采用了线程封闭的观念，把任务封闭在一个线程，自然避免了线程安全问题，不过对于需要依赖多个redis操作的复合操作来说，依然需要锁，而且有可能是分布式锁。
-
-
redis相比memcached有哪些优势？
-
memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型
-
redis的速度比memcached快很多
-
redis可以持久化其数据
-
Redis支持数据的备份，即master-slave模式的数据备份。
-
使用底层模型不同，它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
-
value大小：redis最大可以达到1GB，而memcache只有1MB
-
-
Redis支持的数据类型：
-
我们所说的其支持的数据类型都是在说其存储的value的类型，redis的Key的类型都是字符串。
-
string：
-
redis 中字符串 value 最多可以是 512M。
-
场景：做一些计数功能的缓存
-
-
list：
-
list 列表，它是简单的字符串列表，按照插入顺序排序，你可以添加一个元素到列表的头部（左边）或者尾部（右边），它的底层实际上是个链表。
-
场景：可以当作一个简单消息队列功能，做基于redis的分页功能
-
-
set：
-
是一个String类型的无序集合。
-
场景：全局去重
-
-
sorted set：
-
是一个String类型的有序集合，通过给每一个元素一个固定的分数score来保持顺序。
-
场景：做排行榜应用，取TopN操作，范围查找
-
-
hash:
-
hash 是一个键值对集合，是一个 string 类型的 key和 value 的映射表，key 还是key，但是value是一个键值对（key-value）
-
场景：存放一些结构化的信息
-
-
-
系统常用命令：
-
OBJECT ENCODING key ：显示五种数据类型的底层数据实现结构
-
BGSAVE：后台异步保存当前数据库的数据到磁盘（持久化）
-
BGREWIRTEAOF：手动触发AOF重写操作，用于减小AOF文件体积
-
-
redis数据类型的底层数据结构：
-
通过OBJECT ENCODING key 可以查看当前key的底层数据结构。
-
简单动态字符串（simple dynamic string,SDS）：
-
SDS 数据类型的定义：
-
len 保存了SDS保存字符串的长度
-
buf[ ] 数组用来保存字符串的每个元素
-
free 记录了 buf 数组中未使用的字节数量
-
-
-
使用SDS而不是C语言原生的字符串的优点：
-
常数复杂度获取字符串长度
-
杜绝缓冲区溢出：
-
当进行字符串修改时，可以根据len属性检查空间是否满足，不满足会扩容，防止缓冲区溢出
-
-
减少字符串修改时的内存重新分配次数：
-
C语言由于不记录字符串的长度，所以如果要修改字符串，必须要重新分配内存（先释放再申请），因为如果没有重新分配，字符串长度增大时会造成内存缓冲区溢出，字符串长度减小时会造成内存泄露。
-
SDS在字符串修改时存在空间预分配和惰性空间释放。
-
-
二进制安全：
-
二进制中可能包含空字符串。C语言原生的字符串以空字符结尾，所以不可以正确的存取
-
SDS中以len属性来判断字符串是否结束
-
-
兼容部分C语言中的函数库
-
SDS 还可以作为缓冲区（buffer）：包括 AOF 模块中的AOF缓冲区以及客户端状态中的输入缓冲区
-
-
-
链表：
-
Redis中自己实现了链表，特性如下：
-
双端：链表具有前置节点和后置节点的引用，获取这两个节点时间复杂度都为O(1)。
-
无环：表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL,对链表的访问都是以 NULL 结束。
-
带链表长度计数器：通过 len 属性获取链表长度的时间复杂度为 O(1)。
-
多态：链表节点使用 void* 指针来保存节点值，可以保存各种不同类型的值。
-
-
-
字典：
-
字典又称为符号表或者关联数组、或映射（map），是一种用于保存键值对的抽象数据结构。字典中的每一个键 key 都是唯一的，通过 key 可以对值来进行查找或修改。
-
C 语言中没有内置这种数据结构的实现，所以字典依然是 Redis自己构建的。Redis 的字典使用哈希表作为底层实现。
-
扩容和收缩：当哈希表保存的键值对太多或者太少时，就要通过 rehash(重新散列）来对哈希表进行相应的扩展或者收缩。
-
如果执行扩展操作，会基于原哈希表创建一个大小等于 ht[0].used*2n 的哈希表
-
相反如果执行的是收缩操作，每次收缩是根据已使用空间缩小一倍创建一个新的哈希表。
-
重新利用上面的哈希算法，计算索引值，然后将键值对放到新的哈希表位置上。
-
所有键值对都迁徙完毕后，释放原哈希表的内存空间。
-
-
触发扩容的条件：
-
服务器目前没有执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且负载因子大于等于1。
-
服务器目前正在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且负载因子大于等于5。
-
负载因子 = 哈希表已保存节点数量 / 哈希表大小。
-
-
渐近式 rehash
-
扩容和收缩操作不是一次性、集中式完成的，而是分多次、渐进式完成的。如果保存在Redis中的键值对只有几个几十个，那么 rehash 操作
-
可以瞬间完成。
-
但是如果键值对有几百万，几千万甚至几亿，那么要一次性的进行 rehash，势必会造成Redis一段时间内不能进行别的操作。
-
所以Redis采用渐进式 rehash,这样在进行渐进式rehash期间，字典的删除查找更新等操作可能会在两个哈希表上进行，第一个哈希表没有找到，就会去第二个哈希表上进行查找。但是进行 增加操作，一定是在新的哈希表上进行的。
-
-
-
跳表：
-
对于一个有序的链表，我们依然只能通过遍历来查找一个元素，效率低下。
-
跳表就是将有序的链表分层，相当于是创建了多个分层索引，当链表元素个数增大的时候，跳表的查询效率显著提升。
-
跳表的特点：
-
由很多层结构组成；
-
每一层都是一个有序的链表，排列顺序为由高层到底层，都至少包含两个链表节点，分别是前面的head节点和后面的nil节点；
-
最底层的链表包含了所有的元素；
-
如果一个元素出现在某一层的链表中，那么在该层之下的链表也全都会出现（上一层的元素是当前层的元素的子集）；
-
链表中的每个节点都包含两个指针，一个指向同一层的下一个链表节点，另一个指向下一层的同一个链表节点；
-
-
Redis中为什么使用跳表而不使用查询复杂度同样为log(N)的平衡树？
-
跳表构建起来比平衡树容易
-
跳表支持范围搜索。
-
-
-
整数集合（intset）：
-
用于保存整数值的集合抽象数据类型，它可以保存类型为int16_t、int32_t 或者int64_t 的整数值，并且保证集合中不会出现重复元素。
-
整数集合的每个元素都是 contents 数组的一个数据项，它们按照从小到大的顺序排列，并且不包含任何重复项。
-
length 属性记录了 contents 数组的大小。
-
-
压缩列表：
-
压缩列表（ziplist）是Redis为了节省内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型数据结构
-
一个压缩列表可以包含任意多个节点（entry），每个节点可以保存一个字节数组或者一个整数值。
-
压缩列表的原理：
-
压缩列表并不是对数据利用某种算法进行压缩，而是将数据按照一定规则编码在一块连续的内存区域，目的是节省内存
-
-
-
-
Redis数据类型的实现原理：
-
Redis底层所使用的数据结构我们已经学习了，但是redis并不是直接使用这些数据结构，而是构建了一个对象系统。
-
每次在Redis数据库中创建一个键值对时，至少会创建两个对象，一个是键对象，一个是值对象。
-
Redis中的每个对象都是由 redisObject 结构来表示：
-
-
type属性：记录了对象的类型，五种数据类型string,list,set.sort set ,hash。 命令：type key
-
encoding编码：记录了对象的底层编码（每个对象都至少有两种编码）
-
OBJECT ENCODING key ：显示五种数据类型的底层数据实现结构（编码）
-
-
*ptr：指向底层数据结构的指针
-
-
五大数据类型对象的编码：
-
字符串对象：
-
字符串是Redis最基本的数据类型，不仅所有key都是字符串类型，其它几种数据类型构成的元素也是字符串。注意字符串的长度不能超过512M。
-
编码：字符串对象的编码可以是int，raw或者embstr。
-
-
int 编码：保存的是可以用 long 类型表示的整数值
-
raw 编码（长）：保存长度大于44字节的字符串（redis3.2版本之前是39字节，之后是44字节）
-
embstr 编码（短）（只读）：保存长度小于44字节的字符串（redis3.2版本之前是39字节，之后是44字节）
-
raw和embstr编码的区别：
-
embstr与raw都使用redisObject和sds保存数据，区别在于：
-
embstr的使用只分配一次内存空间（因此redisObject和sds是连续的）
-
raw需要分配两次内存空间（分别为redisObject和sds分配空间）。
-
因此与raw相比，embstr的好处在于创建时少分配一次空间，删除时少释放一次空间，以及对象的所有数据连在一起，寻找方便。
-
而embstr的坏处也很明显，如果字符串的长度增加需要重新分配内存时，整个redisObject和sds都需要重新分配空间，因此redis中的embstr实现为只读。
-
-
编码可以转换吗？
-
当 int 编码保存的值不再是整数，或大小超过了long的范围时，自动转化为raw。
-
对于 embstr 编码，由于 Redis 没有对其编写任何的修改程序（embstr 是只读的），在对embstr对象进行修改时，都会先转化为raw再进行修改，因此，只要是修改embstr对象，修改后的对象一定是raw的，无论是否达到了44个字节。
-
-
列表对象（list）:
-
列表对象的编码可以是 ziplist(压缩列表) 和 linkedlist(双端链表)。
-
当同时满足下面两个条件时，使用ziplist（压缩列表）编码：
-
列表保存元素个数小于512个
-
每个元素长度小于64字节
-
-
不能满足这两个条件的时候使用 linkedlist 编码。
-
也就是说元素又多又长就用linkedlist，否则就用ziplist
-
-
哈希对象（hash)：
-
哈希对象的编码可以是 ziplist 或者 hashtable。
-
当同时满足下面两个条件时，使用ziplist（压缩列表）编码：
-
列表保存元素个数小于512个
-
每个元素长度小于64字节
-
-
不能满足这两个条件的时候使用 hashtable编码。
-
-
集合对象（set）：
-
集合对象 set 是 string 类型（整数也会转换成string类型进行存储）的无序集合。
-
集合对象的编码可以是 intset 或者 hashtable。intset 编码的集合对象使用整数集合作为底层实现，集合对象包含的所有元素都被保存在整数集合中。
-
当集合同时满足以下两个条件时，使用 intset 编码：
-
集合对象中所有元素都是整数
-
集合对象所有元素数量不超过512
-
-
不能满足这两个条件的就使用 hashtable 编码。
-
-
有序集合对象：
-
有序集合对象是有序的。与列表使用索引下标作为排序依据不同，有序集合为每个元素设置一个分数（score）作为排序依据。
-
有序集合的编码可以是 ziplist 或者 skiplist
-
ziplist 编码的有序集合对象使用压缩列表作为底层实现，每个集合元素使用两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员，第二个节点保存元素的分值。并且压缩列表内的集合元素按分值从小到大的顺序进行排列，小的放置在靠近表头的位置，大的放置在靠近表尾的位置。
-
skiplist 编码的有序集合对象使用 zet 结构作为底层实现，一个 zset 结构同时包含一个字典和一个跳跃表：
-
字典的键保存元素的值，字典的值则保存元素的分值；跳跃表节点的 object 属性保存元素的成员，跳跃表节点的 score 属性保存元素的分值。
-
这两种数据结构会通过指针来共享相同元素的成员和分值，所以不会产生重复成员和分值，造成内存的浪费。
-
说明：其实有序集合单独使用字典或跳跃表其中一种数据结构都可以实现，但是这里使用两种数据结构组合起来，原因是假如我们单独使用 字典，虽然能以 O(1) 的时间复杂度查找成员的分值，但是因为字典是以无序的方式来保存集合元素，所以每次进行范围操作的时候都要进行排序；假如我们单独使用跳跃表来实现，虽然能执行范围操作，但是查找操作有 O(1)的复杂度变为了O(logN)。因此Redis使用了两种数据结构来共同实现有序集合。
-
-
-
当有序集合对象同时满足以下两个条件时，对象使用 ziplist 编码：
-
保存的元素数量小于128；
-
保存的所有元素长度都小于64字节。
-
-
不能满足上面两个条件的使用 skiplist 编码。
-
-
-
refcount（引用计数）：
-
Redis自己构建了一个内存回收机制，通过在 redisObject 结构中的 refcount 属性实现。这个属性会随着对象的使用状态而不断变化：
-
创建一个新对象，属性 refcount 初始化为1
-
对象被一个新程序使用，属性 refcount 加 1
-
对象不再被一个程序使用，属性 refcount 减 1
-
当对象的引用计数值变为 0 时，对象所占用的内存就会被释放。
-
-
如果出现循环引用导致内存溢出的时候，我们在配置文件中设置了redis的内存清除策略。
-
共享内存：
-
当key不相同但是value相同时，redis将数据库键的值指针指向一个现有值的对象，将被共享的值对象引用refcount 加 1
-
Redis的共享对象目前只支持整数值的字符串对象。之所以如此，实际上是对内存和CPU（时间）的平衡：共享对象虽然会降低内存消耗，但是判断两个对象是否相等却需要消耗额外的时间。对于整数值，判断操作复杂度为O(1)；对于普通字符串，判断复杂度为O(n)；而对于哈希、列表、集合和有序集合，判断的复杂度为O(n^2)
-
虽然共享对象只能是整数值的字符串对象，但是5种类型都可能使用共享对象（如哈希、列表等的元素可以使用）
-
-
-
lru属性：
-
该属性记录了对象最后一次被命令程序访问的时间。
-
使用 OBJECT IDLETIME 命令可以打印给定键的空转时长，通过将当前时间减去值对象的 lru 时间计算得到。
-
lru 属性除了计算空转时长以外，还可以配合前面内存回收配置使用。
-
如果Redis打开了maxmemory选项，且内存回收算法选择的是volatile-lru或allkeys—lru，那么当Redis内存占用超过maxmemory指定的值时，Redis会优先选择空转时间最长的对象进行释放。
-
-
-
redis单线程为什么执行速度如此之快？
-
完全内存计算
-
单线程，避免了上下文切换
-
使用了多路I/O复用，一个线程监控多个IO流，实现及时响应。
-
-
redis的线程模型：
-
redis的线程模型是一种多路I/O复用模型，具体模型图如下所示：
-
-
简单来说，就是redis-client在操作的时候，会产生具有不同事件类型的socket。
-
在服务端，有一段I/O多路复用程序，将其置入队列之中。
-
然后，文件事件分派器，依次去队列中取，转发到不同的事件处理器中。
-
-
I/O多路复用机制:
-
目前支持I/O多路复用的系统调用有 select，pselect，poll，epoll，I/O多路复用就是通过一种机制
-
一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。
-
select，pselect，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。
-
优点：
-
与多进程和多线程技术相比，I/O多路复用技术的最大优势是系统开销小，系统不必创建进程/线程，也不必维护这些进程/线程，从而大大减小了系统的开销。
-
-
-
常见的多路复用函数：
-
select函数：
-
会修改传入的参数数组，这个对于一个需要调用很多次的函数，是非常不友好的。
-
有最大监听连接数1024个的限制
-
如果任何一个sock(I/O stream)出现了数据，select没有返回具体是哪个返回了数据，需要采用轮询的方式去遍历获取
-
线程不安全（当你在一个线程中已经监听该socket，另一个线程想要将该socket关闭，则结果会不可预知）
-
“If a file descriptor being monitored by select() is closed in another thread, the result is unspecified”
-
-
poll函数：
-
去掉了1024的限制（使用链表搞定）
-
不再修改传入的参数数组
-
依然是线程不安全的
-
-
epoll函数：
-
epoll 不仅返回socket组里面数据，还会告诉你具体哪个socket有数据
-
线程安全
-
-
-
-
Redis可能出现的问题：
-
缓存雪崩
-
缓存同一时间大面积的失效，这个时候又来了一波请求，结果请求都到数据库上，从而导致数据库连接异常。
-
解决方案：
-
给缓存的失效时间，加上一个随机值，避免集体失效。
-
使用互斥锁，但是该方案吞吐量明显下降了。
-
双缓存。我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。
-
-
-
缓存穿透
-
故意去请求缓存中不存在的数据，导致所有的请求都怼到数据库上，从而数据库连接异常。
-
解决方案：
-
利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试
-
采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。
-
提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的key。迅速判断出，请求所携带的Key是否合法有效。如果不合法，则直接返回
-
-
-
缓存的并发竞争
-
多个子系统来并发竞争更新一个Key
-
解决方案：
-
使用一个分布式锁，谁占有谁更新
-
使用队列，将更新操作变成串行
-
指定更新的顺序，每次更新都有一个version，当每个子系统更新时发现当前version大于自己的version，那么放弃更新
-
-
-
缓存和数据库双写一致性
-
高并发请求下会导致数据不一致的问题，如果业务需要数据保持强一致性，那么不可以使用缓存。
-
解决方案：
-
双删延时
-
删除缓存数据
-
更新数据库数据
-
隔固定的时间再次删除缓存
-
-
更新数据库产生的binlog订阅（使用canal），将有变化的key记录下来，并且不断的去删除缓存（如果上次删除缓存失败）
-
-
-
-
Redis数据的过期回收策略与内存淘汰机制：
-
定期删除+惰性删除组合
-
定期删除：
-
当给数据设置的缓存时间到期之后会自动删除，但是比较消耗CPU，redis是单线程执行的，如果高并发情况下会影响系统性能
-
-
定期删除+惰性删除组合：（这个才是使用的策略）
-
redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。
-
惰性删除：
-
在获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。
-
-
-
内存淘汰：
-
如果在数据过期之后，你没有去获取该数据，那么就不会被惰性删除，该数据一直保存，redis内存会越来越高。
-
当内存不足时，通过我们在上边所介绍的redis.conf配置文件中的配置的maxmemory-policy策略来进行内存淘汰
-
-
-
Redis持久化策略：
-
redis是一个基于内存，并且支持数据持久化的NoSql数据库。有两种持久化策略：
-
RDB（快照方式 snapshotting）（全量持久化）：
-
把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里
-
自动触发方式：
-
我们在配置文件redis.conf中配置的snapshotting 指定了当多长时间内有多少次save命令时自动触发持久化操作
-
将这块的save配置注释掉或者配置为空字符串，表示关闭RDB持久化方式
-
-
手动触发方式：
-
通过bgsave命令，在后台异步进行生成快照的操作，同时还可以响应客户都按的请求。
-
通过redis进程fork操作创建子进程，生成快照由子进程负责，完成后自动结束，请求只会在fork阶段被阻塞
-
-
快照恢复：
-
将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。
-
-
优缺点：
-
存在数据丢失的问题
-
恢复大数据集时比AOF方式快
-
RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)
-
-
-
AOF（append-only-file）（增量持久化）：
-
通过记录redis服务器所执行的写命令来记录数据库状态
-
在 redis.conf 配置文件的 APPEND ONLY MODE 下我们可以设置AOF持久化
-
AOF 保存文件的位置和 RDB 保存文件的位置一样，都是通过 redis.conf 配置文件的 dir 配置
-
数据恢复：
-
重启 Redis 之后就会进行 AOF 文件的载入
-
异常修复命令：redis-check-aof --fix 进行修复
-
-
AOF日志重写：
-
AOF文件可能会随着服务器运行的时间越来越大，可以利用AOF重写的功能，来控制AOF文件的大小。
-
AOF重写功能会首先读取数据库中现有的键值对状态，然后根据类型使用一条命令来替代前的键值对多条命令。
-
使用命令 bgrewriteaof 来实现AOF重写
-
-
AOF重写缓存区：
-
Redis 是单线程工作，如果重写AOF 需要比较长的时间，那么在重写 AOF 期间，Redis将长时间无法处理其他的命令，解决办法是将 AOF 重写程序放到子程序中进行，这样有两个好处：
-
子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理其他命令。
-
子进程带有父进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。
-
-
子进程重写导致的问题：
-
因为子进程在进行 AOF 重写期间，服务器进程依然在处理其它命令，这新的命令有可能也对数据库进行了修改操作，使得当前数据库状态和重写后的 AOF 文件状态不一致。
-
-
数据状态不一致解决办法：
-
Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区是在创建子进程后开始使用，当Redis服务器执行一个写命令之后，就会将这个写命令也发送到 AOF 重写缓冲区。
-
当子进程完成 AOF 重写之后，就会给父进程发送一个信号，父进程接收此信号后，就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中。
-
-
-
优点：
-
AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
-
AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
-
AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。
-
-
缺点：
-
对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。
-
虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。
-
RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。
-
-
-
持久化策略选择：
-
AOF更安全，可将数据及时同步到文件中，但需要较多的磁盘IO，AOF文件尺寸较大，文件内容恢复相对较慢， 也更完整。
-
RDB持久化，安全性较差，它是正常时期数据备份及 master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。
-
-
-
以上内容摘抄总结与网络，感谢各位前辈的总结与铺垫。接下来我会继续更新Redis相关文章，全部会以这种笔记形式给出，大家对笔记中不太懂的地方，可以发表评论，我们一起研究学习，此处权当给大家列个学习提纲了。
如果对你有帮助，记得点赞哦~欢迎大家关注我的博客，可以进群366533258一起交流学习哦~
本群给大家提供一个学习交流的平台，内设菜鸟Java管理员一枚、精通算法的金牌讲师一枚、Android管理员一枚、蓝牙BlueTooth管理员一枚、Web前端管理一枚以及C#管理一枚。欢迎大家进来交流技术。
关注微信公众号（文强的技术小屋），学习更多技术知识，一起遨游知识海洋~
