Redis----缓存设计、旁路缓存优化

一.缓存三大问题

1.缓存雪崩

大量缓存数据在同一时间过期，那么此时用户的大量请求就会直接访问数据库，数据库的并发能力有限，可能会宕机导致连锁反应，造成整个系统的崩溃.

1.1解决方案

避免数据同时过期:给key的TTL添加较小的随机值

设置缓存不过期: 后台更新缓存数据

2.缓存击穿

某个高并发且缓存重建业务比较复杂的key突然失效，大量请求冲击数据库且多个线程尝试重建缓存

2.1解决方案

互斥锁:基于sexnx命令的互斥锁，在尝试缓存重建前先获取互斥锁，获取到了再进行缓存重建的工作，保证只有一个线程进行缓存重建的操作，避免浪费系统资源

逻辑过期+缓存预热:提前将热点数据添加到Redis中，不设置真正的过期时间，利用额外字段保存逻辑过期时间，查到数据时判断是否过期.若过期则先返回旧数据，并开启一个子线程获取互斥锁进行异步重建

3.缓存穿透

用户要访问的数据本身在数据库中就不存在，那么缓存中必然也不会存在.这样的请求，首先会访问缓存，缓存中不存在对应的数据必然会访问数据库，而数据库中也没有数据，无法进行缓存重建，那么后续的请求都会重复该流程，请求最终都会到达数据库，无法承受过高的并发导致宕机。缓存穿透一般是数据误删或恶意攻击导致

3.1解决方案

参数校验:提前对参数格式做特殊要求，当请求到来时先进行参数校验，不合法的参数直接拒绝访问

缓存空值:对于缓存中没有，数据库也查不到的数据向Redis中缓存一个空值，避免后续相同的请求再次访问到数据库;缺点:无法处理大量不同非法请求的情况

布隆过滤器:保存数据时，利用哈希函数计算key多个位置，将相应的位置都设置为1，查询元素时同样利用哈希元素进行计算，如果计算出的位置都是1，则认为该元素肯能存在，继续执行后续操作，否则认为元素一定不存在拒绝访问；可能存在元素误删问题

二.缓存更新策略

Cache Aside(旁路缓存) 适合读多写少的场景

写策略:先更新数据库中的数据，再删除缓存中的

直接删除缓存的方式，若每次修改数据都更新缓存则可能会产生很多无效更新，有数据修改时直接删除缓存，有新的读需求时从数据库中查最新的数据重建缓存即可，避免无效更新；若先删除缓存再更新数据库，数据库更新还未完成，此时其他线程查询到旧数据并重建缓存，此时就导致了数据长期不一致.

先更新数据库再删除缓存，更新数据库过程中，其他线程读取到了缓存未来的及删除的旧数据，但当数据库更新完毕后会删除缓存，后续请求会读到最新的数据并重建和缓存，只会导致中途短暂数据不一致，最终数据是一致的.

先更新数据库再删除缓存可能出现的极小概率极端情况:线程A进行数据更新的流程，线程A首先将进行数据库数据更新的操作，与此同时线程B查询缓存(此时缓存还没有被线程A删除)，但由于某中原因缓存提前失效，线程B查询到了数据库未来得及更新的旧数据并进行重建缓存的操作，但恰好在此期间线程A更新数据库完毕并删除了缓存，线程B在线程A删除了缓存后才进行缓存重建的操作，此时多种小概率事件叠加在一起导致了数据的长期不一致，此种情况发生概率较低.可以为缓存添加有效时间，一段时间后缓存失效，自动纠错.

存在的隐患: 更新数据库与删除缓存是两个操作,若删除缓存失败,缓存中还是旧值与数据库中的数据短期不一致，等自动过期后才会最终一致.

读策略: 如果读取的数据命中了缓存，则直接返回数据 ； 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。

若写操作较多旁路缓存方案会影响缓存命中率

若对缓存命中率要求较高，可采用【更新数据库+更新缓存】的方案，同时在此基础上增加别的手段避免并发问题:

分布式锁: 在更新缓存前加互斥锁,保证统一时间只有一个请求更新缓存，解决了并发问题;缺点:影响更新缓存的性能

较短过期时间: 给缓存加上较短过期时间,即便并发问题导致数据不一致,很快也会自动纠错，性能较好;缺点: 还是会出现短期数据不一致

旁路缓存优化,解决缓存删除失败的问题

旁路缓存优化 保证缓存删除成功

消息队列: 将删除缓存要操作的数据添加到消息队列中，由消费者操作数据；若删除缓存成功则移除数据，若删除缓存失败,则利用MQ提供的重试机制进行重试.缺点:入侵原业务,需要改造原有业务代码

订阅binlog+消息队列: 数据库更新成功后会生成相应的日志记录在binlog中，利用Canal订阅binlog，再将Canal订阅到的数据发送到MQ中，利用MQ将消息发送到消费者尝试删除即可. 不入侵原有业务代码,缺点: 引入的额外组件较多

延迟双删？

不实用，无法落地，无法确定第二次删除时机。