Redis Interview Speedrun

redis缓存雪崩

缓存雪崩是指大量key同时失效，此时有大量并发访问请求直接进到数据库，导致数据库压力过大，容易宕机。解决方案是在设置key的过期时间时，不应该设置一样的过期时间，可以选择设置一个固定值加2~5分钟的随机值来设置，避免key同时过期。
redis缓存击穿

缓存击穿是指单个key失效，此时有大量针对这个失效key的并发请求直接进到数据库，导致数据库压力过大，容易宕机。一般是对热点key的访问，解决方案为不设置这个key的过期时间，让它永不过期。
redis缓存穿透

缓存穿透是指对一个不存在的key进行大量并发请求访问，因为不存在，所以直接访问数据库，并且也不会添加到缓存，所以所有请求走的都是数据库，数据库压力过大，容易宕机。解决方案为使用布隆过滤器预先把所有可能存在的值存一遍，用布隆过滤器对用户请求进行过滤，如果key不存在，则直接拒绝，并且由于布隆过滤器底层使用的是bitmap，它是依靠对要存储的值进行多次哈希运算，将得到的值作为位置，将bitmap二进制相应位置置1，所以可以以少量内存存储大量数据。还有一种解决方案为缓存空值。
redis双写一致性

首先要看到底是要求强一致还是最终一致。如果是强一致，可以使用redisson提供的读写锁，写数据时添加写锁（排他锁），其他线程不能读和写；读数据时添加读锁（共享锁），其他线程只能读不能写。如果只要求最终一致，可以选择使用消息队列rabbitmq，写数据库的同时发送一份消息到rabbitmq，要它去通知缓存更新；或者使用canal中间件，它将自己伪装成mysql的一个从节点，当主节点进行写操作时，canal可以通过读取主节点的binlog日志来更新缓存。另外，还有一种方式是延时双删，即删除缓存+修改数据库+延时删除缓存，不过延时多长时间不好确定，还是可能产生脏数据，不能保证强一致性。
redis持久化

redis提供了2种持久化的方案，分别是rdb和aof。rdb，全称redis database，是redis默认开启的持久化方案，是一种指定时间间隔存储的二进制快照文件。它的原理是先fork一个子进程，扫描redis内存生成临时文件，生成好之后替换原本的dump.rdb文件。redis每次正常关闭会存储一次rdb文件，每次启动时，会读取dump.rdb文件的数据恢复到内存中。aof，全称append only file，意为追加文件，存储的不是数据而是生成数据的命令，每次执行会往文件里追加，所以aof文件会越来越大。因此，aof有一个重写的机制，当aof文件比上次重写增大100%且文件大小超过64M时进行重写，重写原理是fork一个子进程，扫描redis内存，把数据对应的set命令记录到一个临时文件，完成后再替换原来的aof文件。可以选择开启rdb和aof混合模式，此时redis启动时，会从dump.rdb里面的aof头中找到aof文件，进行数据恢复到内存中。
redis数据过期策略和数据淘汰策略

数据过期策略有惰性删除和定期删除。惰性删除就是当用到过期key时才将它删除。定期删除有SLOW和FAST两种模式。SLOW模式是定时任务，默认执行频率是10hz（每秒执行10次），每次耗时不超过25ms；FAST模式没有固定执行频率，每次事件循环都会尝试执行，但每两次时间间隔不小于2ms，每次耗时不超过1ms。如果既不进行定期删除，也不访问过期key进行惰性删除，那redis内存很快就会满了，此时就会走redis的数据淘汰策略。数据淘汰策略一共有8种，1.noeviction默认的不淘汰，2.volatile-ttl对设置了ttl过期时间的key淘汰最小ttl的key，3.allkeys-random所有key随机淘汰，4.volatile-random设置了ttl的key进行随机淘汰，后四种设置到2个重要的概念，分别是lru最近最少使用和lfu最少频率使用，所有后四种分别是allkeys-lru, volatile-lru, allkeys-lfu, volatile-lfu。为了确保最常访问的热点数据存储到redis中，所有一般使用的是allkeys-lru。
redis分布式锁使用场景

针对分布式场景下的抢券买票等问题，可以防止超卖；还可以用于保证某个接口的接口幂等性，防止用户重复提交。
redis分布式锁实现原理

redis分布式锁的实现原理是利用了redis的setnx命令，使用setnx命令设置key时，只有当key不存在时，才能设置成功，所以可以把锁作为key，设置key成功就表示获取了锁，删除key表示释放锁。考虑到可能会因为故障导致一个线程不能释放锁而死锁，需要设置锁的过期时间，然后还需要考虑锁的续期等一系列的问题，redis的框架redisson提供了一个watchdog看门狗的机制来解决这个问题，redisson分布式锁的默认过期时间是30秒，watchdog会不断检测持有锁的线程，每隔十秒，如果业务还没执行完，就会重新续期到30秒。
redis主从复制、主从同步流程

redis主从同步分为全量同步和增量同步。全量同步是第一次同步，从节点请求主节点同步数据，主节点检测到是第一次同步数据，然后同步版本信息，把replicationId和offset偏移量给从节点，然后去bgsave生成rdb文件发给从节点读取，生成的途中如果有其他的写操作，则会记录到一个叫repl_baklog的日志文件中，然后把日志文件给从节点同步剩下的。增量同步不是第一次同步，从节点请求主节点同步数据，主节点根据replicationId检测到不是第一次同步数据，然后就获取从节点的offset偏移量，把repl_baklog中自己和从节点的2个offset之间的数据发给从节点进行同步。
redis哨兵模式、集群脑裂

redis哨兵模式是使用奇数个哨兵对redis节点进行健康监测，当一个哨兵对主节点发出的请求超过指定时间都没有响应，则该哨兵主观认为主节点下线，如果超过半数哨兵都主观认为该主节点下线，则升级为该主节点的客观下线，此时哨兵会重新选举一个从节点成为新的主节点。但由于网络故障等原因，导致主节点和哨兵还有从节点没在同一个网络分区，哨兵认为下线选举新主节点，此时产生2个主节点，产生脑裂，写操作可能还在原来的主节点，这时恢复网络，老主节点，变为从节点导致数据丢失。解决方案为在redis.conf配置文件中设置对一个主节点写需要的最少从节点个数以及缩短主从同步的时间，避免脑裂过程中的大量数据丢失问题。
redis分片集群、数据读写规则

redis分片集群是有多个主节点分别存储不同的数据，多个主节点之间互相进行健康监测。每个主节点下还可以有多个从节点。不论用户访问那个节点，请求都会被路由到正确的节点上。它是引入了一个哈希槽的概念，一个redis分片集群，总共有16384个哈希槽，分配到不同的实例上了，当进行数据读写时，会对key的有效部分或key本身进行hax操作，然后对16384进行取余，得到的哈希槽位置所处的那个实例即是进行读写的对象。
redis是单线程的，为什么还那么快

首先，redis是基于纯内存操作的。其次，redis单线程，避免了多线程的上下文切换。然后最重要的一点是redis使用了IO多路复用模型，是非阻塞IO。IO多路复用，是指利用一个线程，同时对多个socket进行监测，在某个socket可读或可写时得到通知，而不用遍历所有的socket，充分利用了cpu资源。一般使用epoll模式，它会在通知用户进程socket就绪的同时将socket写入用户空间，不需要遍历socket，提高了效率。redis的网络模型就是采用了IO多路复用和事件的委派机制来应对多个socket请求，它提供了多种事件处理器，包括连接应答处理器，命令请求处理器，命令响应处理器。