两个通宵熬出来的互联网大厂最新面试题收集整理1000道(一)，欢迎点赞收藏!!!

  最近接触到很多面试相关的内容，所以就专门整理了以下，内容涵盖：Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、Spring Boot、Spring Cloud、RabbitMQ、Kafka、Linux 等技术栈。
后续会出专门的面试视频专题，欢迎关注。

1.MyBatis专题

1、什么是Mybatis？

  1、Mybatis 是一个半 ORM（ 对象关系映射）框架，它内部封装了 JDBC，开发时只需要关注 SQL 语句本身， 不需要花费精力去处理加载驱动、创建连接、创建
statement 等繁杂的过程。程序员直接编写原生态 sql，可以严格控制 sql 执行性能， 灵活度高。
  2、MyBatis 可以使用 XML 或注解来配置和映射原生信息， 将 POJO 映射成数据库中的记录， 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。
  3、通过 xml 文件或注解的方式将要执行的各种 statement 配置起来， 并通过java 对象和 statement 中 sql 的动态参数进行映射生成最终执行的 sql 语句，最后由 mybatis 框架执行 sql 并将结果映射为 java 对象并返回。（ 从执行 sql 到返回 result 的过程）。

2、Mybaits 的优点：

1. 基于 SQL 语句编程，相当灵活，不会对应用程序或者数据库的现有设计造成任何影响，SQL 写在 XML 里，解除 sql 与程序代码的耦合，便于统一管理；提供 XML 标签， 支持编写动态 SQL 语句， 并可重用。
2. 与 JDBC 相比，减少了 50% 以上的代码量，消除了 JDBC 大量冗余的代码，不需要手动开关连接；
3. 很好的与各种数据库兼容（ 因为 MyBatis 使用 JDBC 来连接数据库，所以只要JDBC 支持的数据库 MyBatis 都支持）。
4. 能够与 Spring 很好的集成；
5. 提供映射标签， 支持对象与数据库的 ORM 字段关系映射； 提供对象关系映射标签， 支持对象关系组件维护。

3、MyBatis 框架的缺点：

1. SQL 语句的编写工作量较大， 尤其当字段多、关联表多时， 对开发人员编写SQL 语句的功底有一定要求。
2. SQL 语句依赖于数据库， 导致数据库移植性差， 不能随意更换数据库。

4、MyBatis 框架适用场合：

1. MyBatis 专注于 SQL 本身， 是一个足够灵活的 DAO 层解决方案。
2. 对性能的要求很高，或者需求变化较多的项目，如互联网项目， MyBatis 将是不错的选择。

5、MyBatis 与Hibernate 有哪些不同？

1. Mybatis 和 hibernate 不同，它不完全是一个 ORM 框架，因为 MyBatis 需要程序员自己编写 Sql 语句。
2. Mybatis 直接编写原生态 sql， 可以严格控制 sql 执行性能， 灵活度高， 非常适合对关系数据模型要求不高的软件开发， 因为这类软件需求变化频繁， 一但需求变化要求迅速输出成果。但是灵活的前提是 mybatis 无法做到数据库无关性， 如果需要实现支持多种数据库的软件，则需要自定义多套 sql 映射文件，工作量大。
3. Hibernate 对象/关系映射能力强， 数据库无关性好， 对于关系模型要求高的软件， 如果用 hibernate 开发可以节省很多代码， 提高效率。

6、#{}和${}的区别是什么？

#{}是预编译处理，${}是字符串替换。
Mybatis 在处理#{}时，会将 sql 中的#{}替换为?号，调用 PreparedStatement 的set 方法来赋值；
Mybatis 在处理${}时， 就是把${}替换成变量的值。使用#{} 可以有效的防止 SQL 注入， 提高系统安全性。

7、当实体类中的属性名和表中的字段名不一样 ，怎么办 ？

第 1 种： 通过在查询的 sql 语句中定义字段名的别名， 让字段名的别名和实体类的属性名一致。
第 2 种： 通过<resultMap>来映射字段名和实体类属性名的一一对应的关系。

8、 模糊查询like 语句该怎么写?

第 1 种： 在 Java 代码中添加 sql 通配符。
第 2 种： 在 sql 语句中拼接通配符， 会引起 sql 注入

9、通常一个Xml 映射文件，都会写一个Dao 接口与之对应， 请问，这个Dao 接口的工作原理是什么？Dao 接口里的方法， 参数不同时，方法能重载吗？

  Dao 接口即 Mapper 接口。接口的全限名，就是映射文件中的 namespace 的值； 接口的方法名， 就是映射文件中 Mapper 的 Statement 的 id 值； 接口方法内的参数， 就是传递给 sql 的参数。

  Mapper 接口是没有实现类的，当调用接口方法时，接口全限名+方法名拼接字符串作为 key 值， 可唯一定位一个 MapperStatement。在 Mybatis 中， 每一个、、、标签， 都会被解析为一个MapperStatement 对象。

举例： com.mybatis3.mappers.StudentDao.findStudentById， 可以唯一找到 namespace 为 com.mybatis3.mappers.StudentDao 下面 id 为findStudentById 的 MapperStatement 。

  Mapper 接口里的方法，是不能重载的，因为是使用 全限名+方法名 的保存和寻找策略。Mapper 接口的工作原理是 JDK 动态代理， Mybatis 运行时会使用 JDK 动态代理为 Mapper 接口生成代理对象 proxy， 代理对象会拦截接口方法， 转而执行 MapperStatement 所代表的 sql， 然后将 sql 执行结果返回。

10、Mybatis 是如何进行分页的？分页插件的原理是什么？

  Mybatis 使用 RowBounds 对象进行分页， 它是针对 ResultSet 结果集执行的内存分
页，而非物理分页。可以在 sql 内直接书写带有物理分页的参数来完成物理分页功能， 也可以使用分页插件来完成物理分页。

  分页插件的基本原理是使用 Mybatis 提供的插件接口， 实现自定义插件， 在插件的拦截方法内拦截待执行的 sql，然后重写 sql，根据 dialect 方言，添加对应的物理分页语句和物理分页参数。

11、Mybatis 是如何将sql 执行结果封装为目标对象并返回的？ 都有哪些映射形式？

第一种是使用<resultMap>标签， 逐一定义数据库列名和对象属性名之间的映射关系。
第二种是使用 sql 列的别名功能， 将列的别名书写为对象属性名。

  有了列名与属性名的映射关系后， Mybatis 通过反射创建对象， 同时使用反射给对象的属性逐一赋值并返回， 那些找不到映射关系的属性， 是无法完成赋值的。

12、如何执行批量插入?

首先,创建一个简单的 insert 语句:

<insert id=”insertname”>
  insert into names (name) values (#{value})
</insert>

然后在 java 代码中像下面这样执行批处理插入:

< string > names = new arraylist(); 
    names.add(“fred”); 
    names.add(“barney”); 
    names.add(“betty”);
    names.add(“wilma”);
    // 注意这里 executortype.batch sqlsession sqlsession =
    sqlsessionfactory.opensession(executortype.batch); 
  try {
    namemapper mapper = sqlsession.getmapper(namemapper.class); 
    for (string name: names) {
      mapper.insertname(name);
    }
    sqlsession.commit();
  } catch (Exception e){
     e.printStackTrace(); 
    sqlSession.rollback();
    throw e;
  }finally {
    sqlsession.close();
  }

13、如何获取自动生成的(主)键值?

insert 方法总是返回一个 int 值 ， 这个值代表的是插入的行数。
如果采用自增长策略，自动生成的键值在 insert 方法执行完后可以被设置到传入的参数对象中。

示例：

<insert id=”insertname” usegeneratedkeys=”true” keyproperty=” id”>
  insert into names (name) values (#{name})
</insert>

name name = new name(); name.setname(“fred”);

int rows = mapper.insertname(name);
// 完成后,id 已经被设置到对象中system.out.println(“rows inserted = ” + rows);
system.out.println(“generated key value = ” + name.getid());

14、在 mapper 中如何传递多个参数?

1、第一种： DAO 层的函数

public UserselectUser(String name,String area);

对应的 xml,#{0}代表接收的是 dao 层中的第一个参数，#{1}代表 dao 层中第二参数，更多参数一致往后加即可。

<select id="selectUser"resultMap="BaseResultMap"> 
select *  fromuser_user_t whereuser_name = #{0} and user_area=#{1}
</select>

2、第二种： 使用 @param 注解:

public interface usermapper {
  user selectuser(@param(“username”) string username,@param(“hashedpassword”) string hashedpassword);
}

然后,就可以在 xml 像下面这样使用(推荐封装为一个 map,作为单个参数传递给mapper):

<select id=”selectuser” resulttype=”user”> 
select id, username, hashedpassword 
from some_table
where username = #{username}
  and hashedpassword = #{hashedpassword}
</select>

3、第三种： 多个参数封装成 map

try {
  //映射文件的命名空间.SQL 片段的 ID，就可以调用对应的映射文件中的
  SQL
  //由于我们的参数超过了两个，而方法中只有一个 Object 参数收集，因此我们使用 Map 集合来装载我们的参数
  Map < String, Object > map = new HashMap(); map.put("start", start);
  map.put("end", end);
  return sqlSession.selectList("StudentID.pagination", map);
} catch (Exception e){ 
  e.printStackTrace(); 
  sqlSession.rollback(); 
  throw e;
} finally {
  MybatisUtil.closeSqlSession();
}

15、Mybatis 动态sql 有什么用？执行原理？有哪些动态sql？

  Mybatis 动态 sql 可以在 Xml 映射文件内，以标签的形式编写动态 sql，执行原理是根据表达式的值 完成逻辑判断并动态拼接 sql 的功能。

Mybatis 提供了 9 种动态 sql 标签：trim | where | set | foreach | if | choose| when | otherwise | bind 。

16、Xml 映射文件中，除了常见的select|insert|updae|delete 标签之外，还有哪些标签？

答： <resultMap>、<parameterMap>、<sql>、<include>、<selectKey>， 加上动态 sql 的 9 个标签， 其中为 sql 片段标签， 通过<include>标签引入 sql 片段，<selectKey>为不支持自增的主键生成策略标签。

17、Mybatis 的Xml 映射文件中， 不同的Xml映射文件， id是否可以重复？

  不同的 Xml 映射文件， 如果配置了 namespace， 那么 id 可以重复； 如果没有配置namespace， 那么 id 不能重复；

  原因就是 namespace+id 是作为 Map<String, MapperStatement>的 key 使用的， 如果没有 namespace， 就剩下 id， 那么， id 重复会导致数据互相覆盖。有了 namespace，自然 id 就可以重复， namespace 不同，namespace+id 自然也就不同。

18、为什么说Mybatis 是半自动 ORM 映射工具？它与全自动的区别在哪里？

  Hibernate 属于全自动 ORM 映射工具， 使用 Hibernate 查询关联对象或者关联集合对象时， 可以根据对象关系模型直接获取， 所以它是全自动的。而 Mybatis 在查询关联对象或关联集合对象时， 需要手动编写 sql 来完成，所以，称之为半自动ORM 映射工具。

19、 一对一、一对多的关联查询 ？

一对一查询实现

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
  PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
  "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<!-- 使用接口 代理的方式 namespace必须和接口的全路径名称一致 -->
<mapper namespace="com.sxt.dao.EmpMapper">
  <resultMap type="com.sxt.bean.Emp" id="baseMap">
    <id column="id" property="id"/>
    <result column="name" property="name"/>
    <result column="age" property="age"/>
    <association property="dept" javaType="com.sxt.bean.Department">
      <id column="deptid" property="deptid"/>
      <result column="dname" property="dname"/>
      <result column="desc" property="desc"/>
    </association>
  </resultMap>
  <select id="query" resultMap="baseMap">
    select
      t1.id id
      ,t1.name name
      ,t1.age age
      ,t2.deptid deptid
      ,t2.dname dname
      ,t2.desc 
    from t_emp t1
      left join t_dept t2
      on t1.deptid = t2.deptid
  </select>
  
</mapper>

一对多查询实现

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
  PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
  "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<!-- 使用接口 代理的方式 namespace必须和接口的全路径名称一致 -->
<mapper namespace="com.sxt.dao.DeptMapper">
  <resultMap type="com.sxt.bean.Department" id="baseMap">
    <id column="deptid" property="deptid" />
    <result column="dname" property="dname" />
    <result column="desc" property="desc" />
    <!-- ofType List中泛型的类型 property为变量的名称 -->
    <collection property="emps" ofType="emp">
      <id column="id" property="id" />
      <result column="name" property="name" />
      <result column="age" property="age" />
    </collection>
  </resultMap>
  <select id="query" resultMap="baseMap">
    select
    t1.deptid
    ,t1.dname
    ,t1.desc
    ,t2.name
    ,t2.age
    ,t2.id
    from t_dept t1
    left join t_emp t2
    on t1.deptid =
    t2.deptid
  </select>
</mapper>

20、MyBatis 实现一对一有几种方式?具体怎么操作的？

  有联合查询和嵌套查询,联合查询是几个表联合查询,只查询一次, 通过在resultMap 里面配置 association 节点配置一对一的类就可以完成；

  嵌套查询是先查一个表，根据这个表里面的结果的 外键 id，去再另外一个表里面查询数据, 也是通过 association 配置，但另外一个表的查询通过 select 属性配置。

21、MyBatis 实现一对多有几种方式,怎么操作的？

  有联合查询和嵌套查询。联合查询是几个表联合查询,只查询一次,通过在resultMap 里面的 collection 节点配置一对多的类就可以完成； 嵌套查询是先查一个表, 根据这个表里面的 结果的外键 id,去再另外一个表里面查询数据,也是通过配置 collection, 但另外一个表的查询通过 select 节点配置。

22、Mybatis 是否支持延迟加载？如果支持，它的实现原理是什么？

  答： Mybatis 仅支持 association 关联对象和 collection 关联集合对象的延迟加载， association 指的就是一对一， collection 指的就是一对多查询。在 Mybatis 配置文件中， 可以配置是否启用延迟加载 lazyLoadingEnabled=true|false。

  它的原理是， 使用 CGLIB 创建目标对象的代理对象， 当调用目标方法时， 进入拦截器方法， 比如调用 a.getB().getName()， 拦截器 invoke()方法发现 a.getB()是null 值， 那么就会单独发送事先保存好的查询关联 B 对象的 sql， 把 B 查询上来， 然后调用a.setB(b)，于是 a 的对象 b 属性就有值了，接着完成 a.getB().getName()方法的调用。这就是延迟加载的基本原理。
  当然了， 不光是 Mybatis， 几乎所有的包括 Hibernate， 支持延迟加载的原理都是一样的。

23、Mybatis 的一级、二级缓存:

1）一级缓存: 基于 PerpetualCache 的 HashMap 本地缓存， 其存储作用域为Session， 当 Session flush 或 close 之 后 ， 该 Session 中 的 所 有 Cache 就将清空， 默认打开一级缓存。

2）二级缓存与一级缓存其机制相同， 默认也是采用 PerpetualCache，HashMap 存储， 不同在于其存储作用域为 Mapper(Namespace)， 并且可自定义存储源， 如 Ehcache。默认不打开二级缓存， 要开启二级缓存， 使用二级缓存属性类需要实现 Serializable 序列化接口(可用来保存对象的状态), 可在它的映射文件中配置<cache/> ；

3）对于缓存数据更新机制， 当某一个作用域(一级缓存 Session/二级缓存Namespaces) 的进行了 C/U/D 操作后， 默认该作用域下所有 select 中的缓存将被clear 。

24、什么是 MyBatis 的接口绑定？有哪些实现方式？

接口绑定，就是在 MyBatis 中任意定义接口,然后把接口里面的方法和 SQL 语句绑定, 我们直接调用接口方法就可以,这样比起原来了 SqlSession 提供的方法我们可以有更加灵活的选择和设置。

接口绑定有两种实现方式,一种是通过注解绑定， 就是在接口的方法上面加上@Select、@Update 等注解， 里面包含 Sql 语句来绑定； 另外一种就是通过 xml 里面写 SQL 来绑定, 在这种情况下,要指定 xml 映射文件里面的 namespace 必须为接口的全路径名。当Sql 语句比较简单时候,用注解绑定, 当 SQL 语句比较复杂时候,用 xml 绑定,一般用 xml 绑定的比较多。

25、使用 MyBatis 的mapper 接口调用时有哪些要求？

1、Mapper 接口方法名和 mapper.xml 中定义的每个 sql 的 id 相同；
2、Mapper 接口方法的输入参数类型和 mapper.xml 中定义的每个 sql 的parameterType 的类型相同；
3、Mapper 接口方法的输出参数类型和 mapper.xml 中定义的每个 sql 的resultType 的类型相同；
4、Mapper.xml 文件中的 namespace 即是 mapper 接口的类路径。

26、Mapper 编写有哪几种方式？

第一种： 接口实现类继承 SqlSessionDaoSupport： 使用此种方法需要编写mapper 接口， mapper 接口实现类、mapper.xml 文件。

1、在 sqlMapConfig.xml 中配置 mapper.xml 的位置

<mappers>
  <mapper resource="mapper.xml 文件的地址" />
  <mapper resource="mapper.xml 文件的地址" />
</mappers>

2、定义 mapper 接口
3、实现类集成 SqlSessionDaoSupport mapper 方法中可以 this.getSqlSession()进行数据增删改查。
4、spring 配置

<bean id=" " class="mapper 接口的实现">
  <property name="sqlSessionFactory" ref="sqlSessionFactory"></property>
</bean>

第二种： 使用 org.mybatis.spring.mapper.MapperFactoryBean：

1、在 sqlMapConfig.xml 中配置 mapper.xml 的位置， 如果 mapper.xml 和mappre 接口的名称相同且在同一个目录， 这里可以不用配置

<mappers>
  <mapper resource="mapper.xml 文件的地址" />
  <mapper resource="mapper.xml 文件的地址" />
</mappers>

2、定义 mapper 接口：

1>、mapper.xml 中的 namespace 为 mapper 接口的地址
2>、mapper 接口中的方法名和 mapper.xml 中的定义的 statement 的 id 保持一致
3>、Spring 中定义

<bean id="" class="org.mybatis.spring.mapper.MapperFactoryBean">
  <property name="mapperInterface"  value="mapper 接口地址" />
  <property name="sqlSessionFactory" ref="sqlSessionFactory" />
</bean>

第三种： 使用 mapper 扫描器：
1、mapper.xml 文件编写：
  mapper.xml 中的 namespace 为 mapper 接口的地址；mapper 接口中的方法名和 mapper.xml 中的定义的 statement 的 id 保持一致； 如果将mapper.xml 和 mapper 接口的名称保持一致则不用在 sqlMapConfig.xml 中进行配置。

2、定义 mapper 接口：

注意 mapper.xml 的文件名和 mapper 的接口名称保持一致， 且放在同一个目录3、配置 mapper 扫描器：

<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
  <property name="basePackage" value="mapper 接口包地址"></property>
  <property name="sqlSessionFactoryBeanName" value="sqlSessionFactory"/>
</bean>

4、使用扫描器后从 spring 容器中获取 mapper 的实现对象。

27、简述 Mybatis 的插件运行原理，以及如何编写一个插件。

答： Mybatis 仅可以编写针对 ParameterHandler、ResultSetHandler、StatementHandler、Executor 这 4 种接口的插件， Mybatis 使用 JDK 的动态代理， 为需要拦截的接口生成代理对象以实现接口方法拦截功能， 每当执行这 4 种接口对象的方法时，就会进入拦截方法，具体就是 InvocationHandler 的 invoke() 方法， 当然， 只会拦截那些你指定需要拦截的方法。

编写插件： 实现 Mybatis 的 Interceptor 接口并复写 intercept()方法， 然后在给插件编写注解， 指定要拦截哪一个接口的哪些方法即可， 记住， 别忘了在配置文件中配置你编写的插件。

Zookeeper专题

1.什么是ZooKeeper？

  ZooKeeper 是一个开放源码的分布式协调服务， 它是集群的管理者， 监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终， 将简单易用的接口和性能高效、功能稳定的系统提供给用户。

  分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

Zookeeper 保证了如下分布式一致性特性：

1. 顺序一致性
2. 原子性
3. 单一视图
4. 可靠性
5. 实时性（ 最终一致性）

  客户端的读请求可以被集群中的任意一台机器处理， 如果读请求在节点上注册了监听器， 这个监听器也是由所连接的 zookeeper 机器来处理。对于写请求，这些请求会同时发给其他 zookeeper 机器并且达成一致后，请求才会返回成功。因此， 随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。

  有序性是 zookeeper 中非常重要的一个特性， 所有的更新都是全局有序的， 每个更新都有一个唯一的时间戳， 这个时间戳称为 zxid（ Zookeeper Transaction Id ）。而读请求只会相对于更新有序， 也就是读请求的返回结果中会带有这个
zookeeper 最新的 zxid。

2.ZooKeeper 提供了什么？

1、文件系统
2、通知机制

3.Zookeeper 文件系统

  Zookeeper 提供一个多层级的节点命名空间（ 节点称为 znode）。与文件系统不同的是， 这些节点都可以设置关联的数据， 而文件系统中只有文件节点可以存放数据而目录节点不行。
  Zookeeper 为了保证高吞吐和低延迟， 在内存中维护了这个树状的目录结构， 这种特性使得 Zookeeper 不能用于存放大量的数据， 每个节点的存放数据上限为1M。

4.ZAB 协议？

  ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。

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

  当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障导致不存在过半的服务器与 Leader 服务器保持正常通信时， 所有进程（ 服务器）进入崩溃恢复模式， 首先选举产生新的 Leader 服务器， 然后集群中 Follower 服务器开始与新的 Leader 服务器进行数据同步， 当集群中超过半数机器与该 Leader 服务器完成数据同步之后， 退出恢复模式进入消息广播模式， Leader 服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。

5.四种类型的数据节点 Znode

1、PERSISTENT-持久节点
除非手动删除， 否则节点一直存在于 Zookeeper 上

2、EPHEMERAL-临时节点
临时节点的生命周期与客户端会话绑定， 一旦客户端会话失效（ 客户端与
zookeeper 连接断开不一定会话失效）， 那么这个客户端创建的所有临时节点都会被移除。

3、PERSISTENT_SEQUENTIAL-持久顺序节点
基本特性同持久节点， 只是增加了顺序属性， 节点名后边会追加一个由父节点维护的自增整型数字。

4、EPHEMERAL_SEQUENTIAL-临时顺序节点
基本特性同临时节点， 增加了顺序属性， 节点名后边会追加一个由父节点维护的自增整型数字。

6.Zookeeper Watcher 机制

数据变更通知

  Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听， 当服务端的一些指定事件触发了这个 Watcher， 服务端会向指定客户端发送一个事件通知来实现分布式的通知功能， 然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。

工作机制：

1 、客户端注册 watcher
2 、服务端处理 watcher
3、客户端回调 watcher
Watcher 特性总结：
1、一次性
  无论是服务端还是客户端，一旦一个 Watcher 被触发，Zookeeper 都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力， 不然对于更新非常频繁的节点， 服务端会不断的向客户端发送事件通知， 无论对于网络还是服务端的压力都非常大。

2、客户端串行执行
  客户端 Watcher 回调的过程是一个串行同步的过程。

3、轻量

• Watcher 通知非常简单，只会告诉客户端发生了事件，而不会说明事件的具体内容。
• 客户端向服务端注册 Watcher 的时候，并不会把客户端真实的 Watcher 对象实体传递到服务端，仅仅是在客户端请求中使用 boolean 类型属性进行了标记。

4、watcher event 异步发送 watcher 的通知事件从 server 发送到 client 是异步的，这就存在一个问题，不同的客户端和服务器之间通过 socket 进行通信，由于网络延迟或其他因素导致客户端在不通的时刻监听到事件，由于 Zookeeper 本身提供了 ordering guarantee， 即客户端监听事件后， 才会感知它所监视 znode 发生了变化。所以我们使用 Zookeeper 不能期望能够监控到节点每次的变化。Zookeeper 只能保证最终的一致性， 而无法保证强一致性。

5、注册 watcher getData、exists、getChildren
6、触发 watcher create、delete、setData
7、当一个客户端连接到一个新的服务器上时，watch 将会被以任意会话事件触发。当与一个服务器失去连接的时候， 是无法接收到 watch 的。而当 client 重新连接时， 如果需要的话， 所有先前注册过的 watch， 都会被重新注册。通常这是完全透明的。只有在一个特殊情况下， watch 可能会丢失： 对于一个未创建的 znode 的 exist watch， 如果在客户端断开连接期间被创建了， 并且随后在客户端连接上之前又删除了， 这种情况下， 这个watch 事件可能会被丢失。

7.客户端注册Watcher 实现

1、调用 getData()/getChildren()/exist()三个 API， 传入 Watcher 对象
2、标记请求 request， 封装 Watcher 到 WatchRegistration
3、封装成 Packet 对象， 发服务端发送 request
4、收到服务端响应后， 将 Watcher 注册到 ZKWatcherManager 中进行管理5、请求返回， 完成注册。

8.服务端处理Watcher 实现

1、服务端接收 Watcher 并存储
接收到客户端请求， 处理请求判断是否需要注册 Watcher， 需要的话将数据节点的节点路径和 ServerCnxn（ ServerCnxn 代表一个客户端和服务端的连接， 实现了 Watcher 的 process 接口， 此时可以看成一个 Watcher 对象） 存储在
WatcherManager 的 WatchTable 和 watch2Paths 中去。

2、Watcher 触发
以服务端接收到 setData() 事务请求触发 NodeDataChanged 事件为例：

2.1封装 WatchedEvent
将通知状态（ SyncConnected）、事件类型（ NodeDataChanged） 以及节点路径封装成一个 WatchedEvent 对象

2.2查询 Watcher
从 WatchTable 中根据节点路径查找 Watcher

2.3没找到； 说明没有客户端在该数据节点上注册过 Watcher

2.4找到；提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher（ 从这里可以看出 Watcher 在服务端是一次性的， 触发一次就失效了）

3、调用 process 方法来触发 Watcher
这里 process 主要就是通过 ServerCnxn 对应的 TCP 连接发送 Watcher 事件通知。

9.客户端回调Watcher

  客户端 SendThread 线程接收事件通知， 交由 EventThread 线程回调 Watcher。客户端的 Watcher 机制同样是一次性的， 一旦被触发后， 该 Watcher 就失效了。

10.ACL 权限控制机制

UGO（ User/Group/Others）

目前在 Linux/Unix 文件系统中使用，也是使用最广泛的权限控制方式。是一种粗粒度的文件系统权限控制模式。

ACL（ Access Control List） 访问控制列表包括三个方面：
权限模式（ Scheme）

1、IP： 从 IP 地址粒度进行权限控制
2、Digest： 最常用， 用类似于 username:password 的权限标识来进行权限配置， 便于区分不同应用来进行权限控制
3、World：最开放的权限控制方式，是一种特殊的 digest 模式，只有一个权限标识“ world:anyone”
4、Super： 超级用户

授权对象

授权对象指的是权限赋予的用户或一个指定实体， 例如 IP 地址或是机器灯。

权 限 Permission

1、CREATE： 数据节点创建权限， 允许授权对象在该 Znode 下创建子节点

2、DELETE： 子节点删除权限， 允许授权对象删除该数据节点的子节点
3、READ： 数据节点的读取权限， 允许授权对象访问该数据节点并读取其数据内容或子节点列表等
4、WRITE： 数据节点更新权限， 允许授权对象对该数据节点进行更新操作
5、ADMIN： 数据节点管理权限，允许授权对象对该数据节点进行 ACL 相关设置操作

11.Chroot 特性

  3.2.0 版本后，添加了 Chroot 特性，该特性允许每个客户端为自己设置一个命名空间。如果一个客户端设置了 Chroot， 那么该客户端对服务器的任何操作， 都将会被限制在其自己的命名空间下。

  通过设置 Chroot， 能够将一个客户端应用于 Zookeeper 服务端的一颗子树相对应，在那些多个应用公用一个 Zookeeper 进群的场景下，对实现不同应用间的相互隔离非常有帮助。

12.会话管理

分桶策略：将类似的会话放在同一区块中进行管理，以便于 Zookeeper 对会话进行不同区块的隔离处理以及同一区块的统一处理。

分配原则： 每个会话的“ 下次超时时间点”（ ExpirationTime）

计算公式：

ExpirationTime_ = currentTime + sessionTimeout

13.服务器角色

Leader

1、事务请求的唯一调度和处理者， 保证集群事务处理的顺序性
2、集群内部各服务的调度者

Follower

1、处理客户端的非事务请求， 转发事务请求给 Leader 服务器2、参与事务请求 Proposal 的投票
3、参与 Leader 选举投票

Observer

1、3.0 版本以后引入的一个服务器角色， 在不影响集群事务处理能力的基础上提升集群的非事务处理能力
2、处理客户端的非事务请求， 转发事务请求给 Leader 服务器
3、不参与任何形式的投票

14.Zookeeper 下 Server 工作状态

服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。

1、LOOKING：寻找 Leader 状态。当服务器处于该状态时，它会认为当前集群中没有Leader， 因此需要进入 Leader 选举状态。
2、FOLLOWING： 跟随者状态。表明当前服务器角色是 Follower。
3、LEADING： 领导者状态。表明当前服务器角色是 Leader。
4、OBSERVING： 观察者状态。表明当前服务器角色是 Observer。

15.数据同步

整个集群完成 Leader 选举之后， Learner（ Follower 和 Observer 的统称） 回向Leader 服务器进行注册。当 Learner 服务器想 Leader 服务器完成注册后， 进入数据同步环节。

数据同步流程：（ 均以消息传递的方式进行） Learner 向 Learder 注册
数据同步同步确认
Zookeeper 的数据同步通常分为四类：

1、直接差异化同步（ DIFF 同步）
2、先回滚再差异化同步（ TRUNC+DIFF 同步）
3、仅回滚同步（ TRUNC 同步）
4、全量同步（ SNAP 同步）

在进行数据同步前， Leader 服务器会完成数据同步初始化：
peerLastZxid：
  从 learner 服务器注册时发送的 ACKEPOCH 消息中提取 lastZxid（该Learner 服务器最后处理的 ZXID）
minCommittedLog：
  Leader 服务器Proposal 缓存队列 committedLog 中最小 ZXID
maxCommittedLog：
  Leader 服务器Proposal 缓存队列 committedLog 中最大 ZXID

直接差异化同步（ DIFF 同步）
场景：peerLastZxid 介于 minCommittedLog 和maxCommittedLog 之间先回滚再差异化同步（ TRUNC+DIFF 同步）
场景：当新的Leader 服务器发现某个 Learner 服务器包含了一条自己没有的事务记录，那么就需要让该 Learner 服务器进行事务回滚–回滚到 Leader 服务器上存在的，同时也是最接近于 peerLastZxid 的ZXID
仅回滚同步（ TRUNC 同步）
场景：peerLastZxid 大于 maxCommittedLog
全量同步（ SNAP 同步）
场景一：peerLastZxid 小于 minCommittedLog
场景二：Leader 服务器上没有 Proposal 缓存队列且 peerLastZxid 不等于lastProcessZxid

16.zookeeper 是如何保证事务的顺序一致性的？

  zookeeper 采用了全局递增的事务 Id 来标识， 所有的 proposal（ 提议） 都在被提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字， 高 32 位是 epoch（ 时期; 纪元; 世; 新时代）用来标识 leader 周期，如果有新的 leader 产生出来，epoch 会自增， 低 32 位用来递增计数。当新产生 proposal 的时候， 会依据数据库的两阶段过程， 首先会向其他的 server 发出事务执行请求， 如果超过半数的机器都能执行并且能够成功， 那么就会开始执行。

17.分布式集群中为什么会有Master？

  在分布式环境中， 有些业务逻辑只需要集群中的某一台机器进行执行， 其他的机器可以共享这个结果， 这样可以大大减少重复计算， 提高性能， 于是就需要进行leader 选举。

18.zk 节点宕机如何处理？

  Zookeeper 本身也是集群，推荐配置不少于 3 个服务器。Zookeeper 自身也要保证当一个节点宕机时， 其他节点会继续提供服务。如果是一个 Follower 宕机， 还有 2 台服务器提供访问， 因为 Zookeeper 上的数据是有多个副本的， 数据并不会丢失；如果是一个 Leader 宕机， Zookeeper 会选举出新的 Leader。
  ZK 集群的机制是只要超过半数的节点正常， 集群就能正常提供服务。只有在 ZK 节点挂得太多， 只剩一半或不到一半节点能工作， 集群才失效。
所以
  3 个节点的 cluster 可以挂掉 1 个节点(leader 可以得到 2 票>1.5)
  2 个节点的 cluster 就不能挂掉任何 1 个节点了(leader 可以得到 1 票<=1)

19.zookeeper 负载均衡和nginx 负载均衡区别

  zk 的负载均衡是可以调控， nginx 只是能调权重， 其他需要可控的都需要自己写插件； 但是 nginx 的吞吐量比 zk 大很多， 应该说按业务选择用哪种方式。

20.Zookeeper 有哪几种几种部署模式？

部署模式： 单机模式、伪集群模式、集群模式。

21.集群最少要几台机器，集群规则是怎样的?

集群规则为 2N+1 台， N>0， 即 3 台。

22.集群支持动态添加机器吗？

  其实就是水平扩容了， Zookeeper 在这方面不太好。两种方式：
全部重启：关闭所有 Zookeeper 服务，修改配置之后启动。不影响之前客户端的会话。
逐个重启： 在过半存活即可用的原则下， 一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。

3.5 版本开始支持动态扩容。

23.Zookeeper 对节点的watch 监听通知是永久的吗？为什么不是永久的?

  不是。官方声明： 一个 Watch 事件是一个一次性的触发器， 当被设置了 Watch 的数据发生了改变的时候， 则服务器将这个改变发送给设置了 Watch 的客户端， 以便通知它们。

为什么不是永久的， 举个例子， 如果服务端变动频繁， 而监听的客户端很多情况下， 每次变动都要通知到所有的客户端， 给网络和服务器造成很大压力。
一般是客户端执行 getData(“ /节点 A” ,true)， 如果节点 A 发生了变更或删除， 客户端会得到它的 watch 事件， 但是在之后节点 A 又发生了变更， 而客户端又没有设置watch 事件， 就不再给客户端发送。
在实际应用中， 很多情况下， 我们的客户端不需要知道服务端的每一次变动， 我只要最新的数据即可。

24.Zookeeper 的java 客户端都有哪些？

java 客户端： zk 自带的 zkclient 及 Apache 开源的 Curator。

25.chubby 是什么，和 zookeeper 比你怎么看？

chubby 是 google 的， 完全实现 paxos 算法， 不开源。zookeeper 是 chubby 的开源实现， 使用 zab 协议， paxos 算法的变种。

26.说几个zookeeper 常用的命令。

常用命令： ls get set create delete 等。

27.ZAB 和Paxos 算法的联系与区别？

相同点：
1、两者都存在一个类似于 Leader 进程的角色，由其负责协调多个 Follower 进程的运行
2、Leader 进程都会等待超过半数的 Follower 做出正确的反馈后，才会将一个提案进行提交
3、ZAB 协议中， 每个 Proposal 中都包含一个 epoch 值来代表当前的 Leader 周期， Paxos 中名字为 Ballot

不同点：ZAB 用来构建高可用的分布式数据主备系统（ Zookeeper）， Paxos 是用来构建分布式一致性状态机系统。

28.Zookeeper 的典型应用场景

  Zookeeper 是一个典型的发布/订阅模式的分布式数据管理与协调框架，开发人员可以使用它来进行分布式数据的发布和订阅。
  通过对 Zookeeper 中丰富的数据节点进行交叉使用， 配合 Watcher 事件通知机制， 可以非常方便的构建一系列分布式应用中年都会涉及的核心功能， 如：

1、数据发布/订阅
2、负载均衡
3、命名服务
4、分布式协调/通知
5、集群管理
6、Master 选举7、分布式锁
8、分布式队列

1.数据发布/订阅介绍
  数据发布/订阅系统， 即所谓的配置中心， 顾名思义就是发布者发布数据供订阅者进行数据订阅。

目的

  动态获取数据（ 配置信息）
  实现数据（ 配置信息） 的集中式管理和数据的动态更新

设计模式

  Push 模 式Pull 模 式

数据（ 配置信息） 特性

1、数据量通常比较小
2、数据内容在运行时会发生动态更新
3、集群中各机器共享， 配置一致

如： 机器列表信息、运行时开关配置、数据库配置信息等

基于 Zookeeper 的实现方式

数据存储：将数据（配置信息）存储到 Zookeeper 上的一个数据节点
数据获取：应用在启动初始化节点从 Zookeeper 数据节点读取数据，并在该节点上注册一个数据变更 Watcher
数据变更：当变更数据时，更新Zookeeper 对应节点数据，Zookeeper 会将数据变更通知发到各客户端，客户端接到通知后重新读取变更后的数据即可。

负载均衡zk 的命名服务
命名服务是指通过指定的名字来获取资源或者服务的地址，利用 zk 创建一个全局的路径， 这个路径就可以作为一个名字， 指向集群中的集群， 提供的服务的地址， 或者一个远程的对象等等。

分布式通知和协调

对于系统调度来说： 操作人员发送通知实际是通过控制台改变某个节点的状态， 然后 zk 将这些变化发送给注册了这个节点的 watcher 的所有客户端。

对于执行情况汇报： 每个工作进程都在某个目录下创建一个临时节点。并携带工作的进度数据， 这样汇总的进程可以监控目录子节点的变化获得工作进度的实时的全局情况。

zk 的命名服务（ 文件系统）

命名服务是指通过指定的名字来获取资源或者服务的地址，利用 zk 创建一个全局的路
径， 即是唯一的路径， 这个路径就可以作为一个名字， 指向集群中的集群， 提供的服务的地址， 或者一个远程的对象等等。

zk 的配置管理（ 文件系统、通知机制）

程序分布式的部署在不同的机器上，将程序的配置信息放在 zk 的 znode 下，当有配置发生改变时，也就是 znode 发生变化时，可以通过改变 zk 中某个目录节点的内容， 利用watcher 通知给各个客户端， 从而更改配置。

Zookeeper 集群管理（ 文件系统、通知机制）

所谓集群管理无在乎两点： 是否有机器退出和加入、选举 master。
对于第一点， 所有机器约定在父目录下创建临时目录节点， 然后监听父目录节点的子节点变化消息。一旦有机器挂掉， 该机器与 zookeeper 的连接断开，其所创建的临时目录节点被删除， 所有其他机器都收到通知： 某个兄弟目录被删除， 于是， 所有人都知道： 它上船了。
新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount 又有了， 对于第二点， 我们稍微改变一下， 所有机器创建临时顺序编号目录节点， 每次选取编号最小的机器作为 master 就好。

Zookeeper 分布式锁（ 文件系统、通知机制）

有了 zookeeper 的一致性文件系统， 锁的问题变得容易。锁服务可以分为两类， 一个是保持独占， 另一个是控制时序。

对于第一类，我们将 zookeeper 上的一个 znode 看作是一把锁，通过 createznode 的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的 distribute_lock 节点就释放出锁。
对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点， 和选 master 一样， 编号最小的获得锁， 用完删除， 依次方便。

Zookeeper 队列管理（ 文件系统、通知机制）

两种类型的队列：

1、同步队列， 当一个队列的成员都聚齐时， 这个队列才可用， 否则一直等待所有成员到达。
2、队列按照 FIFO 方式进行入队和出队操作。

第一类， 在约定目录下创建临时目录节点， 监听节点数目是否是我们要求的数目。

第二类， 和分布式锁服务中的控制时序场景基本原理一致， 入列有编号， 出列按编号。在特定的目录下创建 PERSISTENT_SEQUENTIAL 节点， 创建成功时
Watcher 通知等待的队列， 队列删除序列号最小的节点用以消费。此场景下
Zookeeper 的 znode 用于消息存储，znode 存储的数据就是消息队列中的消息内容， SEQUENTIAL 序列号就是消息的编号， 按序取出即可。由于创建的节点是持久化的， 所以不必担心队列消息的丢失问题。

Dubbo专题

1、为什么要用Dubbo？

  随着服务化的进一步发展， 服务越来越多， 服务之间的调用和依赖关系也越来越复杂， 诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术， 如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。就这样为分布式系统的服务治理框架就出现了， Dubbo 也就这样产生了。

2、Dubbo 的整体架构设计有哪些分层?

接口服务层（ Service）：
  该层与业务逻辑相关，根据 provider 和 consumer 的业务设计对应的接口和实现

配置层（ Config）：
  对外配置接口，以 ServiceConfig 和 ReferenceConfig 为中心

服务代理层（ Proxy）：
   服务接口透明代理， 生成服务的客户端 Stub 和 服务端的Skeleton， 以 ServiceProxy 为中心， 扩展接口为 ProxyFactory

服务注册层（ Registry） ：
  封装服务地址的注册和发现， 以服务 URL 为中心， 扩展接口为 RegistryFactory、Registry、RegistryService

路由层（ Cluster） ：
  封装多个提供者的路由和负载均衡， 并桥接注册中心， 以Invoker 为中心， 扩展接口为 Cluster、Directory、Router 和 LoadBlancce

监控层（ Monitor） ：
   RPC 调用次数和调用时间监控， 以 Statistics 为中心， 扩展接口为 MonitorFactory、Monitor 和 MonitorService

远程调用层（ Protocal）：
  封装 RPC 调用，以 Invocation 和 Result 为中心， 扩展接口为 Protocal、Invoker 和 Exporter

信息交换层（ Exchange）：
  封装请求响应模式， 同步转异步。以 Request 和Response 为中心， 扩展接口为 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer

网络传输层（ Transport）：
  抽象 mina 和 netty 为统一接口，以 Message 为中心， 扩展接口为 Channel、Transporter、Client、Server 和 Codec

数据序列化层（ Serialize） ：
  可复用的一些工具， 扩展接口为 Serialization、ObjectInput、ObjectOutput 和 ThreadPool

3、默认使用的是什么通信框架，还有别的选择吗?

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

4、服务调用是阻塞的吗？

  默认是阻塞的， 可以异步调用， 没有返回值的可以这么做。
  Dubbo 是基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务， 相对多线程开销较小， 异步调用会返回一个 Future 对象。

5、一般使用什么注册中心？还有别的选择吗？

  推荐使用 Zookeeper 作为注册中心， 还有 Redis、Multicast、Simple 注册中心， 但不推荐。

6、默认使用什么序列化框架，你知道的还有哪些？

  推荐使用 Hessian 序列化， 还有 Duddo、FastJson、Java 自带序列化。

7、服务提供者能实现失效踢出是什么原理？

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

8、服务上线怎么不影响旧版本？

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

9、如何解决服务调用链过长的问题？

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

10、说说核心的配置有哪些？

11、Dubbo 推荐用什么协议？

dubbo://（推荐）
rmi://
hessian://
http://
webservice://
thrift://
memcached://
redis://
rest://

12、同一个服务多个注册的情况下可以直连某一个服务吗？

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

13、画一画服务注册与发现的流程图？

14、Dubbo 集群容错有几种方案？

15、Dubbo 服务降级，失败重试怎么做？

  可以通过 dubbo:reference 中设置 mock=“return null” 。mock 的值也可以修改为true ， 然后再跟接口同一个路径下实现一个 Mock 类， 命名规则是 “ 接口名称+Mock” 后缀。然后在 Mock 类里实现自己的降级逻辑

16、Dubbo 使用过程中都遇到了些什么问题？

  在注册中心找不到对应的服务,检查 service 实现类是否添加了@service 注解无法连接到注册中心,检查配置文件中的对应的测试 ip 是否正确

17、Dubbo Monitor 实现原理？

  Consumer 端在发起调用之前会先走 filter 链； provider 端在接收到请求时也是先走filter 链， 然后才进行真正的业务逻辑处理。
  默认情况下， 在 consumer 和 provider 的 filter 链中都会有 Monitorfilter。

1. MonitorFilter 向 DubboMonitor 发送数据
2. DubboMonitor 将数据进行聚合后（ 默认聚合 1min 中的统计数据） 暂存到ConcurrentMap<Statistics, AtomicReference> statisticsMap， 然后使用一个含有 3 个线程（ 线程名字： DubboMonitorSendTimer）的线程池每隔 1min 钟， 调用SimpleMonitorService 遍历发送 statisticsMap 中的统计数据，每发送完毕一个， 就重置当前的 Statistics 的 AtomicReference
3. SimpleMonitorService 将这些聚合数据塞入 BlockingQueue queue 中（ 队列大写为 100000）
4. SimpleMonitorService 使 用 一 个 后 台 线 程 （ 线 程 名 为 ： DubboMonitorAsyncWriteLogThread）将 queue 中的数据写入文件（ 该线程以死循环的形式来写）
5. SimpleMonitorService 还会使用一个含有 1 个线程（ 线程名字： DubboMonitorTimer） 的线程池每隔 5min 钟， 将文件中的统计数据画成图表

18、Dubbo 用到哪些设计模式？

  Dubbo 框架在初始化和通信过程中使用了多种设计模式， 可灵活控制类加载、权限控制等功能。

工厂模式
  Provider 在 export 服务时，会调用 ServiceConfig 的 export 方法。ServiceConfig 中有个字段：

private static final Protocol protocol = ExtensionLoader
                    .getExtensionLoader(Protocol.class)
                    .getAdaptiveExtensi on();

  Dubbo 里有很多这种代码。这也是一种工厂模式， 只是实现类的获取采用了 JDK SPI 的机制。这么实现的优点是可扩展性强， 想要扩展实现， 只需要在 classpath 下增加个文件就可以了，代码零侵入。另外， 像上面的 Adaptive 实现，可以做到调用时动态决定调用哪个实现， 但是由于这种实现采用了动态代理， 会造成代码调试比较麻烦， 需要分析出实际调用的实现类。

装饰器模式
  Dubbo 在启动和调用阶段都大量使用了装饰器模式。以 Provider 提供的调用链为例， 具体的调用链代码是在 ProtocolFilterWrapper 的 buildInvokerChain 完成的， 具体是将注解中含有 group=provider 的 Filter 实现， 按照 order 排序， 最后的调用顺序是：

EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter -> ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter -> ExceptionFilter

  更确切地说，这里是装饰器和责任链模式的混合使用。例如，EchoFilter 的作用是判断是否是回声测试请求， 是的话直接返回内容， 这是一种责任链的体现。而像ClassLoaderFilter 则只是在主功能上添加了功能，更改当前线程的 ClassLoader， 这是典型的装饰器模式。

观察者模式
Dubbo 的 Provider 启动时，需要与注册中心交互，先注册自己的服务，再订阅自己的服务， 订阅时， 采用了观察者模式， 开启一个 listener。注册中心会每 5 秒定时检查是否有服务更新， 如果有更新， 向该服务的提供者发送一个 notify 消息， provider 接受到 notify 消息后， 即运行 NotifyListener 的 notify 方法， 执行监听器方法。

动态代理模式
Dubbo 扩展 JDK SPI 的类 ExtensionLoader 的 Adaptive 实现是典型的动态代理实现。Dubbo 需要灵活地控制实现类， 即在调用阶段动态地根据参数决定调用哪个实现类， 所以采用先生成代理类的方法， 能够做到灵活的调用。生成代理类的代码是ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理类的主要逻辑
是， 获取 URL 参数中指定参数的值作为获取实现类的 key。

19、Dubbo 配置文件是如何加载到Spring 中的？

Spring 容器在启动的时候，会读取到 Spring 默认的一些 schema 以及 Dubbo 自定义的schema， 每 个 schema 都 会 对 应 一 个 自 己 的 NamespaceHandler， NamespaceHandler 里面通过 BeanDefinitionParser 来解析配置信息并转化为需要加载的 bean 对象！

20、Dubbo SPI 和 Java SPI 区别？

JDK SPI
JDK 标准的 SPI 会一次性加载所有的扩展实现，如果有的扩展吃实话很耗时，但也没用上， 很浪费资源。

所以只希望加载某个的实现， 就不现实了

DUBBO SPI
1， 对 Dubbo 进行扩展， 不需要改动 Dubbo 的源码
2， 延迟加载， 可以一次只加载自己想要加载的扩展实现。
3， 增加了对扩展点 IOC 和 AOP 的支持， 一个扩展点可以直接 setter 注入其它扩展点。
3， Dubbo 的扩展机制能很好的支持第三方 IoC 容器， 默认支持 Spring Bean。

21、Dubbo 支持分布式事务吗？

目前暂时不支持， 可与通过 tcc-transaction 框架实现

介绍： tcc-transaction 是开源的 TCC 补偿性分布式事务框架Git 地址： https://github.com/changmingxie/tcc-transaction
TCC-Transaction 通过 Dubbo 隐式传参的功能， 避免自己对业务代码的入侵。

22、Dubbo 可以对结果进行缓存吗？

为了提高数据访问的速度。Dubbo 提供了声明式缓存， 以减少用户加缓存的工作量

<dubbo:reference cache=“true” />

其实比普通的配置文件就多了一个标签 cache=“true”

23、服务上线怎么兼容旧版本？

可以用版本号（ version） 过渡， 多个不同版本的服务注册到注册中心， 版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。

24、Dubbo 必须依赖的包有哪些？

Dubbo 必须依赖 JDK， 其他为可选。

25、Dubbo telnet 命令能做什么？

dubbo 服务发布之后， 我们可以利用 telnet 命令进行调试、管理。Dubbo2.0.5 以上版本服务提供端口支持 telnet 命令

连接服务

telnet localhost 20880

查看服务列表

dubbo>ls com.test.TestService
dubbo>ls com.test.TestService

ls (list services and methods)
ls : 显示服务列表。
ls -l : 显示服务详细信息列表。
ls XxxService：显示服务的方法列表。
ls -l XxxService：显示服务的方法详细信息列表。

26、Dubbo 支持服务降级吗？

以通过 dubbo:reference 中设置 mock=“return null”。mock 的值也可以修改为 true， 然后再跟接口同一个路径下实现一个 Mock 类，命名规则是 “ 接口名称+Mock” 后缀。然后在 Mock 类里实现自己的降级逻辑

27、Dubbo 如何优雅停机？

Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的， 所以如果使用
kill -9 PID 等强制关闭指令， 是不会执行优雅停机的， 只有通过 kill PID 时， 才会执行。

28、Dubbo 和 Dubbox 之间的区别？

Dubbox 是继 Dubbo 停止维护后，当当网基于 Dubbo 做的一个扩展项目，如加了服务可 Restful 调用， 更新了开源组件等。

29、Dubbo 和 Spring Cloud 的区别？

根据微服务架构在各方面的要素， 看看 Spring Cloud 和 Dubbo 都提供了哪些支持。

服务注册中心 Zookeep er Spring Cloud Netflix Eureka
服务调用方式 RPC REST API
服务网关 无 Spring Cloud Netflix Zuul
断路器 不完善 Spring Cloud Netflix Hystrix
分布式配置 无 Spring Cloud Config
服务跟踪 无 Spring Cloud Sleuth
消息总线 无 Spring Cloud Bus
数据流 无 Spring Cloud Stream
批量任务 无 Spring Cloud Task
…… …… ……

  使用 Dubbo 构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了， 总是让人不怎么放心， 但是如果你是一名高手， 那这些都不是问题； 而 Spring Cloud 就像品牌机， 在Spring Source 的整合下， 做了大量的兼容性测试，保证了机器拥有更高的稳定性， 但是如果要在使用非原装组件外的东西， 就需要对其基础有足够的了解。

30、你还了解别的分布式框架吗？

别的还有 spring 的 spring cloud， facebook 的 thrift， twitter 的 finagle 等

~好了，篇幅原因本文先更新到此！！！