Sob a avalanche, nenhum floco de neve é inocente~~

Olá a todos, sou o Louie!

O tópico que escrevi hoje é realmente muito básico, mas como alguns cenários são muito importantes para alta simultaneidade, é absolutamente impossível evitá-lo. Estima-se que você o encontrará com frequência durante as entrevistas.

Existem muitos artigos sobre este tema na Internet. Eu queria reimprimir um diretamente, mas senti que não era adequado. Ou o artigo não foi refinado o suficiente ou foi simplificado demais, então eu mesmo deveria escrever um.

Embora o conteúdo seja básico, ainda mantenho o estilo de escrita anterior. Depois de consultar muitos blogs excelentes, pretendo escrever um artigo fácil de entender e abrangente.

prefácio

Vejamos primeiro o processo de consulta normal:

• Query Redis primeiro, se a consulta for bem sucedida, retorne diretamente, se a consulta não existir, vá para query DB;
• Se a consulta de banco de dados for bem-sucedida, os dados serão gravados de volta no Redis, a consulta não existirá e será retornada diretamente.

penetração de cache

Definição: Quando não há dados no banco de dados de consulta e no cache, pois a consulta no banco de dados não possui dados, o resultado não será salvo no cache para tolerância a falhas, portanto, cada solicitação consultará o banco de dados , o que é chamado de penetração de cache.

A linha vermelha é o cenário de penetração de cache, que ocorre quando a chave de consulta não existe no cache e no banco de dados.

Imagine, por exemplo, que existe uma interface que precisa consultar informações do produto. Se um usuário mal-intencionado simular um ID de produto inexistente para iniciar uma solicitação, a simultaneidade instantânea será muito alta e estima-se que seu banco de dados irá travar diretamente acima.

Talvez a primeira reação de todos seja realizar verificações regulares nos parâmetros de entrada e filtrar solicitações inválidas, sim! Isso é verdade, existe alguma outra solução melhor?

Valor vazio do cache

Quando consultamos um valor nulo do banco de dados, podemos semear um valor nulo no cache . Para evitar que o cache fique ocupado por muito tempo, precisamos adicionar um tempo de expiração relativamente curto a esse valor nulo, como 3 ~5 minutos.

No entanto, há um problema com esta solução. Quando um grande número de solicitações inválidas passar, haverá um grande número de caches vazios no cache. Se o espaço do cache estiver cheio, algumas informações do usuário armazenadas em cache serão removidas , em vez disso, causará uma queda na taxa de acertos do cache, portanto, esta solução precisa avaliar a capacidade do cache.

如果缓存空值不可取，这时你可以考虑使用布隆过滤器。

布隆过滤器

布隆过滤器是由一个可变长度为 N 的二进制数组与一组数量可变 M 的哈希函数构成，说的简单粗暴一点，就是一个 Hash Map。

原理相当简单：比如元素 key=#3，假如通过 Hash 算法得到一个为 9 的值，就存在这个 Hash Map 的第 9 位元素中，通过标记 1 标识该位已经有数据，如下图所示，0 是无数据，1 是有数据。

所以通过该方法，会得到一个结论：在 Hash Map 中，标记的数据，不一定存在，但是没有标记的数据，肯定不存在。

为什么“标记的数据，不一定存在”呢？因为 Hash 冲突！

比如 Hash Map 的长度为 100，但是你有 101 个请求，假如你运气好到爆，这 100 个请求刚好均匀打在长度为 100 的 Hash Map 中，此时你的 Hash Map 已经全部标记为 1。

当第 101 个请求过来时，就 100% 出现 Hash 冲突，虽然我没有请求过，但是得到的标记却为 1，导致布隆过滤器没有拦截。

如果需要减少误判，可以增加 Hash Map 的长度，并选择却分度更高的 Hash 函数，比如多次对 key 进行 hash。

除了 Hash 冲突，布隆过滤器其实会带来一个致命的问题：布隆过滤器更新失败。

比如有一个商品 ID 第一次请求，当 DB 中存在时，需要在 Hash Map 中标记一下，但是由于网络原因，导致标记失败，那么下次这个商品 ID 重新发起请求时，请求会被布隆过滤器拦截，比如这个是双11的爆款商品库存，明明有 10W 件商品，你却提示库存不存在，领导可能会说“明天你可以不用来了”。

所以如果使用布隆过滤器，在对 Hash Map 进行数据更新时，需要保证这个数据能 100% 更新成功，可以通过异步、重试的方式，所以这个方案有一定的实现成本和风险。

缓存击穿

定义：某个热点缓存在某一时刻恰好失效，然后此时刚好有大量的并发请求，此时这些请求将会给数据库造成巨大的压力，这种情况就叫做缓存击穿。

这个其实和“缓存穿透”流程图一样，只是这个的出发点是“某个热点缓存在某一时刻恰好失效”，比如某个非常热门的爆款商品，缓存突然失效，流量直接全部打到 DB，造成某一时刻数据库请求量过大，更强调瞬时性。

解决问题的方法主要有 2 种：

1. 分布式锁：只有拿到锁的第一个线程去请求数据库，然后插入缓存，当然每次拿到锁的时候都要去查询一下缓存有没有，这种在高并发场景下，个人不太建议用分布式锁，会影响查询效率；
2. 设置永不过期：对于某些热点缓存，我们可以设置永不过期，这样就能保证缓存的稳定性，但需要注意在数据更改之后，要及时更新此热点缓存，不然就会造成查询结果的误差，比如热门商品，都先预热到数据库，后续再下线掉。

网上还有“缓存续期”的方式，比如缓存 30 分钟失效，可以搞个定时任务，每 20 分钟跑一次，感觉这种方式不伦不类，仅供大家参考。

缓存雪崩

定义：在短时间内有大量缓存同时过期，导致大量的请求直接查询数据库，从而对数据库造成了巨大的压力，严重情况下可能会导致数据库宕机的情况叫做缓存雪崩。

如果说“缓存击穿”是单兵反抗，那“缓存雪崩”就是集体起义了，那什么情况会出现缓存雪崩呢？

1. 短时间内有大量缓存同时过期；
2. 缓存服务宕机，导致某一时刻发生大规模的缓存失效。

那么有哪些解决方案呢？

1. 缓存添加随机时间：可在设置缓存时添加随机时间，比如 0~60s，这样就可以极大的避免大量的缓存同时失效；
2. 分布式锁：加一个分布式锁，第一个请求将数据持久化到缓存后，其它的请求才能进入；
3. 限流和降级：通过限流和降级策略，减少请求的流量；
4. 集群部署：Redis 通过集群部署、主从策略，主节点宕机后，会切换到从节点，保证服务的可用性。

缓存添加随机时间示例：

// 缓存原本的失效时间
int exTime = 10 * 60;
// 随机数生成类
Random random = new Random();
// 缓存设置
jedis.setex(cacheKey, exTime + random.nextInt(1000) , value);
复制代码

---

硬核推荐：

• 从美团挖来的架构师居然这么设计 DB+ 缓存，真的长见识了！
• 去字节面试，直接让人出门左拐：Bean 生命周期都不知道！
• 源码深度解析，Spring 如何解决循环依赖？
• 总监又来了，人狠话不多，这篇 gRPC，小弟佩服！
• 如何才能达到阿里 P7 水平 ？
• 新来个技术总监，把 RabbitMQ 讲的那叫一个透彻，佩服！