Java面试系列总结 ：Dubbo+Zookeeper

1. Dubbo的容错机制有哪些

Dubbo官网提出总共有六种容错策略

1）Failover Cluster 模式

失败自动切换，当出现失败，重试其它服务器。(默认)

2）Failfast Cluster

快速失败，只发起一次调用，失败立即报错。 通常用于非幂等性的写操作，比如新增记录。

3）Failsafe Cluster

失败安全，出现异常时，直接忽略。 通常用于写入审计日志等操作。

4）Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。 通常用于消息通知操作。

5）Forking Cluster

并行调用多个服务器，只要一个成功即返回。 通常用于实时性要求较高的读操作，但需要浪费更多服务资源。 可通过forks=”2”来设置最大并行数。

6）Broadcast Cluster

广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持) 通常用于通知所有提供者更新缓存或日志等本地资源信息。

总结： 在实际应用中查询语句容错策略建议使用默认Failover Cluster ，而增删改建议使用 Failfast Cluster 或者 使用 Failover Cluster（retries=”0”） 策略 防止出现数据 重复添加等等其它问题！建议在设计接口时候把查询接口方法单独做一个接口提供查询。

2. 使用dubbo遇到过哪些问题？

1）增加提供服务版本号和消费服务版本号

这个具体来说不算是一个问题,而是一种问题的解决方案,在我们的实际工作中会面临各种环境资源短缺的问题,也是很实际的问题,刚开始我们还可以提供一个服务进行相关的开发和测试,但是当有多个环境多个版本,多个任务的时候就不满足我们的需求,这时候我们可以通过给提供方增加版本的方式来区分.这样能够剩下很多的物理资源,同时为今后更换接口定义发布在线时，可不停机发布，使用版本号.

引用只会找相应版本的服务,例如：

<dubbo:service interface="com.xxx.XxxService" ref="xxxService"  version="1.0" /> 
<dubbo:reference id="xxxService" interface="com.xxx.XxxService"  version="1.0" /> 

2）dubbo reference注解问题

@Reference 只能在 springbean 实例对应的当前类中使用，暂时无法在父类使用；如果确实要在父类声明一个引用，可通过配置文件配置dubbo:reference，然后在需要引用的地方跟引用springbean一样就可以了.

3）出现 RpcException: No provider available for remote service异常，表示没有可用的服务提供者

（1） 检查连接的注册中心是否正确
（2）到注册中心查看相应的服务提供者是否存在
（3） 检查服务提供者是否正常运行
（4） 服务提供者没挂，但在注册中心里看不到

首先，确认服务提供者是否连接了正确的注册中心，不只是检查配置中的注册中心地址，而且要检查实际的网络连接。

其次，看服务提供者是否非常繁忙，比如压力测试，以至于没有CPU片段向注册中心发送心跳，这种情况，减小压力，将自动恢复。

3. Dubbo的连接方式有哪些？

Dubbo的客户端和服务端有三种连接方式，分别是：广播，直连和使用zookeeper注册中心

4. Dubbo 广播

这种方式是dubbo官方入门程序所使用的连接方式，但是这种方式有很多问题。在企业开发中，不使用广播的方式。

taotao-manager服务端配置：

 <!-- applicationContext-service.xml 文件中 --> 
 <!-- 提供方应用信息，用于计算机依赖关系  --> 
 <dubbo:application name="taotao-manager-service" />
 <!-- 使用 multicast 广播暴露服务地址  --> 
 <dubbo:registry address="multicast://224.5.6.7:1234" /> 
 <!--  使用 dubbo 协议在 20880 协议暴露服务 --> 
 <dubbo:protocol name="dubbo" port="20880" /> 
 <!-- 声明需要暴露的服务接口 --> 
 <dubbo:service interface="com.taotao.manager.service.TestService" ref="testServiceImpl" /> 

客户端配置taotao-manager-web的配置如下：

 <!--springMVC.xml 文件中 --> 
 <!-- 配置 dubbo 服务 --> 
 <dubbp:application name="taotao-manager-web" /> 
 <!-- 使用 multicast 广播暴露服务地址  --> 
 <dubbo:registry address="multicast://224.5.6.7:1234" /> 
 <!-- 声明要调用的服务 timeout 是设置连接超时最长时间，如果不设置，默认超时时间为 3 秒 --> 
 <dubbo:service interface="com.taotao.manager.service.TestService" id="testService" timeout="10000000" /> 

5. Dubbo 直连

这种方式在企业中一般在开发中环境中使用，但是生产环境很少使用，因为服务是直接调用，没有使用注册中心，很难对服务进行管理。Dubbo直连，首先要取消广播，然后客户端直接到指定需要的服务的url获取服务即可。

服务端配置：taotao-manager的修改如下，取消广播，注册中心地址为N/A

 <!-- applicationContext-service.xml 文件中 --> 
 <!-- 提供方应用信息，用于计算机依赖关系  --> 
 <dubbo:application name="taotao-manager-service" /> 
 <!--  <dubbo:registry address="multicast://224.5.6.7:1234" />  --> 
 <!-- 使用 multicast 广播暴露服务地址  --> 
 <dubbo:registry address="N/A" /> 
 <!--  使用 dubbo 协议在 20880 协议暴露服务 --> 
 <dubbo:protocol name="dubbo" port="20880" /> 
 <!-- 声明需要暴露的服务接口 --> 
 <dubbo:service interface="com.taotao.manager.service.TestService" ref="testServiceImpl" /> 

客户端配置：taotao-manager-web配置如下，取消广播，从指定的url中获取服务

 <!--springMVC.xml 文件中 --> 
 <!-- 配置 dubbo 服务 --> 
 <dubbp:application name="taotao-manager-web" /> 
 <!-- 使用 multicast 广播暴露服务地址  --> 
 <!-- <dubbo:registry address="multicast://224.5.6.7:1234" />  --> 
 <!-- 声明要调用的服务 timeout 是设置连接超时最长时间，如果不设置，默认超时时间为 3 秒 --> 
 <dubbo:service interface="com.taotao.manager.service.TestService" id="testService" timeout="10000000" /> 

6. zookeeper 注册中心

Dubbo注册中心和广播注册中心配置类似，不过需要指定注册中心类型和注册中心地址，这个时候就不是把服务信息进行广播了，而是告诉给注册中心进行管理，这个时候我们就需要有一个注册中心。

官方推荐使用zookeeper作为注册中心。

7. Zookeeper介绍

zookeeper在dubbo所处的位置：

1）Provider: 暴露服务的服务提供方。
2）Consumer: 调用远程服务的服务消费方。
3）Registry: 服务注册与发现的注册中心。
4）Monitor: 统计服务的调用次调和调用时间的监控中心。
5）Container: 服务运行容器。

调用关系说明：
1）服务容器负责启动，加载，运行服务提供者。
2）服务提供者在启动时，向注册中心注册自己提供的服务。
3）服务消费者在启动时，向注册中心订阅自己所需的服务。
4）注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
5）服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
6）服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

8. 简单介绍一下zookeeper以及zookeeper的原理。

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

ZooKeeper 的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、 功能稳定的系统提供给用户。

ZooKeeper 包含一个简单的原语集， 提供 Java 和 C 的接口。

ZooKeeper 代码版本中，提供了分布式独享锁、选举、队列的接口，代码在 zookeeper-3.4.3\src\recipes。其中分布锁和队列有 Java 和 C 两个版本，选举只有 Java 版本。

原理：

ZooKeeper 是以 Fast Paxos 算法为基础的，Paxos 算法存在活锁的问题，即当有多个 proposer 交错提交时，有可能互相排斥导致没有一个 proposer 能提交成功，而 Fast Paxos 作了一些优化，通过选举产生一个 leader (领导者)，只有 leader 才能提交 proposer，具体 算法可见 Fast Paxos。因此，要想弄懂 ZooKeeper 首先得对 Fast Paxos 有所了解。

ZooKeeper 的基本运转流程:1、选举 Leader。2、同步数据。3、选举 Leader 过程中算法有很多，但要达到的选举标准是一致的。 4、Leader 要具有最高的执行 ID，类似 root 权限。 5、集群中大多数的机器得到响应并 follow 选出的 Leader。

9. Zookeeper和Eureka区别

1. 在Eureka中，如果有服务器宕掉，Eureka不会有像Zookeeper的选举leader的过程，客户端请求会自动切换新的Eureka的节点中，当宕掉的服务器重新恢复后，Eureka会再次回调管理中。
2. Eureka服务节点在短时间里丢失了大量的心跳连接，Eureka节点会进入”自我保护模式“同时保留”好数据“与”坏数据。
   ZooKeeper下所有节点不可能保证任何时候都能缓存所有的服务注册信息
3. zookeeper是保证cp的一致性
   Eureka是保证ap的可用性

注意	CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性）

10. SpringCloud和Dubbo区别

Dubbo	SpringCloud
二进制传输的，基于saop协议，rpc通信的	HTTP 协议的 REST API
Dubbo只是实现了服务治理	Spring Cloud下面有17个子项目，覆盖了方方面面
dubbo的开发难度较大，dubbo的jar包依赖问题很多大型工程无法解决	接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级
dubbo的注册中心可以选择zk,redis等多种	springcloud的注册中心只能用eureka或者自研

11. Zookeeper集群配置

把zookeeper加入到环境变量，修改之后配置文件zoo.cfg
一致性协调(Coordination)服务，主要有两大功能：统一配置管理和集群负载均衡，

Zookeeper会对通过选举机制，选举一个主节点作为管理者。选举一般都是奇数台，否则会选举失败。并且集群中，有半数以上宕机，则会认为整个集群挂掉。

欢迎关注作者的公众号《Java编程生活》，每日记载Java程序猿工作中遇到的问题