Java 专业技能面试盘点

熟悉SpringBoot、SpringCloud、Dubbo与zookeeper的分布式和微服务框架。

SpringBoot

1、什么是SpringBoot？

Spring Boot 是 Spring 开源组织下的子项目，是 Spring 组件一站式处理方案，主要是简化了使用 Spring 的难度，简省了繁重的配置，提供了各种启动器，开发者能快速上手。

2、为什么要用 Spring Boot？

Spring Boot 优点非常多，如：

独立运行
简化配置
自动配置
无代码生成和XML配置
应用监控
上手容易…..
Spring Boot 集这么多优点于一身，还有理由不使用它呢？

3、Spring Boot 的核心配置文件有哪几个？它们的区别是什么？

Spring Boot 的核心配置文件是 application 和 bootstrap 配置文件。
application 配置文件这个容易了解，主要用于 Spring Boot 项目的自动化配置。
bootstrap 配置文件有以下几个应用场景。
- 使用 Spring Cloud Config 配置中心时，这时需要在 bootstrap 配置文件中增加连接到配置中心的配置属性来加载外部配置中心的配置信息；
- 少量固定的不能被覆盖的属性；
- 少量加密/解密的场景；

3.1、Spring Boot 有哪几种读取配置的方式？

Spring Boot 可以通过 @PropertySource、@Value、@Environment、@ConfigurationProperties 来绑定变量。

3.2、Spring Boot 的配置文件有哪几种格式？它们有什么区别？

.properties 和 .yml，它们的区别主要是书写格式不同。

1).properties

2).yml

另外，.yml 格式不支持**@PropertySource**注解导入配置。

3.3、你如何了解 Spring Boot 配置加载顺序？

在 Spring Boot 里面，可以使用以下几种方式来加载配置。

1）properties文件；

2）YAML文件；

3）系统环境变量；

4）命令行参数；

等等……

3.4、Spring Boot 如何定义多套不同环境配置？

提供多套配置文件，如：

运行时通过命令行-P 参数指定具体的配置文件借助 maven 的 profiles

4、运行 Spring Boot 有哪几种方式？

1）打包用命令或者者放到容器中运行

2）用 Maven/ Gradle 插件运行

3）直接执行 main 方法运行

5、Spring Boot 的核心注解是哪个？它主要由哪几个注解组成的？

启动类上面的注解是**@SpringBootApplication**，它也是 Spring Boot 的核心注解，主要组合包含了以下 3 个注解：

@SpringBootConfiguration：组合了 @Configuration 注解，实现配置文件的功能。

@EnableAutoConfiguration：打开自动配置的功能，也可以关闭某个自动配置的选项，如关闭数据源自动配置功能：@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })。

@ComponentScan：Spring组件扫描。

6、SpringBoot 其他的常用注解

@Enable注释 @Enable注释并不是新发明的注释，早在 Spring 3 框架就引入了这些注释，用这些注释替代 XML 配置文件。很多 Spring 开发者都知道@EnableTransactionManagement 注释，它能够声明事务管理； @EnableWebMvc 注释，它能启用 Spring MVC；以及@EnableScheduling 注释，它可以初始化一个调度器。
@ConfigurationProperties 属性映射下面看 MongoProperties 类，它是一个 Spring Boot 属性映射的例子：
```
@ConfigurationProperties(prefix = "spring.data.mongodb")public class MongoProperties { 	private String host; 	private int port = DBPort.PORT;	private String uri = "mongodb://localhost/test";	private String database; 	// ... getters setters omitted}
```
@ConfigurationProperties 注释将 POJO 关联到指定前缀的每一个属性。例如，spring.data.mongodb.port 属性将映射到这个类的端口属性。强烈建议 Spring Boot 开发者使用这种方式来删除与配置属性相关的瓶颈代码。
@Conditional 注释 Spring Boot 的强大之处在于使用了 Spring 4 框架的新特性：@Conditional 注释，此注释使得只有在特定条件满足时才启用一些配置。在 Spring Boot 的 org.springframework.boot.autoconfigure.condition 包中说明了使用@Conditional 注释能给我们带来什么，下面对这些注释做一个概述：

@ConditionalOnBean @ConditionalOnClass @ConditionalOnExpression @ConditionalOnMissingBean @ConditionalOnMissingClass @ConditionalOnNotWebApplication @ConditionalOnResource @ConditionalOnWebApplication

7、SpringBoot自动配置原理

Spring Boot 的开启注解是：@SpringBootApplication，其实它就是由下面三个注解组成的：

@Configuration 注解，实现配置文件的功能。Spring 自带的，和 Spring Boot 无关
@ComponentScan：Spring 组件扫描。
@EnableAutoConfiguration：打开自动配置的功能，也可以关闭某个自动配置的选项,SpringBoot 框架的神奇之处在于@EnableAutoConfiguration 注解，此注释自动载入应用程序所需的所有 Bean——这依赖于 Spring Boot在类路径中的查找。它能根据类路径下的 jar 包和配置，动态加载配置和注入 bean 。注解@EnableAutoConfiguration, @Configuration, @ConditionalOnClass 就是自动配置的核心，首先它得是一个配置文件，其次根据类路径下能否有这个类去自动配置。比如我在 lib 下放一个 druid 连接池的 jar 包，然后在 application.yml 文件配置 druid 相关的参数，Spring Boot 就能够自动配置所有我们需要的东西，如果我把 jar 包拿掉或者把参数去掉，那 Spring Boot 就不会自动配置。

8、SpringBoot 的 Starters

Starters 可以理解为启动器，它包含了一系列可以集成到应用里面的依赖包，你可以一站式集成 Spring 及其余技术，而不需要四处找示例代码和依赖包。如你想使用 Spring JPA 访问数据库，只需加入 spring-boot-starter-data-jpa 启动器依赖就能使用了。 Starters 包含了许多项目中需要用到的依赖，它们能快速持续的运行，都是一系列得到支持的管理传递性依赖。

8.1、常见的 starter 会包几个方面的内容？分别是什么？

常见的 starter 会包括下面四个方面的内容：

自动配置文件，根据 classpath 是否存在指定的类来决定是否要执行该功能的自动配置。
spring.factories，非常重要，指导 Spring Boot 找到指定的自动配置文件。
endpoint：可以理解为一个 admin，包含对服务的描述、界面、交互(业务信息的查询)。
health indicator：该 starter 提供的服务的健康指标。

两个需要注意的点：

@ConditionalOnMissingBean 的作用是：只有对应的 bean 在系统中都没有被创建，它修饰的初始化代码块才会执行，【用户自己手动创建的 bean 优先】。
Spring Boot Starter 找到自动配置文件(xxxxAutoConfiguration 之类的文件)的方式有两种：

spring.factories:由 Spring Boot 触发探测 classpath 目录下的类，进行自动配置；
@EnableXxxxx:有时需要由 starter 的用户触发*查找自动配置文件的过程。

8.2、Spring Boot Starter 的工作原理

Spring Boot Starter 的工作原理如下：

Spring Boot 在启动时扫描项目所依赖的 JAR 包，寻找包含 spring.factories 文件的 JAR 。
根据 spring.factories 配置加载 AutoConfigure 类。
根据 @Conditional 注解的条件，进行自动配置并将 Bean 注入 Spring Context。

8.3、自定义 springboot-starter 注意事项

springboot 默认 scan 的包名是其 main 类所在的包名。如果引入的 starter 包名不一样，需要自己添加 scan。@ComponentScan(basePackages = {"com.xixicat.demo","com.xixicat.sms"})
对于 starter 中有 feign 的，需要额外指定 @EnableFeignClients(basePackages = {"com.xixicat.sms"})
对于 exclude 一些 autoConfig @EnableAutoConfiguration(exclude ={MetricFilterAutoConfiguration.class})

9、Spring Boot 支持哪些日志框架？推荐和默认的日志框架是哪个？

Spring Boot 支持 Java Util Logging, Log4j2, Lockback 作为日志框架，假如你使用 Starters 启动器，Spring Boot 将使用 Logback 作为默认日志框架。

10、SpringBoot 实现热部署有哪几种方式

主要有两种方式：

Spring Loaded

Spring-boot-devtools

11、Spring Boot 可以兼容老 Spring 项目吗，如何做？

可以兼容，使用@ImportResource注解导入老 Spring 项目配置文件。

12、保护 Spring Boot 应用有哪些方法？

在生产中使用HTTPS

使用Snyk检查你的依赖关系

更新到最新版本

启用CSRF保护

使用内容安全策略防止XSS攻击…

13、Spring Boot 2.X 有什么新特性？与 1.X 有什么区别？

配置变更

JDK 版本更新

第三方类库更新

响应式 Spring 编程支持

HTTP/2 支持

配置属性绑定

更多改进与增强…

14、Spring Boot、Spring MVC 和 Spring 有什么区别？

SpringFramework 最重要的特征是依赖注入。所有 SpringModules 不是依赖注入就是 IOC 控制反转。 当我们恰当的使用 DI 或者是 IOC 的时候，我们可以开发松耦合应用。松耦合应用的单元测试可以很容易的进行。
Spring MVC **提供了一种分离式的方法来开发 Web 应用。**通过运用像 DispatcherServelet，MoudlAndView 和ViewResolver 等一些简单的概念，开发 Web 应用将会变的非常简单。Spring 和 SpringMVC 的问题在于需要配置大量的参数。
Spring Boot **通过一个自动配置和启动的项来目解决这个问题。**为了更快的构建产品就绪应用程序，Spring Boot 提供了一些非功能性特征。

SpringCloud

1、什么是SpringCloud？

spring cloud 是一系列框架的有序集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 spring boot 的开发风格做到一键启动和部署。

2、SpringCloud与SpringBoot的关系

SpringBoot专注于快速方便的开发单个个体的微服务。

SpringCloud是关注全局的微服务协调整理治理框架，整合并管理各个微服务，为各个微服务之间提供：配置管理、服务发现、断路器、路由、事件总线等集成服务。

SpringBoot不依赖于SpringCloud，SpringCloud依赖于SpringBoot，属于依赖关系。

SpringBoot专注于快速，方便的开发单个的微服务个体，SpringCloud关注全局的服务治理框架。

3、Spring cloud 的核心组件有哪些？

Eureka：服务注册于发现。

Feign：基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求。

Ribbon：实现负载均衡，从一个服务的多台机器中选择一台。

Hystrix：提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。

Zuul：网关管理，由 Zuul 网关转发请求给对应的服务。

4、SpringCloud和Dubbo对比

SpringCloud和Dubbo都是现在主流的微服务架构

SpringCloud是Apache旗下的Spring体系下的微服务解决方案

Dubbo是阿里系的分布式服务治理框架

从技术维度上

其实SpringCloud远远的超过Dubbo,Dubbo本身只是实现了服务治理,而SpringCloud现在已经有21个子项目以后还会更多

所以其实很多人都会说Dubbo和SpringCloud是不公平的

但是由于RPC以及注册中心元数据等原因,在技术选型的时候我们只能二者选其一,所以我们常常为用他俩来对比

服务的调用方式：

Dubbo使用的是RPC远程调用。
SpringCloud使用的是 Rest API，其实更符合微服务官方的定义。

服务的注册中心来看：

Dubbo使用了第三方的ZooKeeper作为其底层的注册中心,实现服务的注册和发现。
SpringCloud使用Spring Cloud Netflix Eureka实现注册中心，当然SpringCloud也可以使用ZooKeeper实现,但一般我们不会这样做。

服务网关：

Dubbo并没有本身的实现，只能通过其他第三方技术的整合。
SpringCloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发，
SpringCloud还支持断路器，与git完美集成分布式配置文件支持版本控制，事务总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。

从技术选型上讲：

目前国内的分布式系统选型主要还是Dubbo毕竟国产，而且国内工程师的技术熟练程度高，并且Dubbo在其他维度上的缺陷可以由其他第三方框架进行集成进行弥补。
SpringCloud目前是国外比较流行，当然我觉得国内的市场也会慢慢的偏向SpringCloud，就连刘军作为Dubbo重启的负责人也发表过观点，Dubbo的发展方向是积极适应SpringCloud生态，并不是起冲突。

Rest和RPC对比：其实如果仔细阅读过微服务提出者马丁福勒的论文的话可以发现其定义的服务间通信机制就是Http Rest

RPC最主要的缺陷就是服务提供方和调用方式之间依赖太强，我们需要为每一个微服务进行接口的定义，并通过持续继承发布，需要严格的版本控制才不会出现服务提供和调用之间因为版本不同而产生的冲突。
REST是轻量级的接口，服务的提供和调用不存在代码之间的耦合，只是通过一个约定进行规范，但也有可能出现文档和接口不一致而导致的服务集成问题，但可以通过swagger工具整合，解决代码和文档一体化。所以REST在分布式环境下比RPC更加灵活。

这也是为什么当当网的DubboX在对Dubbo的增强中增加了对REST的支持的原因

文档质量和社区活跃度：

SpringCloud社区活跃度远高于Dubbo，毕竟由于梁飞团队的原因导致Dubbo停止更新迭代五年,而中小型公司无法承担技术开发的成本导致Dubbo社区严重低落，而SpringCloud异军突起,迅速占领了微服务的市场,背靠Spring混的风生水起
Dubbo经过多年的积累文档相当成熟,对于微服务的架构体系各个公司也有稳定的现状。

5、Eureka 介绍

Eureka 是 Netflix 出品的用于实现服务注册和发现的工具。 Spring Cloud 集成了 Eureka，并提供了开箱即用的支持。其中， Eureka 又可细分为 Eureka Server 和 Eureka Client。Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务注册和发现(请对比 Zookeeper)。

Eureka 采用了 C-S 的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用 Eureka 的客户端连接到 Eureka Server 并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。SpringCloud 的一些其他模块（比如 Zuul）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的逻辑。

Eureka 包含两个组件：Eureka Server 和 Eureka Client。

Eureka Server 提供服务注册服务,各个节点启动后会在 EurekaServer 中进行注册，这样 EurekaServer 中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到
EurekaClient 是一个 Java 客户端，用于简化 Eureka Server 的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向 Eureka Server 发送心跳(默认周期为 30 秒)。如果Eureka Server 在多个心跳周期内没有接收到某个节点的心跳，EurekaServer 将会从服务注册表中把这个服务节点移除（默认 90 秒）。

5.1、集群的基本原理

上图是来自 eureka 的官方架构图，这是基于集群配置的 eureka；

处于不同节点的 eureka 通过 Replicate 进行数据同步
Application Service 为服务提供者
Application Client 为服务消费者
Make Remote Call 完成一次服务调用

服务启动后向 Eureka 注册，Eureka Server 会将注册信息向其他 Eureka Server 进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

当服务注册中心 Eureka Server 检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN 状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。 服务提供者在启动后，周期性（默认 30 秒）向 Eureka Server 发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认 90 秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

5.2、Eureka 的自我保护机制

在默认配置中，Eureka Server 在默认 90s 没有得到客户端的心跳，则注销该实例，但是往往因为微服务跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，但是因为网络分区故障时，Eureka Server 注销服务实例则会让大部分微服务不可用，这很危险，因为服务明明没有问题。为了解决这个问题，Eureka 有自我保护机制，通过在 Eureka Server 配置如下参数，可启动保护机制 eureka.server.enable-self-preservation=true 它的原理是，当 Eureka Server 节点在短时间内丢失过多的客户端时（可能发送了网络故障），那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障回复后，该节点会自动退出自我保护模式。自我保护模式的架构哲学是宁可放过一个，决不可错杀一千，好死不如赖活着。

5.3、Eureka 和 Zookeeper 比较

CAP 理论的核心：一个分布式系统不可能同时很好地满足一致性、可用性和分区容错性这三个需求。因此，根据 CAP 原理将 NOSQL 数据分成了 CA 原则、CP 原则、AP 原则三大类：

CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不强。
CP：满足一致性，分区容错性的系统，通常性能不够高。
AP：满足可用用，分区容错性的系统，通常可能对一致性的要求低一些。

CAP 原则又称 CAP 定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partitiontolerance（分区容错性），三者不可兼得。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在 A 和 C之间进行权衡。在此 Zookeeper 保证的是 CP, 而 Eureka 则是 AP。

5.3.1、Zookeeper 保证 CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但**不能接受服务直接down 掉不可用。**也就是说，服务注册功能对可用性的要求要高于一致性。��是 zk 会出现这样一种情况，当 master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 zk 集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得 zk 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

5.3.2、Eureka 保证 AP

Eureka 看明白了这一点，因此在设计时就优先保证可用性。Eureka 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。**而 Eureka 的客户端在向某个 Eureka 注册或时如果发现连接失败，则会自动切换至其它节点，**只要有一台 Eureka 还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka 还有一种自我保护机制，**如果在 15 分钟内超过85%的节点都没有正常的心跳，那么 Eureka 就认为客户端与注册中心出现了网络故障，**此时会出现以下几种情况：

Eureka 不再从注册列表中移除，因为长时间没收到心跳而应该过期的服务。
Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)。
当网络稳定时，当前实例新的注册信息会被同步到其它节点中。

因此， Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 zookeeper 那样使整个注册服务瘫痪。

5.3.3、总结

Zookeeper 保证的是 CP, 而 Eureka 则是 AP

Eureka 作为单纯的服务注册中心来说要比 zookeeper 更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。不过 Eureka 目前 1.X 版本的实现是基于 servlet 的 Javaweb 应用，它的极限性能肯定会受到影响。期待正在开发之中的 2.X 版本能够从 servlet 中独立出来成为单独可部署执行的服务。

5.4、Eureka 的服务续约，失效剔除，和自我保护

失效剔除：有些时候，我们的服务实例并不一定会正常下线，可能由于内存溢出、网络故障等原因使得服务不能正常工作，而服务注册中心并未收到“服务下线”的请求。为了从服务列表中将这些无法提供服务的实例剔除，Eureka Server 在启动的时候会创建一个定时任务，默认每隔一段时间（默认为 60 秒）将当前清单中超时（默认为 90 秒）没有 续约的服务剔除出去。

服务续约：在注册完服务之后，**服务提供者会维护一个心跳用来持续告诉 EurekaServer: "我还活着”，以防止 Eureka Server 的“剔除任务 ” 将该服务实例从服务列表中排除出去，**我们称该操作为服务续约(Renew)。

关千服务续约有两个重要属性，我们可以关注并根据需要来进行调整：

eureka.instance.lease-renewal-interval-in-seconds=30
eureka.instance.lease-expiration-duration-in-seconds=90
eureka.instance.lease-renewal-interval-in-seconds参数用于定义服务续约任务的调用间隔时间，默认为 30 秒。
eureka.instance.lease-expiration-duration-in-seconds参数用于定义服务失效的时间，默认为 90 秒

自我保护：

服务注册到 EurekaServer 之后，会维护一个心跳连接，告诉 EurekaServer 自己还活着。EurekaServer 在运行期间，会统计心跳失败的比例在 15 分钟之内是否低于 85%, 如果出现低于的情况（在单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致）， Eureka Server 会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。

但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的清况， 所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制。

由于本地调试很容易触发注册中心的保护机制，这会使得注册中心维护的服务实例不那么准确。所以，我们在本地进行开发的时候， 可以使用 eureka.server.enable-self-preservaon = false 参数来关闭保护机制，以确保注册中心可以将不可用的实例正确剔除。

6、Ribbon 和 Feign 的区别

Ribbon 和 Feign 都是用于调用其他服务的，不过方式不同。

Ribbon 添加 maven 依赖 spring-starter-ribbon 使用@RibbonClient(value="服务名称") 使用 RestTemplate 调用远程服务对应的方法
feign 添加 maven 依赖 spring-starter-feign 服务提供方提供对外接口调用方使用在接口上使用@FeignClient("指定服务名")
服务的指定位置不同，Ribbon 是在@RibbonClient 注解上声明，Feign 则是在定义抽象方法的接口中使用 @FeignClient 声明。

7、SpringCloud 断路器的作用

当一个服务调用另一个服务由于网络原因或者自身原因出现问题时，调用者就会等待被调用者的响应，当更多的服务请求到这些资源时导致更多的请求等待，这样就会发生连锁效应（雪崩效应）。断路器就是解决这一问题。

断路器有完全打开状态：一定时间内达到一定的次数无法调用，并且多次检测没有恢复的迹象，断路器完全打开。那么下次请求就不会请求到该服务
半开：短时间内有恢复迹象断路器会将部分请求发给该服务当能正常调用时断路器关闭
关闭：当服务一直处于正常状态能正常调用断路器关闭

8、API 网关

API Gateway 是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的 Facade 模式【外观模式】很像。API Gateway 封装内部系统的架构，并且提供 API 给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一个适应当前架构的 APIGateway。

API Gateway 负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过 API Gateway，然后路由这些请求到对应的微服务。 API Gateway 将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果。它可以在 web 协议与内部 使用的非 Web 友好型协议间进行转换，如 HTTP 协议、WebSocket 协议。

请求转发：服务转发主要是对客户端的请求安装微服务的负载转发到不同的服务上
响应合并：把业务上需要调用多个服务接口才能完成的工作合并成一次调用对外统一提供服务。
协议转换：重点是支持 SOAP，JMS，Rest 间的协议转换。
数据转换：重点是支持 XML 和 Json 之间的报文格式转换能力（可选）
安全认证：
- 基于 Token 的客户端访问控制和安全策略
- 传输数据和报文加密，到服务端解密，需要在客户端有独立的 SDK 代理包
- 基于 Https 的传输加密，客户端和服务端数字证书支持
- 基于 OAuth2.0 的服务安全认证(授权码，客户端，密码模式等）

9、配置中心

配置中心一般用作系统的参数配置，它需要满足如下几个要求：高效获取、实时感知、分布式访问。

9.1、zookeeper 配置中心

实现的架构图如下所示，采取数据加载到内存方式解决高效获取的问题，借助 zookeeper 的节点监听机制来实现实时感知。

9.2、SpringCloud Config

SpringCloud Config 为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

10、服务熔断（Hystrix）

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的 不可用,并将不可用逐渐放大的过程。 熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错 误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败 的操作，使得应用程序继续执行而不用等待修正错误，或者浪费 CPU 时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。

11、Hystrix 断路器机制

断路器很好理解, 当 Hystrix Command 请求后端服务失败数量超过一定比例(默认 50%)，断路器会切换到开路状态(Open)。这时所有请求会直接失败而不会发送到后端服务。断路器保持在开路状态一段时间后(默认 5 秒)，自动切换到半开路状态(HALF-OPEN)。这时会判断下一次请求的返回情况，如果请求成功，断路器切回闭路状态(CLOSED)，否则重新切换到开路状态(OPEN)。Hystrix 的断路器就像我们家庭电路中的保险丝，一旦后端服务不可用，断路器会直接切断请求链，避免发送大量无效请求影响系统吞吐量，并且断路器有自我检测并恢复的能力。

Dubbo

1、Dubbo重要概念

1.1 什么是 Dubbo?

Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源Java RPC 框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。简单来说 Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

Dubbo 目前已经有接近 23k 的 Star ，Dubbo的Github 地址：https://github.com/apache/incubator-dubbo 。另外，在开源中国举行的2018年度最受欢迎中国开源软件这个活动的评选中，Dubbo 更是凭借其超高人气仅次于 vue.js 和 ECharts 获得第三名的好成绩。

Dubbo 是由阿里开源，后来加入了 Apache 。正式由于 Dubbo 的出现，才使得越来越多的公司开始使用以及接受分布式架构。

我们上面说了 Dubbo 实际上是 RPC 框架，那么什么是 RPC呢？

1.2 什么是 RPC?RPC原理是什么?

什么是 RPC？

RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。比如两个不同的服务 A、B 部署在两台不同的机器上，那么服务 A 如果想要调用服务 B 中的某个方法该怎么办呢？使用 HTTP请求当然可以，但是可能会比较慢而且一些优化做的并不好。 RPC 的出现就是为了解决这个问题。

RPC原理是什么？

我这里这是简单的提一下。详细内容可以查看下面这篇文章：

http://www.importnew.com/22003.html

服务消费方（client）调用以本地调用方式调用服务；
client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
client stub找到服务地址，并将消息发送到服务端；
server stub收到消息后进行解码；
server stub根据解码结果调用本地的服务；
本地服务执行并将结果返回给server stub；
server stub将返回结果打包成消息并发送至消费方；
client stub接收到消息，并进行解码；
服务消费方得到最终结果。

下面再贴一个网上的时序图：

说了这么多，我们为什么要用 Dubbo 呢？

1.3 为什么要用 Dubbo?

Dubbo 的诞生和 SOA 分布式架构的流行有着莫大的关系。SOA 面向服务的架构（Service Oriented Architecture），也就是把工程按照业务逻辑拆分成服务层、表现层两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。SOA架构中有两个主要角色：服务提供者（Provider）和服务使用者（Consumer）。

如果你要开发分布式程序，你也可以直接基于 HTTP 接口进行通信，但是为什么要用 Dubbo呢？

我觉得主要可以从 Dubbo 提供的下面四点特性来说为什么要用 Dubbo：

负载均衡——同一个服务部署在不同的机器时该调用那一台机器上的服务。
服务调用链路生成——随着系统的发展，服务越来越多，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。Dubbo 可以为我们解决服务之间互相是如何调用的。
服务访问压力以及时长统计、资源调度和治理——基于访问压力实时管理集群容量，提高集群利用率。
服务降级——某个服务挂掉之后调用备用服务。

另外，Dubbo 除了能够应用在分布式系统中，也可以应用在现在比较火的微服务系统中。不过，由于 Spring Cloud 在微服务中应用更加广泛，所以，我觉得一般我们提 Dubbo 的话，大部分是分布式系统的情况。

我们刚刚提到了分布式这个概念，下面再给大家介绍一下什么是分布式？为什么要分布式？

1.4 什么是分布式?

分布式或者说 SOA 分布式重要的就是面向服务，说简单的分布式就是我们把整个系统拆分成不同的服务然后将这些服务放在不同的服务器上减轻单体服务的压力提高并发量和性能。比如电商系统可以简单地拆分成订单系统、商品系统、登录系统等等，拆分之后的每个服务可以部署在不同的机器上，如果某一个服务的访问量比较大的话也可以将这个服务同时部署在多台机器上。

1.5 为什么要分布式?

从开发角度来讲单体应用的代码都集中在一起，而分布式系统的代码根据业务被拆分。所以，每个团队可以负责一个服务的开发，这样提升了开发效率。另外，代码根据业务拆分之后更加便于维护和扩展。

另外，我觉得将系统拆分成分布式之后不光便于系统扩展和维护，更能提高整个系统的性能。你想一想嘛？把整个系统拆分成不同的服务/系统，然后每个服务/系统单独部署在一台服务器上，是不是很大程度上提高了系统性能呢？

2、Dubbo 的架构

2.1 Dubbo 的架构图解

上述节点简单说明：

Provider： 暴露服务的服务提供方
Consumer： 调用远程服务的服务消费方
Registry： 服务注册与发现的注册中心
Monitor： 统计服务的调用次数和调用时间的监控中心
Container： 服务运行容器

调用关系说明：

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

重要知识点总结：

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
服务提供者无状态，任意一台宕掉后，不影响使用
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

2.2 Dubbo 工作原理

图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。

各层说明：

第一层：service层，接口层，给服务提供者和消费者来实现的
第二层：config层，配置层，主要是对dubbo进行各种配置的
第三层：proxy层，服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton
第四层：registry层，服务注册层，负责服务的注册与发现
第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
第六层：monitor层，监控层，对rpc接口的调用次数和调用时间进行监控
第七层：protocol层，远程调用层，封装rpc调用
第八层：exchange层，信息交换层，封装请求响应模式，同步转异步
第九层：transport层，网络传输层，抽象mina和netty为统一接口
第十层：serialize层，数据序列化层，网络传输需要

3、Dubbo 的负载均衡策略

3.1 先来解释一下什么是负载均衡

先来个官方的解释。

维基百科对负载均衡的定义：负载均衡改善了跨多个计算资源（例如计算机，计算机集群，网络链接，中央处理单元或磁盘驱动的的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用具有负载平衡而不是单个组件的多个组件可以通过冗余提高可靠性和可用性。负载平衡通常涉及专用软件或硬件。

上面讲的大家可能不太好理解，再用通俗的话给大家说一下。

比如我们的系统中的某个服务的访问量特别大，我们将这个服务部署在了多台服务器上，当客户端发起请求的时候，多台服务器都可以处理这个请求。那么，如何正确选择处理该请求的服务器就很关键。假如，你就要一台服务器来处理该服务的请求，那该服务部署在多台服务器的意义就不复存在了。负载均衡就是为了避免单个服务器响应同一请求，容易造成服务器宕机、崩溃等问题，我们从负载均衡的这四个字就能明显感受到它的意义。

3.2 再来看看 Dubbo 提供的负载均衡策略

在集群负载均衡时，Dubbo 提供了多种均衡策略，默认为 random 随机调用。可以自行扩展负载均衡策略，参见：负载均衡扩展。

3.2.1 Random LoadBalance(默认，基于权重的随机负载均衡机制)

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

3.2.2 RoundRobin LoadBalance(不推荐，基于权重的轮询负载均衡机制)

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

3.2.3 LeastActive LoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

3.2.4 ConsistentHash LoadBalance

一致性 Hash，相同参数的请求总是发到同一提供者。(如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略。)
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
缺省只对第一个参数 Hash，如果要修改，请配置 ``
缺省用 160 份虚拟节点，如果要修改，请配置 ``

3.3 配置方式

xml 配置方式

服务端服务级别

<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>

注解配置方式：

消费方基于基于注解的服务级别配置方式：

@Reference(loadbalance = "roundrobin")HelloService helloService;

4、zookeeper宕机与dubbo直连的情况

zookeeper宕机与dubbo直连的情况在面试中可能会被经常问到，所以要引起重视。

在实际生产中，假如zookeeper注册中心宕掉，一段时间内服务消费方还是能够调用提供方的服务的，实际上它使用的本地缓存进行通讯，这只是dubbo健壮性的一种体现。

dubbo的健壮性表现：

监控中心宕掉不影响使用，只是丢失部分采样数据
数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
注册中心对等集群，任意一台宕掉后，将自动切换到另一台
注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
服务提供者无状态，任意一台宕掉后，不影响使用
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

我们前面提到过：注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。所以，我们可以完全可以绕过注册中心——采用 dubbo 直连 ，即在服务消费方配置服务提供方的位置信息。

xml配置方式：

<dubbo:reference id="userService" interface="com.zang.gmall.service.UserService" url="dubbo://localhost:20880" />

注解方式：

 @Reference(url = "127.0.0.1:20880")    HelloService helloService;

Zookeeper

1、 ZooKeeper 概览

ZooKeeper 是一个开源的分布式协调服务，ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。后来，Apache ZooKeeper成为Hadoop，HBase和其他分布式框架使用的有组织服务的标准。例如，Apache HBase使用ZooKeeper跟踪分布式数据的状态。ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

原语： 操作系统或计算机网络用语范畴。是由若干条指令组成的，用于完成一定功能的一个过程。具有不可分割性·即原语的执行必须是连续的，在执行过程中不允许被中断。

ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

Zookeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心(提供发布订阅服务)。 服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。如下图所示，在 Dubbo架构中 Zookeeper 就担任了注册中心这一角色。

2、结合个人使用情况的讲一下 ZooKeeper

在我自己做过的项目中，主要使用到了 ZooKeeper 作为 Dubbo 的注册中心(Dubbo 官方推荐使用 ZooKeeper注册中心)。另外在搭建 solr 集群的时候，我使用 ZooKeeper 作为 solr 集群的管理工具。这时，ZooKeeper 主要提供下面几个功能：1、集群管理：容错、负载均衡。2、配置文件的集中管理3、集群的入口。

我个人觉得在使用 ZooKeeper 的时候，最好是使用集群版的 ZooKeeper 而不是单机版的。官网给出的架构图就描述的是一个集群版的 ZooKeeper 。通常 3 台服务器就可以构成一个 ZooKeeper 集群了。

为什么最好使用奇数台服务器构成 ZooKeeper 集群？

所谓的zookeeper容错是指，当宕掉几个zookeeper服务器之后，剩下的个数必须大于宕掉的个数的话整个zookeeper才依然可用。假如我们的集群中有n台zookeeper服务器，那么也就是剩下的服务数必须大于n/2。先说一下结论，2n和2n-1的容忍度是一样的，都是n-1，大家可以先自己仔细想一想，这应该是一个很简单的数学问题了。比如假如我们有3台，那么最大允许宕掉1台zookeeper服务器，如果我们有4台的的时候也同样只允许宕掉1台。假如我们有5台，那么最大允许宕掉2台zookeeper服务器，如果我们有6台的的时候也同样只允许宕掉2台。

综上，何必增加那一个不必要的zookeeper呢？

3、关于 ZooKeeper 的一些重要概念

3.1、重要概念总结

ZooKeeper 本身就是一个分布式程序（只要半数以上节点存活，ZooKeeper 就能正常服务）。
为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么 ZooKeeper 本身仍然是可用的。
ZooKeeper 将数据保存在内存中，这也就保证了高吞吐量和低延迟（但是内存限制了能够存储的容量不太大，此限制也是保持znode中存储的数据量较小的进一步原因）。
ZooKeeper 是高性能的。在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）
ZooKeeper有临时节点的概念。当创建临时节点的客户端会话一直保持活动，瞬时节点就一直存在。而当会话终结时，瞬时节点被删除。持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在Zookeeper上。
ZooKeeper 底层其实只提供了两个功能：①管理（存储、读取）用户程序提交的数据；②为用户程序提供数据节点监听服务。

下面关于会话（Session）、 Znode、版本、Watcher、ACL概念的总结都在《从Paxos到Zookeeper 》第四章第一节以及第七章第八节有提到，感兴趣的可以看看！

3.2 会话（Session）

Session 指的是 ZooKeeper 服务器与客户端会话。在 ZooKeeper 中，一个客户端连接是指客户端和服务器之间的一个 TCP 长连接。客户端启动的时候，首先会与服务器建立一个 TCP 连接，从第一次连接建立开始，客户端会话的生命周期也开始了。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的Watch事件通知。 Session的sessionTimeout值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

在为客户端创建会话之前，服务端首先会为每个客户端都分配一个sessionID。由于 sessionID 是 Zookeeper 会话的一个重要标识，许多与会话相关的运行机制都是基于这个 sessionID 的，因此，无论是哪台服务器为客户端分配的 sessionID，都务必保证全局唯一。

3.3 Znode

在谈到分布式的时候，我们通常说的“节点"是指组成集群的每一台机器。然而，在Zookeeper中，“节点"分为两类，第一类同样是指构成集群的机器，我们称之为机器节点；第二类则是指数据模型中的数据单元，我们称之为数据节点一一ZNode。

Zookeeper将所有数据存储在内存中，数据模型是一棵树（Znode Tree)，由斜杠（/）的进行分割的路径，就是一个Znode，例如/foo/path1。每个上都会保存自己的数据内容，同时还会保存一系列属性信息。

在Zookeeper中，node可以分为持久节点和临时节点两类。所谓持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在Zookeeper上。而临时节点就不一样了，它的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。另外，ZooKeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL.一旦节点被标记上这个属性，那么在这个节点被创建的时候，Zookeeper会自动在其节点名后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。

3.4 版本

在前面我们已经提到，Zookeeper 的每个 ZNode 上都会存储数据，对应于每个ZNode，Zookeeper 都会为其维护一个叫作 Stat 的数据结构，Stat 中记录了这个 ZNode 的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和 aversion（当前ZNode的ACL版本）。

3.5 Watcher

Watcher（事件监听器），是Zookeeper中的一个很重要的特性。Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去，该机制是Zookeeper实现分布式协调服务的重要特性。

3.6 ACL

Zookeeper采用ACL（AccessControlLists）策略来进行权限控制，类似于 UNIX 文件系统的权限控制。Zookeeper 定义了如下5种权限。

其中尤其需要注意的是，CREATE和DELETE这两种权限都是针对子节点的权限控制。

4、 ZooKeeper 特点

顺序一致性： 从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。
原子性： 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
单一系统映像： 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
可靠性： 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

5、 ZooKeeper 设计目标

5.1 简单的数据模型

ZooKeeper 允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似。名称空间由 ZooKeeper 中的数据寄存器组成 - 称为znode，这些类似于文件和目录。与为存储设计的典型文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。

5.2 可构建集群

为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么zookeeper本身仍然是可用的。客户端在使用 ZooKeeper 时，需要知道集群机器列表，通过与集群中的某一台机器建立 TCP 连接来使用服务，客户端使用这个TCP链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了，客户端可以连接到另外的机器上。

ZooKeeper 官方提供的架构图：

上图中每一个Server代表一个安装Zookeeper服务的服务器。组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态，并且每台服务器之间都互相保持着通信。集群间通过 Zab 协议（Zookeeper Atomic Broadcast）来保持数据的一致性。

5.3 顺序访问

对于来自客户端的每个更新请求，ZooKeeper 都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序，应用程序可以使用 ZooKeeper 这个特性来实现更高层次的同步原语。 这个编号也叫做时间戳——zxid（Zookeeper Transaction Id）

5.4 高性能

ZooKeeper 是高性能的。在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）

6、ZooKeeper 集群角色介绍

最典型集群模式： Master/Slave 模式（主备模式）。在这种模式中，通常 Master服务器作为主服务器提供写服务，其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。

但是，在 ZooKeeper 中没有选择传统的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三种角色。如下图所示

ZooKeeper 集群中的所有机器通过一个 Leader 选举过程来选定一台称为 “Leader” 的机器，Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外，Follower 和 Observer 都只能提供读服务。Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程，也不参与写操作的“过半写成功”策略，因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。

当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。这个过程大致是这样的：

Leader election（选举阶段）：节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 leader。
Discovery（发现阶段）：在这个阶段，followers 跟准 leader 进行通信，同步 followers 最近接收的事务提议。
Synchronization（同步阶段）:同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后准 leader 才会成为真正的 leader。
Broadcast（广播阶段）到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。

七、ZooKeeper &ZAB 协议&Paxos算法

7.1 ZAB 协议&Paxos算法

Paxos 算法应该可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos算法，而是使用 ZAB 协议作为其保证数据一致性的核心算法。另外，在ZooKeeper的官方文档中也指出，ZAB协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法。

7.2 ZAB 协议介绍

ZAB（ZooKeeper Atomic Broadcast 原子广播）协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

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

ZAB协议包括两种基本的模式，分别是 崩溃恢复和消息广播。当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。

当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进人消息广播模式了。 当一台同样遵守ZAB协议的服务器启动后加人到集群中时，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加人的服务器就会自觉地进人数据恢复模式：找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。正如上文介绍中所说的，ZooKeeper设计成只允许唯一的一个Leader服务器来进行事务请求的处理。Leader服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议；而如果集群中的其他机器接收到客户端的事务请求，那么这些非Leader服务器会首先将这个事务请求转发给Leader服务器。

关于 ZAB 协议&Paxos算法 需要讲和理解的东西太多了，说实话，笔主到现在不太清楚这俩兄弟的具体原理和实现过程。推荐阅读下面两篇文章：

关于如何使用 zookeeper 实现分布式锁，可以查看下面这篇文章：

10分钟看懂！基于Zookeeper的分布式锁

熟悉jQuery、ajax等前端技术框架

jQuery

jQuery 是一个 JavaScript 库。

jQuery 极大地简化了 JavaScript 编程。

Ajax

AJAX 是一种用于创建快速动态网页的技术。

通过在后台与服务器进行少量数据交换，AJAX 可以使网页实现异步更新。这意味着可以在不重新加载整个网页的情况下，对网页的某部分进行更新。

传统的网页（不使用 AJAX）如果需要更新内容，必需重载整个网页面。

有很多使用 AJAX 的应用程序案例：新浪微博、Google 地图、开心网等等。

我们一般不会用原生的JavaScript发送ajax请求，而是用封装好的比如：jQuery、axios。

参考资料：

https://juejin.cn/post/6844903982066827277#heading-19
https://snailclimb.gitee.io/javaguide/#/
https://www.ycbbs.vip/?p=2468

超多超全的Java专业技能面试盘点（二）