-------------------dubbo和cloud对比------------
巧记：组件均衡注册RPC降级监控链路配置
| dubbo+zk（自带就支持吗） | cloud（自带就支持吗） | |
| 注册与服务发现 | （自带） zk(一致性---zk集群有主从区别，当master宕机，进入选举模式时，就无法正常对外提供服务。)，关注点： 1、过半选举算法--无leader时，投票过半选举，一样就看两种Id大小 2、脑裂问题--新leader出现而原leader又复活（解决：重新进行过半选举，一般新的会保留，因为它过半了，旧的挂了只有一台选它） | （自带） Eureka(高可用--集群是对等的，无主从，各自提供服务且相互注册来解决单点故障，不能保证一致性，但至少有一台存活可以提供服务) |
| 负载均衡和调用 | （自带） 1、dubbo从zk拉取提供者集群列表； 2、通讯传输协议dubbo、http、thrift、hessian 3、序列化协议hessian、xml、json、jdk序列化等 其中dubbo的RPC调用速度快，少三次握手 | （自带） Ribbon和feign: http请求 |
| 服务降级和熔断机制（可以防止雪崩） | （自带）Admin mock配置，实现dubbo服务降级---比如 屏蔽：屏蔽请求，直接返回某个值，如mock="return 123456.." 容错降级：允许请求，在请求失败的时候，再返回某个值，如：mock="fail:return 123456."; | （自带） 1.Hystrix断路器---自定义降级返回值 附：还支持nginx进行流量控制 2.熔断是指服务达到不可用阈值后，直接屏蔽，不去调，和DUBBO屏蔽类似 |
| 分布式配置中心 | （非自带） zk的持久节点唯一性； zk客户端写一个监听zk持久节点变更的方法，代码动态地同步至本地缓存 缺点---不同环境得弄不同的zk服务 | （自带）cloud-config 手动---actuator开启监控断点pom及配置，引用refreshscope注解 |
| 消息总线 | （非自带） | （自带） 一般bus是与cloud config整合： 手动去调一个服务A拉取到配置改动（访问/bus/refresh接口），A会发布消息总线的队列，其他订阅监听事件的服务会接收变更事件消息，也会去消费拉取一次最新的配置。 |
| 消息驱动 | （非自带） | （自带） 集成不同消息中间件的实现 |
| 网关 | （非自带） | （自带）Zuul 聚合API接口，统一接口转发 |
| API文档收集 | （非自带） | （自带）Swagger2 在网关统一收集API文档 l限流 重试机制 负载均衡 |
| 监控中心可视化界面 | （自带）monitor 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心，监控中心则使用数据绘制图表来显示。 | （自带） 监控中心Actuator+可视化AdminUI： 看到Http接口接口调用情况/内存变化/服务连接情况/bean数量 |
| 链路监控跟踪系统（耗时、日志等） | （非自带）客户端字节码注入探针+skywalking+ES 主导----用 Skywalking 做dubbo分布式链路追踪，Skywalking 分析调用关系、调用时间为主 辅助----可集成elk来看服务调用异常及日志为主
| （自带）Sleuth+MQ+Zipkin+ES Zipkin优点：轻量，使用部署简单（拦截请求，发送（HTTP，mq）数据至zipkin服务） |
------------------------------------------zk------------------------------
------zk集群------
从节点处理读请求和投票权
------zk节点------
znode 共有 4 种类型，分别为：持久（无序）、临时（无序）、持久有序和临时有序
------持久节点和临时节点原理及区别-----(默认都是无序的)-
临时节点:dubbo服务（消费和生产者都是）在zk创建的临时节点,当zk客户端与zk服务端断开连接后,由于zk的心跳机制,临时节点会被删除。
持久节点:比如zk配置中心锁，需要主动来删节点
------zk分布式配置中心的原理---
服务端：znode path的定义（包括存储内容）＼修改功能--持久节点（无序）
客户端：监听作用，本地缓存
------zk分布式锁的原理---
首先会有一个永久节点\Locks，然后每个客户端请求的时候会创建一个临时有序节点，在这时每个都是有序的，最小的节点就意味着获取了锁。
在此图上显然ClientC获取了锁，其他的锁获取的节点不是最小的，但是他们前面已有最早占锁的链接，就是lock_00000001在虽然没有获取锁，但是会需要监听lock_00000000的，因为如果监听所有节点的话会浪费很多的资源。相应的大的节点都会watch比自己小的节点，当比自己节点小的节点释放之后然后就可以继续处理了。
------zk在dubbo框架下的原理-
当zk在dubbo框架中用做服务发现和注册（zk注册中心根目录是永久节点）时，会创建一个 /dubbo的永久节点，服务提供方会在/dubbo根目录下需创建临时节点(服务名称、provider的ip、端口)，
服务订阅方也会在/dubbo下需创建临时节点(consumer的ip、端口)。这样，当服务发布方和订阅方发生变化时，ZK会及时更新/dubbo下面的节点列表，会触发变更节点上绑定的Watcher（比如调用者节点就设置了Watcher）
------Watcher（事件监听器）------
Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去
------Zookeeper分布式配置中心原理------
分布式配置中心 （非自带）zk的持久节点唯一性；zk客户端写一个监听zk持久节点变更的方法，Watcher动态地同步至客户端本地缓存配置缺点---不同环境得弄不同的zk服务
------Zk过半选举流程------
1、初始化leader选举，投票
给自己投票 myid zxid 0
2、每个服务器接受投票
(1 0) (2,0) (3,0) >myid 谁最大谁就是leader 33错了 32
3、处理投票
别的服务器 pk
4、统计投票
过半票数n=n/2+1;
5、服务器状态变更
Leader，其他票数低 f
------Zookeeper心跳机制原理------
------------------------------------------dubbo------------------------------
------java spi------
META-INF/services/目录里同时创建一个以服务接口命名的文件,里面放入具体实现子类。
JDK包里通过写好的java.util.ServiceLoader去查到你自定义的实现子类
------dubbo spi------
不同点是：接口扩展点必须指定一个变量名称，来限制你的自定义实现子类和dubbo已存在的接口匹配。
META-INF/services/目录里同时创建一个以服务接口命名的文件,里面放入name=具体实现子类.
演示Dubbo 重写Filter SPI机制：
1.编写Filter 过滤器
2. 编写 dubbo spi 配置文件
dubbo spi 目录文件
dubbo spi 文件内容：
luban=tuling.dubbo.server.LubanFilter
3. 装配自定义Filter
------dubbo透明代理------
javassist动态代理来实现的，好处是比较简单，可以直接给代理类传java代码
负载均衡
------负载均衡------
负载均衡算法在服务和客户端都可配，建议服务端配（自已才知道接口特性），但以客户端优先
注：服务端负载均衡配置是通过zk传递到客户端的
------容错机制------
：当服务调用失败时采取的策略
------调用方式------
支持同步调用、异步调用
------调用通信内部实现源码分析------
泛化提供
提供者写代码将服务接口暴露至zk的方式。通常用于Mock框架或服务降级框架实现。
泛化引用
调用者写代码将服务接口从zk拿到的方式。
隐示传参
是指通过非常方法参数传递参数，类似于http 调用当中添加cookie值。
用于分布式链路追踪的实现。使用方式如下 ：
//客户端隐示设置值
RpcContext.getContext().setAttachment("index", "1"); // 隐式传参，后面的远程调用都会隐
//服务端隐示获取值
String index = RpcContext.getContext().getAttachment("index"); （getContext()里返回的threadlocal的T是RpcContext）
令牌验证
通过令牌验证在注册中心控制权限，以决定要不要下发令牌给消费者，可以防止消费者绕过注册中心访问提供者，另外通过注册中心可灵活改变授权方式，而不需修改或升级提供者
---断线重连（客户端netty连接检测）---
c.dubbo客户端启动时，会开启一个fix延迟定时调度线程器,专门定时2s检测与服务端的netty连接
（如果没有，就建立连接；超时就重连；如果提供者服务挂了zk等40秒通知了客户端，客户端有个bug还检测连接，每2s就会不停刷连接失败）
---心跳机制（客户端netty服务可用与否检测）---
在创建一个连接客户端同时也会创建一个心跳客户端，dubbo客户端默认基于60秒发送一次心跳来保持连接的存活，可通过 heartbeat 设置。
---提供者突然断开---
基于Zookeeper 临时节点机制实现，在zk客户端长连接netty会话超时后 Zookeeper会自动删除所有临时节点，默认为40秒
---TCP协义传输当中的拆包与粘包问题---
TCP是面向字节流的无边边界协议，其只管负责数据传输并不会区分每次请求所对应的消息.
tcp为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。
这时就会出现以下情况：
1.应用程序写入的数据大于MSS大小，这将会发生拆包（把多余的拆掉）。
2.应用程序写入数据小于MSS大小，这将会发生粘包（把两次接收的一部分粘在一起）。
3.接收方法不及时读取套接字缓冲区数据，这将发生粘包。
拆包与粘包解决办法：
1.设置定长消息，服务端每次读取既定长度的内容作为一条完整消息。
2. {"type":"message","content":"hello"}\n
3.使用带消息头的协议、消息头存储消息开始标识及消息体长度信息，服务端获取消息头的时候解析出消息长度，然后向后读取该长度的内容。
比如：Http协议 header 中的 Content-Length 就表示消息体的大小。
-----Dubbo与DubboX区别----
dubbo：使用Dubbo的RPC调用方式，服务间仍然会存在API强依赖；
dubbox：dubbox支持了REST风格的原创调用（HTTP +JSON/XML）；
-------------------RPC------------
？RPC接口与HTTP接口相比，有什么优势？
HTTP协议，需要带HTTP请求头，导致传输起来效率或者说安全性不如RPC，特别是微服务里业务请求十分频繁的情况下不适合；
长链接减少3次握手，不必每次通信都要像http 一样去3次握手什么的，减少了网络开销
其次就是RPC框架一般都有注册中心，具有SOA服务治理，，有丰富的监控管理、发布、下线接口、动态扩展等
第三个来说就是安全性
RPC原理？
1.服务消费方（client）调用以本地调用方式调用服务；
2.client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3.client stub找到服务地址，并将消息发送到服务端；
4.server stub收到消息后进行解码；
5.server stub根据解码结果调用本地的服务；
6.本地服务执行并将结果返回给server stub；
7.server stub将返回结果打包成消息并发送至消费方；
8.client stub接收到消息，并进行解码；
9.服务消费方得到最终结果。
Dubbo RPC调用的真正原理？（最重点）
巧记版：
1）客户端用唯一ID与请求报文+callback放入全局ConcurrentHashMap，然后再封装ID+报文进连接对象发起异步调用，然后当前线程A开始阻塞wait等待服务端的回调（future的get()）。
2）服务端收到请求后把带这个ID的结果返回给客户端。
3）客户端socket连接里，专门监听消息的线程收到消息后，拿到ID从ConcurrentHashMap取出callback，并把返回结果放进callback，然后通过notifyAll()唤醒之前客户端等待的线程A，线程A醒了之后，重新执行future对象callback.get()去抓取刚刚放进去的结果，整个调用完成。
分析源代码，基本原理如下：
1）dubbo客户端当前线程，先将请求报文（如调用的接口名称，方法名称，参数值列表等），和等待回调对象callback，全部封装在一个object对象里。同时，会生成一个唯一的ID（AtomicLong从0累加），把这个ID和object存入全局ConcurrentHashMap里。
同时，再把将ID和请求报文封装成一对象connRequest（前面object里比这里多了一个callback），使用IoSession.write(connRequest)异步发送出去，正式调用服务器。
同时，客户端当前线程再使用callback的get()方法去试图获取远程返回的结果，如果没有就“等待”，（在get()内部，则使用synchronized获取回调对象callback的锁， 再先检测是否已经获取到结果，如果没有，然后调用callback的await()方法，释放callback上的锁，让当前线程处于等待状态）。
2）服务端接收到请求并处理后，将带ID的结果发送给客户端。
3）客户端socket连接里，专门监听消息的线程收到消息，分析结果，取到ID，再从前面的ConcurrentHashMap里面get(ID)，从而找到callback，将方法调用结果设置到callback对象里。
该监听线程接着使用synchronized获取回调对象callback的锁（因为前面调用过wait()，那个线程已释放callback的锁了），
再notifyAll()，唤醒前面处于等待状态的线程继续执行，callback的get()方法继续执行就能拿到调用结果了，至此，整个过程结束。
-------------------dubbo+zk+监控的搭建-------------
？我搭建过，如何搭建？
引用：https://blog.csdn.net/mijichui2153/article/details/81102277
0、搭建java和tomcat环境
一、搭建zookeeper
下载zk软件安装包zookeeper-3.5.3-beta.tar，存放在tomcat目录 /usr/mysoftware/tomcat ，创建建立logs文件夹和data文件夹用于存放日志和数据。修改端口等配置
clientPort使用默认的2181端口即可：
（配集群再另说）。
在进入到bin目录，启动tomcat服务：
二、搭建dubbo监控中心
版本要求：
下载admin软件安装包dubbo-admin-2.5.6.war及以上版本，否则会不支持JDK1.8！
存放在tomcat目录，修改配置dubbo.properties文件指向Zookeeper注册中心的IP地址 ，（说明监控管理中心是直接读的zk，由zk去收集提供者和调用者信息）
然后启动tomcat服务
三、接下来继续生产者和生产者的系统搭建
提供者：
maven引入zkclient包，dubbo包.
启动类加上@EnableDubbo，接口实现类直接用dubbo自带的@Service往注册中心注册提供者接口服务，通过配置向注册中心注册接口服务信息。
调用者：
maven引入zkclient包，dubbo包，提供者接口所在的pom包.
启动类加上@EnableDubbo，业务层直接用dubbo自带的@Reference从注册中心获取提供者接口列表，然后本地调用（底层会以真实地址调用）。
分别把它两放入tomcat启动。
？搭建和使用过程中遇到哪些问题？
1 、监控项目需要更改配置
Java代码
- dubbo.jetty.directory=/home/xx/dubbomitor/dubbo-monitor-simple-2.5.5/monitor
- dubbo.charts.directory=${dubbo.jetty.directory}/charts
- dubbo.statistics.directory=/home/xxx/dubbomitor/dubbo-monitor-simple-2.5.5/monitor/statistics
monitor 这个文件夹需要自己创建的。statistics,charts文件夹，监控项目会自动创建。
2 、项目服务端和客户端增加配置,不然一直找不到服务
statistics 对应的服务端。配置文件中增加
<dubbo:monitor protocol="registry"/>
charts 对应的客户端
<dubbo:monitor protocol="registry"/>
3、zk的端口和tomcat的端口冲突了。如果tomcat先启动了那么zk就无法真正的启动。归根结底：zk的默认端口是8080，这个是和tomcat的默认端口冲突，这回造成每次两者只能启动一个另一个启动不成功。
验证：你直接将tomcat和zk都启动，然后查看端口占用情况“netstat -an |grep 8080”。如下图所示显然是冲突了。
解决办法：在上面vim zoo.cfg 中加上一句
admin.serverPort=8088 #改为没有被占用的端口号
4、如果还是连不上的话关闭防火墙试试。
5、Service用成了spring的
-------------------dubbo+网关gateway-------------
简介：
该网关系统，它所使用的web容器仍为tomcat。
仍会采用nginx作为反向代理服务器，主要是由于nginx的单机高并发能力高，以及后端服务的高可用检测;
网关的作用？
并发量限制
校验拦截
-------nginx实现高并发的原理------
Nginx 采用的是多进程（单线程） & 多路IO复用模型。使用了 I/O 多路复用技术的 Nginx，就成了”并发事件驱动“的服务器。
nginx的单机高并发能力5W,nginx集群lvs还可以让nginx防止故障等问题
-------------------dubbo-------------
？dubbo底层原理？
1.服务容器负责启动，加载，运行服务提供者。
2.服务提供者在启动时，向注册中心注册自己提供的服务。
3.服务消费者在启动时，向注册中心订阅自己所需的服务。
4.注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
5.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
6.服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
？Dubbo的作用或优点（为什么要使用dubbo）？
以12306系统为例，平日里的访问量和春运时的访问量是完全不同的。春运时硬件设备容量不足，肯定需要临时租用一些硬件设备动态加入，用完又动态撤下来，不影响服务。dubbo就是其中一种解决方案能动态的、流动性的调度各个服务。
Dubbo的心跳机制？（默认心跳间隔时间1分钟；）
dubbo源码里会启动心跳任务方法；（双方都有心跳互相调）
比如，消费者最后一次发或收消息的时间差大于心跳间隔时，会触发心跳方法内的心跳业务块去调用一次服务发送心跳消息给提供者。如果3次都没有收到心跳响应，
consumer的定时心跳任务会进行重连服务端。
而provider的定时心跳任务，超时3次，会关闭服务端自已通道channel;；
dubbo客户端和dubbo服务端之间存在心跳。
dubbo服务端和注册中心（zk）存在心跳。
-----dubbo服务提供者的并发量设置（dubbo线程池）-----
dubbo Provider端线程并发数默认是200，我们一舟山把设置threads=500
<dubbo:protocol name="dubbo" port="${dubbo.protocol.port}" threads="500" threadpool="smycached" />
-----dubbo服务提供者和消费者的超时设置和重试设置-----、
https://blog.csdn.net/Black__sheep/article/details/80780895?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param
一 、超时，timeout是以consumer为准
Dubbo超时机制导致的雪崩连接（）
（）
https://blog.csdn.net/qq_26222859/article/details/80493448
消费端设的超时，当消费端发起一次请求后，如果在规定时间内未得到服务端的响应则直接返回超时异常，然后服务端继续执行。--客户端后续再对调用结果进行补偿查询，服务接口要实现幂等
服务端设的超时，当消费端发起一次请求后，一直等待服务端的响应，服务端在方法执行到指定时间后如果未执行完，此时主动返回一个超时异常给到消费端，然后服务端继续执行。
dubbo的超时是争对客户端的，由于是一种NIO模式，消费端发起请求后得到一个ResponseFuture，然后消费端一直轮询这个ResponseFuture直至超时或者收到服务端的返回结果。虽然超时了，但仅仅是消费端不再等待服务端的反馈并不代表此时服务端也停止了执行。
二、dubbo 重试机制 retires 默认2次
1）不要用默认的(retires应设为0)，因为重复入库的问题:第一个请求在超时后未返回，先不抛TimeoutException，调用者会自动再调一次，还超时，会再调第二次。总计调三次，假如是更新加钱操作，可能就加三次了
2）dubbo超时再重试--造成dubbo服务雪崩的问题（redis没有雪崩，而是mysql查后放redis整个过程耗时长，然后dubbo超时了，触发设置的dubbo重试，比如dubbo线程池设地500，并发高时有持续300，正好遇到Null值热点并发，重试第二次时300+实时300=600次；第一批重试第三次时（第二批正好重试第二次，新数据也刚来），并发=300+300+实时300=600次）。
https://blog.csdn.net/u014721131/article/details/52763707
1）对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。
2）对于存在tair或者其他中间件缓存产品，对NULL数据进行缓存，防止出现缓存的变相击穿问题
？选dubbo的原因(与cloud比)？
1、Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
2、SpringCloud基于Http调用的方式，更加灵活，但是消息封装臃肿(可以使用gzip压缩)；Dubbo基于RPC调用的方式（但提供者与zk之间是用的netty,scoket->netty(长连接有状态)），使服务就像可以调用自己本地的服务一样调用别人的服务
3、Dubbo 的定位始终是一款并发 RPC 框架，而 Spring Cloud 的目标是微服务架构下的一站式解决方案.如果公司对效率有极高的要求建议使用 Dubbo，相对比 RPC 的效率会比 HTTP 高很多
(Dubbo缺点是只支持java)
？选cloud的原因(与dubbo比)？
Dubbo 的定位始终是一款 RPC 框架，而 Spring Cloud 的目标是微服务架构下的一站式解决方案
如果公司选择微服务架构去重构整个技术体系，那么
Spring Cloud 是当仁不让之选，它可以说是目前最好的微服务框架没有之一，并且可以断言，将来Dubbo可以很好的整合到Spring Cloud中。
Spring Cloud是一个全家桶。
？dubbo与cloud的相同点和不同点?
引用：https://blog.csdn.net/zhanggqianglovec/article/details/104055255
巧记：组件均衡注册RPC降级监控链路配置
回答1相同点：
dubbo和spring cloud都是微服务框架。
服务发现：就是不用知道服务的ip端口，通过服务名就能使用服务。
回答2不同点：
1、功能组件范围：Dubbo 关注于服务治理这块并且以后也会继续往这个方向去发展，Spring Cloud 关注的是微服务的全套解决方案。Dubbo的功能包括服务注册发现，远程调用，监控等等。Cloud包括全套组件。
2、服务注册和发现：spring cloud服务服务注册和发现,是Eureka组件，Eureka就是为了服务发现而设计的。Dubbo的服务发现模块基于zookeeper实现，是用来保证分布式一致性的一个软件。不是为了服务发现注册而设计的;
3、调用方式：Spring Cloud 抛弃了 Dubbo 的 RPC 通信，Cloud采用的是基于 HTTP调用 的 REST 方式（当然它也有第二种方式和dubbo类似，即接口实现+注解）， Cloud 的REST 相比 RPC 更为灵活，服务提供方和调用方不存在代码级别的强依赖，这在强调快速演化的微服务环境下显得更加合适。但Dubbo 的 RPC服务调用的性能更好
4、阿里的Dubbo和spring家族的Cloud。
特点比较：
运行流程比较
Dubbo：
SpringCloud：(ribbon可用feign替换，以接口+注解方式替换restTemplate)
-------------------Dubbo负载均衡（需利用zk）-------------
负载均衡手写？
？负载均衡工作原理？
每个服务提供者启动时创建一个父节点（存在则重复用），应用客户端通过读取节点列表获得可用服务器列表，并订阅节点事件。若有服务提供者宕机断开时触发事件，客户端监测到后把该Server从可用列表中删除。若有新增节点，也触发订阅的节点事件，列表+1
图
？负载均衡的作用或优点？
负载均衡作用：高可用。
Zookeeper注册中心作用：当提供者出现断电等异常停机时，Zookeeper注册中心能自动删除提供者信息，当提供者重启时，能自动恢复注册数据，以及订阅请求。
？我搭建过，如何搭建？
？搭建和使用过程中遇到哪些问题？
？负载均衡dubbo与nginx的区别?
dubbo的负载均衡是服务层面（在http调用之前，本地负载），nginx的负载均衡在http请求层面。
dubbo在服务发现这个地方做的更像一个dns（解析别名找到具体提供者地址）。
-------------------zookeeper自带集群（是zk自已，不是客户端）-------------
？Zookeeper自带的特性（是zk自已，不是客户端）？
1、Zookeeper：一个leader，多个follower组成的集群（只要zk集群中有半数以上节点存活，集群就能提供服务）
2、全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的
3、分布式读写，更新请求转发，由leader实施
4、更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
5、数据更新原子性，一次数据更新要么成功，要么失败
6、实时性，在一定时间范围内，client能读到最新数据
-------------------Zookeeper注册中心-------------
？Zookeeper注册中心的原理？
？Zookeeper与eureka的区别？
检测节点服务变化的不同：前者长连接发现变化，就立马事件通知；心跳机制间隔性检测变化，然后通知
-------------------zookeeper分布式锁-------------
？分布式锁工作原理？
主要得益于 ZooKeeper 为我们保证了数据的强一致性.
一个是 保持独占阻塞锁，所有客户端都去创建临时节点，最终成功创建的那个客户端也即拥有了这把锁。
另一个是 控制时序,所有客户端都去创建临时有序节点，临时拥有了这把锁，用完断开连接就释放，全局时序执行下一个。
（估计只有分布式配置中心创建的才是持久节点）
？zookeeper分布式锁怎么实现的（实现原理）？
答：唯一性和集群的强一致性（2pc）
通过一起去创建临时节点同一个节点 的方式来实现。每个节点是唯一的，只能有一个成功
所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。（使用临时节点，失效时间容易控制，程序执行完成之后此序列节点消失）
步骤：https://www.cnblogs.com/toov5/p/9899489.html
多个客户端（jvm）同时在Zookeeper上创建同一个相同的临时节点；（zkClient.createEphemeral(lockPath)）
jvm1创建成功时候，jvm2和jvm3创建节点时候会报错，该节点已经存在；（这时候 jvm2和jvm3进行等待）
jvm1执行完毕，释放锁。关闭当前会话连接（就会清除临时节点）。临时节点不复存在了并且事件通知Watcher，jvm2和jvm3继续创建。
？的作用或优点？
一致性、阻塞；
简单，且宕机了会释放锁
-------------------Zookeeper配置中心-------------
？Zookeeper配置中心的原理？（注意多了一个管理系统和其数据库）
利用发布与订阅模型。
发布者管理系统负责把数据持久化到数据库mysql等（服务挂了可再读mysql，重新发布到zk上，类似dubbo注册的服务发现）
有数据变更，发布者管理系统会将数据发布到ZK服务器节点上。
每个zk客户端客户端连接zk后，在zk客户端本地绑定一个监听器,开启事件监听开关，实现订阅。如果zk有变更就会通知zk客户端，执行监听器类的代码，把值同步到本地缓存。
？的作用或优点，基于Zookeeper实现分布式配置中心有什么好处？
一、答：实时推送稳定性、实效性。
优势
1、多个环境配置集中管理。
2、配置更改，实时推送，jvm环境变量及时生效。
3、依靠配置变更，动态扩展功能，减少二次上线带来的成本。
4、减少开发人员、运维人员修改配置带来的额外开销。
---------以前的-------
？dubbo 负载均衡策略算法有几种，及其手写算法？
1.random loadbalance
默认,随机调用实现负载均衡，可以对 provider 不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。
2.roundrobin loadbalance 轮询调用（权重比相同的一种）或权重调用
这个的话默认就是轮询调用，均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。
2.1写重算法（偏随机性）：
2.2精准轮询算法（权重相等且按顺序严格执行）：
3.leastactive loadbalance
这个就是自动感知机器性能调用，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求。
4.consistanthash loadbalance
一致性 Hash 算法，相同参数的请求一定分发到一个 provider 上去，provider 挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性 Hash 策略。
？Dubbo有几种容错机制（某个机器挂了）？
1.failsafe 失败安全，可以认为是把错误吞掉（记录日志）
2.failover(默认) 重试其他服务器；retries(2)重试的次数，默认为2次---故障转移
3.failback 失败后自动恢复
4.forking forks. 设置并行数
5.Broadcast 广播，任意一台报错，则执行的方法报错，通过cluster方式，配置制定的容错方案
----zk服务存在的问题----
但是zk会出现这样一种情况，当master节点网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，重新选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间zk注册服务瘫痪。
-----Dubbo------
？RPC传统有哪些调用方式？dubbo 跟传统的http请求的区别？
一、答：scoket/netty（是scoket封装升级版）/httpClient （注意Restful是短连接无状态，Netty是长连接有状态）
一、答：
dubbo设计之初基本都是考虑内网通讯，安全上基本没什么考虑，比http的安全差远了。
rpc长连接、传输效率较高，适用于内部系统互联；
http短连接，协议标准化且易读，容易对接外部系统，适用于上层业务模块
？Dubbo的核心特性(能做什么)？
巧记：均衡注册RPC灰度
高性能 RPC 分布式服务框架（分布式服务框架、高性能透明化的RPC远程调用、SOA服务治理方案）,采用spring的配置方式进行配置，完全透明化的接入应用
一、dubbo的核心特性（核心服务）:
1.RPC长连接调用(序列化透明的远程通讯): RPC 主要解决远程调用问题，让调用者无感知透明，屏蔽了远程的调用细节
2.集群负载均衡（服务器均匀调用）: 访问量越来越大，一台服务器不够用了，那就得多放几台服务器。dubbo就会看哪台服务器比较空闲了，然后让它去处理一下该请求。
3.服务自动注册发现（zk服务管理）: 引入了注册中心zk服务，用来感知所有的服务，所有的服务都注册到这个注册中心里，统一管理使服务调用方能动态的查找服务提供方（某服务机器挂了zk还会切别的），使地址透明，使服务提供方可以平滑增加或减少机器。
4.运行期流量调度（灰度发布）：Dubbo 通过配置路由策略，可以实现灰度发布，一部分使用旧代码服务，一部分使用新的
5.可视化的服务治理和运维（SOA服务治理方案-监控，和3有点重合）：可以通过可视化页面来实时查询一些服务的状态，包括基本信息、健康状况等等，也可以去调节等等，方便来监控和运维
灰度发布常见一般有三种方式:
-
Nginx+LUA方式
-
根据Cookie实现灰度发布
-
根据来路IP实现灰度发布
？@reference和@resource的区别？
@reference是dubbo注解。
@resource是属于J2EE的的,按变量名（就是id）注入，（@Resource默认按 byName（就是id）注入；@Autowired是spring的，按byType注入，只能有一个子类，不然会异常）
？dubbo的服务降级目的是什么(服务器压力剧增如何保证服务正常)？降级分几类？降级是怎么操作的？
服务降级目的是为了保证核心服务可用。
降级可以有几个层面的分类：自动降级，人工降级；按照功能可以分为：读服务降级和写服务降级；
1.对一些非核心服务进行人工降级，在大促之前通过降级开关关闭那些推荐内容，评价等对主流程序没有影响的功能
2.故障降级，比如调用的远程服务挂了，网络故障，或者RPC服务返回异常。那么可以直接降级，降级的方案比如设置默认值，采用兜底数据（系统推荐的行为广告挂了，可以提前准备静态页面做返回）等等
3.限流降级，在秒杀这种流量比较集中并且流量特别大的情况下，因为突发访问量特别大可能导致系统支撑不了。这个时候可以采用限流来限制访问量。当达到阈值时，后续的请求被降级，比如进入排队页面，比如跳转到错误页面（活动火爆，请稍后重试）
Dubbo的降级方式：Mock (人工降级的话mock到不再弹出推荐内容，故障和限流分别mock向一些静页面和请稍后重试页)
实现步骤
1.在client端创建一个testmock类，实现对应的接口（需要对哪个接口进行mock，就实现哪个）名称必须以mock结尾
2.在client端的xml配置文件中，添加如下配置，增加一个mock属性指向创建的testmock
3.模拟错误（设置timeout）模拟超时异常，运行测试代码即可访问到testmock这个类，当服务端故障解除以后，调用过程将恢复正常
？配置优先级别是怎么样的（以timeout为例）？
1.以timeout为例，显示了配置的查找顺序，其他retries，loadbalance等类似。
（1）方法级优先，接口级次之，全局配置在次之
（2）如果级别一样，则消费方优先，提供方次之
（3）其中，服务提供方配置，通过URL经由注册中心传递给消费方
2.建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。
？SpringBoot与Dubbo整合的三种方式？
目的都是把服务提供者或消费端信息（暴露或提供哪个类），zk信息，监控中心配置注入到Dubbo容器里
1、application.properties中配置自动扫配置包路径等，因为集成了dubbo的所有属性，只需要赋值就行。duboo自带的@Service注解来暴露服务，使用@Reference来引用服务（启动类里要加@EnableDubbo来自动扫配置包路径下的带@Service的类发布服务）
2、引入dubbo.xml配置文件，保留Spring的方式，启动类中要通过 @ImportResource 注解引入配置xml，服务dubbo.xml及提供者provider.xml，（服务方暴露服务有两种方式：1）@Service注解只能暴露整个类服务 2）dubbo.xml配置里能指定暴露某类某个方法）
3、使用注解API的方式（注解类配置类），比如***Config 注解类的配置主要有三点：①注解类加注解@Configuration；②每个注解项添加@Bean注入到容器中；③准确使用注解API。定义完注解类之后，还需要配：@DubboComponentScan注解指定dubbo扫描配置类路径，这里值配你要配置所在路径就好。
----- zookeeper------
？Zookeeper的作用？
分布式的注册中心，通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务名对应关系从列表中删除(集群是多个机器的ip对应一个服务名)，如果无服务机器存活会通知消费者。
优点：
1.负载均衡，为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；
2.资源同步，单单有负载均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；
3.命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布（serviceName和URL地址分别就是持久节点和临时节点，临时节点是可以频繁变更IP这些的）
2.还有分布式锁，Mast选举等
？通讯新协议的对比？
https://blog.csdn.net/yuer2008200820008/article/details/80208025
1、hessian
Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现
基于Hessian的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：Hessian二进制序列化
适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。
适用场景：页面传输，文件传输，或与原生hessian服务互操作
1818
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
