高并发系统之服务器降级
     分类:文章阅读     有: 0 条评论

高并发系统之服务器降级

     分类:文章阅读     有: 0 条评论

网上看到的文章,摘录分享。

​在开发高并发系统时有三把利器用来保护系统:缓存、降级和限流。之前已经有一些文章介绍过缓存和限流了。本文将详细聊聊降级。当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务。系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级。本文将介绍一些笔者在实际工作中遇到的或见到过的一些降级方案供大家参考。

降级的最终目的是保证核心服务可用,即使是有损的。而且有些服务是无法降级的(如加入购物车、结算)。

降级预案
在进行降级之前要对系统进行梳理,看看系统是不是可以丢卒保帅;从而梳理出哪些必须誓死保护,哪些可降级;比如可以参考日志级别设置预案:

一般:比如有些服务偶尔因为网络抖动或者服务正在上线而超时,可以自动降级;

警告:有些服务在一段时间内成功率有波动(如在95~100%之间),可以自动降级或人工降级,并发送告警;

错误:比如可用率低于90%,或者数据库连接池被打爆了,或者访问量突然猛增到系统能承受的最大阀值,此时可以根据情况自动降级或者人工降级;
严重错误:比如因为特殊原因数据错误了,此时需要紧急人工降级。

降级按照是否自动化可分为:自动开关降级和人工开关降级

降级按照功能可分为:读服务降级、写服务降级

降级按照处于的系统层次可分为:多级降级


降级的功能点主要从服务端链路考虑,即根据用户访问的服务调用链路来梳理哪里需要降级:
页面降级:在大促或者某些特殊情况下,某些页面占用了一些稀缺服务资源,在紧急情况下可以对其整个降级,以达到丢卒保帅;

之前总结过一些的文章《使用httpclient必须知道的参数设置及代码写法、存在的风险》和《dbcp配置及jdbc超时设置总结》。在实际场景用一定主要配置好超时时间和超时重试次数和机制。

另外对于新开发的服务想上线进行灰度测试;但是不太确定该服务的逻辑是否正确,此时就需要设置开关,当新服务有问题可以通过开关切换回老服务。还有多机房服务,如果某个机房挂掉了,此时需要将一个机房的服务切到另一个机房,此时也可以通过开关完成切换。

还有一些是因为功能问题需要暂时屏蔽掉某些功能,比如商品规格参数数据有问题,数据问题不能用回滚解决,此时需要开关控制降级。

还有一种是页面静态化场景:
动态化降级为静态化:比如平时网站可以走动态化渲染商品详情页,但是到了大促来临之际可以将其切换为静态化来减少对核心资源的占用,而且可以提升性能;其他还有如列表页、首页、频道页都可以这么玩;可以通过一个程序定期的推送静态页到缓存或者生成到磁盘,出问题时直接切过去;
静态化降级为动态化:比如当使用静态化来实现商品详情页架构时,平时使用静态化来提供服务,但是因为特殊原因静态化页面有问题了,需要暂时切换回动态化来保证服务正确性。

以上都保证出问题了有预案,用户还是可以使用网站,不影响用户购物。

比如扣减库存一般这样操作:
方案1:
1、扣减DB库存,2、扣减成功后更新Redis中的库存;
方案2:
1、扣减Redis库存,2、同步扣减DB库存,如果扣减失败则回滚Redis库存;
前两种方案非常依赖DB,假设此时DB性能跟不上则扣减库存就会遇到问题;因此我们可以想到方案3:
1、扣减Redis库存,2、正常同步扣减DB库存,性能扛不住时降级为发送一条扣减DB库存的消息,然后异步进行DB库存扣减实现最终一致即可;
这种方式发送扣减DB库存消息也可能成为瓶颈;这种情况我们可以考虑方案4:
1、扣减Redis库存,2、正常同步扣减DB库存,性能扛不住时降级为写扣减DB库存消息到本机,然后本机通过异步进行DB库存扣减来实现最终一致性。

也就是说正常情况可以同步扣减库存,在性能扛不住时降级为异步;另外如果是秒杀场景可以直接降级为异步,从而保护系统。还有如下单操作可以在大促时暂时降级将下单数据写入Redis,然后等峰值过去了再同步回DB,当然也有更好的解决方案,但是更复杂,不是本文的重点。
还有如用户评价,如果评价量太大,也可以把评价从同步写降级为异步写。当然也可以对评价按钮进行按比例开放(比如一些人的看不到评价操作按钮)。比如评价成功后会发一些奖励,在必要的时候降级同步到异步。

原文:http://jinnianshilongnian.iteye.com/blog/2306477


(●゚ω゚●)