思考服务雪崩 case

最新推荐文章于 2024-07-24 08:14:07 发布

轩脉刃

最新推荐文章于 2024-07-24 08:14:07 发布

阅读量195

点赞数 1

文章标签：缓存分布式 redis java 数据库

本文链接：https://blog.csdn.net/qq_42015552/article/details/120426286

版权

今天在极客时间读者区有个人问了一个雪崩的问题，具体问题比较简单，就不说了。但是引发了我思考下服务雪崩的场景，想列一下会引发服务雪崩的 case。

你好，我是轩脉刃。

今天在极客时间读者区有个人问了一个雪崩的问题，具体问题比较简单，就不说了。但是引发了我思考下服务雪崩的场景，想列一下会引发服务雪崩的 case。

超时设置不合理

服务雪崩最常见的就是下游服务没设置超时，导致上游服务不可用。

比如像上图的，A->B->C， C 的超时不合理，导致 B 请求不中止，而进而堆积，B 服务逐渐不可用，同理导致 A 服务也不可用。

而在微服务盛行的链式结构中这种影响面会更大。

按照前面的分析，除了 G 之外，其他的节点都会收到波及。

我们在进行下游调用的时候，经常会使用重试机制，但是重试机制一旦使用不合理，也有可能导致下游服务的不可用。

理论上越下层的服务可承受的 qps 应该越高。如果在微服务链路中，有某个下游服务的 qps，比如上图中的 c 没有预估正确，当正常请求量上来之后，c 先扛不住，而扛不住返回的错误码又会让上游服务不断增加重试机制。又进一步加剧了下游服务的不可用。进而整体系统雪崩。

缓存雪崩顾名思义就是原本应该打在缓存中的请求，全部绕开缓存，打到了 DB。从而导致 DB 不可用，根据上一节说的，DB 作为一个服务节点，不可用会导致上游都出现雪崩效应。（其实这里的 DB 也有可能是各种数据或者业务服务）

缓存导致雪崩的原因大致有几种：

1 被攻击

“根据请求中的某个值建立 key 去缓存中获取，获取不到就去数据库中获取”。这种逻辑其实很容易被攻击者利用作为缓存雪崩的手段之一。攻击者只需要建立大量非合理的 key，就可以打穿缓存进入数据库进行请求。请求量只要足够大，那么就可以导致绕过缓存，数据库不可用。

2 缓存瞬时失效

“通过第一个请求建立缓存，建立之后 xxx 时间后失效”。这个也是一个很经常出现瞬时缓存雪崩的原因。因为有可能，第一次批量建立了缓存，又批量在统一时间内缓存失效。缓存失效后大批量的请求会涌入后端数据库，导致数据库不可用。

3 缓存热 key

某个缓存中的 key 问题。缓存中的某个 key 突然有大批量的请求涌入，而缓存的分布式一般是按照 key 进行节点分布的。导致某个缓存服务节点流量过于集中，不可用。而缓存节点不可用又会导致这大批量的请求穿透缓存进入数据库，导致数据库不可用。

大雪过后，没有一片雪花是无辜的。

不知道以上 case 考虑足够不足够。有啥需要补充的可以在公众号留言下？

Hi，我是轩脉刃，一个名不见经传码农，体制内的小愤青，躁动的骚年，2021年想坚持写一些学习/工作/思考笔记，谓之倒逼学习。欢迎关注个人公众号：轩脉刃的刀光剑影。

MORE | 更多原创文章

① gorm日志模块源码解析

关注