记录 gRPC Deadlines 的一次事故

收到交易服务的报警，服务器内存暴增。后经排查发现是因为gRPC客户端调用的时候在上下文（context）中未设置Deadline致使的。
那么为何未设置Deadline会致使内存耗尽呢？

当您使用gRPC时，gRPC库负责通讯，编组，解组和最后期限执行。Deadline容许gRPC客户端指定在RPC以错误DEADLINE_EXCEEDED终止以前，他们愿意等待RPC完成的时间。默认状况下，此截止日期是一个很是大的数字，取决于语言实现。如何指定截止日期也取决于语言。指定截止日期或超时的方式因语言而异 - 例如，并不是全部语言都有默认的截止日期，某些语言使用 deadline ，而某些语言使用timeouts。在服务器端，服务器能够查询特定RPC是否已超时，或者剩余多少时间来完成RPC。

一般，当您未设置截止日期时，将为全部正在进行的请求保留资源，而且全部请求均可能达到最大超时。这会使服务面临资源耗尽的风险，例如内存，这会增长服务的延迟，或者在最坏的状况下可能致使整个过程崩溃。

“什么是好的截止日期/超时值？”没有单一的答案。那么您须要考虑什么才能明智地选择截止日期？要考虑的因素包括整个系统的端到端延迟，哪些RPC是串行的，哪些能够并行进行。工程师须要了解服务，而后设置一个刻意的截止日期用于客户端和服务器之间的RPC。

在gRPC中，关于远程过程调用（RPC）是否成功的，客户端和服务器都作了独立的和本地的判断。这意味着他们的结论可能不匹配！一个在服务端成功完成的RPC可能在客户端失败。例如，服务器能够发送响应，可是这个回复能够在截止日期到期后到达客户端，而客户端将会在回复到达前使用错误状态DEADLINE_EXCEEDED终止。

Setting a deadline

Go

做为客户端，您应始终设置一个期限，以肯定您愿意等待服务器回复的时间。

clientDeadline := time.Now().Add(time.Duration(*deadlineMs) * time.Millisecond)
ctx, cancel := context.WithDeadline(ctx, clientDeadline)

Checking deadlines

On the server side, the server can query to see if a particular RPC is no longer wanted.
在服务端，服务器能够查看是否一个特定的RPC再也不须要。在服务器开始做出响应以前，检查是否还有客户端等待它是很是重要的。在开始昂贵的处理以前，这一点尤为重要。

Go

if ctx.Err() == context.Canceled {
    return status.New(codes.Canceled, "Client cancelled, abandoning.")
}

当您知道客户已达到截止日期时，服务器继续处理请求是否有用？这取决于。若是响应能够缓存在服务器中，则值得处理和缓存;特别是若是它的资源很重，而且每一个请求都要花钱。这将使将来的请求更快，由于结果已经可用。

Adjusting deadlines

若是您设置截止日期但新版本或服务器版本会致使错误回归，该怎么办？截止日期可能过小，致使您的全部请求超时DEADLINE_EXCEEDED，或者太大，您的用户尾部延迟如今很大。您可使用标志来设置和调整截止日期。

Go

var deadlineMs = flag.Int("deadline_ms", 20*1000, "Default deadline in milliseconds.")

ctx, cancel := context.WithTimeout(ctx, time.Duration(*deadlineMs) * time.Millisecond)

参考

gRPC and Deadlines
gRPC