起因

  之前接触了一个需求：提供一个接口，这个接口有一个超时时间，如果超时了返回超时异常；这个接口中调用其他的接口，如果调用超时了，所有请求全部结束。
  在这个接口中，我使用了go协程去调用其他接口，所以不仅涉及到请求的超时控制，而且还涉及到父协程对子协程的控制问题。在翻阅了一些资料之后，了解到了Context的基本知识。

Context

  Context是golang.org.pkg下的一个包，类型是接口类型。主要功能有

• 父协程控制所有的子协程

  Context可以通过context.Background()或者 context.TODO()创建一个空的context。两个区别在于TODO

context可以进行派生，创建出子context。context有四种不同的子context：
  （1）WithCancel：方法入参是一个context；返回值是一个带有新Done的父context的副本，以及cancel函数。当调用cancel函数时，通道将被关闭。关闭规则：会先关闭内部的接收通道；通道关闭了接收该通道的操作会立即返回（即done返回的通道），并且context会向它所有的子值传递信号，如果子context还有子context，那这个撤销信号就会一级一级传递下去。最后这个context会断开其与父context的连接。
  （2）WithDeadline和WithTimeout（本次问题解决就使用的是这个）：WithDeadline或者WithTimeout的功能极为相似。都是返回可以被撤销的Context子值。它们不但可以被手动撤销，还会依据在生成是给定的过期时间，自动地进行定时撤销。
  WithDeadline是设置一个时间点，时间对上了就到期。WithTimeout是设置一段时间，比如几秒，过个这段时间，就超时。其实底层的WithTimeout也是通过WithDeadline实现的。WithTimeout的调用就等于WithDeadline(parent, time.Now().Add(timeout))（其中parent是父级context）
  （3）WithValue:入参是父级parent，存储的键和存储的值。返回的是一个带有数据的Context。这个Context是不能被撤销的。撤销的信号在传递的时候会跳过这个Context。

• 协程间共享数据

  协程间共享数据主要使用的就是WithValue生成的子Context，这个Context存的值在其他的协程中也能读取到。可以用做数据的共享。

• 超时取消协程

  主要用到的是WithDeadline生成的子Context以及Go中HttpClient请求中的context字段（下文会有描述）
*

取消超时请求的模型

调度模型

  其中，对于超时的判断，是根据Context中的Done管道判断的。如果超时了，则Done管道可以拿到东西。

超时之后取消请求

  使用http.NewRequest方法获取到的req，可以调用WithContext将定义好的WithTimeout类型的context放进去，之后调用&htto.Client{}.Do()方法即可。网上有一些博客中让手动调用transport中的CancelRequest方法，但是这个方法已经不被建议使用了。因为它不能取消Http/2的请求。

  现在在代码中有一个私有化的roundTrip方法，会调用CancelRequest调用的cancelRequest方法。而这个roundTrip在transport中会在外面包一层RoundTrip方法，之后交给Client中的send方法进行调用。（具体可以进行源码的查阅）。所以现在通过Client的Do方法，可以自动完成请求的超时控制。

结论

  该调度模型亲测之后，确实可以实现请求的超时控制。只要在最外层设置超时时间时30s，只要过了30s，所有协程中的请求都会结束，对应的协程也会相应的结束；加上Client.Do方法，将超时控制变的更加简洁，后续会写专门写一篇关于http中Client的博客，详细讲解一下Client实现超时控制的原理。
  如果大佬们发现这个调度模型有什么问题，或者我用的方法有什么BUG，欢迎留言指正。（来自Go萌新内心的渴望）

有疑问加站长微信联系（非本文作者）