前言
大家好,今天开始给大家分享 — Dubbo 专题之 Dubbo 延迟和粘滞连接。在前一个章节中我们介绍了 Dubbo 并发控制,Dubbo 为我们提供两大类的配置:消费端的配置和服务提供端配置,我们分别可以对服务提供端和服务消费端进行并发数量的控制。同时我们也例举了常见的使用场景并且进行了源码解析来分析其实现原理。有的小伙伴学习了并发控制可能会想到:如果我们的服务消费端有大量的服务需要引用,那我们的 Dubbo 应用程序可能启动相当的缓慢其原因是:当我们消费端应用启动的时候需要获取远程服务的代理对象的引用,如果我们每一个获取的远程代理对象都在启动的时候创建连接,这样必定会影响我们的应用程序启动,幸好我们的 Dubbo 提供一种配置的方式解决这个问题。那同时也延伸出另外一个问题,就是我们对某个服务的调用能不能一直分配到上次调用的服务提供者呢?带着这些疑问我们开始本章节学习,我们会通过介绍什么是延迟和粘滞连接?怎样通过参数配置改变默认行为?来解决这些问题。下面就让我们快速开始吧!
1. 延迟和粘滞连接简介
通过前面对 Dubbo 相关章节的介绍我相信大家应该有个基本的概念就是我们 Dubbo 中服务消费方持有服务提供端的服务引用,这个引用又通过层层的代理最终通过我们的 TCP/IP
(底层使用Netty
进行网络通讯)与远程服务端进行通讯。在 Dubbo 中为了优化消费端获取服务提供端的引用对象时候创建底层的物理连接,比如在与 Spring
集成中我们的引用对象需要通过 Spring
容器进行对外发布 Bean
实例,然而此时我们并没有真正的使用代理对象,只是将代理对象交给 Spring
管理。为了使代理对象在真正使用的时候才去创建底层的物理从而减少底层连接的创建和释放这就叫做延迟连接。同理粘滞连接的意思就是尽可能让客户端总是向同一提供者发起调用,除非该提供者挂了,再连另一台。下图简单的描述了粘滞连接在第二次、第三次调用服务的时候调用原服务提供者:
2. 配置方式
下面我们主要通过 XML 和 注解的方式进行配置介绍:
2.1 延迟连接:
- XML 方式
<dubbo:reference id="bookFacade"
interface="com.muke.dubbocourse.common.api.BookFacade" lazy="true" ></dubbo:reference>
- 注解方式
@Reference(lazy = true)
2.2 粘滞连接
- XML 方式
<dubbo:reference id="bookFacade" interface="com.muke.dubbocourse.common.api.BookFacade" sticky="true" />
方法级别控制:
<dubbo:reference id="xxxService" interface="com.muke.dubbocourse.common.api.BookFacade">
<dubbo:mothod name="queryAll" sticky="true" />
</dubbo:reference>
- 注解方式
@Reference(sticky = true)
从上面的配置中我们可以简单的总结&#x