浅谈关于服务雪崩的事

这里呢,我只是介绍一下,百度百不到的一些知识点,一些事整理,一些事资料搜集。

什么是雪崩?

雪崩一般是某一个节点失效,导致其他节点缓存命中率降低,从而使缓存中缺失的数据直接去数据库查询,短时间造成数据库服务器的奔溃。

雪崩是系统中的蝴蝶效应导致其发生的原因多种多样,有不合理的容量设计,或者是高并发下某一个方法响应变慢,亦或是某台机器的资源耗尽。从源头上我们无法完全杜绝雪崩源头的发生,但是雪崩的根本原因来源于服务之间的强依赖,所以我们可以提前评估,做好熔断,隔离,限流。 (下章节讲这三分别是啥,大家也可以百度)

如何解决雪崩?

对于一些有一定并发量或数据量较高的数据库操作,我们都会在前端加一层缓存层,并设置失效时间,现在一般是mongoDB或memcached,流程如下:

这个模式在并发量并非太高或数据操作效率很高的情况下基本没有什么问题.

但是也许你已经看到,if(缓存失效&&恰好遇到并发量很高&&数据库操作时间长)

1.缓存失效

2.第一个进程去数据库获取新数据,假如包括SQL+程序逻辑耗时5s

3.这5s内,第二个,第三个...第N个都只是获取到已失效的缓存,于是也都连接数据库

4.结果显而易见,数据库锁->数据库累计大量进程->直至数据库挂掉

那么,如何去解决这个问题呢?其实最简单的方案就是:

添加一个标记,类似于文件锁,用于判断此时程度是否正在更新缓存.

若是,则直接返回旧缓存(标记有设置失效时间,避免由于程序错误导致标记未删除而引起的缓存不更新问题)

若不,则设置一个标记,然后进行数据获取及缓存更新,最后删除标记.

发布了53 篇原创文章 · 获赞 61 · 访问量 5万+

猜你喜欢

转载自blog.csdn.net/qq_40884473/article/details/97376344