可另外参考 https://blog.csdn.net/zl1zl2zl3/article/details/83721147

1. dubbo有哪些组件，必选的有哪些

   Dubbo需要四大基本组件：Registry、Monitor、Provider、Consumer。
   

Provider：提供者
Consumer：消费者
registry：注册中心（相当于中介）
monitor：监控中心（dubbo自己的监控项目，直接解压在tomcat下就能启动了，可以查看消费者，生产者）-----------

https://blog.csdn.net/qq_24853627/article/details/79380707

container：服务容器

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

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

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

3. dubbo的启动过程

   参考自 https://www.jianshu.com/p/7f3871492c71

4. dubbo的一次请求流程是什么样的

5. dubbo 服务调用是阻塞的吗？

   默认是阻塞的，可以异步调用，没有返回值的可以这么做

      <dubbo:reference id="xxx" ....>
         <dubbo:method name="method1" async="true" /
      </dubbo:reference>
   

6. 介绍下对zk的理解，知道cap吗（一致性，可用性，分区容错性）

分布式领域中存在CAP理论，且该理论已被证明：任何分布式系统只可同时满足两点，无法三者兼顾。

①C：Consistency，一致性，数据一致更新，所有数据变动都是同步的。
②A：Availability，可用性，系统具有好的响应性能。 　　
③P：Partition tolerance，分区容错性。

详述如下：

  ● 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。一致性被称为原子对象，任何的读写都应该看起来是“原子“的，或串行的。（等同于所有节点访问同一份最新的数据副本）
  ● 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
  ● 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

（1）一致性
　　一致性是指从系统外部读取系统内部的数据时，在一定约束条件下相同，即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同，可以将一致性级别分为如下几种：

①强一致性（strong consistency）。任何时刻，任何用户都能读取到最近一次成功更新的数据。
　　②单调一致性（monotonic consistency）。任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可　　获取的数据顺序必是单调递增的。
　　③会话一致性（session consistency）。任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值　　 会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。示例case：php的　　session概念。
　　④ 最终一致性（eventual consistency）。用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。
　　⑥弱一致性（weak consistency）。用户无法在确定时间内读到最新更新的值。

二、ZooKeeper提供的一致性服务
　　很多文章和博客里提到，zookeeper是一种提供强一致性的服务，在分区容错性和可用性上做了一定折中，这和CAP理论是吻合的。但实际上zookeeper提供的只是单调一致性。
原因：
　　1. 假设有2n+1个server，在同步流程中，leader向follower同步数据，当同步完成的follower数量大于 n+1时同步流程结束，系统可接受client的连接请求。如果client连接的并非同步完成的follower，那么得到的并非最新数据，但可以保证单调性。
　　2. follower接收写请求后，转发给leader处理；leader完成两阶段提交的机制。向所有server发起提案，当提案获得超过半数（n+1）的server认同后，将对整个集群进行同步，超过半数（n+1）的server同步完成后，该写请求完成。如果client连接的并非同步完成follower，那么得到的并非最新数据，但可以保证单调性。

用分布式系统的CAP原则来分析Zookeeper：
（1）C: Zookeeper保证了最终一致性,在十几秒可以Sync到各个节点.
（2）A: Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的. 如果想保证取得是数据一定是最新的,需要手工调用Sync()
（2）P: 有2点需要分析的.
① 节点多了会导致写数据延时非常大,因为需要多个节点同步.
② 节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入 observer节点缓解这个问题.

8. zk怎么保证一致性

   参考 https://blog.csdn.net/wq237wq/article/details/51607180

   zookeeper是如何保证事务的顺序一致性的
   zookeeper采用了递增的事务Id来标识，所有的proposal都在被提出的时候加上了zxid，zxid实际上是一个64位的数字，高32位是epoch用来标识leader是否发生改变，如果有新的leader产生出来，epoch会自增，低32位用来递增计数。当新产生proposal的时候，会依据数据库的两阶段过程，首先会向其他的server发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行

zookeeper是如何选取主leader的？
当leader崩溃或者leader失去大多数的follower，这时zk进入恢复模式，

zk中znode类型有四种，持久化目录节点 持久化顺序编号目录节点(有顺序 能够在注册机器等许多场景用到) 临时目录节点 临时顺序编号节点
zk的通知机制
client端会对某个znode建立一个watcher事件，当该znode发生变化时，这些client会收到zk的通知，然后client可以根据znode变化来做出业务上的改变等。

zk的配置管理
程序分布式的部署在不同的机器上，将程序的配置信息放在zk的znode下，当有配置发生改变时，也就是znode发生变化时，可以通过改变zk中某个目录节点的内容，利用water通知给各个客户端 从而更改配置。
zk的命名服务
命名服务是指通过指定的名字来获取资源或者服务的地址，利用zk创建一个全局的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。

分布式通知和协调
对于系统调度来说：操作人员发送通知实际是通过控制台改变某个节点的状态，然后zk将这些变化发送给注册了这个节点的watcher的所有客户端。
对于执行情况汇报：每个工作进程都在某个目录下创建一个临时节点。并携带工作的进度数据，这样汇总的进程可以监控目录子节点的变化获得工作进度的实时的全局情况。

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

9. kafka的分区大小怎么确定比较合理

11. dubbo的负载均衡算法（应用于dubbo集群）

① Random LoadBalance（随机均衡算法）

② RoundRobin LoadBalance（权重轮询均衡算法）

③ LeastAction LoadBalance（最少活跃调用数均衡算法）

④ ConsistentHash LoadBalance（一致性Hash均衡算法）

缺省时为Random随机调用