Redis使用场景
目录
缓存
- 缓存穿透
- 缓存击穿
- 缓存雪崩
- 双写一致性
- 持久化
- 数据过期策略
- 数据淘汰策略
分布式锁
- 实现原理（setnx、redission）
其他
- 哨兵模式、集群脑裂
- 分片集群、数据读取规则
- redis是单线程的却很快
缓存
一、缓存穿透
定义：查询一个不存在的数据，Mysql查询不到数据也不会直接写入缓存，导致每次请求都要查数据库
两个解决方案：
-
缓存空数据
优点：简单
缺点：消耗内存，可能发生不一致问题 -
使用布隆过滤器（作用：拦截不存在的数据）
优点：内存占用较少
缺点：实现复杂，存在误判
举例说明：根据文章id查询文章，请求路径如下：
一个get请求： api/enws/getById/1
正常缓存流程：根据id到redis中爬取数据，若找到数据则返回结果；若redis中未找到，再到数据库中查找，将结果返回，返回前需将数据库中查到的数据存储于redis中
缓存穿透是查询一个不存在的数据，Mysql查询不到数据也不会直接写入缓存，导致每次请求都要查数据库。导致这种情况一般是由于系统被恶意攻击，请求路径被获取后制造假id（0、复数、很大的值），疯狂冲击数据库，数据库并发并不高，请求达到一定量就会造成宕机
关于布隆过滤器
二、缓存击穿
定义：给某个key设置过期时间，当key过期时，刚好这个时间点key有大量的并发请求，这些并发请求可能瞬间把DB压垮。
虽然我们再查询时把数据同步到redis，但可能在缓存重建时，存入的是多个表汇总的结果，可能需要分组统计花费较长的时间，比如花费了50毫秒，这时若有大量请求数据库是承受不住的。
两个解决方案：
- 互斥锁
- 逻辑过期
互斥锁：强一致性、性能差
比如：跟钱相关的业务需要保证强一致性
互斥锁文字描述：线程1请求查询，在redis中未查询到缓存数据，于是获取互斥锁，查询数据库重建缓存数据，写入缓存，释放锁；线程1进行的同时线程2也请求查询未命中，于是获取互斥锁但失败了，只能休眠会再一直重试到缓存命中。
互斥锁的作用：确保任意时刻只有一个线程可以访问共享资源，从而避免数据竞争和不一致问题。
逻辑过期：高可用、性能优
比如：互联网行业，更加注重用户体验
逻辑过期文字描述：线程1查询缓存，发现逻辑时间已过期，获取互斥锁后，开启新线程2查询数据库重建缓存数据、写入缓存并重置逻辑过期时间、释放锁，同时线程1中继续并返回过期数据。线程1进行的同时线程3也查询发现逻辑时间过期，获取互斥锁失败后返回过期数据。当线程4命中缓存并没有过期，就可以获得最新查询数据了。
三、缓存雪崩
定义：指同一时段大量缓存key同时失效或Redis服务宕机，导致大量请求达到数据库造成巨大压力。
解决方案
- 给不同key的TTL添加随机值（给不同key设置不同的过期时间）
- 利用redis集群服务的可用性，比如哨兵模式、集群模式（解决redis宕机问题）
- 给缓存业务添加降级限流策略，例如ngxin、spring cloud gateway
- 给业务添加多级缓存，例如Guava、Caffeine
降级可作为系统的保底策略，适用于穿透、击穿、雪崩
四、双写一致性
定义：当修改了数据库数据也要更新缓存的数据，保持缓存和数据库的数据一致
- 读操作：缓存命中，直接返回；缓存未命中查询数据库，写入缓存，设定超时时间
- 写操作：延迟双删
先删除缓存，还是先修改数据库？
先删除缓存，再修改数据库
- 正常情况：
- 出现脏数据情况：
修改数据库数据前被其他线程写入缓存，导致缓存与数据库数据不一致
先修改操作数据库，再删除缓存
-
正常情况：
-
出现脏数据情况：
线程1得到的返回的结果写入缓存，与线程2更新的数据库数据对不上
所以不管先删除缓存，还是先修改数据库都会出现脏数据，应该采取延迟双删的方法，即删除两次缓存，可以降低脏数据的出现。延迟删除是因为数据库是主存模式，延迟删除让主节点把数据同步到从节点，但延迟删除也只是控制了一部分脏数据的风险，由于延迟时间不好确认，也有脏数据的风险，做不到绝对的强一至。
如何保持强一致性？
- 可以采用分布式锁（互斥锁）
强一致，性能低
一般存入缓存的数据都是读多写少，用读写锁来进行控制
- 共享锁：加锁后其他线程可以共享读操作
- 排他锁：加锁后阻塞其他线程读写操作
具体代码操作：
- 读操作
- 写操作
- 异步通知保证数据的最终一致性
利用异步通知解决数据同步问题
- MQ
- canal
它是基于mysql的主从同步实现
当有数据修改写入数据库后，数据库一旦变化就会记录到BINLOG日志文件中，cannal通过binlog数据文件获取变化，我们就可以在缓存服务获取变化的数据，然后更新到缓存
五、持久化
两种方式：RDB、AOF
- RDB(redis数据备份文件，也叫数据快照)
将内存中的数据存到磁盘中，当redis实例故障重启后，从磁盘读取快照文件，恢复数据
人工主动备份：
redis内部有触发RBG的机制，可以在redis.conf文件中找到
- AOF（追加文件，redis处理的每一个命令都记录在AOF文件，可看作是命令日志文件）
六、数据过期策略
Redis过期删除策略：惰性删除 + 定期删除两种策略配合使用
- 惰性删除
定义：访问key时再判断是否过期，过期则删除，反之返回key
优点：对CPU友好
缺点：对内存不友好
- 定期删除
定义：每隔一段时间，会从一定数量的数据库中取出一定数量的随机key进行检查，并删除其中的过期key（随之时间推一会遍历所有key，把所有过期key删除）
- 定期删除分两种模式：SLOW、FAST
SLOW模式是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件redis.conf的hz选项来调整次数
FAST模式执行频率不固定，但两次间隔不低于2ms，每次耗时不好过1ms
优点：可通过限制删除操作执行时长和频率减少删除操作对CPU的影响，另外定期删除能有效释放过期键占用的内存
缺点：难以确定删除操作执行的时长和频率
七、数据淘汰策略
定义：当redis内存不足想添加新key，会按照某种规则将内存数据删除，这种数据删除规则被成为内存的淘汰策略
- redis支持8中不同策略来选择删除key
- noeviction：不淘汰任何key，但内存满不语序写入新数据，默认策略
使用建议
