zookeeper、Dubbo

zookeeper

Zookeeper实际案例中的应用场景？

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

Zookeeper基本的实现的特征？

1. 顺序一致性，从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到Zookeeper中去。
2. 原子性，所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，即整个集群要么都成功应用了某个事务，要么都没有应用。
3. 单一视图，无论客户端连接的是哪个 Zookeeper 服务器，其看到的服务端数据模型都是一致的。
4. 可靠性，一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直被保留，除非有另一个事务对其进行了变更。
5. 实时性，Zookeeper 保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

Zookeeper节点有哪些类型？

1.PERSISTENT 持久化节点
2.PERSISTENT_SEQUENTIAL 顺序自动编号持久化节点，这种节点会根据当前已存在的节点数自动加 1
3.EPHEMERAL 临时节点，客户端session超时这类节点就会被自动删
4.EPHEMERAL_SEQUENTIAL 临时自动编号节点

Zookeeper节点ACL权限控制

ACL 权限控制，使用：scheme🆔perm 来标识，主要涵盖 3 个方面：
　　权限模式（Scheme）：授权的策略
　　授权对象（ID）:授权的对象
　　权限（Permission）:授予的权限
　　
其特性如下：
　　ZooKeeper的权限控制是基于每个znode节点的，需要对每个节点设置权限
　　每个znode支持设置多种权限控制方案和多个权限
　　子节点不会继承父节点的权限，客户端无权访问某节点，但可能可以访问它的子节点

Zookeeper如何实现分布式锁？

Zookeeper分布式锁应用了临时顺序节点。

客户连接zookeeper创建临时节点，只有一个客户端创建节点成功，代表这个客户端获得了锁，执行完业务逻辑代码之后，该客户端断开连接，临时节点被删除，其他客户端继续创建临时节点。为防止羊群效应（一下子很多客户端服务器抢锁），也可以使用临时顺序节点为每台客户端获得锁排序，客户端根据顺序依次获得锁。

分布式锁中代码出现业务逻辑问题，导致一直不释放锁？人员和解决？

在连接zookeeper时，设置sessionTimeout时间，连接超过时间自动断开连接，临时节点被删除，也就是释放锁了。

一致性的原理有哪些？

Zab协议有两种模式，它们分别是恢复模式和广播模式。

(1) 恢复模式
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。

(2) 广播模式
一旦Leader已经和多数的Follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个Server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，它也参与消息广播。ZooKeeper服务一直维持在Broadcast状态，直到Leader崩溃了或者Leader失去了大部分的Followers支持。

分布式基本一致性概念

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

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

Zookeeper选举的策略

1. leader 选举开始时，每个 follower 节点首先清空自己的投票箱，然后投票给自己，并通过广播的方式通知所有其他节点给自己投票；
2. 每个 follower 节点接收到其他 follower 节点的选票，将该外部选票与自己的选票进行对比，对比主要是基于以上5个核心数据项来展开：
   1. 选举轮次：比较 logicalClock，如果外部选票的 logicalClock 大于自己的，则说明自己的选举轮次落后于该外部节点了，则清空自己的投票箱，并将自己的投票更新为当前轮次后重新广播投票出去；小于则忽略该外部选票；等于则进入下面步骤继续比较其他数据；
   2. vote_zxid 大小比较：将外部选票的 vote_zxid 与自己的投票的vote_zxid 进行对比，如果外部的大，则将自己的（vote_myid，vote_zxid）更新为该外部选票的 vote_myid 和 vote_zxid 并广播出去，即投给这个 vote_zxid 更大的 vote_myid；并更新自身的投票箱，即添加或者更新该外部投票对应的 vote_myid 的选票情况。因为在每个节点的投票箱中，对于集群中的所有参与投票 follower 节点只能存在一张投票，即当当前节点收到某个节点的多次投票时，则需要进行覆盖，如节点A刚开始收到节点B投给B自己的投票，A放入投票箱为（B,B），后来又收到B投给C，则更新为（B,C），此时A的投票箱不再存在（B，B）的这种选票了，而是更新为了（B,C）；
   3. vote_myid大小比较：如果 vote_zxid 相同，则投票给 vote_myid 更大的节点；
   4. 重复以上过程，当某个节点发现过半数的 follower 节点都投给了自己，则更新自己的状态为 LEADING，其他节点则更新自己的状态为FOLLOWING，投票结束。接下来进入数据同步阶段。
   5. 数据同步阶段：主要是当前新的 leader 节点将自己的已经 commit 的数据同步给其他 follower 节点。

为什么Zookeeper集群节点一定要是奇数

因为zookeeper需要非宕机节点数过半才能使用，集群节点为奇数可以节约服务器资源。（5台——》宕机3台不可以用，宕机两台可以使用。6台——》宕机3太同样不可以使用，宕机2台可以使用。）所以这样节约一台服务器资源。

Zookeeper如何保证节点一致性问题

ZooKeeper 是通过 Zab 协议来保证分布式事务的最终一致性。Zab（ZooKeeper Atomic Broadcast，ZooKeeper 原子广播协议）支持崩溃恢复，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。
在 ZooKeeper 集群中，所有客户端的请求都是写入到 Leader 进程中的，然后，由 Leader 同步到其他节点，称为 Follower。在集群数据同步的过程中，如果出现 Follower 节点崩溃或者 Leader 进程崩溃时，都会通过 Zab 协议来保证数据一致性。

Zookeeper如果在后期新增zk节点时如何提高选举效率问题？

集群(server.1、server.2、server.3)中新增server.4和server.5两个节点，首先修改server.4和server.5的zoo.cfg配置并启动。节点4和5在启动后会变更自身投票状态，发起一轮Leader选举投票（这时server.2已经是leader了，所以4节点和5节点为Follower）。server.1、server.2、server.3收到投票后由于集群中已有选定Leader，所以会直接反馈server.4和server.5投票结果：server.2是Leader。server.4和server.5收到投票后基于过半原则认定server.2是Leader，自身便切换为Follower。

ZooKeeper集群扩容时，如果Leader节点最后启动就可以避免出现两个leader问题发生，因为在Leader节点重启前，所有的Follower节点zoo.cfg配置已经是相同的，他们基于同一个集群配置两两互联，做投票选举。

Zookeeper Zab一致性协议原理

ZAB可以说是在Paxos算法基础上进行了扩展改造而来的，ZAB协议设计了支持崩溃恢复，ZooKeeper使用单一主进程Leader用于处理客户端所有事务请求，采用ZAB协议将服务器数状态以事务形式广播到所有Follower上；

由于事务间可能存在着依赖关系，ZAB协议保证Leader广播的变更序列被顺序的处理：一个状态被处理那么它所依赖的状态也已经提前被处理；
ZAB协议支持的崩溃恢复可以保证在Leader进程崩溃的时候可以重新选出Leader并且保证数据的完整性;

在ZooKeeper中所有的事务请求都由一个主服务器也就是Leader来处理，其他服务器为Follower，Leader将客户端的事务请求转换为事务Proposal，并且将Proposal分发给集群中其他所有的Follower，然后Leader等待Follwer反馈，当有 过半数（>=N/2+1） 的Follower反馈信息后，Leader将再次向集群内Follower广播Commit信息，Commit为将之前的Proposal提交;

恢复模式:（选举）
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
崩溃恢复过程中，为了保证数据一致性需要处理特殊情况：
1、已经被leader提交的proposal确保最终被所有的服务器follower提交
2、确保那些只在leader被提出的proposal被丢弃
针对这个要求,如果让leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高的ZXID事务proposal，就可以保证这个新选举出来的Leader一定具有所有已经提交的提案，也可以省去Leader服务器检查proposal的提交与丢弃的工作。

广播模式：（数据同步）
一旦Leader已经和多数的Follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。
这时候当一个Server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，它也参与消息广播。
ZooKeeper服务一直维持在广播状态，直到Leader崩溃了或者Leader失去了大部分的Followers支持。
广播模式极其类似于分布式事务中的2pc（two-phrase commit 两阶段提交）：即Leader提起一个决议，由Followers进行投票，Leader对投票结果进行计算决定是否通过该决议，如果通过执行该决议（事务），否则什么也不做。

Zookeeper集群节点如何保证数据同步问题

ZooKeeper 是通过 Zab 协议来保证分布式事务的最终一致性。Zab（ZooKeeper Atomic Broadcast，ZooKeeper 原子广播协议）支持崩溃恢复，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。

Dubbo

Dubbo是什么？

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）

为什么要用Dubbo？

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

Dubbo 和 Spring Cloud 有什么区别？

相同点： SpringCloud和Dubbo都是现在主流的微服务架构

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

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

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

dubbo都支持什么协议，推荐用哪种？

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

Dubbo需要 Web 容器吗？

不需要，如果硬要用 Web 容器，只会增加复杂性，也浪费资源。

Dubbo内置了哪几种服务容器？

Spring Container
Jetty Container
Log4j Container

Dubbo 的服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。

Dubbo里面有哪几种节点角色？

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

Dubbo默认使用什么注册中心，还有别的选择吗？

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

Dubbo有哪几种配置方式？

Spring 配置方式、Java API 配置方式

Dubbo 配置重试次数、请求时间、负载均衡算法、并发控制？

timeout:配置超时时间（单位毫秒）
retries：配置重试次数（默认2次）
loadbalance：负载均衡算法（默认权重随机）

actives：最大并发数（默认为0，表示不限制）

Dubbo 的配置优先级？

• 下图中以timeout为例，显示了配置的查找（优先级）顺序，其它, actives等类似。
• 方法级优先，接口级次之，全局配置再次之。
• 如果级别一样，则消费方优先，提供方次之。
• 其中，服务提供方配置，通过URL经由注册中心传递给消费方。
• 建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。

13、Dubbo 核心的配置有哪些？

在 Provider 上可以配置的 Consumer 端的属性有哪些？

1）timeout：方法调用超时
2）retries：失败重试次数，默认重试 2 次
3）loadbalance：负载均衡算法，默认随机权重
4）actives 消费者端，最大并发调用限制

Dubbo启动时如果依赖的服务不可用会怎样？

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，默认 check=“true”，可以通过 check=“false” 关闭检查。

Dubbo推荐使用什么序列化框架，你知道的还有哪些？

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

Dubbo默认使用的是什么通信框架，还有别的选择吗？

Dubbo 默认使用 Netty 框架，也是推荐的选择，另外内容还集成有Mina、Grizzly。

Dubbo有哪几种集群容错方案，默认是哪种？

Dubbo有哪几种负载均衡策略，默认是哪种？

注册了多个同一样的服务，如果测试指定的某一个服务呢？

可以配置环境点对点直连，绕过注册中心，将以服务接口为单位，忽略注册中心的提供者列表。

Dubbo支持服务多协议吗？

Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

当一个服务接口有多种实现时怎么做？

当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可。

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

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

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

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

Dubbo服务之间的调用是阻塞的吗？

默认是同步等待结果阻塞的，支持异步调用。

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

异步调用流程图如下。

Dubbo支持分布式事务吗？

不支持

Dubbo telnet 命令能做什么？

dubbo 通过 telnet 命令来进行服务治理。
telnet localhost 8090

Dubbo支持服务降级吗？

Dubbo 2.2.0 以上版本支持。

Dubbo如何优雅停机？

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

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

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

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

Dubbo 可以使用 Pinpoint 和 Apache Skywalking(Incubator) 实现分布式服务追踪，当然还有其他很多方案。

服务读写推荐的容错策略是怎样的？

读操作建议使用 Failover 失败自动切换，默认重试两次其他服务器。
写操作建议使用 Failfast 快速失败，发一次调用失败就立即报错。

Dubbo必须依赖的包有哪些？

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

Dubbo的管理控制台能做什么？

管理控制台主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能。详细可以去官网看。

说说 Dubbo 服务暴露的过程。

Dubbo 会在 Spring 实例化完 bean 之后，在刷新容器最后一步发布 ContextRefreshEvent 事件的时候，通知实现了 ApplicationListener 的 ServiceBean 类进行回调 onApplicationEvent 事件方法，Dubbo 会在这个方法中调用 ServiceBean 父类 ServiceConfig 的 export 方法，而该方法真正实现了服务的（异步或者非异步）发布。

Dubbo 停止维护了吗？

2014 年开始停止维护过几年，17 年开始重新维护，并进入了 Apache 项目。

Dubbo 和 Dubbox 有什么区别？

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

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

别的还有 Spring cloud、Facebook 的 Thrift、Twitter 的 Finagle 等。

Dubbo 能集成 Spring Boot 吗？

能，详细见代码案例。

在使用过程中都遇到了些什么问题？

答：Dubbo 的设计目的是为了满足高并发小数据量的 rpc 调用，在大数据量下的性能表现并不好，建议使用 rmi 或 http 协议

你读过 Dubbo 的源码吗？

你觉得用 Dubbo 好还是 Spring Cloud 好？

答：扩展性的问题，没有好坏，只有适合不适合，不过我好像更倾向于使用 Dubbo, Spring Cloud 版本升级太快，组件更新替换太频繁，配置太繁琐，还有很多我觉得是没有 Dubbo 顺手的地方