Dubbo常见面试题(第二弹)

不念不忘少年蓝@ 2022-10-15 12:53 169阅读 0赞

## dubbo 工作原理 ##

*  第一层：service 层，接口层，给服务提供者和消费者来实现的
 *  第二层：config 层，配置层，主要是对 dubbo 进行各种配置的
 *  第三层：proxy 层，服务代理层，无论是 consumer 还是 provider，dubbo 都会给你生成代理，代理之间进行网络通信
 *  第四层：registry 层，服务注册层，负责服务的注册与发现
 *  第五层：cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
 *  第六层：monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监控
 *  第七层：protocal 层，远程调用层，封装 rpc 调用
 *  第八层：exchange 层，信息交换层，封装请求响应模式，同步转异步
 *  第九层：transport 层，网络传输层，抽象 mina 和 netty 为统一接口
 *  第十层：serialize 层，数据序列化层

## 工作流程 ##

1.  第一步：provider 向注册中心去注册
2.  第二步：consumer 从注册中心订阅服务，注册中心会通知 consumer 注册好的服务
3.  第三步：consumer 调用 provider
4.  第四步：consumer 和 provider 都异步通知监控中心

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24_size_16_color_FFFFFF_t_70]

## dubbo 支持哪些协议 每个协议之间有什么特点应用场景 ##

*  dubbo 协议 默认就是走 dubbo 协议，单一长连接，进行的是 NIO 异步通信，基于 hessian  
    作为序列化协议。使用的场景是：传输数据量小（每次请求在 100kb 以内），但是并发量很高。  
    为了要支持高并发场景，一般是服务提供者就几台机器，但是服务消费者有上百台，可能每天调用量达到上亿次！此时用长连接是最合适的，就是跟每个服务消费者维持一个长连接就可以，可能总共就  
    100 个连接。然后后面直接基于长连接 NIO 异步通信，可以支撑高并发请求。  
    长连接，通俗点说，就是建立连接过后可以持续发送请求，无须再建立连接。
 *   rmi 协议 走 Java  
    二进制序列化，多个短连接，适合消费者和提供者数量差不多的情况，适用于文件的传输，一般较少用。
 *  hessian 协议 走 hessian 序列化协议，多个短连接，适用于提供者数量比消费者数量还多的情况，适用于文件的传输，一般较少用。
 *  http 协议 走 json 序列化。
 *  webservice 走 SOAP 文本序列化。
 *  dubbo 支持的序列化协议  dubbo 支持 hession、Java 二进制序列化、json、SOAP 文本序列化多种序列化协议。但是  
    hessian 是其默认的序列化协议。

## dubbo 负载均衡策略和集群容错策略特点场景 ##

*  random loadbalance 默认情况下，dubbo 是 random load  
    balance ，即随机调用实现负载均衡，可以对 provider  
    不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。
 *  roundrobin loadbalance  
    这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。
 *  **举个栗子。** 跟运维同学申请机器，有的时候，我们运气好，正好公司资源比较充足，刚刚有一批热气腾腾、刚刚做好的虚拟机新鲜出炉，配置都比较高：8 核 +  
    16G 机器，申请到 2 台。过了一段时间，我们感觉 2  
    台机器有点不太够，我就去找运维同学说，“哥儿们，你能不能再给我一台机器”，但是这时只剩下一台 4 核 + 8G 的机器。我要还是得要。  
    这个时候，可以给两台 8 核 16G 的机器设置权重 4，给剩余 1 台 4 核 8G 的机器设置权重 2。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24_size_16_color_FFFFFF_t_70 1]

*  leastactive loadbalance  
    这个就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求。
 *  consistanthash loadbalance 一致性 Hash  
    算法，相同参数的请求一定分发到一个 provider 上去，provider  
    挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性  
    Hash 策略。

## dubbo 集群容错策略 ##

**failover cluster 模式**

失败自动切换，自动重试其他机器，默认就是这个，常见于读操作。（失败重试其它机器）  
可以通过以下几种方式配置重试次数：

<dubbo:service retries="2" />

或者

<dubbo:reference retries="2" />

或者

<dubbo:reference>
        <dubbo:method name="findFoo" retries="2" />
    </dubbo:reference>

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24_size_16_color_FFFFFF_t_70 2]

**failfast cluster 模式**  
一次调用失败就立即失败，常见于非幂等性的写操作，比如新增一条记录（调用失败就立即失败）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24_size_16_color_FFFFFF_t_70 3]  
**failsafe cluster 模式**

出现异常时忽略掉，常用于不重要的接口调用，比如记录日志。

配置示例如下：

<dubbo:service cluster="failsafe" />

或者

<dubbo:reference cluster="failsafe" />

**failback cluster 模式**

失败了后台自动记录请求，然后定时重发，比较适合于写消息队列这种。

**forking cluster 模式**

并行调用多个 provider，只要一个成功就立即返回。常用于实时性要求比较高的读操作，但是会浪费更多的服务资源，可通过 forks="2"来设置最大并行数。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24_size_16_color_FFFFFF_t_70 4]  
**broadcacst cluster**

逐个调用所有的 provider。任何一个 provider 出错则报错（从2.1.0版本开始支持）。通常用于通知所有提供者更新缓存或日志等本地资源信息。

**dubbo动态代理策略**  
默认使用 javassist 动态字节码生成，创建代理类。但是可以通过 spi 扩展机制配置自己的动态代理策略。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24_size_16_color_FFFFFF_t_70]: /images/20221014/3e3ed471dadc42ea9182098fe486bfa7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24_size_16_color_FFFFFF_t_70 1]: /images/20221014/32ffd32ec70e48db9c83932e71dae50e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24_size_16_color_FFFFFF_t_70 2]: /images/20221014/a262a87ea1c34cc3a27925b1f4ea2370.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24_size_16_color_FFFFFF_t_70 3]: /images/20221014/d28265da7992414ea97d699bed2f2893.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20210525113358641.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Byb2dyYW1tZXJfdW5pb24=,size_16,color_FFFFFF,t_70