1.Դ?源码?????ʱ
2.restTemplate设置单次访问超时时间
3.Dubbo调用超时那些事儿

Դ??????ʱ

       深入源码和内核，一篇文章彻底理解数据库的请求各种超时参数-事务超时/查询超时/连接超时/登录超时/套接字超时

       数据库在运行过程中，可能会遇到各种超时问题，源码尤其是请求在网络不稳定或业务高并发场景下。理解这些超时的源码原理、工作机制以及不同数据库中的请求表情工厂源码超时参数设置，对于排查异常情况和优化应用性能至关重要。源码本文将带你深入了解数据库超时参数的请求细节。

       数据库的源码超时参数主要包括事务超时、查询超时、请求连接超时、源码登录超时和套接字超时。请求除了这些常见的源码超时参数，客户端的请求JDBC应用程序和服务端的数据库管理系统还可能在服务器上配置操作系统级别的基于TCP keep-alive的超时检测和保活机制，以及套接字级别的源码backtrader源码解读基于TCP keep-alive的超时检测和保活机制。

       事务超时，即transaction timeout，指限制事务中所有语句处理时间之和的最大值。事务超时通常在应用框架中进行配置，例如在Spring中使用注解@Transactional指定。

       查询超时，即query timeout，限制SQL语句的最大执行时间。当执行时间超过指定的超时时间，应用端的数据库驱动程序会抛出超时异常，并发送取消执行信号给数据库管理系统，由数据库管理系统取消执行。

       连接超时，即connectTimeout，共振kdj源码驱动程序建立TCP连接的超时时间。

       登录超时，即loginTimeout，是数据库用户成功登录到数据库服务器的超时时间。考虑到登录过程中的TCP连接建立和认证，配置登录超时时通常需要大于连接超时。

       常规的套接字超时socket timeout同样适用于JDBC应用程序，用于检测和感知网络层面TCP连接异常，避免僵死连接造成的无限等待。

       登录超时、连接超时和套接字超时之间存在差异，但它们都与网络层面的通信和状态检查有关。在配置和理解这些超时参数时，需要区分它们的前端源码讲解作用范围和相互关系。

       查询超时的工作机制在不同数据库管理系统和驱动下略有不同，但基本原理相似。通常通过独立线程跟踪语句执行时间，在超时后抛出错误，并通过底层连接发送取消执行信号给数据库管理系统。

       在配置常见数据库的套接字超时时，需要注意不同的数据库管理系统可能有不同的配置方式。了解和应用这些配置可以有效优化数据库性能和稳定性。

       客户端和服务器端通常都具备基于TCP keep-alive的超时检测和保活机制。在某些情况下，还可以配置套接字级别的基于TCP keep-alive的超时检测和保活机制，进一步提高网络通信的可靠性。

restTemplate设置单次访问超时时间

       在使用restTemplate时，理解其如何设置单次访问的会员排名源码超时时间至关重要。默认情况下，restTemplate通过SimpleClientHttpRequestFactory来实现，其底层逻辑基于socket连接。然而，可以替换默认实现，采用HttpComponentsClientHttpRequestFactory。

       ### 全局自定义超时时间

       要设定全局超时时间，可以通过Factory设置。具体操作时，需要替换默认实现为HttpComponentsClientHttpRequestFactory。接着，通过配置其内部的RequestConfig类来设定超时时间。RequestConfig包含socketTimeout（读取超时时间）和connectTimeout（连接超时时间）两个属性，明确这些设置后，便能控制请求超时。

       ### 单个请求超时时间设置

       了解了全局设置后，针对单个请求超时时间的设定显得更为直接。在HttpComponentsClientHttpRequestFactory的源码中，可以通过自定义`createRequest`方法来实现。通常，此方法返回的HttpContext默认为null，这意味着RequestConfig配置值为null。因此，需要自定义该方法以生成并设置所需的RequestConfig配置。

       为了适应不同线程环境，可以设计一个持有RequestConfig线程上下文对象的类，并将其实例化为线程私有变量。接着，创建一个继承自HttpComponentsClientHttpRequestFactory的子类，并重写`createHttpContext`方法，以应用自定义的RequestConfig。

       通过实例化CustomHttpRequestFactory类，可以灵活地在不同请求中应用自定义的超时设置。在实际应用中，这有助于避免因网络延迟或其他问题导致的超时错误。

       实践示例和详细代码可参考：blog.csdn.net/yaomingya...

Dubbo调用超时那些事儿

       其实之前很早就看过Dubbo源码中关于超时这部分的处理逻辑，但是没有记录下来，最近在某脉上看到有人问了这个问题，想着再回顾一下。

开始

       从dubbo的请求开始，看看dubbo（2.6.6）在超时这块是怎么处理的：

com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeChannel#request(java.lang.Object, int)@Overridepublic ResponseFuture request(Object request, int timeout) throws RemotingException { if (closed) { throw new RemotingException(this.getLocalAddress(), null, "Failed to send request " + request + ", cause: The channel " + this + " is closed!");}// create request.Request req = new Request();req.setVersion(Version.getProtocolVersion());req.setTwoWay(true);req.setData(request);DefaultFuture future = new DefaultFuture(channel, req, timeout);try { channel.send(req);} catch (RemotingException e) { future.cancel();throw e;}return future;}DefaultFuture

       从返回值ResponseFuture类型可以看出，这是一个异步方法（不等同于Dubbo的异步调用）。那么调用超时的关键可以从ResponseFuture来看：

public interface ResponseFuture { Object get() throws RemotingException;Object get(int timeoutInMillis) throws RemotingException;void setCallback(ResponseCallback callback);boolean isDone();}

       可以看到这是一个接口，从request方法可以得知实现类是DefaultFuture，从构造函数入手：

public DefaultFuture(Channel channel, Request request, int timeout) { this.channel = channel;this.request = request;this.id = request.getId();this.timeout = timeout > 0 ? timeout : channel.getUrl().getPositiveParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT);// put into waiting map.FUTURES.put(id, this);CHANNELS.put(id, channel);}

       可以得知每一个DefaultFuture都有一个id，并且等于requestId，timeout是从url中获取的配置，没有时默认ms。

       从代码的注释可以看到FUTURES这个map应该就是关键，是一个waiting map。

       DefaultFuture中还有一个方法：

public static void received(Channel channel, Response response) { try { DefaultFuture future = FUTURES.remove(response.getId());if (future != null) { future.doReceived(response);} else { logger.warn("The timeout response finally returned at "+ (new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(new Date()))+ ", response " + response+ (channel == null ? "" : ", channel: " + channel.getLocalAddress()+ " -> " + channel.getRemoteAddress()));}} finally { CHANNELS.remove(response.getId());}}

       可以看到调用的地方为：

       com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler#received

@Overridepublic void received(Channel channel, Object message) throws RemotingException { //省略一些代码} else if (message instanceof Response) { handleResponse(channel, (Response) message);//省略一些代码}}

       com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler#handleResponse

static void handleResponse(Channel channel, Response response) throws RemotingException { if (response != null && !response.isHeartbeat()) { DefaultFuture.received(channel, response);}}

       回到DefaultFuture.received，可以看到通过Response id从FUTURES中拿了一个DefaultFuture出来，然后调用了doReceived方法，也就是说Response id和Request id 相同。结下来看看doReceived做了什么：

private void doReceived(Response res) { lock.lock();try { response = res;if (done != null) { done.signal();}} finally { lock.unlock();}if (callback != null) { invokeCallback(callback);}}

       首先是加锁，然后通过唤醒了阻塞在Condition上的线程。看看什么地方会阻塞在done这个条件上：

@Overridepublic Object get(int timeout) throws RemotingException { if (timeout <= 0) { timeout = Constants.DEFAULT_TIMEOUT;}if (!isDone()) { long start = System.currentTimeMillis();lock.lock();try { while (!isDone()) { done.await(timeout, TimeUnit.MILLISECONDS);if (isDone() || System.currentTimeMillis() - start > timeout) { break;}}} catch (InterruptedException e) { throw new RuntimeException(e);} finally { lock.unlock();}if (!isDone()) { throw new TimeoutException(sent > 0, channel, getTimeoutMessage(false));}}return returnFromResponse();}

       是get方法，get方法确实在request请求后被调用：

(Result) currentClient.request(inv, timeout).get()

       可以看到get方法的大致逻辑为，先获取锁，然后循环判断isDone，并阻塞等到条件，当条件超时，如果任务完成，或者超过timeout结束循环，接着判断isDone，如果超时抛出TimeoutException。并且通过sent（request请求时间）是否>0（）来判断是clientSide还是serverSide超时。

       isDone逻辑如下：

@Overridepublic boolean isDone() { return response != null;}

       如果是正常Response，也有可能是超时的现象，可以看到get方法最后调用了一个函数：

public interface ResponseFuture { Object get() throws RemotingException;Object get(int timeoutInMillis) throws RemotingException;void setCallback(ResponseCallback callback);boolean isDone();}0TIMEOUT SIDE

       SERVER_TIMEOUT（服务端超时）： 这个就是正常的我们消费端请求一个RPC接口，服务端由于性能等一些原因处理时间超过了timeout配置时间。

       CLIENT_TIMEOUT：我们可以看到是通过sent(上面有说sent>0)这个来判断是否clientTimeout，那么这个sent什么时候改变呢？就在发送请求的地方：

public interface ResponseFuture { Object get() throws RemotingException;Object get(int timeoutInMillis) throws RemotingException;void setCallback(ResponseCallback callback);boolean isDone();}1

       也就是说handler.sent一旦调用成功返回，那么就不算clientSide Timeout了。那么CLIENT_TIMEOUT大概率就是由于client端网络，系统等原因超时。

原文：/post/