都是套路：高并发系统的降级特技

动态化降级为静态化：比如平时网站可以走动态化渲染商品详情页,但是到了大促来临之际可以将其切换为静态化来减少对核心资源的占用,而且可以提升性能；其他还有如列表页、首页、频道页都可以这么玩；可以通过一个程序定期的推送静态页到缓存或者生成到磁盘,出问题时直接切过去；

静态化降级为动态化：比如当使用静态化来实现商品详情页架构时,平时使用静态化来提供服务,但是因为特殊原因静态化页面有问题了,需要暂时切换回动态化来保证服务正确性.

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

4、写服务降级

写服务在大多数场景下是不可降级的,不过可以通过一些迂回战术来解决问题.比如将同步操作转换为异步操作,或者限制写的量/比例.

比如扣减库存一般这样操作：

方案1：

a、扣减DB库存；

b、扣减成功后更新Redis中的库存；

方案2：

a、扣减Redis库存；

b、同步扣减DB库存,如果扣减失败则回滚Redis库存；

前两种方案非常依赖DB,假设此时DB性能跟不上则扣减库存就会遇到问题；因此我们可以想到方案3：

a、扣减Redis库存：

b、正常同步扣减DB库存,性能扛不住时降级为发送一条扣减DB库存的消息,然后异步进行DB库存扣减实现最终一致即可；

这种方式发送扣减DB库存消息也可能成为瓶颈；这种情况我们可以考虑方案4：

a、扣减Redis库存；

b、正常同步扣减DB库存,性能扛不住时降级为写扣减DB库存消息到本机,然后本机通过异步进行DB库存扣减来实现最终一致性.

也就是说正常情况可以同步扣减库存,在性能扛不住时降级为异步；另外如果是秒杀场景可以直接降级为异步,从而保护系统.

还有如下单操作可以在大促时暂时降级将下单数据写入Redis,然后等峰值过去了再同步回DB,当然也有更好的解决方案,但是更复杂,不是本文的重点.

还有如用户评价,如果评价量太大,也可以把评价从同步写降级为异步写.当然也可以对评价按钮进行按比例开放(比如一些人的看不到评价操作按钮).比如评价成功后会发一些奖励,在必要的时候降级同步到异步.

5、多级降级

缓存是离用户最近越高效；而降级是离用户越近越能对系统保护的好.因为业务的复杂性导致越到后端QPS/TPS越低.

页面JS降级开关：主要控制页面功能的降级,在页面中通过JS脚本部署功能降级开关,在适当时机开启/关闭开关；

接入层降级开关：主要控制请求入口的降级,请求进入后会首先进入接入层,在接入层可以配置功能降级开关,可以根据实际情况进行自动/人工降级；

这个可以参考《京东商品详情页服务闭环实践》,尤其在后端应用服务出问题时,通过接入层降级从而给应用服务有足够的时间恢复服务；

应用层降级开关：主要控制业务的降级,在应用中配置相应的功能开关,根据实际业务情况进行自动/人工降级.

总结：

降级能保障系统在大促中活下来,而不是死去,达到丢卒保帅的作用.对用户提供有损服务,总比不服务要好.根据自己的场景设计相应的降级策略,保障系统在危机时刻能通过降级手段平稳度过.

文/张开涛

文章出处：高效运维

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!