大家好，今天来为大家解答dubbo默认超时时间这个问题的一些问题点，包括cookie的默认有效时间也一样很多人还不知道，因此呢，今天就来为大家分析分析，现在让我们一起来看看吧！如果解决了您的问题，还望您关注下本站哦，谢谢~
本文目录
一、dubbo超时时间设置过大有什么影响
客户端资源大量线程挂起。Dubbo是一个分布式服务框架，致力于提供高 *** 能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，如果超时时间设置得太短，复杂业务本来就需要很长时间完成，服务端无法在设定的超时时间内完成业务处理，如果超时时间设置太大，会由于服务端或者 *** 问题导致客户端资源大量线程挂起。需要严格把控时间。
二、使用dubbo进行直连的时候写N/A是啥意思
开源的dubbo已支持4种组件作为注册中心，我们部门使用推荐的zookeeper做为注册中心，由于就瓶颈来说不会出现在注册中心，风险较低，未做特别的研究或比较。
zookeeper，推荐集群中部署奇数个节点，由于zookeeper挂掉一半的机器集群就不可用，所以部署4台和3台的集群都是在挂掉2台后集群不可用
multicast,广播受到 *** 结构的影响，一般本地不想搭注册中心的话使用这种调用
对于zookeeper客户端，dubbo在2.2.0之后默认使用zkclient，2.3.0之后提供可选配置C *** ator，提到这个点的原因主要是因为zkclient发现一些问题：①服务器在修改服务器时间后zkClient会抛出日志错误之类的异常然后容器（我们使用resin）挂掉了，也不能确定就是zkClient的问题，接入dubbo之前无该问题②dubbo使用zkclient不传入连接zookeeper等待超时时间，使用默认的Integer.MAX_VALUE，这样在zookeeper连不上的情况下不报错也无法启动；目前我们准备寻找其他解决方案，比如使用c *** ator试下，还没正式投入。
三、dubbo服务调用异常
1、dubbo服务调用异常有可能是以下原因造成： *** 找不到、调用超时。
2、 *** 找不到：No provider *** ailable。
3、（1）Provider服务没启动，或者注册中心（比如ZooKeeper，Nacos，Consul）宕机了。
4、（2）Dubbo的服务配置有误差，必须保证服务名，组别（默认是Dubbo），version三者都正确。
5、（3）访问的环境有误：通常我们会有开发环境、测试环境、线上生产环境等多套环境。有时候发布的服务到了测试环境，而访问调用时却走了开发环境。
6、（1）服务端确实处理比较慢，无法在指定的时间返回结果，调用端就自动返回一个超时的异常响应来结束此次调用。
7、（2）服务端如果响应的比较快，但当客户端Load很高，负载压力很大的时候，会因为客户端请求发不出去、响应卡在TCPBuffer等问题，造成超时。因为客户端接收到服务端发来的数据或者请求服务端的数据，都会在 *** 层面排队，如果 *** 负载比较高，在内核态的时间占比就会加长，从而造成客户端获取到值时已经超时。
8、（3）通常是业务处理太慢，可在服务提供方机器上执行：jstack［PID］＞jstack.log分析线程都卡在哪个 *** 调用上，这里就是慢的原因。如果不能调优 *** 能，请调高timeout阈值。
9、面向接口 *** 的高 *** 能RPC调用提供高 *** 能的基于 *** 的远程调用能力，服务以接口为粒度，为开发者 *** 远程调用底层细节。
10、智能负载均衡内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高 *** 吞吐量。
11、服务自动注册与发现支持多种注册中心服务，服务实例上下线实时感知。
12、高度可扩展能力遵循微内核+ *** 件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。
13、运行期流量调度内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。
14、可视化的服务治理与运维提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。
四、如何获取dubbo上注册的referencebean
SimpleRegistryService本身也是作为一个dubbo服务暴露。
<dubbo:protocolport="9090"/>
<dubbo:service interface="com.alibaba.dubbo.registry.RegistryService"ref="registryService" registry="N/A" ondisconnect="disconnect"callbacks="1000">
<dubbo:methodname="subscribe"><dubbo:argument index="1" callback="true"/></dubbo:method>
<dubbo:methodname="unsubscribe"><dubbo:argument index="1" callback="false"/></dubbo:method>
<bean id="registryService"class="bf71-95fd-072f-7f49 com.alibaba.dubbo.registry. *** .SimpleRegistryService"/>
上面是暴露注册中心的dubbo服务配置，
发布RegistryService服务， registry属 *** 是”N/A” *** 不能获取注册中心，注册中心服务的发布也是一个普通的dubbo服务的发布，如果没有配置这个属 *** 它也会寻找注册中心，去通过注册中心发布，因为自己本身就是注册中心，直接对外发布服务，外部通过ip：port直接使用。
服务发布定义了回调接口，这里定义了subscribe的第二个入参类暴露的回调服务供注册中心回调，用来当注册的服务状态变更时反向推送到客户端。
Dubbo协议的注册中心的暴露以及调用过程过程跟普通的dubbo服务的其实是一样的，可能跟绝大多数服务的不同的是在SimpleRegistryService在被接收订阅请求subscribe的时候，同时会refer引用调用方暴露的NotifyListener服务，当有注册数据变更时自动推送
Dubbo协议向注册中心发布服务：当服务提供方，向dubbo协议的注册中心发布服务的时候，是如何获取，创建注册中心的，如何注册以及订阅服务的，下面我们来分析其流程。
<dubbo:registry protocol=”dubbo” address="127.0.0.1:9090"/>
<beanid="demoService" class="95fd-072f-7f49-39b3 com.alibaba.dubbo.demo.provider.DemoServiceImpl"/>
<dubbo:serviceinterface="com.alibaba.dubbo.demo.DemoService" ref="demoService"/>
1.指定了哪种的注册中心，是基于dubbo协议的，指定了注册中心的 *** 以及端口号
2.发布DemoService服务，服务的实现为DemoServiceImpl
每个<dubbo:service/>在spring内部都会生成一个ServiceBean实例，ServiceBean的实例化过程中调用export *** 来暴露服务
1.通过loadRegistries获取注册中心registryUrls
registry://127.0.0.1:9090/com.alibaba.dubbo.registry.RegistryService?application=demo-provider&dubbo=2.5.4-SNAPSHOT&owner=william&pid=7084®istry=dubbo×tamp=1415711791506
protocol=registry表示一个注册中心 *** l
调用注册中心的服务RegistryService
dubbo://1 *** .168.0.102:20880/com.alibaba.dubbo.demo.DemoService?anyhost=true&application=demo-provider&dubbo=2.5.4-SNAPSHOT&generic=false&interface=com.alibaba.dubbo.demo.DemoService&loadbalance=roundrobin&methods=sayHello&owner=william&pid=7084&side=provider×tamp=1415712331601
服务提供者的 *** 为1 *** .168.0.102:20880
发布的服务为com.alibaba.dubbo.demo.DemoService
3.遍历registryUrls向注册中心注册服务
给每个registryUrl添加属 *** key为export，value为上面的发布服务 *** l得到如下registryUrl
registry://127.0.0.1:9098/com.alibaba.dubbo.registry.RegistryService?application=demo-provider&dubbo=2.5.4-SNAPSHOT&export=dubbo%3A%2F%2F1 *** .168.0.102%3A20880%2Fcom.alibaba.dubbo.demo.DemoService%3Fanyhost%3Dtrue%26application%3Ddemo-provider%26dubbo%3D2.5.4-SNAPSHOT%26generic%3Dfalse%26interface%3Dcom.alibaba.dubbo.demo.DemoService%26loadbalance%3Droundrobin%26methods%3DsayHello%26owner%3Dwilliam%26pid%3D7084%26side%3Dprovider%26timestamp%3D1415712331601&owner=william&pid=7084®istry=dubbo×tamp=1415711791506
4.由发布的服务实例，服务接口以及registryUrl为参数，通过 *** 工厂proxyFactory获取Invoker对象，Invoker对象是dubbo的核心模型，其他对象都向它靠拢或者转换成它。
5.通过Protocol对象暴露服务protocol.export(invoker)
通过DubboProtocol暴露服务的 *** (不是此节内容)
通过RegistryProtocol将服务 *** 发布到注册中心，并订阅此服务
RegistryProtocol.export(Invoker)暴露服务
1.调DubboProtocol暴露服务的 ***
2.获取注册中心getRegistry(Invoker)
URL转换，由Invoker获取的 *** l是registryURL它的协议属 *** 用来选择何种的Protocol实例如RegistryProtocol， DubboProtocol或者RedisProtocol等等。这里要通过URL去选择何种注册中心，所以根据registry=dubbo属 *** ，重新设置 *** l的协议属 *** 得registryUrl
dubbo://127.0.0.1:9098/com.alibaba.dubbo.registry.RegistryService?application=demo-provider&dubbo=2.5.4-SNAPSHOT& export=dubbo%3A%2F%2F1 *** .168.0.102%3A20880%2Fcom.alibaba.dubbo.demo.DemoService%3Fanyhost%3Dtrue%26application%3Ddemo-provider%26dubbo%3D2.5.4-SNAPSHOT%26generic%3Dfalse%26interface%3Dcom.alibaba.dubbo.demo.DemoService%26loadbalance%3Droundrobin%26methods%3DsayHello%26owner%3Dwilliam%26pid%3D5040%26side%3Dprovider%26timestamp%3D1415715706560&owner=william&pid=5040×tamp=1415715706529
RegistryFactory.getRegistry( *** l)通过工厂类创建注册中心，RegistryFactory通过dubbo的spi机制获取对应的工厂类，这里的是基于dubbo协议的注册中心，所以是DubboRegistryFactory
3.获取发布 *** l就是registryUrl的export参数的值
registryProviderUrl=dubbo://10.33.37.7:20880/com.alibaba.dubbo.demo.DemoService?anyhost=true&application=demo-provider&dubbo=2.5.4-SNAPSHOT&generic=false&interface=com.alibaba.dubbo.demo.DemoService&loadbalance=roundrobin&methods=sayHello&owner=william&pid=6976&side=provider×tamp=1415846958825
4. DubboRegistry.register(registryProviderUrl)
这里注意registryProviderUrl的并没有设置category属 *** ，在注册中心UrlUtils.i *** atch(conuumerUrl, providerUrl)比较的时候，providerUrl的category属 *** 取默认值providers，
这点消费者订阅的时候会指定订阅的 *** l的category=providers，去判断有没有注册的提供者。
5.构建订阅服务overrideProviderUrl,我们是发布服务
provider://10.33.37.7:20880/com.alibaba.dubbo.demo.DemoService?anyhost=true&application=demo-provider&category=config *** ators&check=false&dubbo=2.5.4-SNAPSHOT&generic=false&interface=com.alibaba.dubbo.demo.DemoService&loadbalance=roundrobin&methods=sayHello&owner=william&pid= *** 32&side=provider×tamp=1415847417663
6.构建OverrideListener它实现与NotifyLisener,当注册中心的订阅的 *** l发生变化时回调重新export
7. registry.subscribe(overrideProviderUrl, OverrideListener),注册器向注册中心订阅overrideProviderUrl,同时将Override Listener暴露为回调服务，当注册中心的overrideProviderUrl数据发生变化时回调,
注册器DubboRegistry的registry,subscribe, unRegistry, unSubscribe都类似，是一个dubbo的远程服务调用
DubboRegistryFactory创建注册中心过程
dubbo://127.0.0.1:9098/com.alibaba.dubbo.registry.RegistryService?application=demo-provider&callbacks=10000&connect.timeout=10000&dubbo=2.5.4-SNAPSHOT& interface=com.alibaba.dubbo.registry.RegistryService&lazy=true&methods=register,subscribe,unregister,unsubscribe,lookup&owner=william&pid=84 *** &reconnect=false&sticky=true&subscribe.1.callback=true&timeout=10000×tamp=1415783872554&unsubscribe.1.callback=false
2.根据 *** l注册服务接口构建注册目录对象RegistryDircectory,实现了NotiyfLisener,这里NotiyfLisener实现主要是根据 *** ls去refer引用远程服务RegistryService得到对应的Invoker，当 *** ls变化时重新refer；目录服务可以列出所有可以执行的Invoker
3.利用cluster的join *** ，将Dirctory的多个Invoker对象伪装成一个Invoker对象，这里默认集群策略得到FailoverClusterInvoker
4. FailoverClusterInvoker利用ProxyFactory获取到RegistryService服务的 *** 对象
5.由RegistryService服务的 *** 对象和FailoverClusterInvoker构建dubbo协议的注册中心注册器DubboRegistry
6. RegistryDircectory设置注册器DubboRegistry，设置dubbo的协议
7.调用 RegistryDircectory的notify( *** ls) ***
主要是根据registryUrls，引用各个注册中心的RegistryService服务实现,将引用的服务按key=menthodName/value=invoker缓存起来,目录服务Directory.list(Invocation)会列出所调用 *** 的所有Invoker,一个Invoker *** 对一个注册中心的调用实体。
8.订阅注册中心服务,服务的提供者调注册中心的服务RegistryService属于消费方，所以订阅服务的 *** l的协议是consumer
consumer://1 *** .168.0.102/com.alibaba.dubbo.registry.RegistryService?application=demo-provider&callbacks=10000&connect.timeout=10000&dubbo=2.5.4-SNAPSHOT&interface=com.alibaba.dubbo.registry.RegistryService&lazy=true&methods=register,subscribe,unregister,unsubscribe,lookup&owner=william&pid=6960&reconnect=false&sticky=true&subscribe.1.callback=true&timeout=10000×tamp=14158007 *** 3 *** & unsubscribe.1.callback=false
订阅的目的在于在注册中心的数据发送变化的时候反向推送给订阅方
directory.subscribe( *** l)最终调用注册中心的RegsryService远程服务，它是一个普通的dubbo远程调用。要说跟绝大多数dubbo远程调用的区别： *** l的参数subscribe.1.callback=true它的意思是RegistryService的subscribe *** 的第二个参数NotifyListener暴露为回调服务； *** l的参数 unsubscribe.1.callback=false的意思是RegistryService的 unsubscribe *** 的第二个参数NotifyListener暴露的回调服务销毁。
这里dubbo协议的注册中心调注册中心的服务采用的默认集群调用策略是FailOver,选择一台注册中心，只有当失败的时候才重试其他服务器，注册中心实现也比较简单不具备集群功能，如果想要初步的集群功能可以选用BroadcastCluster它至少向每个注册中心遍历调用注册一遍
五、dubbo线程池满了会超时吗
1、在dubbo调用过程中被调用方有两个线程池：io线程池，业务线程池。
2、<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100"/>
3、all所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
4、direct所有消息都不派发到线程池，全部在 IO线程上直接执行。
5、message只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO线程上执行。
6、execution只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO线程上执行。
7、connection在 IO线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
好了，关于dubbo默认超时时间和cookie的默认有效时间的问题到这里结束啦，希望可以解决您的问题哈！
