标签：负载均衡 toc 阻塞 长连接 java hash failover fast int
一.默认使用的是什么通信框架，还有别的选择吗?
默认也推荐使用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拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用 。
标签：负载均衡 toc 阻塞 长连接 java hash failover fast int
原文地址：https://www.cnblogs.com/ZJOE80/p/9893528.html
