1、Redis的五种数据结构

Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（无序集合）及zset(有序集合)。

• String：一个 key 对应一个字符串，string是Redis 最基本的数据类型。（字节的abase框架只实现了redis的string数据结构，导致我们如果想要存储复杂的数据结构的时候，只能转成json格式的字符串来存储）
• list：一个 key 对应一个字符串列表，底层使用双向链表实现，很多双向链表支持的操作它都支持。

• Hash：

• Set：比如一个Set的实例：A = {'a', 'b', 'c'}，A是集合的key，‘a’, 'b’和‘c’是集合的member。无序、无重复元素。
• SortedSet：在set的基础上加上一个分数score，set里面的数据是有序的

1.1 redis数据结构底层实现

1.1.1 String

使用一种叫简单动态字符串（SDS）的数据类型来实现。

SDS 相比C 字符串的优势：

• SDS保存了字符串的长度，而C字符串不保存长度，需要遍历整个数组（找到’\0’为止）才能取到字符串长度。
• 修改SDS时，检查给定SDS空间是否足够，如果不够会先拓展SDS 的空间，防止缓冲区溢出。C字符串不会检查字符串空间是否足够，调用一些函数时很容易造成缓冲区溢出（比如strcat字符串连接函数）。
• SDS预分配空间的机制，可以减少为字符串重新分配空间的次数。

1.1.2 List

使用双向链表来实现。

1.1.3 Hash

hash结构里其实是一个字典，有许多的键值对（类似于python的dict类型）。

redis的哈希表是一个dictht结构体：

哈希表节点的结构体如下：

其中解决哈希冲突的方法是拉链法。

为了让哈希表的装载因子维持在一个合理的范围之内，需要对哈希表的大小进行扩展或者收缩，这叫做rehash。字典中总共有两个哈希表dictht结构体，ht[0]用来存储键值对，ht[1]用于rehash时暂存数据，平时它指向的哈希表为空，需要扩展或者收缩ht[0]的哈希表时才为它分配空间。

比如扩展哈希表，就是为ht[1]分配一块大小为ht[0]两倍的空间，然后把ht[0]的数据通过rehash的方式全部迁移到ht[1]，最后释放ht[0]，使ht[1]成为ht[0]，再为ht[1]分配一个空哈希表。收缩哈希表类似。

渐进式rehash：redis并不是专门找时间一次性地进行rehash，而是渐进地进行，rehash期间不影响外部对ht[0]的访问，要求修改字典时要把对应数据同步到ht[1]中，全部数据转移完成时，rehash结束。

1.1.4 Set

set可以用intset或者字典实现。

1.1.4.1 inset

只有当数据全是整数值，而且数量少于512个时，才使用intset，intset是一个由整数组成的有序集合，可以进行二分查找。

1.1.4.2 字典

不满足intset使用条件的情况下都使用字典（拉链法），使用字典时把value设置为null。

1.1.5 zset

zset中的每个元素包含数据本身和一个对应的分数(score)。

经典例子：一个zset的key是"math"，代表数学课的成绩，然后可以往这个key里插入很多数据。输入数据的时候，每次需要输入一个姓名和一个对应的成绩。那么这个姓名就是数据本身，成绩就是它的score。

zset的数据本身不允许重复，但是score允许重复。

zset底层实现原理：

1. 数据少时，使用ziplist：ziplist占用连续内存，每项元素都是（数据+score）的方式连续存储，按照score从小到大排序。ziplist为了节省内存，每个元素占用的空间可以不同，对于大的数据（long long），就多用一些字节来存储，而对于小的数据（short），就少用一些字节来存储。因此查找的时候需要按顺序遍历。ziplist省内存但是查找效率低。
2. 数据多时，使用字典+跳表：

字典用来根据数据查score，跳表用来根据score查找数据（查找效率高）。

理论上来讲，查找、插入、删除以及迭代输出有序序列这几个操作，红黑树也可以完成，时间复杂度和跳表是一样的。

redis使用跳表而不是红黑树的原因：

1. 按照区间查找数据这个操作，红黑树的效率没有跳表高。跳表可以在 O(logn)时间复杂度定位区间的起点，然后在原始链表中顺序向后查询就可以了。
2. 相比于红黑树，跳表还具有代码更容易实现、可读性好、不容易出错、更加灵活等优点。
3. 插入、删除时跳表只需要调整少数几个节点，红黑树需要颜色重涂和旋转，开销较大。

跳表插入删除过程

跳表是基于一条有序单链表构造的，通过构建索引提高查找效率，空间换时间，查找方式是从最上面的链表层层往下查找，最后在最底层的链表找到对应的节点：

插入： 逐层查找位置，然后插入到最底层链表。注意需要维护索引与原始链表的大小平衡，如果底层结点大量增多了，索引也相应增加，避免出现两个索引之间结点过多的情况，查找效率降低。同理，底层结点大量减少时，索引也相应减少。

删除： 如果这个结点在索引中也有出现，那么除了要删除原始链表中的结点，还要删除索引中的这个结点。

跳表查找的时间复杂度为O(log(n))。索引占用的空间复杂度为 O(n)。

时间复杂度：时间复杂度 = 索引的层数 * 每层索引遍历元素的个数。

首先看索引层数，假设每两个节点抽一个出来作为上一级索引的结点，而且最高一级索引有3个节点，则索引层数为log2(n)。

然后看每层遍历多少个元素，首先最高层最多遍历3个节点，就能往下走了，同理，次高层也最多遍历三个节点，就能往下走。取平均之后，可以认为每层遍历2个节点。

因此时间复杂度=2log2(n)，同理，如果是每k个节点取一个索引的话，就是klogk(n)

空间复杂度：也是以每两个节点取一个索引为例，第一层n个节点，第二层n/2，第三次n/4，等比序列求和，或者取极限，可以认为索引节点数量无限接近于n，所以空间复杂度为O(n)。

2、Redis持久化

Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数 据恢复。理解掌握持久化机制对于Redis运维非常重要

2.1 RDB持久化

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发

2.1.1 触发机制

手动触发分别对应save和bgsave命令

• save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用

• bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短

2.1.2 自动触发RDB的持久

1. 使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改 时，自动触发bgsave。
2. 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点，更多细节见6.3节介绍的复制原理。
3. 执行debug reload命令重新加载Redis时，也会自动触发save操作。
4. 默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则 自动执行bgsave。

bgsave是主流的触发RDB持久化方式

1. 执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进 程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
2. 父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通 过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒
3. 父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。
4. 子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后 对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的 时间，对应info统计的rdb_last_save_time选项。
5. 进程发送信号给父进程表示完成，父进程更新统计信息，具体见 info Persistence下的rdb_*相关选项。

RDB文件的处理

保存：RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配 置指定。可以通过执行config set dir{newDir}和config set dbfilename{newFileName}运行期动态执行，当下次运行时RDB文件会保存到新目录。

2.1.3 RDB的优缺点

RDB的优点：

• RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据 快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份， 并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。

• Redis加载RDB恢复数据远远快于AOF的方式。

RDB的缺点：

• RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运 行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

• RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式 的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。

2.2 AOF持久化

AOF（append only file）持久化：以独立日志的方式记录每次写命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用 是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

2.2.1 使用AOF

开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名 通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同 RDB持久化方式一致，通过dir配置指定。AOF的工作流程操作：命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）

1. 所有的写入命令会追加到aof_buf（缓冲区）中。

2. AOF缓冲区根据对应的策略向硬盘做同步操作。AOF为什么把命令追加到aof_buf中？Redis使用单线程响应命令，如 果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负 载。先写入缓冲区aof_buf中，还有另一个好处，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡

3. 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。重写后的AOF文件为什么可以变小？有如下原因：

   3.1. 进程内已经超时的数据不再写入文件。

   3.2. 旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。

   3.3 多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢 出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。

   AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF 文件可以更快地被Redis加载

   AOF重写过程可以手动触发和自动触发：

• 手动触发：直接调用bgrewriteaof命令。

• 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

• auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认 为64MB。

• auto-aof-rewrite-percentage：代表当前AOF文件空间 （aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。

  自动触发时机=aof_current_size>auto-aof-rewrite-minsize&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewritepercentage

  其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。

4. 当Redis服务器重启时，可以加载AOF文件进行数据恢复。

2.2.2 流程说明

1. AOF持久化开启且存在AOF文件时，优先加载AOF文件，打印如下日志：

• DB loaded from append only file: 5.841 seconds

2. AOF关闭或者AOF文件不存在时，加载RDB文件，打印如下日志：

• DB loaded from disk: 5.586 seconds

3. 加载AOF/RDB文件成功后，Redis启动成功。

4. AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

2.3 本章重点回顾

1. Redis提供了两种持久化方式：RDB和AOF。
2. RDB使用一次性生成内存快照的方式，产生的文件紧凑压缩比更 高，因此读取RDB恢复速度更快。由于每次生成RDB开销较大，无法做到实时持久化，一般用于数据冷备和复制传输。
3. save命令会阻塞主线程不建议使用，bgsave命令通过fork操作创建子 进程生成RDB避免阻塞。
4. AOF通过追加写命令到文件实现持久化，通过appendfsync参数可以 控制实时/秒级持久化。因为需要不断追加写命令，所以AOF文件体积逐渐变大，需要定期执行重写操作来降低文件体积。
5. AOF重写可以通过auto-aof-rewrite-min-size和auto-aof-rewritepercentage参数控制自动触发，也可以使用bgrewriteaof命令手动触发。
6. 子进程执行期间使用copy-on-write机制与父进程共享内存，避免内 存消耗翻倍。AOF重写期间还需要维护重写缓冲区，保存新的写入命令避免数据丢失。
7. 持久化阻塞主线程场景有：fork阻塞和AOF追加阻塞。fork阻塞时间 跟内存量和系统有关，AOF追加阻塞说明硬盘资源紧张。
8. 单机下部署多个实例时，为了防止出现多个子进程执行重写操作， 建议做隔离控制，避免CPU和IO资源竞争。

3、Redis集群的几种模式

3.1 Redis主从

3.1.1 Redis主从原理

和MySQL需要主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生性能瓶颈，特别是在读压力上，为了分担压力，Redis支持主从复制。Redis的主从结构一主一从，一主多从或级联结构，复制类型可以根据是否是全量而分为全量同步和增量同步。

下图为级联结构：

3.1.1.1 全量同步

Redis全量复制一般发生在slave的初始阶段，这时slave需要将master上的数据都复制一份，具体步骤如下：

1. slave连接master，发送SYNC命令；
2. master街道SYNC命令后，执行BGSAVE命令生产RDB文件并使用缓冲区记录此后执行的所有写命令；
3. master的BGSAVE执行完成后，向所有的slave发送快照文件，并在发送过程中继续记录执行的写命令；
4. slave收到快照后，丢弃所有的旧数据，载入收到的数据；
5. master快照发送完成后就会开始向slave发送缓冲区的写命令；
6. slave完成对快照的载入，并开始接受命令请求，执行来自master缓冲区的写命令；
7. slave完成上面的数据初始化后就可以开始接受用户的读请求了。

大致流程图如下：

3.1.1.2 增量复制

增量复制实际上就是在slave初始化完成后开始正常工作时master发生写操作同步到slave的过程。增量复制的过程主要是master每执行一个写命令就会向slave发送相同的写命令，slave接受并执行写命令，从而保持主从一致。

3.1.2 Redis主从同步的策略

主从同步刚连接的时候进行全量同步；全量同步结束后开始增量同步。如果有需要，slave在任何时候都可以发起全量同步，其主要策略就是无论如何首先会尝试进行增量同步，如果步成功，则会要求slave进行全量同步，之后再进行增量同步。

注意：如果多个slave同时断线需要重启的时候，因为只要slave启动，就会和master建立连接发送SYNC请求和主机全量同步，如果多个同时发送SYNC请求，可能导致master IO突增而发送宕机。

主从复制优缺点：

优点：

• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
• 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成
• Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。
• Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
• Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

缺点：

• Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

3.2 Redis哨兵

3.2.1 Redis哨兵机制

在主从复制实现之后，如果想对master进行监控，Redis提供了一种哨兵机制，哨兵的含义就是监控Redis系统的运行状态，并做相应的响应。

3.2.1.1 哨兵的功能

其主要的功能有以下两点：

1. 监控所有Redis节点是否正常运行；
2. master故障后可以通过投票机制，从slave中选举出新的master，保证集群正常运行。

在一个一主多从的集群中，可以启用多个哨兵进行监控以保证集群足够稳健，这种情况下，哨兵不仅监控主从服务，哨兵之间也会相互监控，建议哨兵至少3个并且是奇数。

3.2.1.2 哨兵的任务

哨兵主要用于管理多个Redis服务器，主要有以下三个任务：

1. 监控：哨兵会不断的检测master和slave之间是否运行正常；
2. 提醒：当监控的某个Redis出现问题，哨兵可以通过API向管理员或其他应用程序发送通知；
3. 故障迁移：当一个master不能正常工作时，哨兵会开始一次自动故障迁移操作，它会将失效master的其中一个slave提升为master，并让失效master和其他slave该为复制新的master，当客户端试图连接失效的master时，集群也会向客户端返回新的master地址，使得集群可以使用新的master代替失效的master。

3.2.2 Redis哨兵的工作原理

哨兵是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议来接收关于Master是否下线的信息,并使用投票协议来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。

每个哨兵会向其它哨兵、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂。若“哨兵群”中的多数sentinel都报告某一master没响应,系统才认为该master"彻底死亡"，通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。

虽然哨兵释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵。

3.2.2.1 监控

sentinel会每秒一次的频率与之前创建了命令连接的实例发送PING，包括主服务器、从服务器和sentinel实例，以此来判断当前实例的状态。down-after-milliseconds时间内PING连接无效，则将该实例视为主观下线。之后该sentinel会向其他监控同一主服务器的sentinel实例询问是否也将该服务器视为主观下线状态，当超过某quorum后将其视为客观下线状态。

当一个主服务器被某sentinel视为客观下线状态后，该sentinel会与其他sentinel协商选出零头sentinel进行故障转移工作。每个发现主服务器进入客观下线的sentinel都可以要求其他sentinel选自己为领头sentinel，选举是先到先得。同时每个sentinel每次选举都会自增配置纪元，每个纪元中只会选择一个领头sentinel。如果所有超过一半的sentinel选举某sentinel领头sentinel。之后该sentinel进行故障转移操作。

如果一个Sentinel为了指定的主服务器故障转移而投票给另一个Sentinel，将会等待一段时间后试图再次故障转移这台主服务器。如果该次失败另一个将尝试，Redis Sentinel保证第一个活性(liveness)属性，如果大多数Sentinel能够对话，如果主服务器下线，最后只会有一个被授权来故障转移。 同时Redis Sentinel也保证安全(safety)属性，每个Sentinel将会使用不同的配置纪元来故障转移同一台主服务器。

3.2.2.2 故障迁移

首先是从主服务器的从服务器中选出一个从服务器作为新的主服务器。选点的依据依次是：网络连接正常->5秒内回复过INFO命令->10*down-after-milliseconds内与主连接过的->从服务器优先级->复制偏移量->运行id较小的。选出之后通过slaveif no ont将该从服务器升为新主服务器。

其次通过slaveof ip port命令让其他从服务器复制该信主服务器。

最后当旧主重新连接后将其变为新主的从服务器。注意如果客户端与就主服务器分隔在一起，写入的数据在恢复后由于旧主会复制新主的数据会造成数据丢失。

故障转移成功后会通过发布订阅连接广播新的配置信息，其他sentinel收到后依据配置纪元更大来更新主服务器信息。Sentinel保证第二个活性属性：一个可以相互通信的Sentinel集合会统一到一个拥有更高版本号的相同配置上。

3.2.2.3 缺点

1. 主从服务器的数据要经常进行主从复制，这样会造成性能下降；
2. 当主服务器宕机后，从服务器切换成主服务器的那段时间，服务是不可用的。

3.3 Redis-cluster模式

Redis在3.0版本开始正式引用RedisCluster特性，RedisCluster是一个分布式，高容错的内存K/V系统，RedisCluster可以使用的功能是普通单机Redis所使用的功能的一个子集，比如，RedisCluster并不支持处理多个keys的命令，因为这需要在不同节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会出现无法预估的错误。

3.3.1 Redis集群的特征

Redis集群有以下几个重要的特征：

1. RedisCluster集群的分片特征在于将空间拆分为16384个槽位，某一个节点负责其中一些槽位；
2. Redis集群提供一定程度的可用性，可以在某个节点宕机或者不可达的情况继续处理命令；
3. Redis集群不存在中心节点或代理节点，集群的其中一个最重要的设计目标是达到线性可扩展性；

其架构如下：

其中每一个圆代表一个节点，任何两个节点是互通的，可以归纳以下几点：

• 所有的节点相互连接；
• 集群消息通信通过集群总线通信，，集群总线端口大小为客户端服务端口+10000，这个10000是固定值；
• 节点与节点之间通过二进制协议进行通信；
• 客户端和集群节点之间通信和通常一样，通过文本协议进行；
• 集群节点不会代理查询；

3.3.2 RedisCluster的原理

Redis Cluster中有一个16384长度的槽的概念，他们的编号为0、1、2、3……16382、16383。这个槽是一个虚拟的槽，并不是真正存在的。正常工作的时候，Redis Cluster中的每个Master节点都会负责一部分的槽，当有某个key被映射到某个Master负责的槽，那么这个Master负责为这个key提供服务，至于哪个Master节点负责哪个槽，这是可以由用户指定的，也可以在初始化的时候自动生成（redis-trib.rb脚本）。这里值得一提的是，在Redis Cluster中，只有Master才拥有槽的所有权，如果是某个Master的slave，这个slave只负责槽的使用，但是没有所有权。

如下所示：

那么Redis集群是怎么存储的呢？

首先，在redis的每一个节点上，都有这么两个东西，一个是插槽（slot）可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是：0-16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

还有就是因为如果集群的话，是有好多个redis一起工作的，那么，就需要这个集群不是那么容易挂掉，所以，理论上就应该给集群中的每个节点至少一个备用的redis服务，这个备用的redis称为从节点（slave）。然后，每一个节点都存有这个集群所有主节点以及从节点的信息，它们之间通过互相的ping-pong判断是否节点可以连接上。

如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。如果某个节点和所有从节点全部挂掉，我们集群就进入faill状态。还有就是如果有一半以上的主节点宕机，那么我们集群同样进入发力了状态。这就是我们的redis的投票机制。

具体的原理图如下：

1. 投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout)认为当前master节点挂掉.
2. 什么时候整个集群不可用(cluster_state:fail)

    a、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败。

    b、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态。

4、Redis的过期策略和内存淘汰机制

4.1 内存淘汰机制

redis内存淘汰机制有以下几个：

1、未设置过期时间

• noeviction默认策略：当内存不足以容纳新写入数据时，新写入操作会报错。这个一般很少用。
• allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key，这个是最常用的。
• allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

2、设置过期时间

• volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
• volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
• volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

4.1.1 Redis中LRU策略的实现（最近最少使用）

在redisObject结构体中定义了一个长度24bit的unsigned类型的字段，用来存储对象最后一次被命令程序访问的时间：

最初Redis是这样实现的：

随机选三个Key，把idle time最大的那个Key移除。后来，把3改成可配置的一个参数，默认为N=5：maxmemory-samples 5

就是这么简单，简单得让人不敢相信了，而且十分有效。但它还是有缺点的：每次随机选择的时候，并没有利用历史信息。在每一轮移除(evict)一个Key时，随机从N个里面选一个Key，移除idle time最大的那个Key；下一轮又是随机从N个里面选一个Key...有没有想过：在上一轮移除Key的过程中，其实是知道了N个Key的idle time的情况的，那我能不能在下一轮移除Key时，利用好上一轮知晓的一些信息？

start from scratch太傻了。于是Redis又做出了改进：采用缓冲池(pooling)

当每一轮移除Key时，拿到了这个N个Key的idle time，如果它的idle time比 pool 里面的 Key的idle time还要大，就把它添加到pool里面去。这样一来，每次移除的Key并不仅仅是随机选择的N个Key里面最大的，而且还是pool里面idle time最大的，并且：pool 里面的Key是经过多轮比较筛选的，它的idle time 在概率上比随机获取的Key的idle time要大，可以这么理解：pool 里面的Key 保留了"历史经验信息"。

采用"pool"，把一个全局排序问题 转化成为了 局部的比较问题。(尽管排序本质上也是比较，囧)。要想知道idle time 最大的key，精确的LRU需要对全局的key的idle time排序，然后就能找出idle time最大的key了。但是可以采用一种近似的思想，即随机采样(samping)若干个key，这若干个key就代表着全局的key，把samping得到的key放到pool里面，每次采样之后更新pool，使得pool里面总是保存着随机选择过的key的idle time最大的那些key。需要evict key时，直接从pool里面取出idle time最大的key，将之evict掉。这种思想是很值得借鉴的。

至此，基于LRU的移除策略就分析完了。

4.1.2 基于LFU（访问频率）的移除策略

Redis里面还有一种基于LFU（访问频率）的移除策略

LFU是在Redis4.0后出现的，LRU的最近最少使用实际上并不精确，考虑下面的情况，如果在|处删除，那么A距离的时间最久，但实际上A的使用频率要比B频繁，所以合理的淘汰策略应该是淘汰B。LFU就是为应对这种情况而生的。

lfu在lru的基础上,删除数据的时候,不是直接看谁最近没有被使用,而是先看谁被调用的少.因此需要增加一个计数器.当需要删除数据的时候, 1.判断计数 2.计数相同时,判断谁调用时间戳靠前

如图.RedisObject有一个24位的字段,前16位存放最近访问的时间戳,后8位存放访问次数. 

问题1:

1.8位,那么最大值就是2^9-1=255.如果每次访问都加1,那岂不是很快就满了,那请求256次和请求256000次没有区别了.

解决:在实现 LFU 策略时，Redis 并没有采用数据每被访问一次，就给对应的 counter 值加 1 的计数规则，而是采用了一个更优化的计数规则。

下面这段 Redis 的部分源码，显示了 LFU 策略增加计数器值的计算逻辑。其中，baseval 是计数器当前的值。计数器的初始值默认是 5（由代码中的 LFU_INIT_VAL 常量设置），而不是 0，这样可以避免数据刚被写入缓存，就因为访问次数少而被立即淘汰。

double r = (double)rand()/RAND_MAX;

...

double p = 1.0/(baseval*server.lfu_log_factor+1);

if (r < p) counter++;   

使用了这种计算规则后，我们可以通过设置不同的 lfu_log_factor 配置项，来控制计数器值增加的速度，避免 counter 值很快就到 255 了。

2.如果一个数据第一分钟,频繁的访问.  后面1小时都不访问了,咋整

Redis 在实现 LFU 策略时，还设计了一个 counter 值的衰减机制。

lfu_decay_time 参数,衰减次数= (当前时间-最近访问时间)/lfu_decay_time

4.1.3 Redis如何淘汰过期的keys（volatile-ttl）

当key过期后，redis是何时检测到的呢？

Redis keys过期有两种方式：被动和主动方式。

当一些客户端尝试访问它时，key会被发现并主动的过期。

当然，这样是不够的，因为有些过期的keys，永远不会访问他们。 无论如何，这些keys应该过期，所以定时随机测试设置keys的过期时间。所有这些过期的keys将会从密钥空间删除。

具体就是Redis每秒10次做的事情：

测试随机的20个keys进行相关过期检测。

删除所有已经过期的keys。

如果有多于25%的keys过期，重复步骤1.

这是一个平凡的概率算法，基本上的假设是，我们的样本是这个密钥控件，并且我们不断重复过期检测，直到过期的keys的百分百低于25%,这意味着，在任何给定的时刻，最多会清除1/4的过期keys。

好处：稍微牺牲下内存，但是保住了redis性能为王！！！！

4.2 过期策略

Redis是使用定期删除+惰性删除两者配合的过期策略。

4.2.1 定期删除

定期删除指的是Redis默认每隔100ms就随机抽取一些设置了过期时间的key，检测这些key是否过期，如果过期了就将其删掉。

因为key太多，如果全盘扫描所有的key会非常耗性能，所以是随机抽取一些key来删除。这样就有可能删除不完，需要惰性删除配合。

4.2.2 惰性删除

惰性删除不再是Redis去主动删除，而是在客户端要获取某个key的时候，Redis会先去检测一下这个key是否已经过期，如果没有过期则返回给客户端，如果已经过期了，那么Redis会删除这个key，不会返回给客户端。

所以惰性删除可以解决一些过期了，但没被定期删除随机抽取到的key。但有些过期的key既没有被随机抽取，也没有被客户端访问，就会一直保留在数据库，占用内存，长期下去可能会导致内存耗尽。所以Redis提供了内存淘汰机制来解决这个问题。

Redis锁

谈起 Redis 锁，下面三个，算是出现最多的高频词汇：

• Setnx
• RedLock
• Redisson

Setnx

目前通常所说的 Setnx 命令，并非单指 Redis 的 setnx key value 这条命令。

一般代指 Redis 中对 Set 命令加上 NX 参数进行使用，Set 这个命令，目前已经支持这么多参数可选：

SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL]

当然了，就不在文章中默写 API 了，基础参数还有不清晰的，可以蹦到官网。

上图是笔者画的 Setnx 大致原理，主要依托了它的 Key 不存在才能 Set 成功的特性，进程 A 拿到锁，在没有删除锁的 Key 时，进程 B 自然获取锁就失败了。

那么为什么要使用 PX 30000 去设置一个超时时间？是怕进程 A 不讲道理啊，锁没等释放呢，万一崩了，直接原地把锁带走了，导致系统中谁也拿不到锁。

就算这样，还是不能保证万无一失。如果进程 A 又不讲道理，操作锁内资源超过笔者设置的超时时间，那么就会导致其他进程拿到锁，等进程 A 回来了，回手就是把其他进程的锁删了，如图

还是刚才那张图，将 T5 时刻改成了锁超时，被 Redis 释放。

进程 B 在 T6 开开心心拿到锁不到一会，进程 A 操作完成，回手一个 Del，就把锁释放了。

当进程 B 操作完成，去释放锁的时候（图中 T8 时刻）

找不到锁其实还算好的，万一 T7 时刻有个进程 C 过来加锁成功，那么进程 B 就把进程 C 的锁释放了。

以此类推，进程 C 可能释放进程 D 的锁，进程 D....(禁止套娃)，具体什么后果就不得而知了。

所以在用 Setnx 的时候，Key 虽然是主要作用，但是 Value 也不能闲着，可以设置一个唯一的客户端 ID，或者用 UUID 这种随机数。

当解锁的时候，先获取 Value 判断是否是当前进程加的锁，再去删除。伪代码：

String uuid = xxxx;

// 伪代码，具体实现看项目中用的连接工具

// 有的提供的方法名为set 有的叫setIfAbsent

set Test uuid NX PX 3000

try{

// biz handle....

} finally {

    // unlock

    if(uuid.equals(redisTool.get('Test')){

        redisTool.del('Test');

    }

}

这回看起来是不是稳了？相反，这回的问题更明显了，在 Finally 代码块中，Get 和 Del 并非原子操作，还是有进程安全问题。

为什么有问题还说这么多呢？有如下两点原因：

• 搞清劣势所在，才能更好的完善。
• 上文中最后这段代码，还是有很多公司在用的。

大小项目悖论：

大公司实现规范，但是小司小项目虽然存在不严谨，可并发倒也不高，出问题的概率和大公司一样低。

那么删除锁的正确姿势之一，就是可以使用 Lua 脚本，通过 Redis 的 eval/evalsha 命令来运行：

-- lua删除锁：

-- KEYS和ARGV分别是以集合方式传入的参数，对应上文的Test和uuid。

-- 如果对应的value等于传入的uuid。

if redis.call('get', KEYS[1]) == ARGV[1] 

    then 

    -- 执行删除操作

        return redis.call('del', KEYS[1]) 

    else 

    -- 不成功，返回0

        return 0 

end

通过 Lua 脚本能保证原子性的原因说的通俗一点：就算你在 Lua 里写出花，执行也是一个命令（eval/evalsha）去执行的，一条命令没执行完，其他客户端是看不到的。

那么既然这么麻烦，有没有比较好的工具呢？就要说到 Redisson 了。

Redisson

Redisson 是 Java 的 Redis 客户端之一，提供了一些 API 方便操作 Redis。

但是 Redisson 这个客户端可有点厉害，笔者在官网截了仅仅是一部分的图：

这个特性列表可以说是太多了，是不是还看到了一些 JUC 包下面的类名，Redisson 帮我们搞了分布式的版本。

比如 AtomicLong，直接用 RedissonAtomicLong 就行了，连类名都不用去新记，很人性化了。

锁只是它的冰山一角，并且从它的 Wiki 页面看到，对主从，哨兵，集群等模式都支持，当然了，单节点模式肯定是支持的。

本文还是以锁为主，其他的不过多介绍。Redisson 普通的锁实现源码主要是 RedissonLock 这个类，还没有看过它源码的盆友，不妨去瞧一瞧。

源码中加锁/释放锁操作都是用 Lua 脚本完成的，封装的非常完善，开箱即用。

这里有个小细节，加锁使用 Setnx 就能实现，也采用 Lua 脚本是不是多此一举？

笔者也非常严谨的思考了一下：这么厉害的东西哪能写废代码？

其实笔者仔细看了一下，加锁解锁的 Lua 脚本考虑的非常全面，其中就包括锁的重入性，这点可以说是考虑非常周全，我也随手写了代码测试一下：

的确用起来像 JDK 的 ReentrantLock 一样丝滑，那么 Redisson 实现的已经这么完善，RedLock 又是什么？

RedLock

RedLock的中文是直译过来的，就叫红锁。红锁并非是一个工具，而是 Redis 官方提出的一种分布式锁的算法。

就在刚刚介绍完的 Redisson 中，就实现了 RedLock 版本的锁。也就是说除了 getLock 方法，还有 getRedLock 方法。

笔者大概画了一下对红锁的理解：

如果你不熟悉 Redis 高可用部署，那么没关系。RedLock 算法虽然是需要多个实例，但是这些实例都是独自部署的，没有主从关系。

RedLock 作者指出，之所以要用独立的，是避免了 Redis 异步复制造成的锁丢失，比如：主节点没来的及把刚刚 Set 进来这条数据给从节点，就挂了。（Lock的缺点）

有些人是不是觉得大佬们都是杠精啊，天天就想着极端情况。其实高可用嘛，拼的就是 99.999...% 中小数点后面的位数。

回到上面那张简陋的图片，红锁算法认为，只要 2N+1 个节点加锁成功，那么就认为获取了锁， 解锁时将所有实例解锁。

流程为：

• 顺序向五个节点请求加锁
• 根据一定的超时时间来推断是不是跳过该节点
• 三个节点加锁成功并且花费时间小于锁的有效期
• 认定加锁成功

也就是说，假设锁 30 秒过期，三个节点加锁花了 31 秒，自然是加锁失败了。

这只是举个例子，实际上并不应该等每个节点那么长时间，就像官网所说的那样，假设有效期是 10 秒，那么单个 Redis 实例操作超时时间，应该在 5 到 50 毫秒(注意时间单位)。

还是假设我们设置有效期是 30 秒，图中超时了两个 Redis 节点。那么加锁成功的节点总共花费了 3 秒，所以锁的实际有效期是小于 27 秒的。

即扣除加锁成功三个实例的 3 秒，还要扣除等待超时 Redis 实例的总共时间。看到这，你有可能对这个算法有一些疑问，那么你不是一个人。

回头看看 Redis 官网关于红锁的描述，就在这篇描述页面的最下面，你能看到著名的关于红锁的神仙打架事件。

Redis的分布式锁 Redlock

引言

之前自己在用redis来实现分布式锁的时候都是基于单个Redis实例，也就是说Redis本身是有单点故障的，Redis的官方文档介绍了一种"自认为"合理的算法，Redlock来实现分布式Redis下的分布式锁。

单点Redis锁

先简单回顾一下单点的Redis锁是怎么实现的。

获取锁

SET resource_name my_random_value NX PX 30000

客户端A在Redis上设置一个特定的键值对，同时给一个超时时间（避免死锁）。其他客户端在访问的时候先看看这个key是否已经存在，并且值等于my_random_value。如果已存在就等待，否则就获取成功，执行业务代码。resource_name和my_random_value是所有客户端都知道并且共享的。

释放锁

if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end

对比key获取到的对应的value是否相等，如果相等，就删除(释放)，否则就返回失败。

之前也写过一篇文章。

单点Redis锁的缺陷

这个缺陷其实很明显，如果只有一个Redis实例，这个挂了，所有依赖他的服务都挂了。显然不太适合大型的应用。

简单的Redis主从架构碰到的问题

为了避免单点故障，我们给Redis做一个Master/Slave的主从架构，一个Master，一台Slave。下面就会碰到这么一个问题。下面是使用场景。

1. 客户端A在Master上获取到一个锁。
2. Master把这个数据同步到Slave的时候挂了（因为Master和Slave之间同步是异步的）。
3. Slave变成了Master。
4. 客户端B通过相同的key，和value获取到锁。分布式锁失效

Redlock算法

假设我们有N（假设5）个Redis master实例，所有节点相互独立，并且业务系统也是单纯的调用，并没有什么其他的类似消息重发之类的辅助系统。下面来模拟一下算法：

1. 客户端获取服务器当前的的时间t0，毫秒数。
2. 使用相同的key和value依次向5个实例获取锁。客户端在获取锁的时候自身设置一个远小于业务锁需要的持续时间的超时时间。举个例子，假设锁需要10秒，超时时间可以设置成比如5-50毫秒。这个避免某个Redis本身已经挂了，但是客户端一直在尝试获取锁的情况。超时了之后就直接跳到下一个节点。
3. 客户端通过当前时间（t1）减去t0，计算获取锁所消耗的时间t2（=t1-t0)。只有t2小于锁的业务有效时间(也就是第二步的10秒)，并且，客户端在至少3(5/2+1)台上获取到锁我们才认为锁获取成功。
4. 如果锁已经获取，那么锁的业务有效时间为10s-t2。
5. 如果客户端没有获取到锁，可能是没有在大于等于N/2+1个实例上获取锁，也可能是有效时间(10s-t2)为负数，我们就尝试去释放锁，即使是并没有在那个节点上获取到。

锁的释放

释放比较简单，直接删除所有实例上对应的key就好。（只删除自己创建的）

redis zset 跳跃表

有序表的搜索

考虑一个有序表

从该有序表中搜索元素 < 23, 43, 59 > ，需要比较的次数分别为 < 2, 4, 6 >，总共比较的次数

为 2 + 4 + 6 = 12 次。有没有优化的算法吗? 链表是有序的，但不能使用二分查找。类似二叉

搜索树，我们把一些节点提取出来，作为索引。得到如下结构：

这里我们把 < 14, 34, 50, 72 > 提取出来作为一级索引，这样搜索的时候就可以减少比较次数了。

我们还可以再从一级索引提取一些元素出来，作为二级索引，变成如下结构：

这里元素不多，体现不出优势，如果元素足够多，这种索引结构就能体现出优势来了。

跳跃表

下面的结构是就是跳表：

其中 -1 表示 INT_MIN， 链表的最小值，1 表示 INT_MAX，链表的最大值。

跳表具有如下性质：

(1) 由很多层结构组成

(2) 每一层都是一个有序的链表

(3) 最底层(Level 1)的链表包含所有元素

(4) 如果一个元素出现在 Level i 的链表中，则它在 Level i 之下的链表也都会出现。

(5) 每个节点包含两个指针，一个指向同一链表中的下一个元素，一个指向下面一层的元素。

跳表的搜索

例子：查找元素 117

(1) 比较 21， 比 21 大，往后面找

(2) 比较 37, 比 37大，比链表最大值小，从 37 的下面一层开始找

(3) 比较 71, 比 71 大，比链表最大值小，从 71 的下面一层开始找

(4) 比较 85， 比 85 大，从后面找

(5) 比较 117， 等于 117， 找到了节点。

跳表的插入

先确定该元素要占据的层数 K（采用丢硬币的方式，这完全是随机的）

然后在 Level 1 ... Level K 各个层的链表都插入元素。

例子：插入 119， K = 2

如果 K 大于链表的层数，则要添加新的层。

例子：插入 119， K = 4

布隆过滤器(Bloom Filter)的原理和实现

什么情况下需要布隆过滤器？

先来看几个比较常见的例子

• 字处理软件中，需要检查一个英语单词是否拼写正确
• 在 FBI，一个嫌疑人的名字是否已经在嫌疑名单上
• 在网络爬虫里，一个网址是否被访问过
• yahoo, gmail等邮箱垃圾邮件过滤功能

这几个例子有一个共同的特点： 如何判断一个元素是否存在一个集合中？

常规思路

• 数组
• 链表
• 树、平衡二叉树、Trie
• Map (红黑树)
• 哈希表

虽然上面描述的这几种数据结构配合常见的排序、二分搜索可以快速高效的处理绝大部分判断元素是否存在集合中的需求。但是当集合里面的元素数量足够大，如果有500万条记录甚至1亿条记录呢？这个时候常规的数据结构的问题就凸显出来了。数组、链表、树等数据结构会存储元素的内容，一旦数据量过大，消耗的内存也会呈现线性增长，最终达到瓶颈。有的同学可能会问，哈希表不是效率很高吗？查询效率可以达到O(1)。但是哈希表需要消耗的内存依然很高。使用哈希表存储一亿 个垃圾 email 地址的消耗？哈希表的做法：首先，哈希函数将一个email地址映射成8字节信息指纹；考虑到哈希表存储效率通常小于50%（哈希冲突）；因此消耗的内存：8 * 2 * 1亿 字节 = 1.6G 内存，普通计算机是无法提供如此大的内存。这个时候，布隆过滤器（Bloom Filter）就应运而生。

布隆过滤器介绍

• 巴顿.布隆于一九七零年提出
• 一个很长的二进制向量 （位数组）
• 一系列随机函数 (哈希)
• 空间效率和查询效率高
• 有一定的误判率（哈希表是精确匹配）

布隆过滤器原理

布隆过滤器（Bloom Filter）的核心实现是一个超大的位数组和几个哈希函数。假设位数组的长度为m，哈希函数的个数为k。

以上图为例，具体的操作流程：假设集合里面有3个元素{x, y, z}，哈希函数的个数为3。首先将位数组进行初始化，将里面每个位都设置位0。对于集合里面的每一个元素，将元素依次通过3个哈希函数进行映射，每次映射都会产生一个哈希值，这个值对应位数组上面的一个点，然后将位数组对应的位置标记为1。查询W元素是否存在集合中的时候，同样的方法将W通过哈希映射到位数组上的3个点。如果3个点的其中有一个点不为1，则可以判断该元素一定不存在集合中。反之，如果3个点都为1，则该元素可能存在集合中。注意：此处不能判断该元素是否一定存在集合中，可能存在一定的误判率。可以从图中可以看到：假设某个元素通过映射对应下标为4，5，6这3个点。虽然这3个点都为1，但是很明显这3个点是不同元素经过哈希得到的位置，因此这种情况说明元素虽然不在集合中，也可能对应的都是1，这是误判率存在的原因。

布隆过滤器添加元素

• 将要添加的元素给k个哈希函数
• 得到对应于位数组上的k个位置
• 将这k个位置设为1

布隆过滤器查询元素

• 将要查询的元素给k个哈希函数
• 得到对应于位数组上的k个位置
• 如果k个位置有一个为0，则肯定不在集合中
• 如果k个位置全部为1，则可能在集合中

Redis为什么那么快

Redis到底有多快

要了解Reids的到底有多么快， 首先需要有相应的评估工具。 其次，需要Redis 在一些平台经验数据，来评估Redis性能数量级。 幸运的是Redis提供了这样的工具，并给出了常用的硬件平台一些经验数据。

下面篇幅比较长，核心观点如下：

1. 可以使用redis-benchmark对Redis的性能进行评估，命令行提供了普通/流水线方式、不同压力评估特定命令的性能的功能。
2. redis性能卓越，作为key-value系统最大负载数量级为10W/s， set和get耗时数量级为10ms和5ms。使用流水线的方式可以提升redis操作的性能。

Redis为什么那么快

Redis是一个单线程应用，所说的单线程指的是Redis使用单个线程处理客户端的请求。 虽然Redis是单线程的应用，但是即便不通过部署多个Redis实例和集群的方式提升系统吞吐， 从官网给出的数据可以看出，Redis处理速度非常快。

Redis性能非常高的原因主要有以下四点：

• 内存存储：Redis是使用内存(in-memeroy)存储,没有磁盘IO上的开销
• 单线程实现：Redis使用单个线程处理请求，避免了多个线程之间线程切换和锁资源争用的开销
• 非阻塞IO：Redis使用多路复用IO技术，在poll，epool，kqueue选择最优IO实现
• 优化的数据结构：Redis有诸多可以直接应用的优化数据结构的实现，应用层可以直接使用原生的数据结构提升性能

下面详细介绍非阻塞IO和优化的数据结构

多路复用IO

在《unix网络编程 卷I》中详细讲解了unix服务器中的5种IO模型。

一个IO操作一般分为两个步骤：

1. 等待数据从网络到达， 数据到达后加载到内核空间缓冲区
2. 数据从内核空间缓冲区复制到用户空间缓冲区

按照两个步骤是否阻塞线程，分为阻塞/非阻塞， 同步/异步。

Reids的IO处理

总的来说Redis使用一种封装多种(select,epoll, kqueue等)实现的Reactor设计模式多路复用IO处理客户端的请求。

Reactor设计模式

Reactor设计模式常常用来实现事件驱动。除此之外， Redis还封装了不同平台多路复用IO的不同的库。处理过程如下：

IO库封装

因为 Redis 需要在多个平台上运行，同时为了最大化执行的效率与性能，所以会根据编译平台的不同选择不同的 I/O 多路复用函数作为子模块。

具体选择过程如下：

Redis 会优先选择时间复杂度为 O(1) 的 I/O 多路复用函数作为底层实现，包括 Solaries 10 中的 evport、Linux 中的 epoll 和 macOS/FreeBSD 中的 kqueue，上述的这些函数都使用了内核内部的结构，并且能够服务几十万的文件描述符。

但是如果当前编译环境没有上述函数，就会选择 select 作为备选方案，由于其在使用时会扫描全部监听的描述符，所以其时间复杂度较差 O(n)，并且只能同时服务 1024 个文件描述符，所以一般并不会以 select 作为第一方案使用。

缓存一致性问题怎么解决？

对于缓存和数据库的操作，主要有以下两种方式。

先删缓存，再更新数据库

先删除缓存，数据库还没有更新成功，此时如果读取缓存，缓存不存在，去数据库中读取到的是旧值，缓存不一致发生。

解决方案：

延时双删的方案的思路是，为了避免更新数据库的时候，其他线程从缓存中读取不到数据，就在更新完数据库之后，再sleep一段时间，然后再次删除缓存。

sleep的时间要对业务读写缓存的时间做出评估，sleep时间大于读写缓存的时间即可。

流程如下：

1. 线程1删除缓存，然后去更新数据库
2. 线程2来读缓存，发现缓存已经被删除，所以直接从数据库中读取，这时候由于线程1还没有更新完成，所以读到的是旧值，然后把旧值写入缓存
3. 线程1，根据估算的时间，sleep，由于sleep的时间大于线程2读数据+写缓存的时间，所以缓存被再次删除
4. 如果还有其他线程来读取缓存的话，就会再次从数据库中读取到最新值

先更新数据库，再删除缓存

如果反过来操作，先更新数据库，再删除缓存呢？

这个就更明显的问题了，更新数据库成功，如果删除缓存失败或者还没有来得及删除，那么，其他线程从缓存中读取到的就是旧值，还是会发生不一致。

解决方案：

消息队列

这是网上很多文章里都有写过的方案。但是这个方案的缺陷会更明显一点。

先更新数据库，成功后往消息队列发消息，消费到消息后再删除缓存，借助消息队列的重试机制来实现，达到最终一致性的效果。

这个解决方案其实问题更多。

1. 引入消息中间件之后，问题更复杂了，怎么保证消息不丢失更麻烦
2. 就算更新数据库和删除缓存都没有发生问题，消息的延迟也会带来短暂的不一致性，不过这个延迟相对来说还是可以接受的

进阶版消息队列

为了解决缓存一致性的问题单独引入一个消息队列，太复杂了。

其实，一般大公司本身都会有监听binlog（Mysql binlog是二进制日志文件，用于记录mysql的数据更新或者潜在更新）消息的消息队列存在，主要是为了做一些核对的工作。

这样，我们可以借助监听binlog的消息队列来做删除缓存的操作。这样做的好处是，不用你自己引入，侵入到你的业务代码中，中间件帮你做了解耦，同时，中间件的这个东西本身就保证了高可用。

当然，这样消息延迟的问题依然存在，但是相比单纯引入消息队列的做法更好一点。

而且，如果并发不是特别高的话，这种做法的实时性和一致性都还算可以接受的。

其他解决方案：设置缓存过期时间

每次放入缓存的时候，设置一个过期时间，比如5分钟，以后的操作只修改数据库，不操作缓存，等待缓存超时后从数据库重新读取。

如果对于一致性要求不是很高的情况，可以采用这种方案。

这个方案还会有另外一个问题，就是如果数据更新的特别频繁，不一致性的问题就很大了。

在实际生产中，我们有一些活动的缓存数据是使用这种方式处理的。

因为活动并不频繁发生改变，而且对于活动来说，短暂的不一致性并不会有什么大的问题。

为什么是删除，而不是更新缓存？

我们以先更新数据库，再删除缓存来举例。

如果是更新的话，那就是先更新数据库，再更新缓存。

举个例子：如果数据库1小时内更新了1000次，那么缓存也要更新1000次，但是这个缓存可能在1小时内只被读取了1次，那么这1000次的更新有必要吗？

反过来，如果是删除的话，就算数据库更新了1000次，那么也只是做了1次缓存删除，只有当缓存真正被读取的时候才去数据库加载。

总结：

首先，我们要明确一点，缓存不是更新，而应该是删除。

删除缓存有两种方式：

1. 先删除缓存，再更新数据库。解决方案是使用延迟双删。
2. 先更新数据库，再删除缓存。解决方案是消息队列或者其他binlog同步，引入消息队列会带来更多的问题，并不推荐直接使用。

针对缓存一致性要求不是很高的场景，那么只通过设置超时时间就可以了。

其实，如果不是很高的并发，无论你选择先删缓存还是后删缓存的方式，都几乎很少能产生这种问题，但是在高并发下，你应该知道怎么解决问题。

缓存穿透，缓存击穿，缓存雪崩

在我们日常的开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫痪，最终导致服务宕机的严重生产问题。

为了克服上述的问题，项目通常会引入NoSQL技术，这是一种基于内存的数据库，并且提供一定的持久化功能。

redis技术就是NoSQL技术中的一种，但是引入redis又有可能出现缓存穿透，缓存击穿，缓存雪崩等问题。

什么是缓存穿透，缓存击穿，缓存雪崩

• 缓存穿透：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。
• 缓存击穿：key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

• 缓存雪崩：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

缓存穿透解决方案

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

粗暴方式伪代码：

//伪代码 
public object GetProductListNew() { 
    int cacheTime = 30; 
    String cacheKey = "product_list"; 
    String cacheValue = CacheHelper.Get(cacheKey); 
    if (cacheValue != null) { 
        return cacheValue; 
    } 
    cacheValue = CacheHelper.Get(cacheKey); 
    if (cacheValue != null) { 
        return cacheValue; 
    } else { 
        //数据库查询不到，为空 
        cacheValue = GetProductListFromDB(); 
        if (cacheValue == null) { 
            //如果发现为空，设置个默认值，也缓存起来 
            cacheValue = string.Empty; 
        } 
        CacheHelper.Add(cacheKey, cacheValue, cacheTime); 
        return cacheValue;
    }
}

缓存击穿解决方案

key可能会在某些时间点被超高并发地访问（且数据过期了），是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。

1、设置热点数据永远不过期。

2、使用互斥锁(mutex key)

业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。

public String get(key) {
    String value = redis.get(key);
    if (value == null) { //代表缓存值过期
        //设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
        if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {  //代表设置成功
            value = db.get(key);
            redis.set(key, value, expire_secs);
            redis.del(key_mutex);
        } else {  //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
            sleep(50);
            get(key);  //重试
        }
    } else {
        return value;
    }
}

memcache代码：

if (memcache.get(key) == null) {
    // 3 min timeout to avoid mutex holder crash  
    if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
        value = db.get(key);
        memcache.set(key, value);
        memcache.delete(key_mutex);
    } else {
        sleep(50);
        retry();
    }
}

其它方案：待各位补充。

缓存雪崩解决方案

与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key。

缓存正常从Redis中获取，示意图如下：

缓存失效瞬间示意图如下：

缓存失效时的雪崩效应对底层系统的冲击非常可怕！大多数系统设计者考虑用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

另外一个方法是加锁排队，伪代码如下：

//伪代码
public object GetProductListNew() {
    int cacheTime = 30;
    String cacheKey = "product_list";
    String lockKey = cacheKey;

    String cacheValue = CacheHelper.get(cacheKey);
    if (cacheValue != null) {
        return cacheValue;
    } else {
        synchronized(lockKey) {
            cacheValue = CacheHelper.get(cacheKey);
            if (cacheValue != null) {
                return cacheValue;
            } else {
                //这里一般是sql查询数据
                cacheValue = GetProductListFromDB();
                CacheHelper.Add(cacheKey, cacheValue, cacheTime);
            }
        }
        return cacheValue;
    }
}

加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。假设在高并发下，缓存重建期间key是锁着的，这是过来1000个请求999个都在阻塞的。同样会导致用户等待超时，这是个治标不治本的方法！

注意：加锁排队的解决方式分布式环境的并发问题，有可能还要解决分布式锁的问题；线程还会被阻塞，用户体验很差！因此，在真正的高并发场景下很少使用！

随机值伪代码：

//伪代码
public object GetProductListNew() {
    int cacheTime = 30;
    String cacheKey = "product_list";
    //缓存标记
    String cacheSign = cacheKey + "_sign";

    String sign = CacheHelper.Get(cacheSign);
    //获取缓存值
    String cacheValue = CacheHelper.Get(cacheKey);
    if (sign != null) {
        return cacheValue; //未过期，直接返回
    } else {
        CacheHelper.Add(cacheSign, "1", cacheTime);
        ThreadPool.QueueUserWorkItem((arg) -> {
            //这里一般是 sql查询数据
            cacheValue = GetProductListFromDB();
            //日期设缓存时间的2倍，用于脏读
            CacheHelper.Add(cacheKey, cacheValue, cacheTime * 2);
        });
        return cacheValue;
    }
}

解释说明：

• 缓存标记：记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key的缓存；
• 缓存数据：它的过期时间比缓存标记的时间延长1倍，例：标记缓存时间30分钟，数据缓存设置为60分钟。这样，当缓存标记key过期后，实际缓存还能把旧数据返回给调用端，直到另外的线程在后台更新完成后，才会返回新缓存。

关于缓存崩溃的解决方法，这里提出了三种方案：使用锁或队列、设置过期标志更新缓存、为key设置不同的缓存失效时间，还有一种被称为“二级缓存”的解决方法。

缓存雪崩

描述：

      缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，        缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

     解决方案：

1. 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
2. 如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
3. 设置热点数据永远不过期。