并发

并发

高并发的解决方案：服务降级，限流，熔断。

Hystrix服务保护框架

服务降级，限流，熔断。

1. 案例：rpc远程调用的过程中，怎么防止服务雪崩效应。面试官可能问，再微服务中怎么保护服务？直接答使用hystrix去保护服务。
2. Hystrix是一个微服务中关于服务保护，在分布式中能够实现对服务一个容错的框架，减少服务与服务间的依赖关系(也就是你的服务挂了，不影响我的服务的意思)，防止服务雪崩效应。容错的概念：服务在发生不可用的时候，出错之后的预备处理方案。
3. 使用hystrix解决服务隔离，防止服务雪崩效应的w问题，保护服务。最终以实现服务的降级，限流，熔断机制。其实防止雪崩效应和互联网安全架构ddos有关联的。
4. 服务雪崩效应：当一个服务突然受到高并发的请求，tomcat服务器承受不了情况下，产生服务的堆积，可能导致其他的服务的不可用，其他服务一直等待，用户体验不好，我们可以使用服务降级，直接走fedback方法里面去，这样用户的体验就会好点。
5. 如果项目中没有进行雪崩效应的解决的情况下，恶意攻击， 使用测试工具(jmeter工具，进行多线程模拟多个请求)进行海量请求一个接口，导致其他的服务接口不可用，一致在转圈，瘫痪了。 所以用到服务降级，限流，熔断，解决服务雪崩效应。

hystrix这个是在什么场景下产生的？

1. 产生的背景：微服务高并发的场景
2. 举例场景：Hystrix针对微服务的保护的框架，因为是微服务，所以涉及到服务之间的RPC远程调用。假设订单服务和会员服务实现rpc调用。RPC远程调用底层使用的是什么技术通讯的，使用的http协议restful底层可以httpclient实现RPC远程通讯。
3. 思考一下：如果现在大量的请求访问订单orderindex服务(消费者)，orderindex服务调用会员memberIndex服务(生产者)。
4. 假设memberIndex服务现在响应时间大概要1.5秒，这里订单服务，会员服务都会出现服务雪崩效应，为什么是两个呢？而不是订单服务一个呢？这是因为我们之间的通讯是使用的是http协议的同步通讯的，所以会员服务等待，同时也会导致订单服务的等待，因为会员服务需要响应回去给订单服务。
5. 如果在微服务中，没有处理好服务的雪崩的问题，那么就可能导致一串连的依赖关系服务产生等待。这是一个严重的问题啊；
6. tomcat底层使用的是：http+线程池，默认情况下，只有一个线程池，一个线程池管理所有的线程请求，每个线程都是独立的请求。怎么查看orderIndex和findOrderIndex在同一个线程池中？使用当前线程名称=线程池名称+线程id组成的。Thread.currentThread().getname()=线程池名称+线程id组成。
   

作用：

• 服务保护，当服务产生的堆积的时候，对服务实现保护的功能。
• 服务的隔离,服务间接口互不影响。
  • 要了解服务的隔离，先了解服务的雪崩效应。
  • 为什么会产生服务的雪崩效应？
    • 假设设置tomcat的最大线程数是20，orderIndex和findOrderIndex在同一个线程池中，先21个请求全部访问的是orderIndex，后1个请求访问findOrderIndex，那么就没有线程去处理findOrderIndex了，这时候，就会出现根本没有线程去处理findOrderIndex的请求了，这时候就会出现findOrderIndex服务的雪崩效应了。
    • 简单点来说就是：服务雪崩效应产生服务堆积在同一个线程池中，因为在同一个线程池中，所有的请求全部都到了一个服务进行访问了，这时候会导致其他的服务没有线程接受请求访问，所以就会产生服务雪崩效应。
  • 服务的隔离，每个服务间接口互不影响，服务隔离有两种实现方式，线程池方式，计数器方式。
    • 线程池方式：每个服务接口都有自己的独立的线程池，管理运行当前自己的接口。缺点：CPU内存开销非常大，但是hystrix里面可以做优化，不用就回收。能够完全隔离，可以彻底解决服务雪崩效应的。确实是可以应用高并发解决雪崩效应的。
    • 计数器方式(很少用)：底层使用的是原子计数器，针对每个服务都设置一个独立的限制阈值， 就是说每个接口设置固定的访问请求次数(线程个数)，走缓存队列，缓存队列又满后，自己实现拒绝策略。当请求进来的时候，先判断计数器的数值，若超过设置的最大线程个数，则拒绝该请求，若不超过，这时候，计数器+1，请求返回成功后计数器-1。
• 服务的降级
  • 服务降级：当服务不可用（服务挂了，网络延迟，服务器端响应慢），客户端一直等待，应该返回一个错误信息给客户端，使用fallback方法返回当前服务不可用的提示。
  • 作用：目的是为了提高用户体验，防止服务雪崩效应。服务降级常与服务熔断一起使用的。if熔断then降级。
  • 业务场景：连接超时，网络延迟，服务器响应慢，
• 服务的熔断(保险丝)
  • 微服务中的服务熔断产生的原因就是服务发生的请求过多（属于高并发），设置一个限制，比如最多同时只能访问100个请求线程，超出的存放在缓存队列中，如果缓存队列中满了，直接拒绝访问，直接访问不了服务
  • 服务熔断最终实现什么效果，防止服务宕机，保护服务。
• 服务的限流
• 总结：
  • 【服务保护】，当服务产生堆积的时候，对服务实现保护功能。
  • 【服务隔离】：线程池隔离。每个服务接口都有自己独立的线程池，每个线程池互不影响。缺点CPU占用率高，所以不是所有的接口都需要采用线程池隔离，关键导致高并发的接口采用就可以了。
  • 【服务降级】：在高并发的情况下，防止用户一直等待，使用服务降级的方式，即返回一个友好提示给客户端，不会去处理请求，调用fallback本地方法，目的就是为了提高用户体验。
  • 【服务熔断】：目的就是为了保护服务，在高并发的情况下，如果请求达到了一定的极限(可以自己设置阈值)，如果流量超出了自己设置的阈值，自动开启保护服务的功能，使用服务降级的方式返回一个友好的提示。
  • 【堆积请求】：默认tomcat的最大的线程数是 150。产生第151个请求， 第151个请求会阻塞。大量请求正在等待，如果堆积请求过多，可能造成服务器瘫痪，所以用到服务保护。

【拓展】：RPC远程调用，和本地调用。

• 本地的调用：只能支持Java语言与Java语言开发的，使用虚拟机与虚拟机之间的通讯。
• RPC远程调用：一般是可以跨平台的采用的是http协议的，因为http协议底层使用的是socket技术，只要你的语言支持socket技术，就可以相互进行通讯。比如：Java开发语言开发的接口，http协议，然后别人可以使用c#语言可以调用http协议，开放平台接口采用HTTP协议，因为能支持更多的语言调用。

互联网高并发限流特技：

为什么要使用服务限流：

• 秒杀抢购，双11，服务安全(流量攻击，DDOS黑客的恶意攻击),雪崩效应，因为流量突然特别大。
• 限流的最终的目的就是为了保护服务。
• 限流算法
  1. 计数器方式(传统的计数器的缺点：临界问题，可能违背定义固定速率的原则)—滑动窗口计数器的方式。
  2. 令牌桶方式(Token):guava限流，令牌算法
  3. 漏桶方式。
  4. 应用层限流(Nginx)属于运维的配置。

1. 计数器方式：
   • 例子：限制每分钟内只能接受客户端的10个请求，否则直接拒绝访问服务，固定速率10R/M
     

• 滑动窗口：
  
• 滑动窗口的计数器的方式总结：
• 窗口是滑动的在0-9秒内没有请求，一个窗口有6个格子，窗口滑动，在50-60s有10个请求，在60-70秒又有10个请求，固定速率是10R/M.不符合固定速率，所以后面的60-70秒的请求会被舍弃掉。

2. 令牌桶的方式(Token):
   令牌桶分为两个动作，动作一：固定速率往桶中存入令牌，动作二：客户端如果想要访问请求，先从桶中获取token。
   

• 使用ratelimiter 实现令牌桶方式限流。

纯手打ratelimiter

1. 传统方式整合ratelimiter有很大的缺点：代码重复量大，而且本身不支持注解的方式。
2. 限流的代码可以放在网关里，但是这就相当于所有的服务接口都要实现限流(也可能用到排除法，但是这还是要告诉网关哪个接口要限流，哪个接口不需要限流)，这会导致维护性不是很强。
3. 正常的互联网公司，不是所有的接口都要实现限 流的，每个接口都要去拿令牌去访问，性能会更差的。一般限流主要针对的是大流量的请求的情况下的。