系统负载剧变下的管控策略

假如目前的系统有100台机器,能够支撑每天1亿的点击量(这个就简单比喻一下),然后系统流量剧变了要,我如何应对,系统有那些策略可以处理,这里总结了一下之前的一些做法。

1、水平扩展

这个最容易理解,加机器,这样的话对于系统刚刚开始的伸缩性设计要求比较高,能够非常灵活的添加机器,来应对流量的变化。

2、系统分组

假如系统服务的业务不同,有优先级高的,有优先级低的,那就让不同的业务调用提前分组好的机器,这样的话在关键时刻,可以保核心业务。

3、系统限流

系统机器也加了,然后分组也做了,但是就是能力提升不上来,说白了就那样了,这时候,可以设置系统的极限能力阀值,例如QPS最大到多少,或者是同时并发的任务有多少,超过这个阀值之后就拒绝提供服务了。

4、业务引流

这个的话跟多的是业务做的事情,把流量引走,不要来请求系统了,一种简单的做法就是,冗余的业务直接隐藏掉链接,从开源节流的角度来想,就是开源。

5、业务降级

如果一个系统请求,涉及到多个逻辑处理,其中有的是可以没有的,就是类似锦上添花的那种,在高并发的情况下,可以通过系统开关的形式,不去做这个请求,这样就间接的提升了系统的能力,毕竟少做了一件事情。

6、依赖系统的能力扩展

如果单独看应用系统,可能东西要做的还真不多,但是要结合上下游的系统,尤其是下游依赖的存储系统,数据库是否能够支持够,分布式缓存是否能够支持够,都需要做好评估。

7、系统依赖梳理

上一条主要是说存储系统,如果本身是SOA的形式,可能会依赖其他系统,各个系统是否强弱依赖,在那个环节依赖了,都需要评估出来,可以人肉来做,也可以系统分析调用情况,来自动的做出来。

8、系统容量评估

系统到底能够撑多少的量,这个要有个客观数字的评估,需要结合系统的负载以及响应时间等数据,搞出一个模型出来,这样方便数字化出来。

9、数据库的读写分离以及主备按照读写比例进行划分

这个在数据库方面可以做优化,跟进系统的读写情况,划分,读写分离,全力保证写,然后如果读的压力太大,可以增加备库来提供读服务。

 

大体想到了几个点,简单的罗列一下。

你可能感兴趣的:(高并发)