redis面试～～有这一篇就够了

redis介绍

1、redis 是什么？

redis可以理解就是一个数据库，不过与传统数据库不同的是 redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向。另外，redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。除此之外，redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

2、为什么要用 redis？/为什么要用缓存？

因为传统的关系型数据库如Mysql已经不能适用所有的场景了，比如秒杀的库存扣减，APP首页的访问流量高峰等等，都很容易把数据库打崩，所以引入了缓存中间件，目前市面上比较常用的缓存中间件有 Redis 和 Memcached。

3、为什么要用 redis 而不用 map/guava 做缓存?

缓存分为本地缓存和分布式缓存。以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束。

使用 redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性。

缺点是需要保持 redis 或 memcached服务的高可用，整个程序架构上较为复杂。

4、Memcache 和 redis 对比

1、redis支持更丰富的数据类型（支持更复杂的应用场景）：Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。memcache支持简单的数据类型，String。

2、Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用,而Memecache把数据全部存在内存之中。

3、集群模式：memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 redis 目前是原生支持 cluster 模式的.

4、Memcached是多线程，非阻塞IO复用的网络模型；Redis使用单线程的多路 IO 复用模型。

5、redis 的线程模型

redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，根据 socket 上的事件来选择对应的事件处理器进行处理。 文件事件处理器的结构包含 4 个部分：

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

6、Redis 为什么是单线程的？

1、一直可能有个误区，多线程 一定比 单线程 效率高，其实不然！多线程就涉及到上线文切换，CPU上下文的切换大概在 1500ns 左右。

2、redis 核心就是 如果我的数据全都在内存里，我单线程的去操作 就是效率最高的，为什么呢？因为多线程的本质就是 CPU 模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。

7、redis的优缺点

优点：

1、支持多种数据类型 string、list、set、zset、hash

2、数据可以持久化保持（AOF、快照），写入硬盘，

3、支持灾难恢复，主从复制。主机会自动将数据同步到从机，可以进行读写分离。

4、读写性能优异。

缺点：

1、redis不支持自动容错和恢复功能，主从宕机都会导致前端读写失败，需要手动重启机器。

2、主机宕机，主从数据复制过程中，数据未完全复制到从机，会出现数据不一致。

3、redis较难支持在线扩容，当集群数据达到上限在线扩容变得复杂。

8、redis为什么快？

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

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。它的，数据存在内存中，类似于HashMap，HashMap的优势 就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路I/O复用模型，非阻塞IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求

redis支持的数据结构

五种基本数据结构

String字符串类型

介绍

String 类型是 Redis 中最常使用的类型，内部的实现是通过 SDS（Simple Dynamic String ）来存储的。SDS 类似于 Java 中的 ArrayList，可以通过预分配冗余空间的方式来减少内存的频繁分配。这是最简单的类型，就是普通的 set 和 get，做简单的 KV 缓存。

应用场景

1、缓存功能：String字符串是最常用的数据类型，不仅仅是Redis，各个语言都是最基本类型，因此，利用Redis作为缓存，配合其它数据库作为存储层，利用Redis支持高并发的特点，可以大大加快系统的读写速度、以及降低后端数据库的压力。

2、计数器：许多系统都会使用Redis作为系统的实时计数器，可以快速实现计数和查询的功能。比如想知道什么时候封锁一个IP地址（访问超过几次），INCRBY命令让这些变得很容易，通过原子递增保持计数。

3、共享用户Session：用户重新刷新一次界面，可能需要访问一下数据进行重新登录，或者访问页面缓存Cookie，但是可以利用Redis将用户的Session集中管理，在这种模式只需要保证Redis的高可用，每次用户Session的更新和获取都可以快速完成。大大提高效率。

List列表类型

介绍

Redis中的List其实就是链表（Redis用双端链表实现List）。使用List结构，我们可以轻松地实现最新消息排队功能（比如新浪微博的TimeLine）。List的另一个应用就是消息队列，可以利用List的 PUSH 操作，将任务存放在List中，然后工作线程再用 POP 操作将任务取出进行执行。

应用场景

1、消息队列：Redis的链表结构，可以轻松实现阻塞队列，可以使用左进右出的命令组成来完成队列的设计。比如：数据的生产者可以通过Lpush命令从左边插入数据，多个数据消费者，可以使用BRpop命令阻塞的“抢”列表尾部的数据。

2、文章列表或者数据分页展示的应用。比如，我们常用的博客网站的文章列表，当用户量越来越多时，而且每一个用户都有自己的文章列表，而且当文章多时，都需要分页展示，这时可以考虑使用Redis的列表，列表不但有序同时还支持按照范围内获取元素，可以完美解决分页查询功能。大大提高查询效率

Set集合类型

介绍

Redis的集合类型和列表都可以存储多个字符串，它们的不同之处在于。列表可以存储多个相同的字符串，而集合通过散列表来保证自己存储的每个字符串都是各不相同的。

应用场景

1、共同好友、二度好友（并集、交集、差集运算）

2、利用唯一性，可以统计访问网站的所有独立IP

Hash散列类型

介绍

Redis的散列可以存储多个键值对之间的映射。和字符串一样，散列存储的值既可以是字符串又可以是数字值。并且用户同样可以对散列存储的数字进行自增或自减操作。

应用场景

适用于存储对象（object）信息，如用户详细信息，用户id为key，他的姓名、性别、年龄等信息为field-value。存储多个用户信息的化，可以将filed存为用户id，每个用户的信息序列化为json存于value。

有序集合Sorted set

介绍

Sorted set 是排序的 Set，去重但可以排序，写进去的时候给一个分数，自动根据分数排序。有序集合的使用场景与集合类似，但是set集合不是自动有序的，而Sorted set可以利用分数进行成员间的排序，而且是插入时就排序好。所以当你需要一个有序且不重复的集合列表时，就可以选择Sorted set数据结构作为选择方案。

应用场景

1、排行榜：有序集合经典使用场景。例如视频网站需要对用户上传的视频做排行榜，榜单维护可能是多方面：按照时间、按照播放量、按照获得的赞数等。

2、用Sorted Sets来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

redis数据结构-高级篇

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

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

Geospatial:可以用来保存地理位置，并作位置距离计算或者根据半径计算位置等。比如用Redis来实现附近的人？或者计算最优地图路径？

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

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

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

扩展-Bloom Filter

1、背景如果想判断一个元素是不是在一个集合里，一般想到的是将集合中所有元素保存起来，然后通过比较确定。链表、树、散列表（又叫哈希表，Hash table）等等数据结构都是这种思路，存储位置要么是磁盘，要么是内存。很多时候要么是以时间换空间，要么是以空间换时间。在响应时间要求比较严格的情况下，如果我们存在内里，那么随着集合中元素的增加，我们需要的存储空间越来越大，以及检索的时间越来越长，导致内存开销太大、时间效率变低。此时需要考虑解决的问题就是，在数据量比较大的情况下，既满足时间要求，又满足空间的要求。即我们需要一个时间和空间消耗都比较小的数据结构和算法。Bloom Filter就是一种解决方案。

2、Bloom Filter 原理布隆过滤器的原理是，当一个元素被加入集合时，通过K个散列函数将这个元素映射成一个位数组中的K个点，把它们置为1。检索时，我们只要看看这些点是不是都是1就（大约）知道集合中有没有它了：如果这些点有任何一个0，则被检元素一定不在；如果都是1，则被检元素很可能在。这就是布隆过滤器的基本思想。Bloom Filter跟单哈希函数Bit-Map不同之处在于：Bloom Filter使用了k个哈希函数，每个字符串跟k个bit对应。从而降低了冲突的概率。

3、缓存穿透每次查询都会直接打到DB，言而简之就是我们先把我们数据库的数据都加载到我们的过滤器中，比如数据库的id现在有：1、2、3那就用id：1 为例子他在上图中经过三次hash之后，把三次原本值0的地方改为1下次数据进来查询的时候如果id的值是1，那么我就把1拿去三次hash 发现三次hash的值，跟上面的三个位置完全一样，那就能证明过滤器中有1的，反之如果不一样就说明不存在了。一般我们都会用来防止缓存击穿。一般你数据库的id都是1开始然后自增的，那我知道你接口是通过id查询的，我就拿负数去查询，这个时候，会发现缓存里面没这个数据，我又去数据库查也没有，一个请求这样，100个，1000个，10000个呢？你的DB基本上就扛不住了，如果在缓存里面加上这个，是不是就不存在了，你判断没这个数据就不去查了，直接return一个数据为空不就好了嘛。

4、Bloom Filter的缺点bloom filter之所以能做到在时间和空间上的效率比较高，是因为牺牲了判断的准确率、删除的便利性存在误判，可能要查到的元素并没有在容器中，但是hash之后得到的k个位置上值都是1。如果bloom filter中存储的是黑名单，那么可以通过建立一个白名单来存储可能会误判的元素。删除困难。一个放入容器的元素映射到bit数组的k个位置上是1，删除的时候不能简单的直接置为0，可能会影响其他元素的判断。可以采用Counting Bloom Filter

5、Bloom Filter 实现布隆过滤器有许多实现与优化，Guava中就提供了一种Bloom Filter的实现。在使用bloom filter时，绕不过的两点是预估数据量n以及期望的误判率fpp，在实现bloom filter时，绕不过的两点就是hash函数的选取以及bit数组的大小。对于一个确定的场景，我们预估要存的数据量为n，期望的误判率为fpp，然后需要计算我们需要的Bit数组的大小m，以及hash函数的个数k，并选择hash函数。

redis 事务

1 Redis事务的概念： Redis 提供的不是严格的事务，Redis 只保证串行执行命令，并且能保证全部执行，但是执行命令失败时并不会回滚，而是会继续执行下去。

2 Redis事务没有隔离级别的概念： 批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。

3 Redis不保证原子性： Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

4 Redis事务的三个阶段：开始事务命令入队执行事务

5 Redis事务相关命令： watch key1 key2 … : 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ） multi : 标记一个事务块的开始（ queued ） exec : 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ） discard : 取消事务，放弃事务块中的所有命令 unwatch : 取消watch对所有key的监控

redis-持久化

持久化的实现方式

1、快照方式持久化快照方式持久化就是在某时刻把所有数据进行完整备份。例：Mysql的Dump方式、Redis的RDB方式。

2、写日志方式持久化写日志方式持久化就是把用户执行的所有写指令（增删改）备份到文件中，还原数据时只需要把备份的所有指令重新执行一遍即可。例：Mysql的Binlog、Redis的AOF、Hbase的HLog。

两种机制的对比

RDB

优点：他会生成多个数据文件，每个数据文件分别都代表了某一时刻Redis里面的数据，这种方式，有没有觉得很适合做冷备，完整的数据运维设置定时任务，定时同步到远端的服务器，比如阿里的云服务，这样一旦线上挂了，你想恢复多少分钟之前的数据，就去远端拷贝一份之前的数据就好了。RDB对Redis的性能影响非常小，是因为在同步数据的时候他只是fork了一个子进程去做持久化的，而且他在数据恢复的时候速度比AOF来的快。

缺点：RDB都是快照文件，都是默认五分钟甚至更久的时间才会生成一次，这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉。AOF则最多丢一秒的数据，数据完整性上高下立判。还有就是RDB在生成数据快照的时候，如果文件很大，客户端可能会暂停几毫秒甚至几秒，你公司在做秒杀的时候他刚好在这个时候fork了一个子进程去生成一个大快照，哦豁，出大问题。

AOF

优点：上面提到了，RDB五分钟一次生成快照，但是AOF是一秒一次去通过一个后台的线程fsync操作，那最多丢这一秒的数据。AOF在对日志文件进行操作的时候是以append-only的方式去写的，他只是追加的方式写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损。AOF的日志是通过一个叫非常可读的方式记录的，这样的特性就适合做灾难性数据误删除的紧急恢复了，比如公司的实习生通过flushall清空了所有的数据，只要这个时候后台重写还没发生，你马上拷贝一份AOF日志文件，把最后一条flushall命令删了就完事了。

缺点：一样的数据，AOF文件比RDB还要大。AOF开启后，Redis支持写的QPS会比RDB支持写的要低，他不是每秒都要去异步刷新一次日志嘛fsync，当然即使这样性能还是很高，我记得ElasticSearch也是这样的，异步刷新缓存区的数据去持久化，为啥这么做呢，不直接来一条怼一条呢，那我会告诉你这样性能可能低到没办法用的，大家可以思考下为啥哟。

如何选择使用哪种持久化方式？

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。

redis-主从复制

什么是主从复制

Redis的主从复制机制是指可以让从服务器(slave)能精确复制主服务器(master)的数据

主从复制的方式

Redis的主从复制是异步复制，异步分为两个方面，

一个是master服务器在将数据同步到slave时是异步的，因此master服务器在这里仍然可以接收其他请求，

一个是slave在接收同步数据也是异步的。

复制方式Redis主从复制分为以下三种方式：

一、当master服务器与slave服务器正常连接时，master服务器会发送数据命令流给slave服务器,将自身数据的改变复制到slave服务器。二、当因为各种原因master服务器与slave服务器断开后，slave服务器在重新连上master服务器时会尝试重新获取断开后未同步的数据即部分同步，或者称为部分复制。

三、如果无法部分同步(比如初次同步)，则会请求进行全量同步，这时master服务器会将自己的rdb文件发送给slave服务器进行数据同步，并记录同步期间的其他写入，再发送给slave服务器，以达到完全同步的目的，这种方式称为全量复制。

主从复制的原理

master服务器会记录一个replicationId的伪随机字符串，用于标识当前的数据集版本，还会记录一个当数据集的偏移量offset，不管master是否有配置slave服务器，replication Id和offset会一直记录并成对存在。

当master与slave正常连接时，slave使用PSYNC命令向master发送自己记录的旧master的replication id和offset，而master会计算与slave之间的数据偏移量，并将缓冲区中的偏移数量同步到slave，此时master和slave的数据一致。而如果slave引用的replication太旧了，master与slave之间的数据差异太大，则master与slave之间会使用全量复制的进行数据同步。

如何避免slave被清空

slave会被清空？slave不用同步了master的数据吗？备份的数据怎么会清空了呢？当master服务器关闭了持久化时，如果发生故障后自动重启时，由本地没有保存持久化的数据，重启的Redis内存数据为空，而slave会自动同步master的数据，这时候，slave服务器的数据也会被清空。如何避免slave被清空呢？如果条件允许(一般都可以的)，master服务器还是要开启持久化，这样master故障重启时，可以快速恢复数据，而同步这台master的slave数据也不会被清空。如果master不能开启持久化，则不应该设置让master发生故障后重启(有些机器会配置自动重启)，而是将某个slave服务器升级为master服务器，对外继续提供服务。

主从复制中的key过期问题

我们都知道Redis可以通过设置key的过期时间来限制key的生存时间，Redis处理key过期有惰性删除和定期删除两种机制，而在配置主从复制后，slave服务器就没有权限处理过期的key，这样的话，对于在master上过期的key，在slave服务器就可能被读取，所以master会累积过期的key，积累一定的量之后，发送del命令到slave，删除slave上的key。如果slave服务器升级为master服务器 ，则它将开始独立地计算key过期时间，而不需要通过master服务器的帮助。

主从复制的作用

1 保存Redis数据副本当我们只是通过RDB或AOF把Redis的内存数据持久化毕竟只是在本地，并不能保证绝对的安全，而通过将数据同步slave服务器上，可以保留多一个数据备份，更好地保证数据的安全。

2 读写分离单机QPS是有上限的，而且Redis的特性就是必须支撑读高并发的，那你一台机器又读又写，这谁顶得住啊，不当人啊！但是你让这个master机器去写，数据同步给别的slave机器，他们都拿去读，分发掉大量的请求那是不是好很多，而且扩容的时候还可以轻松实现水平扩容。启动一台slave 的时候，他会发送一个psync命令给master ，如果是这个slave第一次连接到master，他会触发一个全量复制。master就会启动一个线程，生成RDB快照，还会把新的写请求都缓存在内存中，RDB文件生成后，master会将这个RDB发送给slave的，slave拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存，然后master会把内存里面缓存的那些新命名都发给slave。

3 高可用性与故障转移服务器的高可用性是指服务器能提供7*24小时不间断的服务，Redis可以通过Sentinel系统管理多个Redis服务器，当master服务器发生故障时，Sentineal系统会根据一定的规则将某台slave服务器升级为master服务器,继续提供服务，实现故障转移，保证Redis服务不间断。

Sentinel哨兵组件的主要功能

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

面试题

1、redis的基础知识

2、redis内存淘汰机制

Redis的过期策略，是有定期删除+惰性删除两种。

volatile-lru：从已设置过期时间的数据集（server. db[i]. expires）中挑选最近最少使用的数据淘汰。

volatile-ttl：从已设置过期时间的数据集（server. db[i]. expires）中挑选将要过期的数据淘汰。

volatile-random：从已设置过期时间的数据集（server. db[i]. expires）中任意选择数据淘汰。

allkeys-lru：从数据集（server. db[i]. dict）中挑选最近最少使用的数据淘汰。

allkeys-random：从数据集（server. db[i]. dict）中任意选择数据淘汰。no-enviction（驱逐）：禁止驱逐数据。

3、主从复制时，数据传输的时候断网了或者服务器挂了怎么办啊？

传输过程中有什么网络问题啥的，会自动重连的，并且连接之后会把缺少的数据补上的。需要注意的就是，RDB快照的数据生成的时候，缓存区也必须同时开始接受新请求，不然你旧的数据过去了，你在同步期间的增量数据咋办？

4、redis-缓存雪崩、击穿、穿透

雪崩

同一时间所有的redis全部失效，所有的请求都打到数据库。如何解决？处理缓存雪崩简单，在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效，或者设置热点数据永远不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就完事了，不要设置过期时间）。

什么是缓存穿透和击穿？它们跟雪崩的区别？

缓存穿透：是指缓存和数据库中都没有的数据，而用户不断发起请求，我们数据库的 id 都是1开始自增上去的，如发起为id值为 -1 的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。Redis还有一个高级用法布隆过滤器（Bloom Filter）这个也能很好的防止缓存穿透的发生，他的原理也很简单就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在你return就好了，存在你就去查了DB刷新KV再return。

缓存击穿：这个跟缓存雪崩有点像，但是又有一点不一样，缓存雪崩是因为大面积的缓存失效，打崩了DB，而缓存击穿不同的是缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞。

缓存穿透和缓存击穿分别怎么解决？

缓存穿透：我会在接口层增加校验，比如用户鉴权校验，参数做校验，不合法的参数直接代码Return，比如：id 做基础校验，id <=0的直接拦截等。我们在开发程序的时候都要有一颗“不信任”的心，就是不要相信任何调用方，如果上游或者下游挂掉了怎么办，参数不合理怎么处理等。

缓存击穿：从缓存取不到的数据，在数据库中也没有取到，这时也可以将对应Key的Value对写为null、位置错误、稍后重试这样的值具体取啥问产品，或者看具体的场景，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。同时在获取数据库里的数据的时候，也需要进行加锁控制，保证同一时间只有一个线程去请求数据库，刷新缓存。还可以通过自旋的方式，或者信号量的方式

5、redis-哨兵、持久化、主从

见上 redis-主从复制

6、LRU

7、redis 实现异步队列

我们在实际开发中经常会有专业的消息队列中间件，但是如果系统中没有mq中间件，又懒得维护mq中间件，那么我们可以通过redis来实现 因为redis并不是专业实现队列的中间件，因此在实现方式上还是会存在一些问题，还是比不上rocketMq之类的中间件。redis实现队列主要是使用数据结构中的list，因为它是按照塞入顺序排序的结构，我们就可以按照左边塞入，右边取出的方式来实现先入先出的队列需求 弹出时使用blpop的方法而不是lpop方法是因为如果使用lpop方法的话会造成如果队列中没有数据，连接一直空置的情况，所以使用blpop的方法可以在没有数据的时候将连接阻塞，在有数据时再读取 。 当然使用blpop同样可能存在长时间没有数据，redis将连接断掉的情况，因此就需要我们在使用时将这种情况的异常也考虑进去，在catch中将连接重新建立之类。

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

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

存在的问题

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

解决方案

延时双删的方案的思路是，为了避免更新数据库的时候，其他线程从缓存中读取不到数据，就在更新完数据库之后，再sleep一段时间，然后再次删除缓存。sleep的时间要对业务读写缓存的时间做出评估，sleep时间大于读写缓存的时间即可。

流程如下：

1、线程1删除缓存，然后去更新数据库

2、线程2来读缓存，发现缓存已经被删除，所以直接从数据库中读取，这时候由于线程1还没有更新完成，所以读到的是旧值，然后把旧值写入缓存

3、线程1，根据估算的时间，sleep，由于sleep的时间大于线程2读数据+写缓存的时间，所以缓存被再次删除

4、如果还有其他线程来读取缓存的话，就会再次从数据库中读取到最新值

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

存在的问题

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

解决方案

消息队列先更新数据库，成功后往消息队列发消息，消费到消息后再删除缓存，借助消息队列的重试机制来实现，达到最终一致性的效果。这个解决方案其实问题更多。引入消息中间件之后，问题更复杂了，怎么保证消息不丢失更麻烦就算更新数据库和删除缓存都没有发生问题，消息的延迟也会带来短暂的不一致性，不过这个延迟相对来说还是可以接受的

为了解决缓存一致性的问题单独引入一个消息队列，太复杂了。一般大公司本身都会有监听binlog消息的消息队列存在，主要是为了做一些核对的工作。这样，我们可以借助监听binlog的消息队列来做删除缓存的操作。这样做的好处是，不用你自己引入，侵入到你的业务代码中，中间件帮你做了解耦，同时，中间件的这个东西本身就保证了高可用。当然，这样消息延迟的问题依然存在，但是相比单纯引入消息队列的做法更好一点。如果并发不是特别高的话，这种做法的实时性和一致性都还算可以接受的。

设置缓存过期时间

每次放入缓存的时候，设置一个过期时间，比如5分钟，以后的操作只修改数据库，不操作缓存，等待缓存超时后从数据库重新读取。如果对于一致性要求不是很高的情况，可以采用这种方案。这个方案还会有另外一个问题，就是如果数据更新的特别频繁，不一致性的问题就很大了。

8、redis 实现分布式锁