机遇屋-grpc报错rpc error:code=DeadlineExceeded desc = context deadline exceeded

grpc报错rpc error:code=DeadlineExceeded desc = context deadline exceeded

作者：ych

### 现象
grpc调用报错
```
grpc报“rpc error:code=DeadlineExceeded desc = context deadline exceeded”
```

### 原因分析
客户端用的上下文是`context.WithTimeout`超时时间小于服务端的返回时间，造成`context deadline exceeded`。

当您使用gRPC时，gRPC库负责通信，编组，解组和最后期限执行。`Deadline`允许`gRPC`客户端指定在RPC以错误`DEADLINE_EXCEEDED`终止之前，他们愿意等待RPC完成的时间。默认情况下，此截止日期是一个非常大的数字，取决于语言实现。

### 问题解决
DialContext传入一个Timeout的context,就像下面的例子
```
ctx1, cel := context.WithTimeout(context.Background(), time.Second*5)
defer cel()
conn, err := grpc.DialContext(ctx1, address, grpc.WithBlock(), grpc.WithInsecure())
```
最简单的解决办法就是把超时时间调大一点 以前设置的是一秒 现在调成五秒。

### 总结
[官方参考](https://grpc.io/blog/deadlines/#c "官方参考")
```
grpc deadlines
```
当您使用gRPC时，gRPC库负责通信，编组，解组和最后期限执行。Deadline允许gRPC客户端指定在RPC以错误DEADLINE_EXCEEDED终止之前，他们愿意等待RPC完成的时间。默认情况下，此截止日期是一个非常大的数字，取决于语言实现。如何指定截止日期也取决于语言。指定截止日期或超时的方式因语言而异 - 例如，并非所有语言都有默认的截止日期，某些语言使用 deadline ，而某些语言使用timeouts。在服务器端，服务器可以查询特定RPC是否已超时，或者剩余多少时间来完成RPC。

通常，当您未设置截止日期时，将为所有正在进行的请求保留资源，并且所有请求都可能达到最大超时。这会使服务面临资源耗尽的风险，例如内存，这会增加服务的延迟，或者在最坏的情况下可能导致整个过程崩溃。

当未设置`Deadlines`时，将采用默认的`DEADLINE_EXCEEDED`（这个时间非常大）

如果产生了阻塞等待，就会造成大量正在进行的请求都会被保留，并且所有请求都有可能达到最大超时

这会使服务面临资源耗尽的风险，例如内存，这会增加服务的延迟，或者在最坏的情况下可能导致整个进程崩溃

gRPC客户端建议显式的指定一个超时时间.

根据官方说明：
>TL;DR: Always set a deadline. This post explains why we recommend being deliberate about setting deadlines, with useful code snippets to show you how.

总是设定一个最后期限。这篇文章解释了为什么我们建议仔细考虑设定最后期限，用有用的代码片段告诉你如何设定最后期限。

### 关联知识
gRPC 超时如何做到跨进程传递？
gRPC 框架通过`HTTP2 HEADERS Frame`中的`grpc-timeout`字段来实现跨进程传递超时时间。

客户端发起请求时，如果设置了带`timeout`的`ctx`，则会导致底层`HTTP2 HEADERS Frame`中追加`grpc-timeout`字段。

服务端接收`RPC`请求时，`gRPC`框架底层解析`HTTP2 HEADERS`帧，读取`grpc-timeout`值，并覆盖透传到实际处理`RPC`请求的业务 `gPRC Handle`中

如果此时服务端又发起对其他`gRPC`服务的调用，且使用的是透传的`ctx`，这个`timeout`会减去在本进程中耗时，从而导致这个`timeout` 传递到下一个`gRPC`服务端时变短，这样即实现了所谓的 超时传递 。目前这个功能测试发现在`grpc-go`和`grpc-java`中实现，`grpc-python`貌似暂未实现此功能

golang使用grpc超时控制和对冲策略
golang在GRPC中设置client的超时时间
[参考URL](http://www.yuepc.com/a/23861.html "参考URL")

#### 通常重试策略有三种配置

1、失败重新请求的最大次数，达到最大次数仍然失败，不再进行重试；

2、退避时间：退避时间取的是 random(0, delay)；

3、可重试错误码：设置可错误码，对于不可重试的，立即停止重试并将错误返回应用层。

### 其它
[CSDN](https://blog.csdn.net/inthat/article/details/123881103 "原作者")

评论区

先去登录