限流

1、控制单位时间内的请求数

atomicLong#incrementAndGet()

分布式限流

很多时候我需要有一个全局的限速，例如用户注册时，让用户输入手机验证码，为了防止短信接口不被恶意频繁调用，一般会限制用户每分钟获取验证码频率，例如一分钟不能超过5次。

此时，我们可以通过Redis的来实现，伪代码如下：

phoneNum = "186xxxxxx";
key = "verifyCode:limit:"+phoneNum 
// SET key value EX 60 NX
isExists = redis.set(key, 1, "EX 60", "NX");
if( isExists !=null || redis.incr(key) <=5) {
    //通过
} else {
    //限速
}

上述，就是通过Redis实现了限速功能，例如一些网站限制一个IP地址不能在一秒钟内访问超过n次也可以采用类似的思路来实现。

2、并发线程数

Semaphore

从上图可以看出上游的A、B服务直接依赖了下游的基础服务C、D和E，对于A，B服务都依赖的基础服务D这种场景，服务A和B其实处于某种竞争关系，当我们考量服务A的并发阈值时，不可忽略的是服务B对A的影响，所以，大多情况并发阈值的设置需要保守一点，如果服务A的并发阈值设置过大，当流量高峰期来临，有可能直接拖垮基础服务D并影响服务B，即雪崩效应来了。从表面上看并发量限流似乎很有用，但也不可否认，它仍然可以造成流量尖刺，即每台服务器上该服务的并发量从0上升到阈值是没有任何“阻力”的，这是因为并发量考虑的只是服务能力边界的问题。

3、漏斗算法

均匀的速率

4、令牌桶算法

可接受突然大的流量

 

Sentinel

对于provider

根据qps限流

Service Provider 用于向外界提供服务，处理各个消费者的调用请求。为了保护 Provider 不被激增的流量拖垮影响稳定性，可以给 Provider 配置 QPS 模式的限流，这样当每秒的请求量超过设定的阈值时会自动拒绝多的请求。限流粒度可以是 服务接口 和 服务方法 两种粒度。若希望整个服务接口的 QPS 不超过一定数值，则可以为对应服务接口资源（resourceName 为接口全限定名）配置 QPS 阈值；若希望服务的某个方法的 QPS 不超过一定数值，则可以为对应服务方法资源（resourceName 为接口全限定名:方法签名）配置 QPS 阈值

 

对于consumer限流

根据并发数

Service Consumer 作为客户端去调用远程服务。每一个服务都可能会依赖几个下游服务，若某个服务 A 依赖的下游服务 B 出现了不稳定的情况，服务 A 请求 服务 B 的响应时间变长，从而服务 A 调用服务 B 的线程就会产生堆积，最终可能耗尽服务 A 的线程数。我们通过用并发线程数来控制对下游服务 B 的访问，来保证下游服务不可靠的时候，不会拖垮服务自身。基于这种场景，推荐给 Consumer 配置线程数模式的限流，来保证自身不被不稳定服务所影响。采用基于线程数的限流模式后，我们不需要再显式地去进行线程池隔离，Sentinel 会控制资源的线程数，超出的请求直接拒绝，直到堆积的线程处理完成，可以达到信号量隔离的效果。

我们看一下这种模式的效果。假设当前服务 A 依赖两个远程服务方法 sayHello(java.lang.String) 和 doAnother()。前者远程调用的响应时间 为 1s-1.5s 之间，后者 RT 非常小（30 ms 左右）。服务 A 端设两个远程方法 thread count 为 5。然后每隔 50 ms 左右向线程池投入两个任务，作为消费者分别远程调用对应方法，持续 10 次。可以看到 sayHello 方法被限流 5 次，因为后面调用的时候前面的远程调用还未返回（RT 高）；而 doAnother() 调用则不受影响。线程数目超出时快速失败能够有效地防止自己被慢调用所影响。

 通过降级

服务降级

当服务依赖于多个下游服务，而某个下游服务调用非常慢时，会严重影响当前服务的调用。这里我们可以利用 Sentinel 熔断降级的功能，为调用端配置基于平均 RT 的降级规则。这样当调用链路中某个服务调用的平均 RT 升高，在一定的次数内超过配置的 RT 阈值，Sentinel 就会对此调用资源进行降级操作，接下来的调用都会立刻拒绝，直到过了一段设定的时间后才恢复，从而保护服务不被调用端短板所影响。同时可以配合 fallback 功能使用，在被降级的时候提供相应的处理逻辑。

Fallback

从 0.1.1 版本开始，Sentinel Dubbo Adapter 还支持配置全局的 fallback 函数，可以在 Dubbo 服务被限流/降级/负载保护的时候进行相应的 fallback 处理。用户只需要实现自定义的 DubboFallback 接口，并通过 DubboFallbackRegistry 注册即可。默认情况会直接将 BlockException 包装后抛出。同时，我们还可以配合 Dubbo 的 fallback 机制 来为降级的服务提供替代的实现。

 

 

 

 

 

 

快30岁的的我，突然发现自己不再年轻，可能自己消耗的太多，懂得的太晚

 

我是一名程序媛，很重感情的姑娘，我的童年记忆里我又觉得我是特别的苦，但是很快乐的姑娘

小时候家里太穷，基本都是看着别人家的孩子在吃好吃的，我只有在那里看着的份，在我记事起，我爸爸腿受伤了，我延迟上学了一年，那年6岁我开始照顾我爸爸，我的童年，我的少年都是很苦的过来的，而我一直在抗争，在与命运抗争

村里还是重男轻女的，但是我的父母比较的开明，我多次的跟我爸妈谈过话，我说我要上大学，我不想看到到头的生活，那时候我只有9岁，我就知道我要干什么，穷人家的孩子是要受尽各种的苦，才能考上高中，考上大学，我顺利的考上了高中，是年纪里唯一个考上高中的学生，可能我的学校太差，还有我的刻苦，我一直都是年级第一的

高中的时候生病，考试成绩577分，那年第一年知分填志愿，我与一本无缘，我还是选择离开家乡，去了东北读书

 

整个过程我觉得我是快乐的，我一直都是成绩很棒，一切我也充满希望，大学毕业，也进入大厂，做起了一个程序媛

可能我的童年里，太多的与生活做斗争，不知道什么是感情，可能也因为自己的性格里有太多的不安全感，与谈了三年的恋爱告了别分了手，我一直都是在感情里慢半拍的人，分手了半年时间，回了趟大学，想起了点点滴滴，在大学的每一步我都在哭，在想想毕业后自己艰辛，我突然觉得我真的失去了我最爱的人，我是爱他的

 

然后在回京以后，我路上一直哭，坐地铁自己低着头一直哭的稀里哗啦，我告诉我自己，我真的失去了太多，我没有把握住那个对我那么好，那么单纯付出的人

 

然后毕业以后在伤痛里沉浸了3个月才像一个正常人一样，突然想开了好多，但是持续了3年，我也没再去真正的去谈恋爱

自己一直没有走出来，在毕业后的第三年，我觉得我应该走出来了，遇到了公司的同事，他傻乎乎，对人很真诚，对我也足够的忍耐，一起学习，一起玩，最后商量一起来杭州，中间有很多的矛盾，来了杭州才发现，他这个人平时看着足够的忍耐，却脾气爆发的时候像是爆炸，每次都把我炸的自己蹲在地上哭，没有想象的杭州生活的美好，而是各种的矛盾，来了快一年，7个月都在争吵，他也不断的离家出走，最后两者都很受伤，以分手收场

 

我再看看现在的我自己，老了好多，颓废了好多，觉得自己很惨，怎么就跟他来了这里，没有一个朋友和亲人

我再看看我的经历，是不是我真的没有爱的能力，28岁的我，被这段感情折磨的已经没有了爱的动力，自己一个人的杭州，没有一点的生机和活力

在看一直奋斗自己，一直过不了感情这个砍，看到了世界的残酷，人性的恶毒，并不是每个人都善良，对自己好才是王道

 

我不知道自己何时才能走出来，将近30岁的年级，看着别人都走进了婚姻的殿堂，而我在这里还在舔着伤口

我一直在想活着的意义，婚姻的本质，是不是自己一直都错了，还是注定要一辈子孤独终老

此时的自己已经哭的一塌糊涂，毕业的时候班长叮嘱我说，敏敏，你很单纯，心软，在社会上我好怕你被骗，你以后小心点

我终于知道为什么班长叮嘱我了，可能我真的是很单纯，看事情没那么复杂，可以很快乐的生活着，但是现在的自己，好难受

 

突然觉得自己长大了，又突然觉得自己没了未来

 

杭州一个人的城市，不是太容易的，自己也老了吧，不再想着交友，认识新的人，我好想回到去年，甚至大学的时候，我起码是快乐的，更想回到高中的时候，那时候的我不知道感情是这样子有如此大的杀伤力的

 

生活放眼望去，似乎什么都到头了，甚至恐惧未来的自己