Redis是基于内存的单进程单线程模型的KV数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。

它完全基于内存，绝大部分请求都是内存操作。数据也存在内存，类似于HashMap（HashMap的优势就是查找和操作的时间复杂度都是O(1)）；支持许多数据结构，例如String，Hash，List，Set，Sort Set，BitMap，Hyperloglog和Geospatial等。

Redis具有内置的复制，Lua脚本，LRU逐出，事务和不同级别的磁盘持久性，并通过Redis Sentinel和Redis Cluster自动分区提供了高可用性。

1. 线程模型

基于Reactor模式实现了自己的网络事件处理器，称为文件事件处理器（File Event Handler）。这个文件事件处理器是单线程的，所以Redis才叫做单线程的模型。

文件事件处理器采用I/O多路复用机制同时监听多个Socket，根据Socket上的事件来选择对应的事件处理器进行处理。

文件事件处理器的结构包含4个部分：

1. 多个Socket；
2. IO多路复用程序；
3. 文件事件分派器；
4. 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）。

多个Socket可能会并发产生不同的操作，每个操作对应不同的文件事件； I/O多路复用程序会监听多个Socket，会将Socket产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

2. 数据类型

基础数据类型：字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。

还有HyperLogLog、Geo、Pub/Sub，Redis Module（BloomFilter，RedisSearch，Redis-ML）

2.1 String

字符串，普通的set和get，做简单的KV缓存。

应用场景：

1. 缓存功能：利用Redis作为缓存，再配合其它数据库作为存储层。利用Redis支持高并发的特点，可以大大加快系统的读写速度、以及降低后端数据库的压力。
2. 计数器：使用Redis作为系统的实时计数器，可以快速实现计数和查询的功能。而且最终的数据结果可以按照特定的时间落地到数据库等存储介质当中进行永久保存。
3. 共享Session：利用Redis将Session集中管理，每次Session的更新和获取都可以快速完成，大大提高效率。

2.2 Hash

字典，类似Map的一种结构。

应用场景：

1. 将结构化的数据给缓存在Redis里，比如一个对象（前提是这个对象没嵌套其他的对象），然后每次读写缓存的时候，可以就操作Hash里的某个字段。

2.3 List

有序列表。

应用场景：

1. 列表型的数据结构：如粉丝列表。通过lrange命令，读取某个闭区间内的元素，列表不但有序同时还支持按照范围内获取元素，实现基于Redis的高性能分页。
2. 异步队列：使用右进左出的命令组成来完成队列的设计。例如：数据的生产者可以通过Rpush命令从右边插入数据，多个数据消费者，可以使用BLpop命令阻塞的“抢”列表头部的数据。

2.4 Set

自动去重的无序集合。

应用场景：

1. 全局去重。
2. 交集、并集、差集的操作。比如把两个人的好友列表整一个交集。

2.5 Sorted Set

zset，去重可排序的Set。写进去的时候给一个分数score，自动根据分数排序，利用分数进行成员间的排序，而且是插入时就排序好。

应用场景：

1. 排行榜：有序集合经典使用场景。例如微博热搜榜，后面的热度值为score。
2. 带权重的队列：比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务，让重要的任务优先执行。
3. 延迟队列：时间戳作为score，消息内容作为key，调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。

2.6 高级用法

2.6.1 Bitmap

位图是支持按bit位来存储信息，可以用来实现布隆过滤器（BloomFilter）。

2.6.2 HyperLogLog

基数统计。供不精确的去重计数功能，比较适合用来做大规模数据的去重统计，例如统计UV

2.6.3 Geospatial

地理信息。可以用来保存地理位置，并作位置距离计算或者根据半径计算位置等

2.6.4 Pub/Sub

发布订阅 。功能是订阅发布功能，可以用作简单的消息队列

2.6.5 Pipeline

管道。可以批量执行一组指令，一次性返回全部结果，可以减少频繁的请求应答。

Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务。这意味着通常情况下一个请求会遵循以下步骤：

1. 客户端向服务端发送一个查询请求，并监听Socket返回，通常是以阻塞模式，等待服务端响应。
2. 服务端处理命令，并将结果返回给客户端。

Redis管道技术可以在服务端未响应时，客户端可以继续向服务端发送请求，并最终一次性读取所有服务端的响应。可以将多次IO往返的时间缩减为一次，前提是pipeline执行的指令之间没有因果相关性。

使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。

2.6.6 Lua

脚本。Redis支持提交Lua脚本来执行一系列的功能

3. 事务

Redis通过MULTI、EXEC、WATCH等命令来实现事务功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制。

Redis只保证串行执行命令，并且能保证全部执行，但是执行命令失败时并不会回滚，而是会继续执行下去。

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令执行完毕后，才去处理其他客户端的命令请求。

一个事务从开始到结束通常会经历三个阶段：事务开始，命令入队和事务执行。

1. MULTI命令的执行标志着事务的开始，将执行该命令的客户端从非事务状态切换成事务状态；
2. 客户端发送的是EXEC、DISCARD、WATCH和MULTI四个命令以外的其他命令，服务器会将这个命令放入一个事务队列里面，然后向客户端返回QUEUE回复。
3. 当一个处于事务状态的客户端向服务端发送EXEC命令式，这个EXEC命令会立即被执行。服务器会遍历这个客户端的事务队列，执行队列中保存的所有命令，最后将执行命令所得结果全部返回给客户端。

4. 持久化

Redis是内存数据库，它将自己的数据库状态存在内存里面，所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面，那么一旦服务器进程退出，服务器中的数据库状态也会消失不见。

Redis提供了两种持久化方式，都可以把Redis内存中的数据持久化到磁盘上：

1. RDB（redis database）：全量持久化，对Redis中的数据执行周期性的持久化。
2. AOF（append only file）：增量持久化，对每条写入命令作为日志，以append-only的模式写入一个日志文件中。这个方式是只追加的方式，所以没有任何磁盘寻址的开销。

4.1 RDB

RDB通过保存数据库中的键值对来记录数据库状态。

有两个Redis命令用于生成RDB文件，一个是SAVE，一个是BGSAVE。

1. SAVE：阻塞Redis服务器进程，直到RDB文件创建完毕，在服务器进程阻塞期间，服务器不能处理任何命令请求。
2. BGSAVE：派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求。子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

用户可以通过save选项设置多个保存条件，只要有任意一个条件满足，服务器就会执行BGSAVE命令。

优点

1. 生成多个数据文件，每个数据文件分别都代表了某一时刻Redis里面的数据。
2. 对Redis的性能影响非常小，在同步数据的时候派生了一个子进程去做持久化的。
3. 采用二进制压缩存储，数据恢复的速度比AOF快。

缺点

1. RDB都是快照文件，都是默认五分钟甚至更久的时间才会生成一次，意味着这次同步到下次同步中间五分钟的数据都很可能全部丢失掉，而AOF则最多丢一秒的数据。

4.2 AOF

AOF通过保存Redis服务器所执行的写命令来记录数据库状态。

AOF分为命令追加，文件写入和文件同步三个步骤：

1. 命令追加：服务器执行完写命令后，添加命令转成协议，追加到AOF缓冲区末尾；
2. 文件写入与同步：根据 appendfsync 的值进行选择，默认everysec。

appendfsync	描述	效率	安全性
always	将AOF缓冲区中的所有内容写入并同步到AOF文件。	最低	最安全，只丢失一个时间循环中所产生的命令数据
everysec	将AOF缓冲区中的所有内容写入到AOF文件，如果上次同步AOF文件的时间距离现在超过一秒，那么再次将AOF文件进行同步（由一个线程专门负责）。	足够快	只丢失一秒的命令数据
no	将AOF缓冲区中的所有内容写入到AOF文件，但并不对AOF文件进行同步，由操作系统决定。	最快	将丢失上次同步AOF文件之后的所有写命令数据

文件同步：在现代操作系统中，当用户调用write函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满，或者超过指定的时限之后，才真正的将缓冲区写入到磁盘中。

优点

1. AOF在对日志文件写入操作是以追加模式，少了磁盘寻址的开销，写入性能惊人，文件也不容易破损。
2. 有灵活的同步策略，支持每秒同步、每次修改同步和不同步。
3. RDB默认五分钟一次生成快照，AOF默认是一秒一次去通过一个后台的线程fsync操作，那最多丢这一秒的数据。

缺点

1. 相同规模的数据集，AOF要大于RDB，AOF在运行效率上往往会慢于RDB。

4.2.1 AOF重写

AOF重写是生成新AOF文件，并替换旧AOF文件的功能。使用BGREWIRTEAOF，来创建子进程进行AOF重写。但实际上，AOF文件重写并不需要对现有的AOF文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。它将原来可能保存一个键所需的多个命令减少为一条，来代替之前记录的这个键值对。如果超过常量值64，就会将一条命令转成多条。

步骤：

1. 发送BGREWIRTEAOF，创建子进程，执行AOF文件重写；
2. 执行客户端发来的命令过，追加写命令到AOF缓冲区，AOF重写缓冲区；
3. 完成AOF文件重写，向父进程发送信号；
4. 接收到子进程信号，将缓冲区追加到AOF文件的末尾；
5. 用新AOF文件覆盖旧AOF文件。

4.3 RDB与AOF

AOF文件的更新频率通常比RDB文件的更新频率高，所以如果服务器开启AOF，就会优先使用AOF还原；只有在AOF关闭时，才会使用RDB文件还原数据库状态。

5. 缓存

缓存是高并发场景下提高热点数据访问性能的一个有效手段。

5.1 缓存类型

缓存的类型分为：本地缓存、分布式缓存和多级缓存。

本地缓存
本地缓存就是在进程的内存中进行缓存，比如我们的JVM堆中，可以用LRUMap来实现，也可以使用Ehcache这样的工具来实现。

本地缓存是内存访问，没有远程交互开销，性能最好，但是受限于单机容量，一般缓存较小且无法扩展。

分布式缓存
分布式缓存可以很好得解决这个问题。

分布式缓存一般都具有良好的水平扩展能力，对较大数据量的场景也能应付自如。缺点就是需要进行远程请求，性能不如本地缓存。

多级缓存
为了平衡这种情况，实际业务中一般采用多级缓存，本地缓存只保存访问频率最高的部分热点数据，其他的热点数据放在分布式缓存中。

5.2 缓存问题

5.2.1 缓存雪崩

产生的原因是缓存挂掉，所有的请求都直接到数据库。

解决方法：

1. 在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效；

   setRedis(Key，value，time + Math.random() * 10000);
   

2. 如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题；
3. 设置热点数据永远不过期，有更新操作就更新缓存；
4. 使用快速失败的熔断策略，减少 DB 瞬间压力；
5. 使用主从模式和集群模式来尽量保证缓存服务的高可用；

5.2.2 缓存击穿

缓存击穿是指一个Key非常热点，在不停的扛着大并发，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库。

解决方法：

1. 设置热点数据永远不过期；
2. 使用互斥锁更新，保证同一个进程中针对同一个数据不会并发请求到数据库，减小数据库压力；
3. 使用随机退避方式，失效时随机sleep一个很短的时间，再次查询，如果失败再执行更新；

5.2.3 缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，数据库的id都是1开始自增上去的，如发起为id值为-1的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。

解决方法：

1. 在接口层增加参数校验。
2. 从缓存取不到的数据，在数据库中也没有取到，这时也可以将对应Key的Value对写为null、位置错误、稍后重试这样的值，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击，我们要知道正常用户是不会在单秒内发起这么多次请求的，那网关层Nginx可以对单个IP每秒访问次数超出阈值的IP都拉黑。
3. 使用布隆过滤器（Bloom Filter），特点是存在性检测，利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在就return，存在你就去查了DB刷新KV再return。

5.3 一致性

最经典的缓存+数据库读写的模式，就是Cache Aside Pattern。

读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
更新的时候，先更新数据库。如果涉及很多其他的逻辑操作，应该删除缓存；如果只是更改缓存中的值，无其他逻辑操作，可以直接更新。

6. 内存淘汰

6.1 失效机制

Redis 的key可以设置过期时间，过期后Redis采用主动和被动结合的失效机制，一种是在定期的主动删除，另一种是访问时触发惰性删除。

最大内存 maxmemory 可以设置内存使用限制为指定的字节数。当达到内存限制时，Redis将根据选择的淘汰机制尝试删除密钥。如果Redis无法根据策略删除密钥，或者策略为设置为’noeviction’，Redis将开始回复命令错误将使用更多的内存，例如SET，LPUSH等，并将继续回复诸如GET之类的只读命令。

1. 定期删除：默认100s就随机抽一些设置了过期时间的key，去检查是否过期，过期了就删了；
2. 惰性删除：查询key的时候，判断是否过期，过期就删掉返回空。

6.2 内存淘汰机制

内存淘汰机制	解释
noeviction	不要逐出任何东西，只需在写操作中返回错误。
allkeys-lru	尝试回收最近最少使用的键（LRU），使得新添加的数据有空间存放。
volatile-lru	尝试回收最近最少使用的键（LRU），但仅限于在过期集合的键，使得新添加的数据有空间存放。
allkeys-lfu	尝试回收最少使用的键（LFU），使得新添加的数据有空间存放。
volatile-lfu	尝试回收最少使用的键（LFU），但仅限于在过期集合的键，使得新添加的数据有空间存放。
allkeys-random	回收随机的键，使得新添加的数据有空间存放。
volatile-random	回收随机的键，但仅限于在过期集合的键，使得新添加的数据有空间存放。
volatile-ttl	回收在过期集合的键，并且优先回收存活时间（TTL）较短的键，使得新添加的数据有空间存放。

7. 复制

在Redis中，可通过执行SLAVEOF命令或设置slaveof选项，让一个服务器去复制另一个服务器。被复制的称为主服务器，对主服务器进行复制的称为从服务器。

复制功能分为同步（sync）和命令传播（command propagate）：

1. 同步：用于将从服务器的数据库状态更新至主服务器当前所处的服务器状态。
2. 命令传播：当主服务器的数据库状态被修改，导致主从服务器的数据库状态不一致时，让主从服务器的数据库重新回到一致状态。

7.1 旧版复制

同步

1. 从服务器连接主服务器，发送SYNC命令；
2. 主服务器接收到SYNC命名后，开始执行BGSAVE命令，在后台生成RDB文件，并使用缓冲区记录从现在开始执行的所有写命令；
3. 主服务器BGSAVE执行完后，将生成的RDB文件发送给从服务器，并在发送期间继续记录被执行的写命令；
4. 从服务器收到快照文件后丢弃所有旧数据，载入收到的RDB文件；
5. 主服务器在发送RDB文件完毕后，开始向从服务器发送缓冲区中的写命令；
6. 从服务器完成对RDB文件的载入，并执行来自主服务器缓冲区的写命令。

命令传播
在同步操作执行完毕后，主从服务器的数据库将达到一致状态。但是当主服务器执行客户端发送的写命令时，主从数据库状态又不一致了。所以主服务器需要将写命令发送给从服务器去执行，让主从数据库状态再次回到一致。

缺陷

1. 从服务器初次复制可以很好完成任务，但对于断线后重新复制，虽然最终能回到一致状态，但是效率很低。

7.2 新版复制

为了解决旧版复制功能来处理断线重复复制情况时的低效问题，Redis使用PSYNC命令来代替SYNC命令来执行复制时的同步操作。

PSYNC命令具有完整重同步（full resynchronization）和部分重同步（patial resynchronization）两种模式：

1. 完整重同步：用于处理初次同步情况。和SYNC命令执行步骤一样，通过让主服务器创建并发送RDB文件，以及向
   从服务器发送保存在缓冲区里面的写命令来进行同步
2. 部分重同步：用于处理断线后重复制情况。当从服务器在断线后重新连接主服务器，如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这些写命令，就可以将数据库更新至主服务器当前状态。

7.2.1 部分重同步

部分重同步通过复制偏移量，复制积压缓冲区，服务器运行ID三个部分来实现。

7.2.1.1 复制偏移量

主从服务器都分别维护一个复制偏移量，主服务器每次向从服务器传播N个字节的数据，就会在自己的服务偏移量上加N；从服务器每次收到主服务器传播来的N个字节的数据，也会在自己的服务偏移量上加N。

7.2.1.2 复制积压缓冲区

主服务器维护的一个固定长度的先进先出队列，默认为1M，通过repl-backlog-size选项进行修改复制积压缓冲区大小。当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列。

当主服务器进行命令传播时，不仅将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区中。主服务器的复制积压缓冲区里面会保存一部分最近传播的写命令，并且会为每个字节记录偏移量。

当从服务器重新连上主服务器，从服务器通过PSYNC命令将自己的复制偏移量offset发送给主服务器，主服务器会根据这个复制偏移量决定进行何种同步。
如果offset偏移量之后的数据（即offset+1）仍然在复制积压缓冲区中，那么进行部分重同步；否则进行完成重同步。

7.2.1.3 服务器运行ID

每个服务器，无论主从，都有自己的运行ID，在启动时自动生成。

当从服务器对主服务器进行初次复制，主服务器会将自己的运行ID发送给从服务器，从服务器会将这个运行ID保存起来。
当从服务器断线并重新脸上一个主服务器，从服务器将向当前连接的主服务器发送之前保存的运行ID。如果断线前后的主服务器运行ID相同，主服务器继续尝试执行部分重同步；相反，主服务器执行完成重同步。

主服务器通过向从服务器传播命令来更新从服务器的状态，保持主从服务器一致。
而从服务器则通过向主服务器发送命令来进行心跳检测，以及命令丢失检测。

8. Sentinal

Sentinal（哨兵）是Redis的高可用解决方案：由一个或多个Sentinal实例组成Sentinal系统，通过Raft协议来保证自身的高可用。

Sentinal系统可以监控任意多个主服务器，以及这些主服务器属下的所有从服务器。在被监控的主服务器进入下线状态时，Sentinal系统会选出Sentinal Leader，负责执行故障转移操作，将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

Sentinal选主策略

1. slave的priority设置的越低，优先级越高；
2. 同等情况下，slave复制的数据越多优先级越高；
3. 相同的条件下运行id越小越容易被选中。

哨兵组件的主要功能

1. 集群监控：负责监控Redis master和slave进程是否正常工作。
2. 消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
3. 故障转移：如果master node挂掉了，会自动转移到slave node上。
4. 配置中心：如果故障转移发生了，通知client客户端新的 master 地址。

9. Cluster

Redis 集群是Redis提供的分布式数据库方案，集群通过分片（sharding）来进行数据共享，并提供复制和故障转移功能。

集群的整个数据库被分为16384个槽（slot），数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点可以处理0个或最多16384个槽。

复制与故障转移
Redis集群中的节点分为主节点（Master）和从节点（Slave），其中主节点用于处理槽，而从节点则用于复制某个主节点，并在被复制的主节点下线时，在从节点中通过Raft协议选举新的主节点，代替下线主节点继续处理命令请求。

10. 底层数据结构

10.1 简单动态字符串

Redis没有直接使用C语言传统的字符串标识，而是使用简单动态字符串（simple dynamic string），并将SDS用于默认字符串表示。SDS 还可以作为缓冲区：包括 AOF 模块中的AOF缓冲区以及客户端状态中的输入缓冲区。

struct sdshdr{// 记录buf数组中已使用字节的数量，等于SDS保存字符串的长度int len; // 记录 buf 数组中未使用字节的数量int free; // 字节数组，用于保存字符串char buf[];
}

10.1.1 相比C字符串优势

10.1.1.1 常数复杂度获取字符串长度

C 语言，获取字符串的长度通常是经过遍历计数来实现的，时间复杂度为 O(n)；SDS有len 属性，获取 SDS 字符串的长度只需要读取 len 属性。

10.1.1.2 杜绝缓冲区溢出

C 语言中使用 strcat 函数来进行两个字符串的拼接，一旦没有分配足够长度的内存空间，就会造成缓冲区溢出；SDS 数据类型，在进行字符修改的时候，会首先根据记录的 len 属性检查内存空间是否满足需求，如果不满足，会进行相应的空间扩展，然后再进行修改操作。

10.1.1.3 减少修改字符串的内存重新分配次数

C语言由于不记录字符串的长度，所以如果要修改字符串，必须要重新分配内存（先释放再申请），因为如果没有重新分配，字符串长度增大时会造成内存缓冲区溢出，字符串长度减小时会造成内存泄露。

对于SDS，由于len属性和free属性的存在，对于修改字符串SDS实现了空间预分配和惰性空间释放两种策略：

1. 空间预分配（优化字符串增长）：SDS在进行修改，还会为SDS分配额外的未使用空间。当len小于1MB，那么分配和len同样大小的未使用空间；当len大于1MB，那么分配1MB未使用空间。通过空间预分配，Redis可以减少连续执行字符串增长操作所需的内存重分配。
2. 惰性空间释放（优化字符串缩短）：SDS要缩短保存的字符串时，不会立即使用内存重分配回收缩短出来的字节，而是使用free属性将这些字节数量记录下来，并等待将来使用。避免缩短字符串时所需的内存重分配操作，并为将来的增长提供优化。SDS也提供了相应的API，可以手动释放这些未使用的空间。

10.1.1.4 二进制安全

C字符串以空字符作为字符串结束的标识，而对于一些二进制文件（如图片等），内容可能包括空字符串，因此C字符串无法正确存取；SDS 的API 都是以处理二进制的方式来处理 buf 里面的元素，并且 SDS 不是以空字符串来判断是否结束，而是以 len 属性表示的长度来判断字符串是否结束。

10.1.1.5 兼容部分 C 字符串函数

SDS 是二进制安全的，但是一样遵从每个字符串都是以空字符串结尾的惯例，这样可以重用 C 语言库<string.h> 中的一部分函数。

10.2 字典

Redis的字典使用哈希表作为底层实现，类似HashMap。

一个哈希表里面可以有多个哈希表节点，而每个哈希节点就保存了字典中的一个键值对。

10.3 跳跃表

跳跃表（SkipList）是基于有序链表的扩展，通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。支持平均O(logN)，最坏O(N)复杂度的节点查找，还可以通过顺序性操作来批量处理节点。

Redis使用跳表不用b+树，是因为跳表相比b+树实现简单，占用内存小。

性质

1. 由很多层结构组成；
2. 每一层都是一个有序的链表，排列顺序为由高层到底层，都至少包含两个链表节点，分别是前面的head节点和后面的nil节点；
3. 最底层的链表包含了所有的元素；
4. 如果一个元素出现在某一层的链表中，那么在该层之下的链表也全都会出现（上一层的元素是当前层的元素的子集）；
5. 链表中的每个节点都包含两个指针，一个指向同一层的下一个链表节点，另一个指向下一层的同一个链表节点；

跳跃表有很多层组成，每层都是链表，并且是有序的，每个节点保存这指向同层下一个节点和指向下一层同一个节点的指针。其中最底层的链表保存了所有的数据，通过分层优化搜索存储在最底层的数据，进行搜索和插入。

1. 搜索：从最高层的链表节点开始，如果比当前节点要大和比当前层的下一个节点要小，那么则往下找。也就是和下一层的同节点的下一个节点进行比较，以此类推，一直找到最底层的最后一个节点，如果找到则返回，反之则返回空。
2. 插入：首先确定插入的层数，一种方法是假设抛一枚硬币，如果是正面就累加，直到遇见反面为止，最后记录正面的次数作为插入的层数。当确定插入的层数k后，则需要将新元素插入到从底层到k层。
3. 删除：在各个层中找到包含指定值的节点，然后将节点从链表中删除即可，如果删除以后只剩下头尾两个节点，则删除这一层。

10.4 整数集合

整数集合（intset）是集合的底层实现之一，当一个集合只包含整数值元素，并且这个集合的元素数量不多时，Redis就会使用整数集合作为集合的底层实现。

struct inset{// 编码方式uint32_t encoding;// 集合包含元素数量uint32_t length;// 保存元素的数组int8_t contents[];
}

intset可以保存int16_t、int32_t或int64_t的整数值，并且保证集合中不会出现重复元素（通过二分查找整数判断是否已存在）。

升级
当新元素要添加到整数集合，并且新元素的类型比整数集合现有所有元素的类型要长时，整数集合会先进行升级，然后才能将新元素添加到里面，所以添加元素的时间复杂度为O(N)。

新元素小于所有现有元素时，新元素添加到最开头（索引0）；相反，新元素添加到最末尾（索引length-1）。

升级策略可以提升整数集合的灵活性，并且可以尽可能的节约内存；但不支持降级，升级后会一直保持升级状态。

10.5 压缩列表

压缩列表（zipList）是Redis为了节约内存而开发，是由一系列特殊编码的连续内存块组成的顺序型数据结构。当一个列表只包含少量列表项或一个哈希只包含少量键值对，Redis就会使用压缩列表来做列表和哈希的底层实现。

一个压缩列表可以包含任意多个节点，每个节点可以保存一个字节数组或者一个整数值。

10.6 数据类型底层实现

判断对象类型

type key

查看值对象的编码

object encoding key

10.6.1 String

String的编码可以是int，embstr或raw。

1. int 编码：保存的是可以用 long 类型表示的整数值。
2. embstr 编码：保存长度小于44字节的字符串（Redis 3.2 版本之前是39字节，之后是44字节）。
3. raw 编码：保存长度大于44字节的字符串（Redis 3.2 版本之前是39字节，之后是44字节）。

当 int 编码保存的值不再是整数，或大小超过了long的范围时，自动转化为raw。

对于 embstr 编码，由于 Redis 没有对其编写任何的修改程序（embstr 是只读的），在对embstr对象进行修改时，都会先转化为raw再进行修改，因此，只要是修改embstr对象，修改后的对象一定是raw的，无论是否达到了44个字节。

10.6.2 List

List的编码可以是压缩列表，双端链表。

当同时满足下面两个条件时，使用压缩列表编码：

1. 每个元素长度小于64字节（redis.conf 中的 list-max-ziplist-value 选项）；
2. 列表保存元素个数小于512个（redis.conf 中的 list-max-ziplist-entries 选项）。

不能满足这两个条件的时候使用双端链表编码。

10.6.3 Hash

Hash的编码可以是压缩列表，字典。

当同时满足下面两个条件时，使用压缩列表编码：

1. 每个元素长度小于64字节；
2. 列表保存元素个数小于512个（redis.conf 中的 set-max-intset-entries 选项）。

不能满足这两个条件的时候使用字典编码。

10.6.4 Set

Set的编码可以是整数集合，字典。

当同时满足下面两个条件时，使用整数集合编码：

1. 集合对象中所有元素都是整数；
2. 集合对象所有元素数量不超过512（redis.conf 中的 set-max-intset-entries 选项）。

不能满足这两个条件的就使用字典编码。

10.6.5 Sorted Set

Sorted Set的编码可以是压缩列表，跳跃表+字典。

当同时满足下面两个条件时，使用压缩列表编码：

1. 元素长度都小于64字节（redis.conf 中的 zset-max-ziplist-value 选项）；
2. 元素数量小于128（redis.conf 中的 zset-max-ziplist-entries 选项）。

不能满足上面两个条件的使用跳跃表+字典编码。

以上两个条件也可以通过Redis配置文件zset-max-ziplist-entries 选项和 zset-max-ziplist-value 进行修改。

11. 与Memcache区别

Memcache

1. 使用多线程异步IO的方式，可以合理利用CPU多核的优势，性能非常优秀；
2. 功能简单，使用内存存储数据；
3. 对缓存的数据可以设置失效期，过期后的数据会被清除；
4. 失效的策略采用延迟失效，就是当再次使用数据时检查是否失效；
5. 当容量存满时，会对缓存中的数据进行剔除，剔除时除了会对过期key进行清理，还会按LRU策略对数据进行剔除。

Memcache限制

1. key不能超过250个字节；
2. value不能超过1M字节；
3. key的最大失效时间是30天；
4. 只支持K-V结构，不提供持久化和主从同步功能。

Redis支持复杂的数据结构
Redis相比Memcached来说，拥有更多的数据结构，能支持更丰富的数据操作。

Redis原生支持集群模式
在redis 3.x版本中，就能支持Cluster模式，而Memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据。

性能对比
由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起 Remcached，还是稍有逊色。

12. 学习思路

1. 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃；
2. 事中：本地ehcache缓存 + Hystrix限流+降级，避免MySQL被打死；
3. 事后：Redis 持久化RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据；

数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。只要数据库不死，就是说，对用户来说，3/5的请求都是可以被处理的。 只要有3/5的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来一次。

13. 命令

keys

获取指定模式key列表。由于Redis单线程，如果Key很多，执行keys命令就会阻塞直到完成。

scan

无阻塞获取指定模式的key列表，会有一定的重复概率，需要在客户端做一次去重，整体所花费的时间会比直接用keys指令长。

scan命令仅对返回的元素提供有限保证，因为递增迭代的集合可以在迭代过程中更改。

del

删除命令del是阻塞的。

unlink

异步删除一个key。

flushall/flushdb async

异步删除数据库所有key。

参考：
Redis基础
缓存雪崩、击穿、穿透
Redis哨兵、持久化、主从、手撕LRU
双写一致性、并发竞争、线程模型
Redis常见面试题
Redis的最全知识点
I/O多路复用技术（multiplexing）是什么？
缓存，究竟是淘汰，还是修改？
究竟先操作缓存，还是数据库？
Redis 的主从同步，及两种高可用方式
Redis 教程
Redis 中文官网 redis.conf
漫画：什么是跳跃表？
Redis 设计与实现
Redis数据结构——压缩列表
Redis详解（四）------ redis的底层数据结构
Redis详解（五）------ redis的五大数据类型实现原理