转自https://blog.csdn.net/Q3838418/article/details/81988598
在开发高并发系统时有三把利器用来保护系统:缓存、降级和限流。
高并发系统设计原则
1. 做得少,一方面是指在功能特性上有所为,有所不为,另一方面是指一次处理的信息量要少。
2. 做得巧,根据业务自身的特点,选择合理的业务实现方式,选择合理的缓存类型和缓存调用时机。
1.扩容
根据业务系统的类型,考虑不同的针对在数据库方面的扩容:
-读操作扩容
-写操作扩容
2.缓存
手段
主要是Redis、CDN、浏览器等,其次可能存在的一些问题如下:
2.3可能存在的问题
2.3.1一致性
缓存一致性的话,主要可能考虑到以下几种可能导致一致性问题:
2.3.2缓存并发
由于并发时大量请求瞬间涌入,那么在建立或修改缓存时(还没完成),就可能已经打到DB或老缓存上了,造成雪崩或缓存一致性问题
解决方案:
锁机制
2.3.3缓存穿透
缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞。
解决方案:
最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被 这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法(我们采用的就是这种),如果一个查询返回的数据为空(不管是数 据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。
2.3.4雪崩
缓存雪崩是指在我们设置缓存时采用了相同的过期时间,导致缓存在某一时刻同时失效,请求全部转发到DB,DB瞬时压力过重雪崩。
解决方案
大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程(进程)写,从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开,比如我们可以在原有的失效时间基础上增加一个随机值,比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。
3.消息队列
做到了大量请求异步与解耦,比如下单与短信验证码请求 的处理,及早返回处理。
比如远程调用较慢,可以用消息队列攒一堆去完成调用。
基于消息的模型,等通知即可,而不是处理(那是RPC),以及索引库更新,只是一个通知,而不是强完成(重量级),只是通知而不是职责所在(比如上游系统对下的通知)。
仅仅最终一致性。
需求场景
及一些非核心业务或者多个对象、数据量小时,而
相比RPC框架(dubbo等),RPC场景是需要 强一致性、对延迟敏感、注重结果立马返回、重量级
4.应用拆分
SOA 微服务等
个人看法,原则是:
1.业务是否适合拆分,拆分后耦合度不能高
2.是否需要拆分,拆分是为了高并发高可用,是否解决了高并发热点问题?
5.应用限流
比如股票系统中,收盘后,你有几百万数据需要入库了,如果不做限流,瞬间将会把带宽全部打满,其它服务暂时GG或者主从延迟很大等等问题。
---------------------
作者:词汇族
来源:CSDN
原文:https://blog.csdn.net/Q3838418/article/details/81988598
版权声明:本文为博主原创文章,转载请附上博文链接!