总结
就写到这了,也算是给这段时间的面试做一个总结,查漏补缺,祝自己好运吧,也希望正在求职或者打算跳槽的 程序员看到这个文章能有一点点帮助或收获,我就心满意足了。多思考,多问为什么。希望小伙伴们早点收到满意的offer! 越努力越幸运!
金九银十已经过了,就目前国内的面试模式来讲,在面试前积极的准备面试,复习整个 Java 知识体系将变得非常重要,可以很负责任的说一句,复习准备的是否充分,将直接影响你入职的成功率。但很多小伙伴却苦于没有合适的资料来回顾整个 Java 知识体系,或者有的小伙伴可能都不知道该从哪里开始复习。我偶然得到一份整理的资料,不论是从整个 Java 知识体系,还是从面试的角度来看,都是一份含技术量很高的资料。
ILeastActive LoadBalance
最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。使慢的提供者收到更少请求,因为越慢的提供者的
调用前后计数差会越大。
I ConsistentHash LoadBalance
一致性Hash,相同参数的请求总是发到同-提供者。当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。缺省只对第一个参数Hash,如果要修改,请配置
<dubbo: pa rameter key=“hash. arguments” value=“0,1” />
缺省用160份虚拟节点,如果要修改,请配置
<dubbo: pa rameter key=“hash. nodes” va lue=“320” />
Dubbo通过Token令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo 还提供服务黑白名单,来控制服务所允许的调用方。
在开发及测试环境下,经常需要绕过注册中心,只测试指定服务提供者,这时候可能需要点对点直连,点对点直联方式,将以服务接口为单位,忽略注册中心的提供者列表,
| Failsafe Cluster
失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。[AppleScript]纯文本查看复制代码?
服务注册中心,动态的注册和发现服务,使服务的位置透明,并通过在消费方获取服务提供方地址列表,实现软负载均衡和Failover,注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和消费者只在启动时与注册中心交互,注册中心不转发请求,服务消费者向注册中心获取服务提供者地址列表,并根据负载算法直接调用提供者,注册中心,服务提供者,服务消费者三者之间均为长连接,监控中心除外,注册中心通过长连接感知服务提供者的存在,服务提供者宕机,注册中心将立即推送事件通知消费者注册中心和监控中心全部宕机,不影响已运行的提供者和消费者,消费者在本地缓存了提供者列表注册中心和监控中心都是可选的,服务消费者可以直连服务提供者。
- dubbo服务集群配置(集群容错模式)
在集群调用失败时,Dubbo 提供了多种容错方案,缺省为failover重试。可以自行扩展集群容错策略I Failover Cluster默认)
失败自动切换,当出现失败,重试其它服务器。(缺省)通常用于读操作,但重试会带来更长延迟。可通过retries="2"来设置重试次数(不含第一次)。
<dubbo:service retries=“2” cluster=“failover”/>
或:
<dubbo: reference retries=“2” cluster-“failover”/>
cluster="failove r"可以不用写,因为默认就是failover
| Failfast Cluster
快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,
比如新增记录。
dubbo :service cluster=“failfast” />
或:
<dubbo: reference cluster=“failfast” />
cluster=“failfast"和把cluster=” failover"、retries=“0”
是一样的效果,retries="0"就是不重试
I Failsafe Cluster
失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。
<dubbo:service cluster=“failsafe” />
或:
<dubbo: reference cluster=“failsafe” />
| Failback Cluster
失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
<dubbo: service cluster=" failback" />
或:
<dubbo: reference clus ter=" failback" />
I Forking Cluster
并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过forks= “2"来设置最大并行数。
<dubbo: service cluster=" forking" forks=“2” />
或:
<dubbo: reference cluster=" forking" forks=“2”/>
|配置
服务端服务级别
<dubbo: service interface=“…” loadbalance=" roundrobin" />
客户端服务级别
<dubbo: reference interface=“. .。” Loadba lance=" round rob in"
服务端方法级别
<dubbo:service interface=“… .”> <dubbo meth
od name=“… .” Loadbalance
客户端方法级别
<dubbo: reference interface=“… .”> <dubbo : method name=“. .。”Loadba lance=”
-
dubbo 通信协议dubbo协议为什么要消费者比提供者个数多:因dubbo协议采用单- -长连接,假设网络为千兆网卡(1024Mbit= 128MByte),根据测试经验数据每条连接最多只能压满7MByte(不同的环境可能不一样,供参考),理论上1个服务提供者需要20个服务消费者才能压满网卡。
-
dubbo 通信协议dubbo协议为什么不能传大包:因dubbo协议采用单-长连接,如果每次请求的数据包大小为500KByte,假设网络为千兆网卡(1024Mbit= 128MByte),每条连接最大7MByte(不同的环境可能不一样,供参考),单个服务提供者的TPS(每秒处理事务数)最大为:128MByte / 500KByte= 262。单个消费者调用单个服务提供者的TPS(每秒处理事务数)最大为:7MByte/ 500KByte= 14。如果能接受,可以考虑使用,否则网络将成为瓶颈。
-
dubbo 通信协议dubbo协议为什么采用异步单一长连接:因为服务的现状大都是服务提供者少,通常只有几台机器,而服务的消费者多,可能整个网站都在访问该服务,比如Morgan的提供者只有6台提供者,却有上百台消费者,每天有1.5亿次调用,如果采用常规的hessian服务,服务提供者很容易就被压跨,通过单- -连接,保证单-消费者不会压死提供者,长连接, 减少连接握手验证等,并使用异步 I0,复用线程池,防止C10K问题。
最后
我还为大家准备了一套体系化的架构师学习资料包以及BAT面试资料,供大家参考及学习
已经将知识体系整理好(源码,笔记,PPT,学习视频)
q-1715772217557)]
[外链图片转存中…(img-Z3Q0RUei-1715772217558)]