最近重大新闻头条,推广网站优化seo教程上排名,wordpress 并发量,自己做网站分销Redis Interview Speedrun redis缓存雪崩 缓存雪崩是指大量key同时失效#xff0c;此时有大量并发访问请求直接进到数据库#xff0c;导致数据库压力过大#xff0c;容易宕机。解决方案是在设置key的过期时间时#xff0c;不应该设置一样的过期时间#xff0c;可以选择设置…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次每次耗时不超过25msFAST模式没有固定执行频率每次事件循环都会尝试执行但每两次时间间隔不小于2ms每次耗时不超过1ms。如果既不进行定期删除也不访问过期key进行惰性删除那redis内存很快就会满了此时就会走redis的数据淘汰策略。数据淘汰策略一共有8种1.noeviction默认的不淘汰2.volatile-ttl对设置了ttl过期时间的key淘汰最小ttl的key3.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请求它提供了多种事件处理器包括连接应答处理器命令请求处理器命令响应处理器。
