Java面试题之分布式/微服务篇

经济依旧不景气啊，如此大环境下Java还是这么卷，又是一年一次的金三银四。
兄弟们，你准备好了吗？冲冲冲！欧里给！

分布式/微服务相关面试题解

题一：CAP理论，BASE理论
题二：负载均衡算法、类型有哪些
- 算法
- 类型
- - [DNS 方式实现负载均衡](#DNS 方式实现负载均衡)
  - [硬件负载均衡：F5 和 A10](#硬件负载均衡：F5 和 A10)
  - [软件负载均衡（Nginx 、 HAproxy 、 LVS ）](#软件负载均衡（Nginx 、 HAproxy 、 LVS ）)
[题三：分布式架构下，Session 共享有什么方案？](#题三：分布式架构下，Session 共享有什么方案？)
题四：简述你对RPC、RMI的理解
题五：分布式id生成方案
- UUID
- 数据库自增序列
- Leaf-segment
- 基于redis、mongodb、zk等中间件生成
- 雪花算法
题六：分布式锁解决方案
- Zookeeper分布式锁
- Redis分布式锁
题七：分布式事务解决方案
题八：如何实现接口的幂等性？
[题九：简述ZAB 协议](#题九：简述ZAB 协议)
题十：zk的数据模型和节点类型？
题十一：简述zk的命名服务、配置管理、集群管理
[题十二：讲下Zookeeper watch机制](#题十二：讲下Zookeeper watch机制)
题十三：zk和eureka的区别？
[题十四：Spring Cloud和Dubbo的区别？](#题十四：Spring Cloud和Dubbo的区别？)
题十五：什么是Hystrix？简述实现机制
题十六：springcloud核心组件及其作用
[题十七：Dubbo 的整体架构设计及分层](#题十七：Dubbo 的整体架构设计及分层)

题一：CAP理论，BASE理论

Consistency (一致性)：

即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致。

对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。

从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。

Availability (可用性):

即服务一直可用，而且是正常响应时间。系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。

Partition Tolerance (分区容错性):

即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。

CP和AP：分区容错是必须保证的，当发生网络分区的时候，如果要继续服务，那么强一致性和可用性只能 2 选 1

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）

BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

基本可用：

响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。
软状态：数据同步允许一定的延迟
最终一致性：系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，不要求实时

题二：负载均衡算法、类型有哪些

算法

1、轮询法

将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

2、随机法

通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知，随着客户端调用服务端的次数增多，其实际效果越来越接近于平均分配调用量到后端的每一台服务器，也就是轮询的结果。

3、源地址哈希法

源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。

4、加权轮询法

不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请求；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。

5、加权随机法

与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。

6、最小连接数法

最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。

类型

DNS 方式实现负载均衡

硬件负载均衡：F5 和 A10

软件负载均衡（Nginx 、 HAproxy 、 LVS ）

区别：

Nginx ：七层负载均衡，支持 HTTP、E-mail 协议，同时也支持 4 层负载均衡；
HAproxy ：支持七层规则的，性能也很不错。OpenStack 默认使用的负载均衡软件就是HAproxy；
LVS ：运行在内核态，性能是软件负载均衡中最高的，严格来说工作在三层，所以更通用一些，适用各种应用服务。

题三：分布式架构下，Session 共享有什么方案？

1、采用无状态服务，抛弃session

2、存入cookie（有安全风险）

3、服务器之间进行 Session 同步，这样可以保证每个服务器上都有全部的 Session 信息，不过当服务器数量比较多的时候，同步是会有延迟甚至同步失败；

4、 IP 绑定策略使用 Nginx （或其他复杂均衡软硬件）中的 IP 绑定策略，同一个 IP 只能在指定的同一个机器访问，但是这样做失去了负载均衡的意义，当挂掉一台服务器的时候，会影响一批用户的使用，风险很大；

5、使用 Redis 存储把 Session 放到 Redis 中存储，虽然架构上变得复杂，并且需要多访问一次 Redis ，但是这种方案带来的好处也是很大的：

实现了 Session 共享；
可以水平扩展（增加 Redis 服务器）；
服务器重启 Session 不丢失（不过也要注意 Session 在 Redis 中的刷新/失效机制）；
不仅可以跨服务器 Session 共享，甚至可以跨平台（例如网页端和 APP 端）。

题四：简述你对RPC、RMI的理解

RPC：在本地调用远程的函数，远程过程调用，可以跨语言实现 httpClient

RMI：远程方法调用，java中用于实现RPC的一种机制，RPC的java版本，是J2EE的网络调用机制，跨JVM调用对象的方法，面向对象的思维方式

直接或间接实现接口 java.rmi.Remote 成为存在于服务器端的远程对象，供客户端访问并提供一定的服务

远程对象必须实现java.rmi.server.UniCastRemoteObject类，这样才能保证客户端访问获得远程对象

时，该远程对象将会把自身的一个拷贝以Socket的形式传输给客户端，此时客户端所获得的这个拷贝称

为"存根"，而服务器端本身已存在的远程对象则称之为"骨架"。其实此时的存根是客户端的一个代理，

用于与服务器端的通信，而骨架也可认为是服务器端的一个代理，用于接收客户端的请求之后调用远程

方法来响应客户端的请求。

java 复制代码

public interface IService extends Remote {
  String service(String content) throws RemoteException;
}
public class ServiceImpl extends UnicastRemoteObject implements IService {
  private String name;
  public ServiceImpl(String name) throws RemoteException {
    this.name = name;
 }
  @Override
  public String service(String content) {
    return "server >> " + content;
 }
 }
public class Server {
  public static void main(String[] args) {
    try {
      IService service02 = new ServiceImpl("service02");
      Context namingContext = new InitialContext();
      namingContext.rebind("rmi://127.0.0.1/service02", service02);
   } catch (Exception e) {
      e.printStackTrace();
   }
    System.out.println("000000！");
 }
}
public class Client {
  public static void main(String[] args) {
    String url = "rmi://127.0.0.1/";
    try {
      Context namingContext = new InitialContext();
      IService service02 = (IService) namingContext.lookup(url +
"service02");
      Class stubClass = service02.getClass();
      System.out.println(service02 + " is " + stubClass.getName());
      //com.sun.proxy.$Proxy0
     
      Class[] interfaces = stubClass.getInterfaces();
      for (Class c : interfaces) {
        System.out.println("implement" + c.getName() + " interface");
     }
      System.out.println(service02.service("hello"));
   } catch (Exception e) {
      e.printStackTrace();
   }
 }
}

题五：分布式id生成方案

UUID

1，当前日期和时间 ---->时间戳

2，时钟序列。 ---->计数器

3，全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。

优点：

代码简单，性能好（本地生成，没有网络消耗）

保证唯一（相对而言，重复概率极低可以忽略）

缺点：

每次生成的ID都是无序的，而且不是全数字，且无法保证趋势递增。

UUID生成的是字符串，字符串存储性能差，查询效率慢，写的时候由于不能产生顺序的append 操作，需要进行insert操作，导致频繁的页分裂，这种操作在记录占用空间比较大的情况下，性能下降比较大，还会增加读取磁盘次数

UUID长度过长，不适用于存储，耗费数据库性能。

ID无一定业务含义，可读性差。

有信息安全问题，有可能泄露mac地址

数据库自增序列

单机模式：

优点：

实现简单，依靠数据库即可，成本小。

ID数字化，单调自增，满足数据库存储和查询性能。

具有一定的业务可读性。（结合业务code）

缺点：

强依赖DB，存在单点问题，如果数据库宕机，则业务不可用。

DB生成ID性能有限，单点数据库压力大，无法扛高并发场景。

信息安全问题，比如暴露订单量，url查询改一下id查到别人的订单

数据库高可用：多主模式做负载，基于序列的起始值和步长设置，不同的初始值，相同的步长，步长大于节点数

优点：

解决了ID生成的单点问题，同时平衡了负载。

缺点：

系统扩容困难：系统定义好步长之后，增加机器之后调整步长困难。

数据库压力大：每次获取一个ID都必须读写一次数据库。

主从同步的时候：电商下单->支付insert master db select数据，因为数据同步延迟导致查不到这个数据。加cache(不是最好的解决方式)数据要求比较严谨的话查master主库。

Leaf-segment

采用每次获取一个ID区间段的方式来解决，区间段用完之后再去数据库获取新的号段，这样一来可以大大减轻数据库的压力

核心字段：biz_tag，max_id，step

biz_tag用来区分业务，max_id表示该biz_tag目前所被分配的ID号段的最大值，step表示每次分配的号段长度，原来每次获取ID都要访问数据库，现在只需要把Step设置的足够合理如1000，那么现在可以在1000个ID用完之后再去访问数据库。

优点：

扩张灵活，性能强能够撑起大部分业务场景。

ID号码是趋势递增的，满足数据库存储和查询性能要求。

可用性高，即使ID生成服务器不可用，也能够使得业务在短时间内可用，为排查问题争取时间。

缺点：

可能存在多个节点同时请求ID区间的情况，依赖DB

双buffer：将获取一个号段的方式优化成获取两个号段，在一个号段用完之后不用立马去更新号段，还有一个缓存号段备用，这样能够有效解决这种冲突问题，而且采用双buffer的方式，在当前号段消耗了10%的时候就去检查下一个号段有没有准备好，如果没有准备好就去更新下一个号段，当当前号段用完了就切换到下一个已经缓存好的号段去使用，同时在下一个号段消耗到10%的时候，又去检测下一个号段有没有准备好，如此往复。

优点：

基于JVM存储双buffer的号段，减少了数据库查询，减少了网络依赖，效率更高。

缺点：

segment号段长度是固定的，业务量大时可能会频繁更新号段，因为原本分配的号段会一下用完

如果号段长度设置的过长，但凡缓存中有号段没有消耗完，其他节点重新获取的号段与之前相比可能跨度会很大。动态调整Step

基于redis、mongodb、zk等中间件生成

雪花算法

生成一个64bit的整性数字

第一位符号位固定为0，41位时间戳，10位workId，12位序列号

位数可以有不同实现

优点：

每个毫秒值包含的ID值很多，不够可以变动位数来增加，性能佳（依赖workId的实现）。

时间戳值在高位，中间是固定的机器码，自增的序列在低位，整个ID是趋势递增的。能够根据业务场景数据库节点布置灵活挑战bit位划分，灵活度高。

缺点：

强依赖于机器时钟，如果时钟回拨，会导致重复的ID生成，所以一般基于此的算法发现时钟回拨，都会抛异常处理，阻止ID生成，这可能导致服务不可用。

题六：分布式锁解决方案

需要这个锁独立于每一个服务之外，而不是在服务里面。

数据库：利用主键冲突控制一次只有一个线程能获取锁，非阻塞、不可重入、单点、失效时间

Zookeeper分布式锁

zk通过临时节点，解决了死锁的问题，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉，其他客户端自动获取锁。临时顺序节点解决惊群效应

Redis分布式锁

setNX，单线程处理网络请求，不需要考虑并发安全性

所有服务节点设置相同的key，返回为0、则锁获取失败

setnx 问题：

1、早期版本没有超时参数，需要单独设置，存在死锁问题（中途宕机）

2、后期版本提供加锁与设置时间原子操作，但是存在任务超时，锁自动释放，导致并发问题，加锁与释放锁不是同一线程问题

删除锁：判断线程唯一标志，再删除

可重入性及锁续期没有实现，通过redisson解决（类似AQS的实现，看门狗监听机制）

redlock：意思的机制都只操作单节点、即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况（redis同步设置可能数据丢失）。redlock从多个节点申请锁，当一半以上节点获取成功、锁才算获取成功，redission有相应的实现。

题七：分布式事务解决方案

XA规范：分布式事务规范，定义了分布式事务模型

四个角色：事务管理器(协调者TM)、资源管理器(参与者RM)，应用程序AP，通信资源管理器CRM

全局事务：一个横跨多个数据库的事务，要么全部提交、要么全部回滚

JTA事务是java对XA规范的实现，对应JDBC的单库事务

两阶段协议 ：

第一阶段（ prepare ）：每个参与者执行本地事务但不提交，进入 ready 状态，并通知协调者已经准备就绪。

第二阶段（ commit ）当协调者确认每个参与者都 ready 后，通知参与者进行 commit 操作；如果有参与者 fail ，则发送 rollback 命令，各参与者做回滚。

问题：

单点故障：一旦事务管理器出现故障，整个系统不可用（参与者都会阻塞住）
数据不一致：在阶段二，如果事务管理器只发送了部分 commit 消息，此时网络发生异常，那么只有部分参与者接收到 commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
响应时间较长：参与者和协调者资源都被锁住，提交或者回滚之后才能释放
不确定性：当协调者事务管理器发送 commit 之后，并且此时只有一个参与者收到了 commit，那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。

三阶段协议 ：主要是针对两阶段的优化，解决了2PC单点故障的问题，但是性能问题和不一致问题仍然没有根本解决

引入了超时机制解决参与者阻塞的问题，超时后本地提交，2pc只有协调者有超时机制

第一阶段：CanCommit阶段，协调者询问事务参与者，是否有能力完成此次事务。
- 如果都返回yes，则进入第二阶段
- 有一个返回no或等待响应超时，则中断事务，并向所有参与者发送abort请求
第二阶段：PreCommit阶段，此时协调者会向所有的参与者发送PreCommit请求，参与者收到后开始执行事务操作。参与者执行完事务操作后（此时属于未提交事务的状态），就会向协调者反馈"Ack"表示我已经准备好提交了，并等待协调者的下一步指令。
第三阶段：DoCommit阶段，在阶段二中如果所有的参与者节点都返回了Ack，那么协调者就会从"预提交状态"转变为"提交状态"。然后向所有的参与者节点发送"doCommit"请求，参与者节点在收到提交请求后就会各自执行事务提交操作，并向协调者节点反馈"Ack"消息，协调者收到所有参与者的Ack消息后完成事务。相反，如果有一个参与者节点未完成PreCommit的反馈或者反馈超时，那么协调者都会向所有的参与者节点发送abort请求，从而中断事务。

TCC（补偿事务）：Try、Confirm、Cancel

针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作

Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作既回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。

TCC模型对业务的侵入性较强，改造的难度较大，每个操作都需要有 try 、 confirm 、cancel 三个接口实现。

confirm 和 cancel 接口还必须实现幂等性。

消息队列的事务消息：

发送prepare消息到消息中间件
发送成功后，执行本地事务
- 如果事务执行成功，则commit，消息中间件将消息下发至消费端（commit前，消息不会被消费）
- 如果事务执行失败，则回滚，消息中间件将这条prepare消息删除
消费端接收到消息进行消费，如果消费失败，则不断重试

题八：如何实现接口的幂等性？

唯一id。每次操作，都根据操作和内容生成唯一的id，在执行之前先判断id是否存在，如果不存在则执行后续操作，并且保存到数据库或者redis等。
服务端提供发送token的接口，业务调用接口前先获取token,然后调用业务接口请求时，把token携带过去,服务器判断token是否存在redis中，存在表示第一次请求，可以继续执行业务，执行业务完成后，最后需要把redis中的token删除
建去重表。将业务中有唯一标识的字段保存到去重表，如果表中存在，则表示已经处理过了
版本控制。增加版本号，当版本号符合时，才能更新数据
状态控制。例如订单有状态已支付未支付支付中支付失败，当处于未支付的时候才允许修改为支付中。
。。。。。。

题九：简述ZAB 协议

ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议，实现分布式数据一致性

所有客户端的请求都是写入到 Leader 进程中，然后，由 Leader 同步到其他节点，称为 Follower。在集群数据同步的过程中，如果出现 Follower 节点崩溃或者 Leader 进程崩溃时，都会通过 Zab 协议来保证数据一致性

ZAB 协议包括两种基本的模式：崩溃恢复和消息广播。

消息广播 ：

集群中所有的事务请求都由 Leader 节点来处理，其他服务器为 Follower，Leader 将客户端的事务请求转换为事务 Proposal，并且将 Proposal 分发给集群中其他所有的 Follower。

完成广播之后，Leader 等待 Follwer 反馈，当有过半数的 Follower 反馈信息后，Leader 将再次向集群内 Follower 广播 Commit 信息，Commit 信息就是确认将之前的 Proposal 提交。

Leader 节点的写入是一个两步操作，第一步是广播事务操作，第二步是广播提交操作，其中过半数指的是反馈的节点数 >=N/2+1，N 是全部的 Follower 节点数量。

崩溃恢复：

初始化集群，刚刚启动的时候
Leader 崩溃，因为故障宕机
Leader 失去了半数的机器支持，与集群中超过一半的节点断连

此时开启新一轮 Leader 选举，选举产生的 Leader 会与过半的 Follower 进行同步，使数据一致，当与过半的机器同步完成后，就退出恢复模式，然后进入消息广播模式

整个 ZooKeeper 集群的一致性保证就是在上面两个状态之前切换，当 Leader 服务正常时，就是正常的消息广播模式；当 Leader 不可用时，则进入崩溃恢复模式，崩溃恢复阶段会进行数据同步，完成以后，重新进入消息广播阶段。

Zxid 是 Zab 协议的一个事务编号，Zxid 是一个 64 位的数字，其中低 32 位是一个简单的单调递增计数器，针对客户端每一个事务请求，计数器加 1；而高 32 位则代表 Leader 周期年代的编号。

Leader 周期（ epoch），可以理解为当前集群所处的年代或者周期，每当有一个新的Leader 选举出现时，就会从这个 Leader 服务器上取出其本地日志中最大事务的 Zxid，并从中读取 epoch 值，然后加 1，以此作为新的周期 ID。高 32 位代表了每代 Leader 的唯一性，低 32 位则代表了每代 Leader 中事务的唯一性。

zab节点的三种状态 ：

following：服从leader的命令

leading：负责协调事务

election/looking：选举状态

题十：zk的数据模型和节点类型？

数据模型：树形结构

zk维护的数据主要有：客户端的会话（session）状态及数据节点（dataNode）信息。

zk在内存中构造了个DataTree的数据结构，维护着path到dataNode的映射以及dataNode间的树状层级关系。为了提高读取性能，集群中每个服务节点都是将数据全量存储在内存中。所以，zk最适于读多写少且轻量级数据的应用场景。

数据仅存储在内存是很不安全的，zk采用事务日志文件及快照文件的方案来落盘数据，保障数据在不丢失的情况下能快速恢复。

树中的每个节点被称为--- Znode

Znode 兼具文件和目录两种特点。可以做路径标识，也可以存储数据，并可以具有子 Znode。具有增、删、改、查等操作。

Znode 具有原子性操作，读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的 ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。

Znode 存储数据大小有限制。每个 Znode 的数据大小至多 1M，常规使用中应该远小于此值。

Znode 通过路径引用，如同 Unix 中的文件路径。路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在ZooKeeper 中，路径由 Unicode 字符串组成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如关键配额信息。

持久节点：一旦创建、该数据节点会一直存储在zk服务器上、即使创建该节点的客户端与服务端的会话关闭了、该节点也不会被删除

临时节点：当创建该节点的客户端会话因超时或发生异常而关闭时、该节点也相应的在zk上被删除。

有序节点：不是一种单独种类的节点、而是在持久节点和临时节点的基础上、增加了一个节点有序的性质。

题十一：简述zk的命名服务、配置管理、集群管理

命名服务：

通过指定的名字来获取资源或者服务地址。Zookeeper可以创建一个全局唯一的路径，这个路径就可以作为一个名字。被命名的实体可以是集群中的机器，服务的地址，或者是远程的对象等。一些分布式服务框架（RPC、RMI）中的服务地址列表，通过使用命名服务，客户端应用能够根据特定的名字来获取资源的实体、服务地址和提供者信息等
配置管理：

实际项目开发中，经常使用.properties或者xml需要配置很多信息，如数据库连接信息、fps地址端口等等。程序分布式部署时，如果把程序的这些配置信息保存在zk的znode节点下，当你要修改配置，即znode会发生变化时，可以通过改变zk中某个目录节点的内容，利用watcher通知给各个客户端，从而更改配置。
集群管理：

集群管理包括集群监控和集群控制，就是监控集群机器状态，剔除机器和加入机器。zookeeper可以方便集群机器的管理，它可以实时监控znode节点的变化，一旦发现有机器挂了，该机器就会与zk断开连接，对应的临时目录节点会被删除，其他所有机器都收到通知。新机器加入也是类似。

题十二：讲下Zookeeper watch机制

客户端，可以通过在znode上设置watch，实现实时监听znode的变化

Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端

父节点的创建，修改，删除都会触发Watcher事件。
子节点的创建，删除会触发Watcher事件。

一次性：一旦被触发就会移除，再次使用需要重新注册，因为每次变动都需要通知所有客户端，一次性可以减轻压力，3.6.0默认持久递归，可以触发多次

轻量：只通知发生了事件，不会告知事件内容，减轻服务器和带宽压力

Watcher 机制包括三个角色：客户端线程、客户端的 WatchManager 以及 ZooKeeper 服务器

客户端向 ZooKeeper 服务器注册一个 Watcher 监听，
把这个监听信息存储到客户端的 WatchManager 中
当 ZooKeeper 中的节点发生变化时，会通知客户端，客户端会调用相应 Watcher 对象中的回调方法。watch回调是串行同步的

题十三：zk和eureka的区别？

zk：CP设计(强一致性)，目标是一个分布式的协调系统，用于进行资源的统一管理。

当节点crash后，需要进行leader的选举，在这个期间内，zk服务是不可用的。

eureka：AP设计（高可用），目标是一个服务注册发现系统，专门用于微服务的服务发现注册。

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）

同时当eureka的服务端发现85%以上的服务都没有心跳的话，它就会认为自己的网络出了问题，就不会从服务列表中删除这些失去心跳的服务，同时eureka的客户端也会缓存服务信息。eureka对于服务注册发现来说是非常好的选择。

题十四：Spring Cloud和Dubbo的区别？

底层协议：springcloud基于http协议，dubbo基于Tcp协议，决定了dubbo的性能相对会比较好。

注册中心：Spring Cloud 使用的 eureka ，dubbo推荐使用zookeeper

模型定义：dubbo 将一个接口定义为一个服务，SpringCloud 则是将一个应用定义为一个服务

SpringCloud是一个生态，而Dubbo是SpringCloud生态中关于服务调用一种解决方案（服务治理）

题十五：什么是Hystrix？简述实现机制

分布式容错框架

阻止故障的连锁反应，实现熔断
快速失败，实现优雅降级
提供实时的监控和告警

资源隔离：线程隔离，信号量隔离

线程隔离：Hystrix会给每一个Command分配一个单独的线程池，这样在进行单个服务调用的时候，就可以在独立的线程池里面进行，而不会对其他线程池造成影响
信号量隔离：客户端需向依赖服务发起请求时，首先要获取一个信号量才能真正发起调用，由于信号量的数量有限，当并发请求量超过信号量个数时，后续的请求都会直接拒绝，进入fallback流程。信号量隔离主要是通过控制并发请求量，防止请求线程大面积阻塞，从而达到限流和防止雪崩的目的。

熔断和降级：调用服务失败后快速失败

熔断是为了防止异常不扩散，保证系统的稳定性

降级：编写好调用失败的补救逻辑，然后对服务直接停止运行，这样这些接口就无法正常调用，但又不至于直接报错，只是服务水平下降

通过HystrixCommand 或者HystrixObservableCommand 将所有的外部系统（或者称为依赖）包装起来，整个包装对象是单独运行在一个线程之中（这是典型的命令模式）。
超时请求应该超过你定义的阈值
为每个依赖关系维护一个小的线程池（或信号量）; 如果它变满了，那么依赖关系的请求将立即被拒绝，而不是排队等待。
统计成功，失败（由客户端抛出的异常），超时和线程拒绝。
打开断路器可以在一段时间内停止对特定服务的所有请求，如果服务的错误百分比通过阈值，手动或自动的关闭断路器。
当请求被拒绝、连接超时或者断路器打开，直接执行fallback逻辑。
近乎实时监控指标和配置变化。

题十六：springcloud核心组件及其作用

Eureka：服务注册与发现

注册：每个服务都向Eureka登记自己提供服务的元数据，包括服务的ip地址、端口号、版本号、通信协议等。eureka将各个服务维护在了一个服务清单中（双层Map，第一层key是服务名，第二层key是实例名，value是服务地址加端口）。同时对服务维持心跳，剔除不可用的服务，eureka集群各节点相互注册每个实例中都有一样的服务清单。

发现：eureka注册的服务之间调用不需要指定服务地址，而是通过服务名向注册中心咨询，并获取所有服务实例清单(缓存到本地)，然后实现服务的请求访问。

Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从⼀个服务的多台机器中选择⼀台（被调用方的服务地址有多个），Ribbon也是通过发起http请求，来进行的调用，只不过是通过调用服务名的地址来实现的。虽然说Ribbon不用去具体请求服务实例的ip地址或域名了，但是每调用一个接口都还要手动去发起Http请求。

java 复制代码

@RestController
public class ConsumerController {
  @Autowired
  RestTemplate restTemplate;
  @GetMapping("/ribbon-consumer")
  public String helloConsumer(){
    return
restTemplate.getForEntity("http://exampleservice/index",String.class).getBody();
 }
}

Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求，简化服务间的调用，在Ribbon的基础上进行了进一步的封装。单独抽出了一个组件，就是Spring Cloud Feign。

在引入Spring Cloud Feign后，我们只需要创建一个接口并用注解的方式来配置它，即可完成对服务提供方的接口绑定。

调用远程就像调用本地服务一样

UserController.java

java 复制代码

@RestController
public class UserController {
  @GetMapping("/getUser")
  public String getUser(){
    List<String> list = new ArrayList<>();
    list.add("张三");
    String json = JSON.toJSONString(list);
    return json;
 }
}

UserClient.java

java 复制代码

@FeignClient(name = "user")
public interface UserClient {
  @GetMapping("/getUser")
  String getUser();
}

TestController.java

java 复制代码

@RestController
public class TestController {
  @Resource
  UserClient userClient;
  @RequestMapping("/test")
  public String test(){
    String user = userClient.getUser();
    return user;
 }
}

Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，通过统计接口超时次数返回默认值，实现服务熔断和降级。

Zuul：如果前端、移动端要调用后端系统，统⼀从Zuul网关进入，由Zuul网关转发请求给对应的服务，通过与Eureka进行整合，将自身注册为Eureka下的应用，从Eureka下获取所有服务的实例，来进行服务的路由。Zuul还提供了一套过滤器机制，开发者可以自己指定哪些规则的请求需要执行校验逻辑，只有通过校验逻辑的请求才会被路由到具体服务实例上，否则返回错误提示。

题十七：Dubbo 的整体架构设计及分层

五个角色：

注册中心registry：服务注册与发现
服务提供者provider：暴露服务
服务消费者consumer：调用远程服务
监控中心monitor：统计服务的调用次数和调用时间
容器container：服务允许容器

调用流程：

1：container容器负责启动、加载、运行provider

2：provider在启动时，向regisitry中心注册自己提供的服务

3：consumer在启动时，向regisitry中心订阅自己所需的服务

4：regisitry返回服务提供者列表给consumer，如果有变更，registry将基于长连接推送变更数据给consumer

5：consumer调用provider服务，基于负载均衡算法进行调用

6：consumer调用provider的统计，基于短链接定时每分钟一次统计到monitor

分层：

接口服务层（ Service）：面向开发者，业务代码、接口、实现等
配置层（ Config）：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为中心
服务代理层（ Proxy）：对生产者和消费者、dubbo都会产生一个代理类封装调用细节，业务层对远程调用无感
服务注册层（ Registry）：封装服务地址的注册和发现，以服务 URL 为中心
路由层（ Cluster）：封装多个提供者的路由和负载均衡，并桥接注册中心
监控层（ Monitor）： RPC 调用次数和调用时间监控
远程调用层（ Protocal）：封装 RPC 调用
信息交换层（ Exchange）：封装请求响应模式，同步转异步
网络传输层（ Transport）：抽象 mina 和 netty 为统一接口，统一网络传输接口
数据序列化层（ Serialize）：数据传输的序列化和反序列化