qq_50446805的博客

这个时候已经进入了判断内部了，所以会执行删除锁，但是这个时候因为锁恰好失效，所以其他请求就占有锁，那么自己在删除锁的时候，其实删除的是别人的锁，这样在极端的情况下其实也会出问题的。举个例子：我们这的艾鹿薇奢侈品，由于疫情，是不让所有人全进去店里购买的，必须没人排队发放一张卡，有了这张卡才能进店里购买，并且只能进一个人（或一个家庭），直达出来，才能放后面的进入，也就是每次都是一个个的进去，这么这个一张卡其实就是令牌的理念，也就是分布锁了。如果抢到了锁，后续其他的请求只能等待释放，释放了以后再次争抢锁。

之前那样，如果要避免bigkey甚至其他的一些key冲突，我们其实需要对存值的时候的key，做好规范，因为在一个庞大的系统中，我们会有无数的key存在redis中，如果不做好规范管理，那么不仅会冲突，甚至会带来一些不可预料的生产风险。

BigKey: 用户越多，redis数据越多，bigkey会使得缓存数据更大，网络带宽会被占用，执行效率就低下，高并发的时候吞吐量QPS也会下降。

这种方案能解决方案一的原子性问题，但是依然会存在很大的问题，如下所示：1、时钟不同步：如果不同的节点的系统时钟不同步，可能导致锁的过期时间计算不准确。解决方案：使用相对时间而非绝对时间，或者使用时钟同步工具确保系统时钟同步。2、死锁：在某些情况下，可能出现死锁，例如由于网络问题导致锁的释放操作未能执行。解决方案：使用带有超时和重试的锁获取和释放机制，确保在一定时间内能够正常操作。

如果说用户对redis的写操作不多甚至没有，95%以上都是读操作，那么用rdb也没啥问题，我们有一个项目是采用的缓存预热方式，用户几乎没有写操作，所以直接采用RDB就够用了，因为哪怕redis挂了，甚至RDB没了，数据还是能通过预热重新载入。AOF重写，redis会把当前所有的数据以rdb形式存入到aof中，这都是二进制数据，数据量小，随后新的数据以aof形式追加到这个aof中，那么这个aof中包含两种文件类型数据，一个是rdb，一个是aof，那么恢复的时候redis会同时恢复，这样恢复过程会更快。

上图中，Redis会备份RDB到磁盘，那么备份到磁盘的过程是会耗时的，内存中redis的数据越多越大，比如8g内存中有4g都是redis数据，那么在备份到磁盘的时候会有传输过程，有一定的时间损耗，可能几十秒也有可能1分钟多，这个RDB快照并不是瞬间产生的。不论是开发游戏还是普通的项目，肯定会有维护期，那么在维护期的时候，就会用到save，直接阻塞，不让新的数据写入，游戏项目是最常见的，直接停服了，所有玩家等着新版本上线后才能重新进。*由于定时全量备份是重量级操作，所以对于实时备份的业务场景，就不适用了。

缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。

布隆过滤器能够实现使用较少的空间来高效判断一个指定的元素是否包含在一个集合中布隆过滤器并不保存这些数据,所以只能判断是否存在,而并不能取出该元素使用情景:凡是判断一个元素是否在一个集合中的操作,都可以使用它布隆过滤器常见使用场景idea中编写代码,一个单词是否包含在正确拼写的词库中(拼写不正确划绿线的提示)公安系统,根据身份证号\人脸信息,判断该人是否在追逃名单中爬虫检查一个网址是否被爬取过......

布隆过滤器能够实现使用较少的空间来高效判断一个指定的元素是否包含在一个集合中布隆过滤器并不保存这些数据,所以只能判断是否存在,而并不能取出该元素使用情景:凡是判断一个元素是否在一个集合中的操作,都可以使用它布隆过滤器常见使用场景idea中编写代码,一个单词是否包含在正确拼写的词库中(拼写不正确划绿线的提示)公安系统,根据身份证号\人脸信息,判断该人是否在追逃名单中爬虫检查一个网址是否被爬取过......

候选人嗯~~，我想一下缓存穿透是指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。这种情况大概率是遭到了攻击。解决方案的话，我们通常都会用布隆过滤器来解决它2.面试官候选人嗯，是这样~布隆过滤器主要是用于检索一个元素是否在一个集合中。我们当时使用的是redisson实现的布隆过滤器。它的底层主要是先去初始化一个比较大数组，里面存放的二进制0或1。