Dubbo&Zookeeper面试题

1. Dubbo中zk做注册中心，如果注册中心集群都挂掉了，发布者和订阅者直接还能通信吗?

可以通信，启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等信息，缓存在本地，每次调用时，按照本地存储的地址进行调用；

注册中心对集群，任意一台宕机后，将会切换到另一台；注册中心全部宕机后，服务的提供者和消费者仍能通过本地缓存通讯。服务提供者无状态，任意宕机后，不影响使用；服务提供者全部宕机，服务消费者会服务使用，并无限次重连等待服务者恢复；

挂掉是不要紧的，但前提是没有增加新的服务，如果要调用新的服务，则是无法通信的；

2.Dubbo有哪些负载均衡策略

https://www.cnblogs.com/wyq178/p/9822731.html
什么是负载均衡策略
我们的程序是分布式应用，服务部署在多个节点（服务器）上，当消费者调用服务时，zk返回给dubbo的是一个节点列表，但是dubbo只会选择一台服务器，那么它究竟选择哪一台呢？这就是dubbo的负载均衡策略。

负载均衡介绍
改善了跨多个计算资源（如计算机、计算机集群、网络连接，中央处理单元或磁盘驱动的工作负载分布）负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。即：避免单个服务器响应同一请求，容易造成服务器宕机、崩溃等问题；

• Random LoadBalance
  随机：
  按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。(权重可以在dubbo管控台配置)

• RoundRobin LoadBalance
  轮循:
  按公约后的权重设置轮循比率。存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

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

• ConsistentHash LoadBalance
  一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂掉时，原本该发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动

3.Dubbo在安全机制方面是如何解决的

Dubbo通过Token令牌防止用户绕过注册中心直连，然后再注册中心上管理授权。Dubbo还提供了服务黑白名单，来控制服务所允许的调用方

4.Dubbo连接注册中心和直连的区别

直连
在开发及测试环境下，经常需要绕过注册中心，只测试指定的服务提供者，这时候可能需要点对点直连。点对点直连方式，将以服务接口为单位，忽略注册中心的提供者列表、服务注册中心，动态的注册和发现服务，使服务的位置透明，并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，注册中心返回服务提供者地址列表给到消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者；

举例说明：
服务生产者和消费者均绕开注册中心，消费者直接连接生产者。如测试环境和开发环境共用共一个注册中心，本地调试的时候一般采取直连的方式。即：有服务A（服务生产者），应用B（服务消费者），改动了A，希望B上看到效果，则把A的dubbo配置文件中的register均改为false，并且B需要消费本地的服务后加上url=“dubbo://IP:端口号”，在本地分别启动A、B，就是B直连A

注册中心
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。注册中心负责服务地址的注册与查询，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，注册中心，服务提供者，服务消费者三者直接均为长连接，监控中心除外，注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送时间通知消费者。

总结
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表；
注册中心和监控中心都是可选的，服务消费可以直连服务提供者

5.Dubbo通信协议

Dubbo通信协议https://blog.csdn.net/qq_34988624/article/details/86481801

Dubbo通信协议（默认）
Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。反之，Dubbo缺省协议不适合传送大数据量的服务，比如传文件、视频等，除非请求量很低；
缺省协议，使用基于 netty 和 hessian 3.2.1 的 tbremoting 交互。

• 连接个数：单连接
• 连接方式：长连接
• 传输协议：TCP
• 传输方式：NIO异步传输
• 序列化：Hessian二进制序列化
• 使用范围：传入传出参数数据包较小（建议小于100k），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要使用dubbo协议传输大文件或超大字符串。
• 适用场景：常规远程服务方法调用

Dubbo协议为什么要消费者比提供者个数多

因为dubbo协议采用单一长连接，假设网络为千兆网卡（1024Mbit=128MBytes），根据测试经验数据每条连接最多只能压满7MBytes，理论上1个服务提供者需要20个服务消费者才能压满网卡。

Dubbo协议为什么不能传大包

dubbo协议采用单一长连接，如果每次请求的数据包大小为500kByte，假设网络为千兆网卡，每条连接最大7MB，单个服务提供者的TPS（每秒处理事务数）最大为128MB/500KB=262.单个消费者调用单个服务提供者的TPS最大为7MB/500KB=14.如果能接受，可以考虑使用，否则网络将成为瓶颈

Dubbo协议为什么采用异步单一长连接

因为服务的现状大都是服务提供者少，通常只有几台机器，而服务的消费者较多，可能整个网站都在访问该服务。如果采用常规的hessian服务，服务提供者很容易被压垮，通过单一连接，保证单一消费者不会压死提供者，单一长连接，减少连接握手验证等，并使用异步IO，复用线程池，防止C10K问题。

6.Zookeeper

zk是一个分布式数据一致性解决方案，致力于分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。
分布式应用程序可以基于zk实现数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、leader选举、分布式锁、分布式队列等功能

ZK目标

高性能
zk将全量数据存储在内存中，并直接服务于客户端的所有非事务请求，尤其适用于以读为主的应用场景
高可用
zk一般以集群的方式对外提供服务，一般3~5台机器就可以组成一个可用的zk集群。每台机器都会在内存中维护当前的服务器状态，并且每台机器之间都相互保持着通信。只要集群中超过一半的机器都能正常工作，那么整个集群都能正常对外服务；
严格顺序访问
对于来自客户端的每个更新请求，zk都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序

ZK五大特性

zk一般以集群的方式对外提供无法，一个集群包含多个节点，每个节点对应一台zk服务器，所有的节点共同对外提供服务，整个集群环境对分布式数据一致性提供了全面的支持，具体包括一下五大特性：
顺序一致性：从同一个客户端发起的请求，最终将会严格按照其发送顺序进入zk中
原子性：所以请求的响应结果在整个分布式集群环境中具备原子性，即要么整个集群中的所有机器都成功的处理了某个请求，要么就都没有处理，绝对不会出现集群中一部分机器处理了某个请求，而另一部分机器却没有处理的情况。
单一性：无论客户端连接到zk集群中的哪台服务器， 每个客户端所看到的服务端模型都是一致的，不可能出现两种不同的数据状态，因为zk集群中每台服务器直接会进行数据同步
可靠性：一旦服务端数据的状态发生了变化，就会立即存储起来，除非此时有另一个请求对其进行了变更，否则数据一定是可靠的；
实时性当某个请求被成功处理后，zk仅仅保证在一定时间内，客户端最终一定能从服务端上读取到最新的数据状态，即zk保证数据的最终一致性

Watcher-数据变更的通知

在zk中，引入watcher机制来实现分布式数据的发布/订阅功能。zk允许客户端向服务器注册一个watcher监听，当服务器的一些指定事件触发了这个watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。
Watcher机制为以下三个过程：
客户端注册watcher
在创建一个zk客户端对象实例时，可以向构造方法中传入一个watcher，这个watcher将作为整个zk会话期间的默认watcher，一直保存在客户端，并向zk服务器注册。watcher客户端并不会把真是的watcher对象传递到服务器，仅仅是在客户端中请求中使用boolean类型属性进行标记，降低网络开销和服务器内存开销。
服务端处理watcher
服务端执行数据变更，当watcher监听的对应数据节点的数据内容发生变更，如果找到对应的watcher，会将其提取出来，同时从管理中将其删除（说明watcher在服务端是一次性的，即触发一次就失效了），触发watcher，向客户端发送通知。
客户端回调watcher
客户端获取通知，识别出事件类型，从相应的watcher存储中去除对应的watcher（说明客户端也是一次性的，即一旦触发就会失效）

ZK经典使用场景

数据发布与订阅

发布与订阅即所谓的配置管理，顾名思义就是将数据发布到zk节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用。

1. 索引信息和集群中机器节点状态存放在zk的一些指定节点，供哥哥客户端订阅使用。
2. 系统日志存储，这些日志通常2-3天后被清除。
3. 应用中用到的一些配置信息集中管理，在应用启动的时候主动来获取一次，并且在节点上注册一个watcher，以后每次配置有更新，实时通知到应用，获取最新配置信息
4. 业务逻辑中需要用到一些全局变量，比如一些消息中间件的消息队列通常有个offset，这个offset放在zk上，这样集群中每个发送者都能知道当前的发送进度
5. 系统中有些信息需要动态获取，并且还会存在人工手动去修改这个信息。以前通常是暴露出接口，例如JMX接口，有了zk后，只要将这些信息放在zk节点上即可。

分布通知/协调

zk中特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之家的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对zk上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应的处理。

1. 另一种心跳检测机制：检测系统和被检测系统之间并不直接关联起来，而是通过zk上某个节点关联，大大减少了系统耦合
2. 另一种系统调度模式：某系统有控制台和推送系统两部分组成，控制台的职责是控制推送进行相应的推送工作。管理人员在控制台做的一些操作，实际上是修改了zk上某些节点的状态，而zk就是把这些变化通知给他们注册watcher的客户端，即推送系统，于是，作出相应的推送任务。
3. 另一种工作汇报模式：类似于任务分发系统，子任务启动后，到zk来注册一个临时节点，并且定时将自己的进度进行汇报（将进度写回这个临时节点），这样任务管理者就能够实时知道任务进度

分布式锁

这个主要得益于zk为我们保证了数据的强一致性，即用户只要完全相信每时每刻，zk集群中任意节点（一个zk server）上相同znode的数据是一定相同的。锁服务可以分为两个，一个是保持独占，另一个是控制时序。
保持独占：就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是吧zk上的一个znode看做是一把锁，通过create Znode的方式来实现。所有客户端都去创建/distribute_lock节点，最终成功创建的那个客户端也即拥有了这把锁。
控制时序：就是所有试图来获取这个锁的客户端，最终都会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这个distribute_lock已经预先存在，客户端在它下面创建临时有序节点（这个可以通过几点的属性控制：CreateMode.EPHEMERAL_SEQUENTIAL来指定）。zk的父节点（/distribute_lock）维持一份sequence，保证子节点创建的时序性，从而也形成了每个客户端的全局时序性

集群管理

1. 集群机器监控：这通常用于那种对集群中机器状态，机器在线率有较高要求的场景，能够快速对集群中机器变化作出响应。这样的场景中，往往有一个监控系统，实时检测集群机器是否存活。过去的做法通常是：监控系统通过某种手段（比如ping）定时检测每个机器，或者每个机器自己定时向监控系统汇报“我还活着”。 这种做法可行，但是存在两个比较明显的问题：1. 集群中机器有变动的时候，牵连修改的东西比较多。2. 有一定的延时。

利用ZooKeeper有两个特性，就可以实时另一种集群机器存活性监控系统：a. 客户端在节点 x 上注册一个Watcher，那么如果 x 的子节点变化了，会通知该客户端。b. 创建EPHEMERAL类型的节点，一旦客户端和服务器的会话结束或过期，那么该节点就会消失。

2. Master选举则是zookeeper中最为经典的使用场景了。
   在分布式环境中，相同的业务应用分布在不同的机器上，有些业务逻辑（例如一些耗时的计算，网络I/O处理），往往只需要让整个集群中的某一台机器进行执行， 其余机器可以共享这个结果，这样可以大大减少重复劳动，提高性能，于是这个master选举便是这种场景下的碰到的主要问题。
   利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建 /currentMaster 节点，最终一定只有一个客户端请求能够创建成功。