Redis 面试场景

项目地址

• 教程作者：
• 教程地址：

• 代码仓库地址：

• 所用到的框架和插件：

dbt 
airflow

一、Redis使用场景

1.1 统计网站访问次数

1.2 产品分类树

1. 缓存预热

• 分类树优化 从2s优化到0.1s

2. 预热失败

场景：如果没预热到的数据突然访问量很大，会造成缓存击穿

1.3 分布式锁（常见）

1. 方案1：直接加锁

1. 使用商品的sku作为setnx的key，只有最先设置key的人才可以设置setnx，其余的都失败，意味着，高并发的场景下，只有第一个设置key的线程，才会设置setnx
2. 加锁之后，一定要使用finally 删除锁，且需要给锁添加过期时间，原子性添加
   存在问题：
3. 这种方式只适合 QPS为 100以下的场景，高并发场景不能使用，如果锁的时间过短（5s)，但是业务执行长（8s），那么当第一个线程还没执行完，释放了锁，第二线程又设置了锁，会造成严重的超卖。

2. 方案2：锁判断

1. 解决别的线程释放自己的锁：给自己的锁添加一个身份，一般是请求ID，在finally删除锁的时候，需要判断是否为当前的请求，是当前的请求，才可以删除。
2. finally删除锁的时候，如果由于系统gc，执行了if判断，但是在删除锁的时候,gc导致卡顿，redis设置了过期时间，自动清除了锁，还会造成上面的1的问题，所以在判断自己的锁和删除锁的时候，也需要原子性
3. 2 的问题，redis无法解决，因为他没有提供，如果不是在双11的场景下，一般中小型公司，很难遇到这个问题

3. 方案3：锁续命

• 设置了10s的过期时间，如果一些请求会超过10s随机到达了13或者18，就需要我们设置另一个线程进行定时轮询，如果主线程的锁还在，那么就加5s，如果还在就继续