先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
如果你需要这些资料，可以添加V获取：vip1024b （备注Java）
正文
引入hystrix
- 虽然包里面包含了hystrix 。我们还是引入对应的start开启相关配置吧。这里其实就是在openfeign专题中的例子。在那个专题我们提供了PaymentServiceFallbackImpl、PaymentServiceFallbackFactoryImpl两个类作为备选方案。不过当时我们只需指出openfeign支持设置两种方式的备选方案。今天我们
org.springframework.cloudspring-cloud-starter-netflix-hystrix演示下传统企业没有备选方案的情况会发生什么灾难。
openfeign 使用
接口调用
接口测试
-
首先我们对payment#createByOrder接口进行测试。查看下响应情况接口响应情况
-
在测试payment#getTimeout/id方法。postman接口调用jmeter压测tomcat最大线程数测试
-
spring中默认的tomcat的最大线程数是200.为了保护我们辛苦的笔记本。这里我们将线程数设置小点。这样我们更容易复现线程被打满的情况。线程满了就会影响到payment#createByOrder接口。
-
现在我们用jmeter来压测payment#getTimeOut/id这个接口。一位需要4S等待会造成资源消耗殆尽问题。这个时候我们的payment#createByOrder也会被阻塞。
-
上面我们压测的是payment的原生接口。如果压测的是order模块。如果没有在openfeign中配置fallback。那么order服务就会因为payment#getTimeOut/id接口并发导致线程满了从而导致order模块响应缓慢。这就是雪崩效应。下面我们从两个方面来解决雪崩的发生。
业务隔离
====
-
上面的场景发生是因为payment#createByOrder 和payment#getTimeOut/id同属于payment服务。一个payment服务实际上就是一个Tomcat服务。同一个tomcat服务是有一个线程池的。每次请求落到该tomcat 服务里就会去线程池中申请线程。获取到线程了才能由线程来处理请求的业务。就是因为tomcat内共享线程池。所以当payment#getTimeOut/id并发上来后就会抢空线程池。导致别的借口甚至是毫不相关的接口都没有资源可以申请。只能干巴巴地等待资源的释放。
-
这就好比上班高峰期乘坐电梯因为某一个公司集中上班导致一段时间电梯全部被使用了。这时候国家领导过来也没办法上电梯。
-
我们也知道这种情况很好解决。每个园区都会有专用电梯供特殊使用。
-
我们解决上述问题也是同样的思路。进行隔离。不同的接口有不同的线程池。这样就不会造成雪崩。
线程隔离
====
线程隔离
-
还记得我们上面为了演示并发将order模块的最大线程数设置为10.这里我们通过测试工具调用下order/getpayment/1这个接口看看日志打印情况接口日志
-
我们接口调用的地方将当前线程打印出来。我们可以看到一直都是那10个线程在来回的使用。这也是上面为什么会造成雪崩现象。
@HystrixCommand(
groupKey = “order-service-getPaymentInfo”,
commandKey = “getPaymentInfo”,
threadPoolKey = “orderServicePaymentInfo”,
commandProperties = {
@HystrixProperty(name = “execution.isolation.thread.timeoutInMilliseconds”,value = “1000”)
},
threadPoolProperties = {
@HystrixProperty(name = “coreSize” ,value = “6”),
@HystrixProperty(name = “maxQueueSize”,value = “100”),
@HystrixProperty(name = “keepAliveTimeMinutes”,value = “2”),
@HystrixProperty(name = “queueSizeRejectionThreshold”,value = “100”)
},
fallbackMethod = “getPaymentInfoFallback”
)
@RequestMapping(value = “/getpayment/{id}”,method = RequestMethod.GET)
public ResultInfo getPaymentInfo(@PathVariable(“id”) Long id) {
log.info(Thread.currentThread().getName());
return restTemplate.getForObject(PAYMENT_URL+“/payment/get/”+id, ResultInfo.class);
}
public ResultInfo getPaymentInfoFallback(@PathVariable(“id”) Long id) {
log.info(“已经进入备选方案了，下面交由自由线程执行”+Thread.currentThread().getName());
return new ResultInfo();
}
@HystrixCommand(
groupKey = “order-service-getpaymentTimeout”,
commandKey = “getpaymentTimeout”,
threadPoolKey = “orderServicegetpaymentTimeout”,
commandProperties = {
@HystrixProperty(name = “execution.isolation.thread.timeoutInMilliseconds”,value = “10000”)
},
threadPoolProperties = {
@HystrixProperty(name = “coreSize” ,value = “3”),
@HystrixProperty(name = “maxQueueSize”,value = “100”),
@HystrixProperty(name = “keepAliveTimeMinutes”,value = “2”),
@HystrixProperty(name = “queueSizeRejectionThreshold”,value = “100”)
}
)
@RequestMapping(value = “/getpaymentTimeout/{id}”,method = RequestMethod.GET)
public ResultInfo getpaymentTimeout(@PathVariable(“id”) Long id) {
log.info(Thread.currentThread().getName());
return orderPaymentService.getTimeOut(id);
}
- 这里演示效果不好展示，我就直接展示数据吧。
-
如果我们将hystrix加载payment原生服务就不会出现上面第三条情况。为什么我会放在order上就是想让大家看看雪崩的场景。在并发50的时候因为payment设置的最大线程也是10，它本身也是有吞吐量的。在order#getpyament/id接口虽然在order模块因为hystrix线程隔离有自己的线程运行，但是因为原生服务不给力导致自己调用超时从而影响运行的效果。这样演示也是为了后续引出fallback解决雪崩的一次场景模拟吧。
-
我们可以在payment服务中通过hystrix设置fallback。保证payment服务低延迟从而保证order模块不会因为payment自己缓慢导致order#getpayment这种正常接口异常。
-
还有一点虽然通过hystrix进行线程隔离了。但是我们在运行其他接口时响应时间也会稍长点。因为CPU在进行线程切换的时候是有开销的。这一点也是痛点。我们并不能随心所欲地进行线程隔离的。这就引出我们的信号量隔离了。
信号量隔离
=====
- 关于信号量隔离这里也就不演示了。演示的意义不是很大
@HystrixCommand(
commandProperties = {
@HystrixProperty(name = “execution.isolation.thread.timeoutInMilliseconds”,value = “1000”),
@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_STRATEGY,value = “SEMAPHORE”),
@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_SEMAPHORE_MAX_CONCURRENT_REQUESTS,value = “6”)
},
fallbackMethod = “getPaymentInfoFallback”
)
-
我们如上配置表示信号量最大为6 。表示并发6之后就会进行等待。等待超时时间为1s。
-
除了线程隔离、信号量隔离等隔离手段我们可以通过请求合并、接口数据缓存等手段加强稳定性。
服务降级
====
触发条件
====
-
程序发生除HystrixBadRequestException异常。
-
服务调用超时
-
服务熔断
-
线程池、信号量不够
timeout
-
在上面我们的timeout接口。不管是线程隔离还是信号量隔离在条件满足的时候就会直接拒绝后续请求。这样太粗暴了。上面我们也提到了fallback。
-
还记的上面我们order50个并发的timeout的时候会导致getpayment接口异常，当时定位了是因为原生payment服务压力撑不住导致的。如果我们在payment上加入fallback就能保证在资源不足的时候也能快速响应。这样至少能保证order#getpayment方法的可用性。配置fallback
-
但是这种配置属于实验性配置。在真实生产中我们不可能在每个方法上配置fallback的。这样愚蠢至极。
-
hystrix除了在方法上特殊定制的fallback以外，还有一个全局的fallback。只需要在类上通过@DefaultProperties(defaultFallback = “globalFallback”)来实现全局的备选方案。一个方法满足触发降级的条件时如果该请求对应的HystrixCommand注解中没有配置fallback则使用所在类的全局fallback。如果全局也没有则抛出异常。
不足
==
-
虽然DefaultProperties 可以避免每个接口都配置fallback。但是这种的全局好像还不是全局的fallback。我们还是需要每个类上配置fallback。笔者查阅了资料好像也没有
-
但是在openfeign专题里我们说了openfeign结合hystrix实现的服务降级功能。还记的里面提到了一个FallbackFactory这个类吗。这个类可以理解成spring的BeanFactory。这个类是用来产生我们所需要的FallBack的。我们在这个工厂里可以生成一个通用类型的fallback的代理对象。代理对象可以根据代理方法的方法签名进行入参和出参。
-
这样我们可以在所有的openfeign地方配置这个工厂类。这样的话就避免的生成很多个fallback。美中不足的还是需要每个地方都指定一下。关于FallBackFactory感兴趣的可以下载源码查看或者进主页查看openfeign专题。
服务熔断
====
@HystrixCommand(
commandProperties = {
@HystrixProperty(name = “circuitBreaker.enabled”,value = “true”), //是否开启断路器
@HystrixProperty(name = “circuitBreaker.requestVolumeThreshold”,value = “10”), //请求次数
@HystrixProperty(name = “circuitBreaker.sleepWindowInMilliseconds”,value = “10000”), //时间范围
@HystrixProperty(name = “circuitBreaker.errorThresholdPercentage”,value = “60”), //失败率达到多少后跳闸
},
fallbackMethod = “getInfoFallback”
)
@RequestMapping(value = “/get”, method = RequestMethod.GET)
public ResultInfo get(@RequestParam Long id) {
if (id < 0) {
int i = 1 / 0;
}
log.info(Thread.currentThread().getName());
return orderPaymentService.get(id);
}
public ResultInfo getInfoFallback(@RequestParam Long id) {
return new ResultInfo();
}
-
首先我们通过circuitBreaker.enabled=true开启熔断器
-
circuitBreaker.requestVolumeThreshold设置统计请求次数
-
circuitBreaker.sleepWindowInMilliseconds 设置时间滑动单位 ， 在触发熔断后多久进行尝试开放，及俗称的半开状态
-
circuitBreaker.errorThresholdPercentage 设置触发熔断开关的临界条件
-
上面的配置如果最近的10次请求错误率达到60% ，则触发熔断降级 ， 在10S内都处于熔断状态服务进行降级。10S后半开尝试获取服务最新状态
-
下面我们通过jmeter进行接口http://localhost/order/get?id=-1进行20次测试。虽然这20次无一例额外都会报错。但是我们会发现一开始报错是因为我们代码里的错误。后面的错误就是hystrix熔断的错误了。一开始是by zero 错误、后面就是short-circuited and fallback failed 熔断错误了
jmeter压测
- 正常我们在hystrix中会配置fallback ， 关于fallback两种方式我们上面降级章节已经实现了。这里是为了方便看到错误的不同特意放开了。
HystrixCommand中配置的参数
- 在HystrixCommand中配置的参数基本都是在HystrixPropertiesManager对象中。我们可以看到关于熔断器的配置有6个参数。基本就是我们上面的四个配置
服务限流
====
- 服务降级我们上面提到的两种隔离就是实现限流的策略。
请求合并
====
-
除了熔断、降级、限流以外hystrix还为我们提供了请求合并。顾名思义就是将多个请求合并成一个请求已达到降低并发的问题。
-
比如说我们order有个接个是查询当个订单信息order/getId?id=1 突然有一万个请求过来。为了缓解压力我们集中一下请求每100个请求调用一次order/getIds?ids=xxxxx 。这样我们最终到payment模块则是10000/100=100个请求。下面我们通过代码配置实现下请求合并。
HystrixCollapser
================
HystrixPropertiesManager
- 在Hystrix中所有的properties配置都会在HystrixPropertiesManager.java中。我们在里面可以找到Collapser只有两个相关的配置。分别表示最大请求数和统计时间单元。
@HystrixCollapser(
scope = com.netflix.hystrix.HystrixCollapser.Scope.GLOBAL,
batchMethod = “getIds”,
collapserProperties = {
@HystrixProperty(name = HystrixPropertiesManager.MAX_REQUESTS_IN_BATCH , value = “3”),
@HystrixProperty(name = HystrixPropertiesManager.TIMER_DELAY_IN_MILLISECONDS, value = “10”)
}
)
@RequestMapping(value = “/getId”, method = RequestMethod.GET)
public ResultInfo getId(@RequestParam Long id) {
if (id < 0) {
int i = 1 / 0;
}
log.info(Thread.currentThread().getName());
return null;
}
@HystrixCommand
public List getIds(List ids) {
System.out.println(ids.size()+“@@@@@@@@@”);
return orderPaymentService.getIds(ids);
}
- 上面我们配置了getId会走getIds请求，最多是10S三个请求会合并在一起。然后getIds有payment服务在分别去查询最终返回多个ResultInfo。
通过jemeter进行getId接口压测
-
我们通过jemeter进行getId接口压测，日志中ids的长度最大是3 。验证了我们上面getId接口的配置。这样就能保证在出现高并发的时候会进行接口合并降低TPS。
-
上面我们是通过请求方法注解进行接口合并处理。实际上内部hystrix是通过HystrixCommand
工作流程
====
Hystrix官网给出的流程图
-
官网给出的流程图示，并配备流程说明一共是9部。下面我们就翻译下。
-
①、创建HystrixCommand或者HystrixObservableCommand对象
-
HystrixCommand : 用在依赖单个服务上
-
HystrixObservableCommand : 用在依赖多个服务上
-
②、命令执行，hystrrixCommand 执行execute、queue ；hystrixObservableCommand执行observe、toObservable
知其然不知其所以然，大厂常问面试技术如何复习？
1、热门面试题及答案大全
面试前做足功夫，让你面试成功率提升一截，这里一份热门350道一线互联网常问面试题及答案助你拿offer
2、多线程、高并发、缓存入门到实战项目pdf书籍
3、文中提到面试题答案整理
4、Java核心知识面试宝典
覆盖了JVM 、JAVA集合、JAVA多线程并发、JAVA基础、Spring原理、微服务、Netty与RPC、网络、日志、Zookeeper、Kafka、RabbitMQ、Hbase、MongoDB 、Cassandra、设计模式、负载均衡、数据库、一致性算法 、JAVA算法、数据结构、算法、分布式缓存、Hadoop、Spark、Storm的大量技术点且讲解的非常深入
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
*
覆盖了JVM 、JAVA集合、JAVA多线程并发、JAVA基础、Spring原理、微服务、Netty与RPC、网络、日志、Zookeeper、Kafka、RabbitMQ、Hbase、MongoDB 、Cassandra、设计模式、负载均衡、数据库、一致性算法 、JAVA算法、数据结构、算法、分布式缓存、Hadoop、Spark、Storm的大量技术点且讲解的非常深入
[外链图片转存中…(img-mR7qp3kI-1713184447668)]
[外链图片转存中…(img-YCKJ8DZn-1713184447668)]
[外链图片转存中…(img-sHUlBn66-1713184447669)]
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-MMj1eEzQ-1713184447669)]
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
4402
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
