seo查询站长工具,枣强网站建设公司,电子商务网站设计,万户网络待遇怎么样Redis常问面试题 Redis常问面试题1、Redis 支持哪几种数据类型#xff1f;2、Redis 做登录是怎么实现的#xff1f;和传统session有何区别#xff1f;3、什么是缓存穿透#xff1f;4、什么是缓存雪崩#xff1f;5、什么是缓存击穿#xff1f;6、Redis高可用的几种实现方式… Redis常问面试题 Redis常问面试题1、Redis 支持哪几种数据类型2、Redis 做登录是怎么实现的和传统session有何区别3、什么是缓存穿透4、什么是缓存雪崩5、什么是缓存击穿6、Redis高可用的几种实现方式6.1 主从复制6.2 哨兵模式6.3 分片集群 7、Redis持久化方式7.1、RDB7.2、AOF 8、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的基础上实现的各种分布式锁的实现有效的解决上面几个问题。
