Redis深入理解、面试常问、疑难解答

Redis常问面试题

1、Redis 支持哪几种数据类型？

String、Hash、List、Set、Sorted Set

2、Redis 做登录是怎么实现的？和传统session有何区别？

传统的登录，使用的是session存储用户信息，这样存在弊处：
1、重启项目，session都丢失了，正在登录的用户需要重新登录
2、在分布式微服务项目中，存在session共享问题，很难搞
现在最流行的是把用户认证信息存到redis中，就不存在上面两个问题了。
1、用户登录，生成token，存入redis即可完成校验，把用户信息在拦截器中放到ThreadLocal中，方便后面使用。
2、用户验证码登录，生成的验证码放入到redis，用户登录时匹配验证码即可。

3、什么是缓存穿透？

缓存穿透是指查询缓存和数据库都不存在的数据，导致每次查询都会透过缓存，直接查询数据库。
解决方式：
1、缓存空对象：如果查不存在的key，就给该key设置个null值存到redis中。
优点：实现简单，维护方便
缺点：额外的内存消耗，大量的key为null占用内存（给key设置个过期时间也能解决）。
可能造成数据的短期不一致，比如给key设置null了，下次该key有值时，记得维度到redis中。
2、布隆过滤器:
布隆过滤器是一种数据结构，相当于在客户端和缓存中间加了一个过滤器，布隆过滤器会对缓存中所有的key进行n次hash运算，这样可以得到n个位置，然后将这n个位置的元素置为1。但客户端查询时，也会对查询的key进行n次hash运算，得到n个位置，如果这n个位置全为1则,去缓存查询，否则返回空给客户端。
布隆过滤器存在误判，我们一般不使用。

4、什么是缓存雪崩？

缓存雪崩是指当缓存中有大量的key在同一时刻过期，或者redis服务器宕机，导致大量的请求查询数据库，导致数据库压力加大。
解决方式：
1、将每个key的过期时间打散，使他们的失效时间均匀分布。
2、部署redis时使用集群，主从复制，哨兵。

5、什么是缓存击穿？

缓存击穿是指当缓存中的热点数据过期了，在该热点数据重新载入内存前有大量查询请求穿过缓存，直接查询数据库，导致数据库压力过大。

6、Redis高可用的几种实现方式

6.1 主从复制

主（master）和 从（slave）部署在不同的服务器上，当主节点服务器写入数据时会同步到从节点的服务器上，一般主节点负责写入数据，从节点负责读取数据。
优点：
1、读写分离，提高效率。
2、主节点负责写操作，从节点负责读操作；如果写少读多场景，配置多个从节点的话，效率非常高。数据热备份，提供多个副本。从节点宕机，影响较小。
缺点：
1、主节点故障，集群则无法进行工作，可用性比较低，从节点升主节点需要人工手动干预。因为只有主节点能进行写操作，一旦主节点宕机，整个服务就无法使用。当然此时从节点仍可以进行读操作，但是对于整个服务流程来说，是无法使用的。
2、Master的写的压力难以降低。主节点只能有一个，因此单节点内存大小不会太大，因此存储数据量受限。一个主节点，也无法分担写的压力

数据同步原理：
1、slave新加入同步：向主节点一次性同步数据，第一次是拿到RDB文件同步数据的
2、增量同步：后面主节点接收到新写入的数据，会把数据写入到repl_baklog文件中，slave节点从repl_baklog拿到数据，完成数据同步。
3、如果slave挂了，重启后，也是通过从主节点repl_baklog文件进行数据同步的。
思考数据同步原理：
1、slave向master同步数据时，master怎么判断slave是否为第一次同步？
答：每个节点都会存在一个replId，主节点和从节点的replId是一致的，不护为主从的两个节点的replId肯定不一致。 假设有A和B两个Mater,这两个Mater的replId肯定不一致，把B设置为A的slave(设置的过程，也就是第一次同步)，这时A和B的replId是一致的，则可以根据两个节点的replId是否一致，来判断是否为第一次同步。
2、增量同步时，slave怎么知道从repl_baklog文件的哪个位置开始同步数据？
offset：数据偏移量，slave会记录repl_baklog文件中的一个偏移量，说白了，就是上次同步到第几行了，下次从第几行以后开始同步。

6.2 哨兵模式

哨兵模式是在主从模式的基础上添加了故障检测和自动故障转移的功能。在哨兵模式中，一个或多个哨兵进程监视Redis节点的运行状况。如果主节点发生故障，哨兵会检测到这一情况并自动将其中一个从节点提升为新的主节点。这个过程是自动的，所以不需要人为干预。哨兵模式提高了Redis集群的可靠性，确保即使主节点发生故障，Redis服务也能够继续运行。

哨兵(Sentinel)模式原理：
1、哨兵节点会以每秒一次的频率对每个 Redis 节点发送PING命令，并通过 Redis 节点的回复来判断其运行状态。
2、当哨兵监测到主服务器发生故障时，会自动在从节点中选择一台将机器，并其提升为主服务器，然后使用 PubSub 发布订阅模式，通知其他的从节点，修改配置文件，跟随新的主服务器。 当客户端试图连接失效的主服务器时， 哨兵也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
3、存在误判情况：可能master并没有挂，只是sentinel和master之间的网络不通导致，导致ping失败。为了避免误判，通常会启动多个sentinel，一般是奇数个，比如3个，那么可以指定当有多个sentinel都觉得master挂掉了，此时才断定master真的挂掉了，通常这个值设置为sentinel的一半，比如sentinel的数量是3个，那么这个量就可以设置为2个。

多哨兵之间工作原理：
1、主观下线： 主观下线，适用于主服务器和从服务器。如果在规定的时间内(配置参数：down-after-milliseconds)，Sentinel节点没有收到目标服务器的有效回复，则判定该服务器为“主观下线”。比如 Sentinel1向主服务发送了PING命令，在规定时间内没收到主服务器PONG回复，则 Sentinel1 判定主服务器为“主观下线”。
2、客观下线： 客观（被动）下线，只适用于主服务器。 Sentinel1 发现主服务器出现了故障，它会通过相应的命令，询问其它 Sentinel 节点对主服务器的状态判断。如果超过半数以上的 Sentinel 节点认为主服务器 down 掉，则 Sentinel1 节点判定主服务为“客观下线”。
投票选举： 投票选举，所有 Sentinel 节点会通过投票机制，按照谁发现谁去处理的原则，选举 Sentinel1 为领头节点去做 Failover（故障转移）操作。Sentinel1 节点则按照一定的规则在所有从节点中选择一个最优的作为主服务器，然后通过发布订阅功能通知其余的从节点（slave）更改配置文件，跟随新上任的主服务器（master）。至此就完成了主从切换的操作。
总结&&注意：
Sentinel 负责监控主从节点的“健康”状态。当主节点挂掉时，自动选择一个最优的从节点切换为主节点。客户端来连接 Redis 集群时，会首先连接 Sentinel，通过 Sentinel 来查询主节点的地址，然后再去连接主节点进行数据交互。当主节点发生故障时，客户端会重新向 Sentinel 要地址，Sentinel 会将最新
的主节点地址告诉客户端。因此应用程序无需重启即可自动完成主从节点切换。
2、哨兵下的redis集群，除了新增了哨兵，其他的和主从都是一摸一样的。

6.3 分片集群

不管redis主从，还是高可用的 sentinel 哨兵模式。我们所做的这些工作只是保证了数据备份以及高可用，目前为止我们的程序一直都是向1台redis写数据，其他的redis只是备份而已。而分片集群其实是将不同的数据按照一定的分布规则分布在不同的机器上。

7、Redis持久化方式

7.1、RDB

1、 RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。
2、RDB是通过fork一个redis的当前进程生产RDB文件的。
优点：
1、 适合大规模的数据恢复。
2 、如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
缺点：
1 、数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2 、备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍），最后再将临时文件替换之前的备份文件。

7.2、AOF

Redis 默认不开启AOF。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

注意：Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）
混合持久化将 AOF 和 RDB 两种持久化方式结合起来，兼顾了实时性和恢复性，提供了更全面的数据保护策略，使 Redis 在不同应用场景中更加强大和可靠。但需要注意的是，混合持久化可能会增加存储开销和磁盘 I/O 负载，因此在配置时需要谨慎考虑

8、Redis锁原理

1、Redis锁是通过命令：SET key value NX EX 10实现的，利用锁到期时间释放锁。
2、多个线程执行同一块代码时，锁的key一致时，存在线程锁之间的误删情况(锁的key加上当前线程ID可以解决该问题)。但是一般我们都会根据具体的业务设置锁的key,如该key被加锁了，下次过来线程同步时，就忽略了。

用redis的setnx命令实现分布式锁，会有很多弊端。
1、不可重入：简单的来说就是一旦setnx [key] [value]后，就不能再对这个key做任何操作了（除了删除）。
假设我们在开发中有A和B两个业务，在业务A中，执行了setnx操作，然后在业务A中调用业务B。然后在业务B中也有setnx的操作（同一个KEY），此时，业务B就会阻塞在这里，等待业务A释放锁，但是，业务A肯定不会释放锁，因为业务A还没有执行完（调B）。故就会发生死锁。
2、不可重试 ：之前业务逻辑中，尝试获取锁，如果获取不到就直接return了，没有“重来”的机会！也无法提供重试的机制
3、超时释放：如果分布式锁的ttl是一分钟，业务执行了两分钟，这样锁在业务还没执行完，就释放掉了。
4、主从一致性：假如，在主节点中获取到了锁，在主节点向从节点同步这个锁信息的时候，主节点宕机了，那么从节点就会从中挑选一个作为主节点， 可是，此时之前的锁信息就丢失了，也就发生了锁失效的问题。

Redisson
Redisson是一个在Redis的基础上实现的各种分布式锁的实现，有效的解决上面几个问题。