关于Dubbo面试问题

一.默认使用的是什么通信框架,还有别的选择吗?

默认也推荐使用netty框架,还有mina。

二.服务调用是阻塞的吗?

默认是阻塞的,可以异步调用,没有返回值的可以这么做。

三.一般使用什么注册中心?还有别的选择吗?

推荐使用zookeeper注册中心,还有redis等不推荐。

四.默认使用什么序列化框架,你知道的还有哪些?

默认使用Hessian序列化,还有Duddo、FastJson、Java自带序列化。

五.服务提供者能实现失效踢出是什么原理?

服务失效踢出基于zookeeper的临时节点原理。

六.服务上线怎么不影响旧版本?

采用多版本开发,不影响旧版本。

七.如何解决服务调用链过长的问题?

可以结合zipkin实现分布式服务追踪。

八.说说核心的配置有哪些?

核心配置有

dubbo:service/

dubbo:reference/

dubbo:protocol/

dubbo:registry/

dubbo:application/

dubbo:provider/

dubbo:consumer/

dubbo:method/

九.dubbo推荐用什么协议?

默认使用dubbo协议。

十.同一个服务多个注册的情况下可以直连某一个服务吗?

可以直连,修改配置即可,也可以通过telnet直接某个服务。

十一.Dubbo集群容错怎么做?

读操作建议使用Failover失败自动切换,默认重试两次其他服务器。写操作建议使用Failfast快速失败,发一次调用失败就立即报错。

十二.为什么要用Dubbo进行数据传输?
一般服务端服务器比较少,消费端有可能会有很多项目或者工程会调用dubbo的接口,而且数据量传输较小且并发量比较高的情况下用dubbo效率会很高。

十三.Dubbo的负载均衡策略怎么配置?
在集群负载均衡时,Dubbo 提供了多种均衡策略,缺省为 random 随机调用。可以自行扩展负载均衡策略,参见:负载均衡扩展。负载均衡策略有( 随机、轮循、最少活跃调用数、一致性Hash)

Random LoadBalance

随机,按权重设置随机概率。

在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。

RoundRobin LoadBalance

轮循,按公约后的权重设置轮循比率。

存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。

LeastActive LoadBalance

最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。

使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

一致性 Hash,相同参数的请求总是发到同一提供者。

当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。

算法参见:http://en.wikipedia.org/wiki/Consistent_hashing

缺省只对第一个参数 Hash,如果要修改,请配置 <dubbo:parameter key="hash.arguments" value="0,1" />

缺省用 160 份虚拟节点,如果要修改,请配置 <dubbo:parameter key="hash.nodes" value="320" />

配置

服务端服务级别

<dubbo:service interface="..." loadbalance="roundrobin" />

客户端服务级别

<dubbo:reference interface="..." loadbalance="roundrobin" />

服务端方法级别

<dubbo:service interface="...">

    <dubbo:method name="..." loadbalance="roundrobin"/>

</dubbo:service>

客户端方法级别

<dubbo:reference interface="...">

    <dubbo:method name="..." loadbalance="roundrobin"/>

</dubbo:reference>

十四.dubbo连接注册中心和直连的区别。
在开发及测试环境下,经常需要绕过注册中心,只测试指定服务提供者,这时候可能需要点对点直连,

点对点直联方式,将以服务接口为单位,忽略注册中心的提供者列表,

服务注册中心,动态的注册和发现服务,使服务的位置透明,并通过在消费方获取服务提供方地址列表,实现软负载均衡和Failover,

注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。

服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。注册中心负责服务地址的注册与查找,相当于目录服务,

服务提供者和消费者只在启动时与注册中心交互,注册中心不转发请求,服务消费者向注册中心获取服务提供者地址列表,并根据负载算法直接调用提供者,注册中心,服务提供者,

服务消费者三者之间均为长连接,监控中心除外,注册中心通过长连接感知服务提供者的存在,服务提供者宕机,注册中心将立即推送事件通知消费者

注册中心和监控中心全部宕机,不影响已运行的提供者和消费者,消费者在本地缓存了提供者列表

注册中心和监控中心都是可选的,服务消费者可以直连服务提供者。

十五.Dubbo中zookeeper做注册中心,如果注册中心集群都挂掉,发布者和订阅者之间还能通信么?

可以的,启动dubbo时,消费者会从zk拉取注册的生产者的地址接口等数据,缓存在本地。每次调用时,按照本地存储的地址进行调用 。 

 

猜你喜欢

转载自www.cnblogs.com/ZJOE80/p/9893528.html