保障分布式系统的稳定性(一)：流量控制

服务稳定性的实现方案: 依赖管理&服务分级&优雅降级&开关&应急预案

一.流量控制

1.为什么要控制流量

      在平时的正常的访问流量下，系统可以正常运行，但是当遇到热点事件，流量突然间增大的情况下。但是预估值和真实的访问量可能会有很大的出入，流量是不能准确估算的，所以要对我们的系统制定应急预案，防范流量突然暴涨的情况下我们的系统被压垮。

注：流量的控制可以从多个维度来进行

2.流量控制——限QPS

对系统总的并发请求数进行控制

方法一：

白名单机制：可以采用白名单的机制来限制访问，没有加入白名单的用户不让访问系统

方法二：

临牌池机制：

        用户访问系统必须获得令牌池中的令牌，才能进行访问。令牌池每秒钟，阀门开启一次，所有的请求去令牌池中并发的抢夺令牌，获得令牌的可以访问系统，没有获得的返回“系统正忙”或者让该请求加入队列然后重试（注意：这里是一个坑，不能让请求加入到队列中，因为加入队列后会带来很大的问题，访问的请求底层是一个socket连接，我们不知道要过多长时间才能获得访问，hold住这个socket连接要耗费系统的资源，如果保存的请求量比较大的，系统的load会非常的高，会带来很大的系统负载压力。最好的方法是让直接拒绝掉访问的请求，返回给用户，让用户重试，重新访问）。

       可以通过控制令牌池中令牌的数量来控制访问，当一个请求访问获得令牌时令牌池中的令牌数量减一，当访问结束后要把令牌还回到令牌池中，令牌数量加一。

方式一：

       阀门每秒开启一次，开启后重新初始化令牌池，取了令牌后不用归还

方式二：

        令牌池是固定的，直接限制并发，取令牌进行访问，访问结束后归还令牌

       另一种思路采用单机的内存队列来实现，实现请求的有限等待，！！！

如果是IO密集型的操作，比如说网络IO，它的瓶颈一般不在CPU和内存，限制并发数用处不大，因为瓶颈不在并发数（并发主要是占用的是CPU和内存资源）

    

     使用分布式队列来实现流量控制方式：

        注意这里要根据具体的业务场景来应用，要找出瓶颈在哪里，如果瓶颈在后端的业务处理则可以采用这种分布式队列处理（例如发邮件这类的，瓶颈在邮件的投递过程，不是在写邮件的过程），如果瓶颈在前端的页面请求，则采用队列不合适。