【面试大全-缓存】-Redis必修课_面试经典问题系统哪些地方用到了缓存(1)

最新推荐文章于 2024-09-28 17:17:04 发布

2401_86436885

最新推荐文章于 2024-09-28 17:17:04 发布

阅读量814

点赞数 10

文章标签：缓存面试 redis

本文链接：https://blog.csdn.net/2401_86436885/article/details/142182474

版权

不仅仅使用RDB这样回照成很多数据丢失
也不仅仅使用AOF，AOF恢复速度慢，AOF每次都会记录命令，恢复难度可能增大
Redis支持同事开启两种方式持久化方式，我们可以综合这两种机制，用AOF来保证数据不丢失，做为数据恢复的第一选择，用RDB来做不同程度的冷备，在AOF丢失或者损坏的时候，采用RDB进行恢复
如果两种都开启，在Redis重启的时候，会采用AOF来加载数据，因为AOF数据更加完整

Redis没有使用哈希一致性算法，使用的是哈希槽，Redis中哈希槽一共有16384个，假设有三个集群节点，挂掉一个节点时，在某段时间这段哈希槽是不可用的，也就是集群不可用。

Master最好不要做持久化工作，入RDB快照，AOF日志文件
如果数据比较重要，可以在slave开启AOF日志按秒进行配置持久化
为了主从复制的安全性和稳定性，最好部署在同一局域网内
主从复制不要用图状结构，用单向链表结构更为稳定，即 Master -> Slave1 -> Slave2 -> Slave3 。如果master挂掉，Salve1立即启用做为master。

我们可以使用 keys 和 scan 命令
使用 keys 命令 ：可以使用keys进行全数据查询，当然Redis是单线程，数据量过大会进行阻塞，而且keys没有分页功能。
使用 scan 命令：scan命令和keys命令一样具有匹配功能，但是scan命令不会阻塞线程，并且查找的数据可能存在重复，需要客户端自己去重，因为scan是通过游标进行查询的，所以不会导致Redis出现假死，scan在检索过程中，被删除的元素是不会被查询出来的，相对来说scan命令耗费的时间更长，但是不影响Redis正常使用。

为了解决数据不至于问题，其中一种解决方案是使用读写串行化，可以通过队列来实现，但是可能存在读请求的挤压，读请求并发高。
如果写入数据库和更新到缓存的值是一致的时候，这个时候可以同步更新缓存和数据库，如果对于写比较频繁，而读不频繁的时候，我们需要对对缓存进行删除，等读的时候再去获取
如果写数据的值和缓存的值不一致的时候，写入缓存的数据需要通过几个表进行计算，那就没必要马上更新缓存，需要要删除缓存即可，等获取需要的时候再去进行计算
一般的解决方案是先删除缓存数据，再更新数据库。
常见的三种方式：
先更新数据库库、再更新缓存
先删除缓存，再更新数据库
先更新数据库，再删除缓存。
首先我们放入缓存的数据本来就不应该是实时性要求过高，比如用户余额，所以缓存的过期时间保证最终一致性是比较靠谱的。
我们不应该过度设计增加系统的复杂度
遇到实时性、一致性要求较高的，就应该查询数据库，即使可能性能不高。

缓存雪崩：系统设置的缓存在同一时间大面积过期，这时业务都去查询DB，给DB造成很大的压力，可能导致服务器岩机。
解决办法：讲缓存失效时间分散。
缓存穿透：指用户查询的时候缓存里面没有，数据库里面也没有，这两就会导致查询2次无用的操作，这样就绕过缓存直接查询数据库。
解决办法：1.布隆过滤器：将所有可能存在的数据存在一个bitmap中，一个一定不存在的数据会被拦截掉，从而避免了对底层系统的压力。2.简单的方法：查询为空，继续缓存这个空的value，过期时间相对设置短一些。
缓存预热：系统上线后，将相关系统的缓存直接存入缓存系统中，避免短时间内大量查询数据库。
解决方法：1.直接写个缓存刷新页面，上线时统一刷新。2.数据量不大时可以初始化加载。