关于服务的降级和熔断

Question

老师我想问一下，学生没有遇到过真正的高并发场景所以有些疑问，首先有可能我的理解就有问题。tomcat的默认并发量是150，在默认的前提下，是不是说如果有10000个并发过来剩下的就会堵塞等这150个处理完了才能处理剩下的，我在网上学习了用ratelimited进行降级的方案，但是按照这个理解，如果并发一万个线程，那么9000多个线程会堵塞住压根进不来，而用ratelimited去降级的实际是那150个进来的，这样处理的时间还是很长呀？对用户的反馈还是不好。并且我mysql同时接受150个并发是没问题的，java处理150个线程也是没问题的，降级的意义何在？

Answer 1

Jimin 2018-09-04 23:33:26

你好，这个理解确实有点问题，把服务降级想的稍微有点狭隘了。先说你这个场景，假设你只能处理同时处理150个线程，你可以让一部分线程阻塞在哪里，却不能让10000-150个线程阻塞在哪里，首先是用户体验肯定不好，而且很多等待都是白等，因为我们请求接口时本身也有超时时间的，一直等下去是没意义的，还有，线程本身等待也是对cpu和内存有消耗，本来就处理不来的，这样就更不好了。

服务降级和熔断除了能让某些接口尽快返回，更多的保护系统。跳出你这个场景来举例子说说

比如系统需要请求的第三方接口很明显挂了，我们请求已经没任何意义了，这样完全可以不再去调用了，不去浪费宝贵的连接，不去浪费宝贵的连接-处理-返回这段时间，取而代之降级返回一个默认的返回，提前和调用者沟通好，某些返回代表第三方出现问题了，这样一来就可以很平滑的绕过去了，而不是悲观的等待第三方接口恢复。

再比如我们系统数据库都有主从之分，很多请求都可以访问从库获取数据，这样对数据库压力会很小。但是可能会遇到主从延迟同步的时候，这时临时降级为查主库就可以很容易的绕过这个问题了，在开发时注意一下就可以提前预防这个问题了，否则就只能改代码发布处理了。

再举个例子，某个处理总出异常，但又不是特别核心。比如地图上计算距离，有时曲线计算时间太长，导致超时了，这时就可以简单点计算个直线距离乘以个比例进行返回（许多系统实际就是这样做的）。

服务降级和熔断本质上是给系统提供了多种选择，当系统核心希望的处理流程出现问题时，可以换一种可以接受的方式去处理，不至于明知道是错的，还一直继续做。对我们而言，也是预防系统出现特殊问题时，对系统尽可能的保护好。

• 提问者 qq_loneliness_0 #1

  谢谢老师的回答让我对这个认识更加深了，但是老师我可能没表达清楚。我的意思是这个150的堵塞不是我想要做的，假设我用的tomcat服务器，我今天在网上查它默认只支持150的并发，那么这个时候10000个请求进来是不是说tomcat就以150为单位，给我做了一个队列来访问我的接口，那么我现在做降级实际上是在为150做降级，而9000多的线程被tomcat堵塞住了，我没办法控制？？我对tomcat也不是很熟 所以，不知道对不对。就算我做了降级，但是实际上线程是分成150一批分批进我的接口的。那么用户的反应速度就会超级慢。。并没有很好的处理好这个问题？

• Jimin 回复 提问者 qq_loneliness_0 #2

  一台服务器明显处理不过来，怎么调整都不行了，从根本上说，这时需要加机器了。

• 提问者 qq_loneliness_0 回复 Jimin #3

  tomcat只能处理150-250的并发量，对于每一台机器而言，我们的限流降级，其实只是针对的150-250的并发量？？？而我们处理超过这个并发量的情况只能通过集群来处理可以这么理解吗

点开查看后面2条评论