关于超时

为了让所有通信任务可以在用户的预期下精确运行，我们提供了大量的超时配置功能，并且确保这些超时的准确性。
这些超时配置里，有些是全局的，比如连接超时，但你又可以通过upstream功能，给某个域名配置自己的连接超时。
有一些超时是任务级的，比如完整发送一条消息的超时。因为用户需要根据消息大小，动态配置这个值。
当然对server来讲，又有自己的超时整体配置。总之，超时是一件很复杂的事，我们会做得很精确。
所有超时都采用poll风格，也就是int型，毫秒级，-1表示无限。
另外，正如我们在项目介绍里说的，所有的配置你都可以忽略，可以等遇到实际需求了再进行调整。

基础通信超时配置

在EndpointParams.h文件里，可以看到：

  1. struct EndpointParams
  2. {
  3.     size_t max_connections;
  4.     int connect_timeout;
  5.     int response_timeout;
  6.     int ssl_connect_timeout;
  7. };
  9. static constexpr struct EndpointParams ENDPOINT_PARAMS_DEFAULT =
  10. {
  11.     .max_connections        = 200,
  12.     .connect_timeout        = 10 * 1000,
  13.     .response_timeout       = 10 * 1000,
  14.     .ssl_connect_timeout    = 10 * 1000,
  15. };

其中，与超时相关的配置包括以下3项。

  • connect_timeout: 与目标建立连接的超时。默认为10秒。
  • response_timeout: 等待目标响应的超时，默认为10秒。代表成功发送到目标、或从目标读取到一块数据的超时。
  • ssl_connect_timeout: 与目标完成SSL握手的超时。默认为10秒。

这个结构体是通信连接的最基础的配置，后续几乎所有的通信配置都会含有这个结构体。

全局超时配置

在WFGlobal.h文件里，可以看到我们一个全局配置信息：

  1. struct WFGlobalSettings
  2. {
  3.     EndpointParams endpoint_params;
  4.     unsigned int dns_ttl_default;
  5.     unsigned int dns_ttl_min;
  6.     int dns_threads;
  7.     int poller_threads;
  8.     int handler_threads;
  9.     int compute_threads;
  10. };
  12. static constexpr struct WFGlobalSettings GLOBAL_SETTINGS_DEFAULT =
  13. {
  14.     .endpoint_params    =    ENDPOINT_PARAMS_DEFAULT,
  15.     .dns_ttl_default    =    12 * 3600,    /* in seconds */
  16.     .dns_ttl_min        =    180,          /* reacquire when communication error */
  17.     .dns_threads        =    8,
  18.     .poller_threads     =    2,
  19.     .handler_threads    =    20,
  20.     .compute_threads    =    -1
  21. };
  22. //compute_threads<=0 means auto-set by system cpu number

其中，与超时相关的配置就是EndpointParams endpoint_params这一项

修改全局配置的方法是，调用我们任何工厂函数之前，执行类似下面的操作：

  1. int main()
  2. {
  3.     struct WFGlobalSettings settings = GLOBAL_SETTINGS_DEFAULT;
  4.     settings.endpoint_params.connect_timeout = 2 * 1000;
  5.     settings.endpoint_params.response_timeout = -1;
  6.     WORKFLOW_library_init(&settings);
  7. }

上例把连接超时修改为2秒，server响应超时为无限。这种配置下，每次任务里都必须配置接收完整消息的超时，否则可能陷入无限的等待。
全局的超时配置，可以通过upstream功能，被单独的地址配置覆盖，比如你可以指定某个域名的连接超时。
Upstream每一个AddressParams也有一个EndpointParams endpoint_params项，使用方式与Global相仿。
具体结构详见upstream文档

Server超时配置

在http_proxy示例的里，我们介绍过server启动配置。其中超时相关的配置包括：

  • peer_response_timeout: 这个的定义和全局的peer_response_timeout一样，指的是远程client的响应超时，默认为10秒。
  • receive_timeout: 接收一条完整请求的超时，默认为-1。
  • keep_alive_timeout: 连接保持时间。默认1分钟。redis server为5分钟。
  • ssl_accept_timeout: 完成ssl握手的超时，默认为10秒。

在这个默认配置下，client可以每9秒发送一个字节，让server一直接收而不引起超时。所以，如果服务用于公网，需要配置receive_timeout。

任务级别的超时配置

任务级别的超时配置通过网络任务的几个接口调用来完成：

  1. template <class REQ, class RESP>
  2. class WFNetworkTask : public CommRequest
  3. {
  4. ...
  5. public:
  6.     /* All in milliseconds. timeout == -1 for unlimited. */
  7.     void set_send_timeout(int timeout) { this->send_timeo = timeout; }
  8.     void set_receive_timeout(int timeout) { this->receive_timeo = timeout; }
  9.     void set_keep_alive(int timeout) { this->keep_alive_timeo = timeout; }
  10. ...
  11. }

其中，set_send_timeout()设置发送完整消息的超时，默认值为-1。
set_receive_timeout()只对client任务有效，指接收完整server回复的超时，默认值为-1。

  • server任务的receive_timeout在server启动配置里。所有被用户处理的server任务，都已经成功接收了完整请求。

set_keep_alive()接口设置连接保持超时。一般来讲，框架能很好的处理连接保持的问题，用户不需要调用。
如果是http协议，client或server想要使用短连接，可通过添加HTTP header来完成，尽量不要用这个接口去修改。
如果一个redis client想要在请求之后关闭连接，则需要用这个接口。显然，在callback里set_keep_alive()是无效的（连接已经被复用）。

任务的同步等待超时

有一个非常特殊的超时配置，是全局唯一一个同步等待超时。我们并不鼓励使用，但在某些应用场景下能得到很好的效果。
目前框架里，目标服务器是有连接上限的（全局和upstream都可以配置）。如果连接已经达到上限，默认的情况下，client任务失败返回。
callback里task->get_state()得到WFT_STATE_SYS_ERROR, task->get_error()得到EAGAIN。如果任务配置了retry，会自动发起重试。
在这里，我们允许通过task->set_wait_timeout()接口，配置一个同步等待超时，如果在这段时间内，有连接被释放，则任务可以占用这个连接。
如果用户配置了wait_timeout，并且在超时之前没有拿到连接，则callback得到WFT_STATE_SYS_ERROR状态和ETIMEDOUT错误。

  1. class CommRequest : public SubTask, public CommSession
  2. {
  3. public:
  4.     ...
  5.     void set_wait_timeout(int wait_timeout) { this->wait_timeout = wait_timeout; }
  6. }

超时的原因查看

通信task包含一个get_timeout_reason()接口，用于返回超时原因，但不是很细致，包括以下几个返回值：

  • TOR_NOT_TIMEOUT: 不是超时。
  • TOR_WAIT_TIMEOUT: 同步等待超时。
  • TOR_CONNECT_TIMEOUT: 连接超时。包括TCP，SCTP等协议的连接和SSL连接超时，都是这个值。
  • TOR_TRANSMIT_TIMEOUT: 一切传输超时。不能进一步区分是发送阶段还是接收阶段。以后可能会细化。
    • server任务，超时原因一定是TRANSMIT_TIMEOUT，并且一定是发送回复的阶段。

超时功能的实现

框架内部，需要处理的超时种类比我们在这里展现的还要更多。除了wait_timeout，全都是依赖于Linux的timer_fd，每个epoll线程一个。
默认配置下，epoll线程数为2，可以满足大多数应用的需要了。
目前的超时算法利用了链表+红黑树的数据结构，时间复杂度在O(1)和O(logn)之间，其中n为epoll线程的fd数量。
超时处理目前看不是瓶颈所在，因为Linux内核epoll相关调用也是O(logn)时间复杂度，我们把超时都做到O(1)也区别不大。