当您对外部模块的存储库进行了 fork （例如修复模块代码中的问题或添加功能）时，您可以让 Go 工具将您的 fork 用于模块的源代码。这对于测试您自己的代码的更改很有用。
创新互联建站专注于蒲城网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供蒲城营销型网站建设，蒲城网站制作、蒲城网页设计、蒲城网站官网定制、成都小程序开发服务，打造蒲城网络公司原创品牌,更为您提供蒲城网站排名全网营销落地服务。
为此，您可以使用go.mod 文件中的replace指令将外部模块的原始模块路径替换为存储库中 fork 的路径。这指示 Go 工具在编译时使用替换路径（fork 的位置），例如，同时允许您保留import 原始模块路径中的语句不变。
在以下 go.mod 文件示例中，当前模块需要外部模块example.com/theirmodule。然后该replace指令将原始模块路径替换为example.com/myfork/theirmodule模块自己的存储库的分支。
设置require/replace对时，使用 Go 工具命令确保文件描述的需求保持一致。使用go list命令获取当前模块正在使用的版本。然后使用go mod edit命令将需要的模块替换为fork：
注意： 当您使用该replace指令时，Go 工具不会像添加依赖项中所述对外部模块进行身份验证。
您可以使用go get命令从其存储库中的特定提交为模块添加未发布的代码。
为此，您使用go get命令，用符号@指定您想要的代码 。当您使用go get时，该命令将向您的 go.mod 文件添加一个 需要外部模块的require指令，使用基于有关提交的详细信息的伪版本号。
以下示例提供了一些说明。这些基于源位于 git 存储库中的模块。
当您的代码不再使用模块中的任何包时，您可以停止将该模块作为依赖项进行跟踪。
要停止跟踪所有未使用的模块，请运行go mod tidy 命令。此命令还可能添加在模块中构建包所需的缺失依赖项。
要删除特定依赖项，请使用go get，指定模块的模块路径并附加 @none，如下例所示：
go get命令还将降级或删除依赖于已删除模块的其他依赖项。
当您使用 Go 工具处理模块时，这些工具默认从 proxy.golang.org（一个公共的 Google 运行的模块镜像）或直接从模块的存储库下载模块。您可以指定 Go 工具应该使用另一个代理服务器来下载和验证模块。
如果您（或您的团队）已经设置或选择了您想要使用的不同模块代理服务器，您可能想要这样做。例如，有些人设置了模块代理服务器，以便更好地控制依赖项的使用方式。
要为 Go 工具指定另一个模块代理服务器，请将GOPROXY 环境变量设置为一个或多个服务器的 URL。Go 工具将按照您指定的顺序尝试每个 URL。默认情况下，GOPROXY首先指定一个公共的 Google 运行模块代理，然后从模块的存储库直接下载（在其模块路径中指定）：
您可以将变量设置为其他模块代理服务器的 URL，用逗号或管道分隔 URL。
Go 模块经常在公共互联网上不可用的版本控制服务器和模块代理上开发和分发。您可以设置 GOPRIVATE环境变量。您可以设置GOPRIVATE环境变量来配置go命令以从私有源下载和构建模块。然后 go 命令可以从私有源下载和构建模块。
GOPRIVATE或环境变量可以设置为匹配模块前缀的全局模式列表，这些GONOPROXY前缀是私有的，不应从任何代理请求。例如：
部署简单。Go编译生成的是一个静态可执行文件，除了glibc外没有其他外部依赖。这让部署变得异常方便：目标机器上只需要一个基础的系统和必要的管理、监控工具，完全不需要操心应用所需的各种包、库的依赖关系，大大减轻了维护的负担。这和Python有着巨大的区别。由于历史的原因，Python的部署工具生态相当混乱【比如setuptools,distutils,pip,
buildout的不同适用场合以及兼容性问题】。官方PyPI源又经常出问题，需要搭建私有镜像，而维护这个镜像又要花费不少时间和精力。
并发性好。Goroutine和channel使得编写高并发的服务端软件变得相当容易，很多情况下完全不需要考虑锁机制以及由此带来的各种问题。单个Go应用也能有效的利用多个CPU核，并行执行的性能好。这和Python也是天壤之比。多线程和多进程的服务端程序编写起来并不简单，而且由于全局锁GIL的原因，多线程的Python程序并不能有效利用多核，只能用多进程的方式部署;如果用标准库里的multiprocessing包又会对监控和管理造成不少的挑战【我们用的supervisor管理进程，对fork支持不好】。部署Python应用的时候通常是每个CPU核部署一个应用，这会造成不少资源的浪费，比如假设某个Python应用启动后需要占用100MB内存，而服务器有32个CPU核，那么留一个核给系统、运行31个应用副本就要浪费3GB的内存资源。
良好的语言设计。从学术的角度讲Go语言其实非常平庸，不支持许多高级的语言特性;但从工程的角度讲，Go的设计是非常优秀的：规范足够简单灵活，有其他语言基础的程序员都能迅速上手。更重要的是Go自带完善的工具链，大大提高了团队协作的一致性。比如gofmt自动排版Go代码，很大程度上杜绝了不同人写的代码排版风格不一致的问题。把编辑器配置成在编辑存档的时候自动运行gofmt，这样在编写代码的时候可以随意摆放位置，存档的时候自动变成正确排版的代码。此外还有gofix,
govet等非常有用的工具。
执行性能好。虽然不如C和Java，但通常比原生Python应用还是高一个数量级的，适合编写一些瓶颈业务。内存占用也非常省。
1.通过endless包实现
2.通过shutdown实现
在go 1.8.x后，golang在http里加入了shutdown方法，用来控制优雅退出。什么是优雅退出？ 简单说就是不处理新请求，但是会处理正在进行的请求，把旧请求都处理完，也就是都response之后，那么就退出。
shutdown通过context上下文实现 。
社区里不少http graceful动态重启，平滑重启的库，大多是基于http.shutdown做的。平滑启动的原理很简单，fork子进程，继承listen fd, 老进程优雅退出。
3.context原理
context 是 Go 并发编程中常用到一种编程模式。
在并发程序中，由于超时、取消操作或者一些异常情况，往往需要进行抢占操作或者中断后续操作。熟悉 channel 的朋友应该都见过使用 done channel 来处理此类问题。比如以下这个例子：
上述例子中定义了一个 buffer 为0的 channel done , 子协程运行着定时任务。如果主协程需要在某个时刻发送消息通知子协程中断任务退出，那么就可以让子协程监听这个 done channel ，一旦主协程关闭 done channel ，那么子协程就可以推出了，这样就实现了主协程通知子协程的需求。这很好，但是这也是有限的。
如果我们可以在简单的通知上附加传递额外的信息来控制取消：为什么取消，或者有一个它必须要完成的最终期限，更或者有多个取消选项，我们需要根据额外的信息来判断选择执行哪个取消选项。
考虑下面这种情况：假如主协程中有多个任务1, 2, …m，主协程对这些任务有超时控制；而其中任务1又有多个子任务1, 2, …n，任务1对这些子任务也有自己的超时控制，那么这些子任务既要感知主协程的取消信号，也需要感知任务1的取消信号。
如果还是使用 done channel 的用法，我们需要定义两个 done channel ，子任务们需要同时监听这两个 done channel 。嗯，这样其实好像也还行哈。但是如果层级更深，如果这些子任务还有子任务，那么使用 done channel 的方式将会变得非常繁琐且混乱。
我们需要一种优雅的方案来实现这样一种机制：
这个时候 context 就派上用场了。
我们首先看看 context 的结构设计和实现原理。
先看 Context 接口结构，看起来非常简单。
Context 接口包含四个方法：
可以看到 Done 方法返回的 channel 正是用来传递结束信号以抢占并中断当前任务； Deadline 方法指示一段时间后当前 goroutine 是否会被取消；以及一个 Err 方法，来解释 goroutine 被取消的原因；而 Value 则用于获取特定于当前任务树的额外信息。而 context 所包含的额外信息键值对是如何存储的呢？其实可以想象一颗树，树的每个节点可能携带一组键值对,如果当前节点上无法找到 key 所对应的值，就会向上去父节点里找，直到根节点，具体后面会说到。
emptyCtx 是一个 int 类型的变量，但实现了 context 的接口。 emptyCtx 没有超时时间，不能取消，也不能存储任何额外信息，所以 emptyCtx 用来作为 context 树的根节点。
但我们一般不会直接使用 emptyCtx ，而是使用由 emptyCtx 实例化的两个变量，分别可以通过调用 Background 和 TODO 方法得到，但这两个 context 在实现上是一样的。那么 Background 和 TODO 方法得到的 context 有什么区别呢？可以看一下官方的解释：
Background 和 TODO 只是用于不同场景下：
Background 通常被用于主函数、初始化以及测试中，作为一个顶层的 context ，也就是说一般我们创建的 context 都是基于 Background ；
而 TODO 是在不确定使用什么 context 的时候才会使用。
下面将介绍两种不同功能的基础 context 类型： valueCtx 和 cancelCtx 。
valueCtx 利用一个 Context 类型的变量来表示父节点 context ，所以当前 context 继承了父 context 的所有信息； valueCtx 类型还携带一组键值对，也就是说这种 context 可以携带额外的信息。 valueCtx 实现了 Value 方法，用以在 context 链路上获取 key 对应的值，如果当前 context 上不存在需要的 key ,会沿着 context 链向上寻找 key 对应的值，直到根节点。
WithValue 用以向 context 添加键值对：
这里添加键值对不是在原 context 结构体上直接添加，而是以此 context 作为父节点，重新创建一个新的 valueCtx 子节点，将键值对添加在子节点上，由此形成一条 context 链。获取 value 的过程就是在这条 context 链上由尾部上前搜寻：
跟 valueCtx 类似， cancelCtx 中也有一个 context 变量作为父节点；变量 done 表示一个 channel ，用来表示传递关闭信号； children 表示一个 map ，存储了当前 context 节点下的子节点； err 用于存储错误信息表示任务结束的原因。
再来看一下 cancelCtx 实现的方法：
可以发现 cancelCtx 类型变量其实也是 canceler 类型，因为 cancelCtx 实现了 canceler 接口。 Done 方法和 Err 方法没必要说了， cancelCtx 类型的 context 在调用 cancel 方法时会设置取消原因，将 done channel 设置为一个关闭 channel 或者关闭 channel ，然后将子节点 context 依次取消，如果有需要还会将当前节点从父节点上移除。
WithCancel 函数用来创建一个可取消的 context ，即 cancelCtx 类型的 context 。 WithCancel 返回一个 context 和一个 CancelFunc ，调用 CancelFunc 即可触发 cancel 操作。直接看源码：
之前说到 cancelCtx 取消时，会将后代节点中所有的 cancelCtx 都取消， propagateCancel 即用来建立当前节点与祖先节点这个取消关联逻辑。
这里或许有个疑问，为什么是祖先节点而不是父节点？这是因为当前 context 链可能是这样的：
当前 cancelCtx 的父节点 context 并不是一个可取消的 context ，也就没法记录 children 。
timerCtx 是一种基于 cancelCtx 的 context 类型，从字面上就能看出，这是一种可以定时取消的 context 。
timerCtx 内部使用 cancelCtx 实现取消，另外使用定时器 timer 和过期时间 deadline 实现定时取消的功能。 timerCtx 在调用 cancel 方法，会先将内部的 cancelCtx 取消，如果需要则将自己从 cancelCtx 祖先节点上移除，最后取消计时器。
WithDeadline 返回一个基于 parent 的可取消的 context ，并且其过期时间 deadline 不晚于所设置时间 d 。
与 WithDeadline 类似， WithTimeout 也是创建一个定时取消的 context ，只不过 WithDeadline 是接收一个过期时间点，而 WithTimeout 接收一个相对当前时间的过期时长 timeout :
首先使用 context 实现文章开头 done channel 的例子来示范一下如何更优雅实现协程间取消信号的同步：
这个例子中，只要让子线程监听主线程传入的 ctx ，一旦 ctx.Done() 返回空 channel ，子线程即可取消执行任务。但这个例子还无法展现 context 的传递取消信息的强大优势。
阅读过 net/http 包源码的朋友可能注意到在实现 http server 时就用到了 context , 下面简单分析一下。
1、首先 Server 在开启服务时会创建一个 valueCtx ,存储了 server 的相关信息，之后每建立一条连接就会开启一个协程，并携带此 valueCtx 。
2、建立连接之后会基于传入的 context 创建一个 valueCtx 用于存储本地地址信息，之后在此基础上又创建了一个 cancelCtx ，然后开始从当前连接中读取网络请求，每当读取到一个请求则会将该 cancelCtx 传入，用以传递取消信号。一旦连接断开，即可发送取消信号，取消所有进行中的网络请求。
3、读取到请求之后，会再次基于传入的 context 创建新的 cancelCtx ,并设置到当前请求对象 req 上，同时生成的 response 对象中 cancelCtx 保存了当前 context 取消方法。
这样处理的目的主要有以下几点：
在整个 server 处理流程中，使用了一条 context 链贯穿 Server 、 Connection 、 Request ，不仅将上游的信息共享给下游任务，同时实现了上游可发送取消信号取消所有下游任务，而下游任务自行取消不会影响上游任务。
context 主要用于父子任务之间的同步取消信号，本质上是一种协程调度的方式 。另外在使用 context 时有两点值得注意：上游任务仅仅使用 context 通知下游任务不再需要，但不会直接干涉和中断下游任务的执行，由下游任务自行决定后续的处理操作，也就是说 context 的取消操作是无侵入的； context 是线程安全的，因为 context 本身是不可变的（ immutable ），因此可以放心地在多个协程中传递使用。
/bin/bash -c "ls -l"
cmd-golang-pipe
pipe()创建2个文件描述符，fd[0]可读，fd[1]可写
fork() 创建子进程 fd[1]被继承到子进程
dup2() 重定向子进程 stdout/stderr到fd[1]
exec() 在当前进程内，加载并执行二进制程序
模拟一下cmd调用
模拟调用cmd时，杀死bash进程
go开源Cronexpr库
Parse() 解析与校验Cron表达式
Next() 根据当前时间，计算下一次调度时间
模拟一下cron调用
执行结果
模拟多个cron调用
执行结果
一般来说，进程的操作使用的是一些系统的命令，所以go内部使用os包，进行一些运行系统命令的操作
os 包及其子包 os/exec 提供了创建进程的方法。
一般的，应该优先使用 os/exec 包。因为 os/exec 包依赖 os 包中关键创建进程的 API，为了便于理解，我们先探讨 os 包中和进程相关的部分。
Unix :fork创建一个进程，（及其一些变种，如 vfork、clone）。
Go:Linux 下创建进程使用的系统调用是 clone。
允许一进程（父进程）创建一新进程（子进程）。具体做法是，新的子进程几近于对父进程的翻版：子进程获得父进程的栈、数据段、堆和执行文本段的拷贝。可将此视为把父进程一分为二。
终止一进程，将进程占用的所有资源（内存、文件描述符等）归还内核，交其进行再次分配。参数 status 为一整型变量，表示进程的退出状态。父进程可使用系统调用 wait() 来获取该状态。
目的有二：其一，如果子进程尚未调用 exit() 终止，那么 wait 会挂起父进程直至子进程终止；其二，子进程的终止状态通过 wait 的 status 参数返回。
加载一个新程序（路径名为 pathname，参数列表为 argv，环境变量列表为 envp）到当前进程的内存。这将丢弃现存的程序文本段，并为新程序重新创建栈、数据段以及堆。通常将这一动作称为执行一个新程序。
没有直接提供 fork 系统调用的封装，而是将 fork 和 execve 合二为一，提供了 syscall.ForkExec。如果想只调用 fork，得自己通过 syscall.Syscall(syscall.SYS_FORK, 0, 0, 0) 实现。
os.Process 存储了通过 StartProcess 创建的进程的相关信息。
一般通过 StartProcess 创建 Process 的实例，函数声明如下：
它使用提供的程序名、命令行参数、属性开始一个新进程。StartProcess 是一个低级别的接口。os/exec 包提供了高级别的接口，一般应该尽量使用 os/exec 包。如果出错，错误的类型会是 *PathError。
属性定义如下：
FindProcess 可以通过 pid 查找一个运行中的进程。该函数返回的 Process 对象可以用于获取关于底层操作系统进程的信息。在 Unix 系统中，此函数总是成功，即使 pid 对应的进程不存在。
Process 提供了四个方法：Kill、Signal、Wait 和 Release。其中 Kill 和 Signal 跟信号相关，而 Kill 实际上就是调用 Signal，发送了 SIGKILL 信号，强制进程退出，关于信号，后续章节会专门讲解。
Release 方法用于释放 Process 对象相关的资源，以便将来可以被再使用。该方法只有在确定没有调用 Wait 时才需要调用。Unix 中，该方法的内部实现只是将 Process 的 pid 置为 -1。
通过 os 包可以做到运行外部命令，如前面的例子。不过，Go 标准库为我们封装了更好用的包： os/exec，运行外部命令，应该优先使用它，它包装了 os.StartProcess 函数以便更容易的重定向标准输入和输出，使用管道连接 I/O，以及作其它的一些调整。
exec.LookPath 函数在 PATH 指定目录中搜索可执行程序，如 file 中有 /，则只在当前目录搜索。该函数返回完整路径或相对于当前路径的一个相对路径。
func LookPath(file string) (string, error)
如果在 PATH 中没有找到可执行文件，则返回 exec.ErrNotFound。
Cmd 结构代表一个正在准备或者在执行中的外部命令，调用了 Run、Output 或 CombinedOutput 后，Cmd 实例不能被重用。
一般的，应该通过 exec.Command 函数产生 Cmd 实例：
用法
得到 * Cmd 实例后，接下来一般有两种写法：
前面讲到，通过 Cmd 实例后，有两种方式运行命令。有时候，我们不只是简单的运行命令，还希望能控制命令的输入和输出。通过上面的 API 介绍，控制输入输出有几种方法：
参考资料：
一、关于连接池
一个数据库服务器只拥有有限的资源，并且如果你没有充分使用这些资源，你可以通过使用更多的连接来提高吞吐量。一旦所有的资源都在使用，那么你就不 能通过增加更多的连接来提高吞吐量。事实上，吞吐量在连接负载较大时就开始下降了。通常可以通过限制与可用的资源相匹配的数据库连接的数量来提高延迟和吞 吐量。
如何在Go语言中使用Redis连接池
如果不使用连接池，那么，每次传输数据，我们都需要进行创建连接，收发数据，关闭连接。在并发量不高的场景，基本上不会有什么问题，一旦并发量上去了，那么，一般就会遇到下面几个常见问题：
性能普遍上不去
CPU 大量资源被系统消耗
网络一旦抖动，会有大量 TIME_WAIT 产生，不得不定期重启服务或定期重启机器
服务器工作不稳定，QPS 忽高忽低
要想解决这些问题，我们就要用到连接池了。连接池的思路很简单，在初始化时，创建一定数量的连接，先把所有长连接存起来，然后，谁需要使用，从这里取走，干完活立马放回来。 如果请求数超出连接池容量，那么就排队等待、退化成短连接或者直接丢弃掉。
二、使用连接池遇到的坑
最近在一个项目中，需要实现一个简单的 Web Server 提供 Redis 的 HTTP interface，提供 JSON 形式的返回结果。考虑用 Go 来实现。
首先，去看一下 Redis 官方推荐的 Go Redis driver。官方 Star 的项目有两个：Radix.v2 和 Redigo。经过简单的比较后，选择了更加轻量级和实现更加优雅的 Radix.v2。
Radix.v2 包是根据功能划分成一个个的 sub package，每一个 sub package 在一个独立的子目录中，结构非常清晰。我的项目中会用到的 sub package 有 redis 和 pool。
由于我想让这种被 fork 的进程最好简单点，做的事情单一一些，所以，在没有深入去看 Radix.v2 的 pool 的实现之前，我选择了自己实现一个 Redis pool。(这里，就不贴代码了。后来发现自己实现的 Redis pool 与 Radix.v2 实现的 Redis pool 的原理是一样的，都是基于 channel 实现的, 遇到的问题也是一样的。)
不过在测试过程中，发现了一个诡异的问题。在请求过程中经常会报 EOF 错误。而且是概率性出现，一会有问题，一会又好了。通过反复的测试，发现 bug 是有规律的，当程序空闲一会后，再进行连续请求，会发生3次失败，然后之后的请求都能成功，而我的连接池大小设置的是3。再进一步分析，程序空闲300秒 后，再请求就会失败，发现我的 Redis server 配置了 timeout 300，至此，问题就清楚了。是连接超时 Redis server 主动断开了连接。客户端这边从一个超时的连接请求就会得到 EOF 错误。
然后我看了一下 Radix.v2 的 pool 包的源码，发现这个库本身并没有检测坏的连接，并替换为新server{location/pool{content_by_lua_block{localredis=require"resty.redis"localred=redis:new()localok,err=red:connect("127.0.0.1",6379)ifnotokthenngx.say("failedtoconnect:",err)returnendok,err=red:set("hello","world")ifnotokthenreturnendred:set_keepalive(10000,100)}}}
发现有个 set_keepalive 的方法，查了一下官方文档，方法的原型是 syntax: ok, err = red:set_keepalive(max_idle_timeout, pool_size) 貌似 max_idle_timeout 这个参数，就是我们所缺少的东西，然后进一步跟踪源码，看看里面是怎么保证连接有效的。
function_M.set_keepalive(self,...)localsock=self.sockifnotsockthenreturnnil,"notinitialized"endifself.subscribedthenreturnnil,"subscribedstate"endreturnsock:setkeepalive(...)end
至此，已经清楚了，使用了 tcp 的 keepalive 心跳机制。
于是，通过与 Radix.v2 的作者一些讨论，选择自己在 redis 这层使用心跳机制，来解决这个问题。
四、最后的解决方案
在创建连接池之后，起一个 goroutine，每隔一段 idleTime 发送一个 PING 到 Redis server。其中，idleTime 略小于 Redis server 的 timeout 配置。连接池初始化部分代码如下：
p,err:=pool.New("tcp",u.Host,concurrency)errHndlr(err)gofunc(){for{p.Cmd("PING")time.Sleep(idelTime*time.Second)}}()
使用 redis 传输数据部分代码如下：
funcredisDo(p*pool.Pool,cmdstring,args...interface{})(reply*redis.Resp,errerror){reply=p.Cmd(cmd,args...)iferr=reply.Err;err!=nil{iferr!=io.EOF{Fatal.Println("redis",cmd,args,"erris",err)}}return}
其中，Radix.v2 连接池内部进行了连接池内连接的获取和放回，代码如下：
//Cmdautomaticallygetsoneclientfromthepool,executesthegivencommand//(returningitsresult),andputstheclientbackinthepoolfunc(p*Pool)Cmd(cmdstring,args...interface{})*redis.Resp{c,err:=p.Get()iferr!=nil{returnredis.NewResp(err)}deferp.Put(c)returnc.Cmd(cmd,args...)}
这样，我们就有了 keepalive 的机制，不会出现 timeout 的连接了，从 redis 连接池里面取出的连接都是可用的连接了。看似简单的代码，却完美的解决了连接池里面超时连接的问题。同时，就算 Redis server 重启等情况，也能保证连接自动重连。