1.什么是redis？
redis是一款开源的NoSQL数据库，开源将数据以键值对的方式进行存储，与其他数据库不同的是，redis是通过内存进行数据存储的，也因此redis的读写性能非常高，被广泛应用于分布式缓存方向。
2.什么是缓存？
缓存就是数据交换的缓冲区，是临时存储数据的区域，一般读写性能较高。
3.Redis为什么这么快？
1.redis是通过内存存储数据的，读写性能较高
2.redis基于Reactor模式设计了一套高效的事件处理模型，主要是单线程事件循环和 IO 多路复用
3.redis具有优化过的各种数据类型
4.redis的通信协议实现简单解析高效
4.Redis这么快，为什么不用来当主数据库？
1.Redis是基于内存进行存储的，内存成本太高，2.Redis的数据持久化有丢失数据的风险。
5.为什么用Redis？
1、访问速度更快，传统数据库数据保存在磁盘，而 Redis 基于内存，内存的访问速度比磁盘快很多。
2.高并发，直接操作缓存能够承受的数据库请求数量是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而，我们也就提高了系统整体的并发。
3.功能全面，Redis 除了可以用作缓存之外，还可以用于分布式锁、限流、消息队列、延时队列等场景
5.Redis常用的数据类型有哪些？
1.5种基本数据类型：list，hash，string，set，zset
2.特殊数据类型：bitmap：位图，geospatial：地理位置，HyperLogLog基数统计等等
6.Redis的单线程模型了解吗？
Redis基于Reactor模式设计的事件处理模型对应的是文件时间处理器，而文件事件处理器是单线程的，也因此说Redis是单线程模型。虽然文件事件处理器以单线程方式运行，但通过使用 I/O 多路复用程序来监听多个套接字，文件事件处理器既实现了高性能的网络通信模型，又可以很好地与 Redis 服务器中其他同样以单线程方式运行的模块进行对接，这保持了 Redis 内部单线程设计的简单性。
7.既然是单线程，那怎么监听大量的客户端连接呢？
Redis 通过 IO 多路复用程序 来监听来自客户端的大量连接（或者说是监听多个 socket），它会将感兴趣的事件及类型（读、写）注册到内核中并监听每个事件是否发生。I/O 多路复用技术的使用让 Redis 不需要额外创建多余的线程来监听客户端的大量连接，降低了资源的消耗（和 NIO 中的 Selector 组件很像）。
8.Redis给缓存数据设置过期时间有什么用？
Redis设置过期时间除了能缓解内存压力之外，还能完成一些特定的功能，比如很多时候，我们的业务场景就是需要某个数据只在某一时间段内存在，比如我们的短信验证码可能只在 1 分钟内有效，用户登录的 Token 可能只在 1 天内有效。
9.Redis是如何判断数据是否过期的？
Redis通过维护过期字典判断，Redis有一个过期字典，可以看作是一个hash表，键存放数据，值是一个 long long 类型的整数，这个整数保存了 key 所指向的数据库键的过期时间（毫秒精度的 UNIX 时间戳）
10Redis过期数据的删除策略了解吗？
Redis有两种过期删除策略，分别是惰性删除和定期删除，惰性删除是当使用该缓存数据时再判断是否过期，如果过期则删除，（这样对 CPU 最友好，但是可能会造成太多过期 key 没有被删除）定期删除则是，每过一段时间就挑选出一些过期数据进行删除。（Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。）定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，所以 Redis 采用的是 定期删除+惰性删除 。
11.Redis的内存淘汰机制了解吗？
Redis 提供 6 种数据淘汰策略：
- volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。
- volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰。
- volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰。
- allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。
- allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰。
- no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！
12.如何解决大量key集中过期的问题？
如果是由大量缓存数据同时过期导致的，可以给数据的过期时间加上一个随机值，比如可以在原有的失效时间基 础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重 复率就会降低，就很难引发集体失效的事件，
开启 lazy-free（惰性删除） 。lazy-free 特性是 Redis 4.0 开始引入的，指的是让 Redis 采用异步方式延迟释放 key 使用的内存，将该操作交给单独的子线程处理，避免阻塞主线程。
13.什么是bigkey？
简单来说，如果一个 key 对应的 value 所占用的内存比较大，那这个 key 就可以看作是 bigkey。比如String 类型的 value 超过 1MB，就可认为是bigkey
14.bigkey是怎么产生的？有什么危害？
bigkey的产生可能是因为：1.缓存的使用类型不当。2.程序设计不当。3.没有清理缓存，导致如hash中有大量空数据，4.对业务规模的考虑不周。
危害：1.客户端超时阻塞：由于 Redis 执行命令是单线程处理，然后在操作大 key 时会比较耗时，那么就会阻塞 Redis，从客户端这一视角看，就是很久很久都没有响应。2.网络阻塞：每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。3.工作线程阻塞：如果使用 del 删除大 key 时，会阻塞工作线程，这样就没办法处理后续的命令。4.大 key 造成的阻塞问题还会进一步影响到主从同步和集群扩容。
15.如何发现bigkey？
1、使用 Redis 自带的 --bigkeys 参数来查找。
2、使用 Redis 自带的 SCAN 命令
3、借助开源工具分析 RDB 文件。
4、借助公有云的 Redis 分析服务。
16.如何处理bigkey？
1.分割 bigkey：将一个 bigkey 分割为多个小 key。例如，将一个含有上万字段数量的 Hash 按照一定策略（比如二次哈希）拆分为多个 Hash。
2.手动清理：Redis 4.0+ 可以使用 UNLINK 命令来异步删除一个或多个指定的 key。Redis 4.0 以下可以考虑使用 SCAN 命令结合 DEL 命令来分批次删除。
3.采用合适的数据结构：例如，文件二进制数据不使用 String 保存、使用 HyperLogLog 统计页面 UV、Bitmap 保存状态信息（0/1）。
4.开启 lazy-free（惰性删除） ：lazy-free 特性是 Redis 4.0 开始引入的，指的是让 Redis 采用异步方式延迟释放 key 使用的内存，将该操作交给单独的子线程处理，避免阻塞主线程。
17.什么是缓存穿透 ? 怎么解决 ?
当用户访问的数据在redis缓存和数据库中都不存在时，请求就会直达数据库，如果有大量这样的请求打向数据库，有可能会压垮数据库（大概率是遭到了攻击），这种情况称之为缓存穿透。
要解决这个问题，可以通过1.缓存空数据（将访问的不存在的数据缓存为空数据保存，下一次访问时就不会访问到数据库了），缺点：占用内存，且可能会有短期不一致性。优点：简单直接。
2.使用布隆过滤器拦截（将存在的数据缓存，则不存在的数据将会被拦截（布隆过滤器的本质就是一个超长的二进制数组））。缺点：实现复杂，具有一定的误判概率（误判率：数组越小，误判的概率越大，数组越大误判率越小，但是同时带来了更多的内存消耗），占用内存。优点：内存占用较少，没有多余的key。
3.接口限流根据用户或者 IP 对接口进行限流，对于异常频繁的访问行为，还可以采取黑名单机制，例如将异常 IP 列入黑名单。
补充：除了上面两种常规解决方法之外，还有一些建议：1.使用较复杂的访问参数，让人不易猜测，2.做好权限校验。3.使用多级缓存4做好热点参数的限流等等
18.介绍一下布隆过滤器？
布隆过滤器主要是用于检索一个元素是否在一个集合中。我们当时使用的是 redisson实现的布隆过滤器。 它的底层主要是先去初始化一个比较大数组，里面存放的二进制0或1。在一 开始都是0，当一个key来了之后经过3次hash计算，模于数组长度找到数据 的下标然后把数组中原来的0改为1，这样的话，三个数组的位置就能标明一 个key的存在。查找的过程也是一样的。 当然是有缺点的，布隆过滤器有可能会产生一定的误判，我们一般可以设置 这个误判率，大概不会超过5%，其实这个误判是必然存在的，要不就得增 加数组的长度，其实已经算是很划分了，5%以内的误判率一般的项目也能 接受，不至于高并发下压倒数据库。
19.什么是缓存击穿 ? 怎么解决 ?
缓存击穿是指某个缓存数据过期了，而此时突然有大量并发请求打了过来，大量请求访问数据库导致数据库挂掉。
要解决这个问题方法1.使用锁的方式，缓存失效时，不立即进行缓存重建，先使用如 Redis 的 setnx 去设置一个互斥锁，当操作成功返回时再进行缓存重建的操作，否则重试方法，2.使用逻辑过期的方法，①：在设置key的时候，设置一个过期时间字段一块存入缓存中，不给当前 key设置过期时间 ②：当查询的时候，从redis取出数据后判断时间是否过期 ③：如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据， 这个数据不是最新的。
锁的方法适用于需要强一致性的数据，而逻辑判断则无需强一致性。
20.什么是缓存雪崩 ? 怎么解决 ?
缓存雪崩主要是指，当有大量缓存同时过期，导致大量请求达到数据库导致数据库挂掉或者因为redis服务器重启导致大量请求达到数据库。
解决方法：如果是由大量缓存数据同时过期导致的，可以给数据的过期时间加上一个随机值，比如可以在原有的失效时间基 础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重 复率就会降低，就很难引发集体失效的事件
针对 Redis 服务不可用的情况：解决redis宕机问题）：1.用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落在了底层存储系统上。
2.采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。3.限流，避免同时处理大量的请求。
4.多级缓存，例如本地缓存+Redis 缓存的组合，当 Redis 缓存出现问题时，还可以从本地缓存中获取到部分数据。
针对热点缓存失效的情况：1.缓存永不失效（不太推荐，实用性太差）。2.缓存预热，也就是在程序启动后或运行过程中，主动将热点数据加载到缓存中。3.（解决同一时间大量失效问题）缓存失效时间分散开，比如我们可以在原有的失效时间的基础上增加一个随机值，比如一到五分钟随即，这样每一个缓存的过期时间的重复率都会降低，这样就很难引发集体失效的事件。
21.redis做为缓存，mysql的数据如何与redis进行同步呢？（双写一致 性）
采用的阿里的canal组件实现数据同步：不需要更改业务代码，部署 一个canal服务。canal服务把自己伪装成mysql的一个从节点，当mysql数据 更新以后，canal会读取binlog数据，然后在通过canal的客户端获取到数据， 更新缓存即可。
采用的是redisson实现的读写锁，在读的时候添加共享锁，可以保证读 读不互斥，读写互斥。当我们更新数据的时候，添加排他锁，它是读写，读 读都互斥，这样就能保证在写数据的同时是不会让其他线程读数据的，避免 了脏数据。这里面需要注意的是读方法和写方法上需要使用同一把锁才行。
延迟双删，如果是写操作，我们先把缓存中的数据删除，然后更新 数据库，最后再延时删除缓存中的数据，其中这个延时多久不太好确定，在 延时的过程中可能会出现脏数据，并不能保证强一致性，所以没有采用它。
22.redis做为缓存，数据的持久化是怎么做的？
Redis中提供了两种数据持久化的方式：1、RDB 2、AOF
RDB是一个快照文件，它是把redis内存存储的数据写到磁盘上，当 redis实例宕机恢复数据的时候，方便从RDB的快照文件中恢复数据。 AOF的含义是追加文件，当redis操作写命令的时候，都会存储这个文件中， 当redis实例宕机恢复数据的时候，会从这个文件中再次执行一遍命令来恢复 数据
23.这两种方式，哪种恢复的比较快呢？
RDB因为是二进制文件，在保存的时候体积也是比较小的，它恢复 的比较快，但是它有可能会丢数据，我们通常在项目中也会使用AOF来恢复 数据，虽然AOF恢复的速度慢一些，但是它丢数据的风险要小很多，在AOF 文件中可以设置刷盘策略，我们当时设置的就是每秒批量写入一次命令
24.数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的 数据都是热点数据 ?
可以使用 allkeys-lru （挑选最近最少使用的数据淘汰）淘汰策略，那留下来 的都是经常访问的热点数据
25.Redis的内存用完了会发生什么？
这个要看redis的数据淘汰策略是什么，如果是默认的配置，redis内存 用完以后则直接报错。我们当时设置的 allkeys-lru 策略。把最近最常访问的 数据留在缓存中
26.Redis分布式锁如何实现 ?
在redis中提供了一个命令setnx(SET if not exists) 由于redis的单线程的，用了命令之后，只能有一个客户端对某一个key设置 值，在没有过期或删除key的时候是其他客户端是不能设置这个key的。
27.如何控制Redis实现分布式锁有效时长呢？
redis的setnx指令不好控制这个问题，我们当时采用的 redis的一个框架redisson实现的。在redisson中需要手动加锁，并且可以控制锁的失效时间和等待时间，当锁 住的一个业务还没有执行完成的时候，在redisson中引入了一个看门狗机 制，就是说每隔一段时间就检查当前业务是否还持有锁，如果持有就增加加 锁的持有时间，当业务执行完成之后需要使用释放锁就可以了 还有一个好处就是，在高并发下，一个业务有可能会执行很快，先客户1持 有锁的时候，客户2来了以后并不会马上拒绝，它会自旋不断尝试获取锁， 如果客户1释放之后，客户2就可以马上持有锁，性能也得到了提升。
28.redisson实现的分布式锁是可重入的吗？
是可以重入的。这样做是为了避免死锁的产生。这个重入其实 在内部就是判断是否是当前线程持有的锁，如果是当前线程持有的锁就会计 数，如果释放锁就会在计算上减一。在存储数据的时候采用的hash结构，大 key可以按照自己的业务进行定制，其中小key是当前线程的唯一标识，value 是当前线程重入的次数
29.redisson实现的分布式锁能解决主从一致性的问题吗？
不能的，比如，当线程1加锁成功后，master节点数据会异 步复制到slave节点，此时当前持有Redis锁的master节点宕机，slave节点被 提升为新的master节点，假如现在来了一个线程2，再次加锁，会在新的 master节点上加锁成功，这个时候就会出现两个节点同时持有一把锁的问 题。 我们可以利用redisson提供的红锁来解决这个问题，它的主要作用是，不能 只在一个redis实例上创建锁，应该是在多个redis实例上创建锁，并且要求在 大多数redis节点上都成功创建锁，红锁中要求是redis的节点数量要过半。这 样就能避免线程1加锁成功后master节点宕机导致线程2成功加锁到新的 master节点上的问题了。 但是，如果使用了红锁，因为需要同时在多个节点上都添加锁，性能就变的 很低了，并且运维维护成本也非常高，所以，我们一般在项目中也不会直接 使用红锁，并且官方也暂时废弃了这个红锁
30.如果业务非要保证数据的强一致性，这个该怎么解决呢？
redis本身就是支持高可用的，做到强一致性，就非常影响性 能，所以，如果有强一致性要求高的业务，建议使用zookeeper实现的分布 式锁，它是可以保证强一致性的
31.Redis集群有哪些方案, 知道嘛 ?
在Redis中提供的集群方案总共有三种：主从复制、哨兵模 式、Redis分片集群。
32.介绍一下主从同步
是这样的，单节点Redis的并发能力是有上限的，要进一步提 高Redis的并发能力，可以搭建主从集群，实现读写分离。一般都是一主多 从，主节点负责写数据，从节点负责读数据，主节点写入数据之后，需要把 数据同步到从节点中
33.能说一下，主从同步数据的流程
主从同步分为了两个阶段，一个是全量同步，一个是 增量同步 全量同步是指从节点第一次与主节点建立连接的时候使用全量同步，流程是 这样的： 第一：从节点请求主节点同步数据，其中从节点会携带自己的replication id 和offset偏移量。 第二：主节点判断是否是第一次请求，主要判断的依据就是，主节点与从节 点是否是同一个replication id，如果不是，就说明是第一次同步，那主节点 就会把自己的replication id和offset发送给从节点，让从节点与主节点的信息 保持一致。 第三：在同时主节点会执行bgsave，生成rdb文件后，发送给从节点去执 行，从节点先把自己的数据清空，然后执行主节点发送过来的rdb文件，这 样就保持了一致 当然，如果在rdb生成执行期间，依然有请求到了主节点，而主节点会以命 令的方式记录到缓冲区，缓冲区是一个日志文件，最后把这个日志文件发送 给从节点，这样就能保证主节点与从节点完全一致了，后期再同步数据的时 候，都是依赖于这个日志文件，这个就是全量同步 增量同步指的是，当从节点服务重启之后，数据就不一致了，所以这个时 候，从节点会请求主节点同步数据，主节点还是判断不是第一次请求，不是 第一次就获取从节点的offset值，然后主节点从命令日志中获取offset值之后 的数据，发送给从节点进行数据同步
34.怎么保证Redis的高并发高可用
首先可以搭建主从集群，再加上使用redis中的哨兵模式，哨兵模式 可以实现主从集群的自动故障恢复，里面就包含了对主从服务的监控、自动 故障恢复、通知；如果master故障，Sentinel会将一个slave提升为master。 当故障实例恢复后也以新的master为主；同时Sentinel也充当Redis客户端的 服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户 端，所以一般项目都会采用哨兵的模式来保证redis的高并发高可用。
35.你们使用redis是单点还是集群，哪种集群
当时使用的是主从（1主1从）加哨兵。一般单节点不超 过10G内存，如果Redis内存不足则可以给不同服务分配独立的Redis主从节 点。尽量不做分片集群。因为集群维护起来比较麻烦，并且集群之间的心跳 检测和数据通信会消耗大量的网络带宽，也没有办法使用lua脚本和事务。
36.redis集群脑裂，该怎么解决呢？
这个在项目很少见，不过脑裂的问题是这样的，我们现在用的 是redis的哨兵模式集群的 有的时候由于网络等原因可能会出现脑裂的情况，就是说，由于redis master节点和redis salve节点和sentinel处于不同的网络分区，使得sentinel没 有能够心跳感知到master，所以通过选举的方式提升了一个salve为master， 这样就存在了两个master，就像大脑分裂了一样，这样会导致客户端还在 old master那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会 将old master降为salve，这时再从新master同步数据，这会导致old master中 的大量数据丢失。 关于解决的话，我记得在redis的配置中可以设置：第一可以设置最少的salve 节点个数，比如设置至少要有一个从节点才能同步数据，第二个可以设置主 从数据复制和同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的 数据丢失
37.redis的分片集群有什么作用？
分片集群主要解决的是，海量数据存储的问题，集群中有多个 master，每个master保存不同数据，并且还可以给每个master设置多个slave 节点，就可以继续增大集群的高并发能力。同时每个master之间通过ping监 测彼此健康状态，就类似于哨兵模式了。当客户端请求可以访问集群任意节 点，最终都会被转发到正确节点。
38.Redis分片集群中数据是怎么存储和读取的？
在redis集群中是这样的 Redis 集群引入了哈希槽的概念，有 16384 个哈希槽，集群中每个主节点绑 定了一定范围的哈希槽范围， key通过 CRC16 校验后对 16384 取模来决定放 置哪个槽，通过槽找到对应的节点进行存储。 取值的逻辑是一样的
39.能解释一下I/O多路复用模型？
I/O多路复用是指利用单个线程来同时监听多个Socket ，并 在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU 资源。目前的I/O多路复用都是采用的epoll模式实现，它会在通知用户进程 Socket就绪的同时，把已就绪的Socket写入用户空间，不需要挨个遍历 Socket来判断是否就绪，提升了性能。 其中Redis的网络模型就是使用I/O多路复用结合事件的处理器来应对多个 Socket请求，比如，提供了连接应答处理器、命令回复处理器，命令请求处 理器； 在Redis6.0之后，为了提升更好的性能，在命令回复处理器使用了多线程来 处理回复事件，在命令请求处理器中，将命令的转换使用了多线程，增加命 令转换速度，在命令执行的时候，依然是单线程