结尾
这不止是一份面试清单,更是一种”被期望的责任“,因为有无数个待面试者,希望从这篇文章中,找出通往期望公司的”钥匙“,所以上面每道选题都是结合我自身的经验于千万个面试题中经过艰辛的两周,一个题一个题筛选出来再次对好答案和格式做出来的,面试的答案也是再三斟酌,深怕误人子弟是小,影响他人仕途才是大过,也希望您能把这篇文章分享给更多的朋友,让他帮助更多的人,帮助他人,快乐自己,最后,感谢您的阅读。
由于细节内容实在太多啦,在这里我花了两周的时间把这些答案整理成一份文档了,在这里只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
===========================================================================
-
对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护
-
在复杂的分布式系统中,阻止某一个依赖服务的故障在整个系统中蔓延,服务A->服务B->服务C,服务C故障了,服务B也故障了,服务A故障了,整套分布式系统全部故障,整体宕机
-
提供fail-fast(快速失败)和快速恢复的支持
-
提供fallback优雅降级的支持
-
支持近实时的监控、报警以及运维操作5 Hystrix要解决的问题在复杂的分布式系统架构中,每个服务都有很多的依赖服务,而每个依赖服务都可能会故障
如果服务没有和自己的依赖服务进行隔离,那么可能某一个依赖服务的故障就会拖垮当前这个服务
=================================================================
某个服务有30个依赖服务,每个依赖服务的可用性非常高,已经达到了99.99%的高可用性
那么该服务的可用性就是99.99%的30次方,也就是99.7%的可用性
99.7%的可用性就意味着3%的请求可能会失败,因为3%的时间内系统可能出现了故障不可用了。
对于1亿次访问来说,3%的请求失败,也就意味着300万次请求会失败,也意味着每个月有2个小时的时间系统是不可用的。在真实生产环境中,可能更加糟糕。
上面也就是说,即使你每个依赖服务都是99.99%高可用性,但是一旦你有几十个依赖服务,还是会导致你每个月都有几个小时是不可用的。
================================================================================
-
阻止任何一个依赖服务耗尽所有的资源,比如tomcat中的所有线程资源
-
避免请求排队和积压,采用限流和fail fast来控制故障
-
提供fallback降级机制来应对故障
-
使用资源隔离技术,比如bulkhead(舱壁隔离技术),swimlane(泳道技术),circuit breaker(短路技术),来限制任何一个依赖服务的故障的影响
-
通过近实时的统计/监控/报警功能,来提高故障发现的速度
-
通过近实时的属性和配置热修改功能,来提高故障处理和恢复的速度
-
保护依赖服务调用的所有故障情况,而不仅仅只是网络故障情况
调用这个依赖服务的时候,client调用包有bug,阻塞,等等,依赖服务的各种各样的调用的故障,都可以处理
==============================================================================
- 通过HystrixCommand或者HystrixObservableCommand来封装对外部依赖的访问请求,这个访问请求一般会运行在独立的线程中,资源隔离
总结
这个月马上就又要过去了,还在找工作的小伙伴要做好准备了,小编整理了大厂java程序员面试涉及到的绝大部分面试题及答案,希望能帮助到大家
5e56a57acb)收录**