在使用

第三方库引起的线上问题、如何在线线上环境进行调试定位问题以及golang开发中各种问题精华整理总结。

在使用

描述这是一个临时重定向意味着请求的资源已经临时移动到了一个新的

POST

明确规定客户端必须不改变请求方法进行重定向。

例如如果原始请求是

应用由于

由于后台服务多区域部署需要涉及到2个以上的环境数据打通当请求到达

区域时发现数据在

最新版本是tagv2.7.0这个版本已经是2021年11月份发布的而在2022年5月份就有人在

github

主分支了然而至今并没有发布新版本这就导致线上出了这个重定向问题。

https://github.com/go-resty/resty/pull/568

下面我们来看看这个

bytes.NewBuffer(r.bodyBuf.Bytes())

io.Copy

url.Parse(ts.URL)t.Log(ts.URL:,

targetURL.Host)c

c.R().SetBody([]byte(strconv.Itoa(newRnd().Int()))).Post(targetURL.String()

/redirect-with-body)assertError(t,

err)assertNotNil(t,

重定向请求且并发量急剧变大时同一时间出现碰撞的概率就变大了就出现了串数据的情况这是非常严重的问题。

unrecognized

上建立了一个镜像库下载github上的镜像库放入GOPATH下即可

mkdir

https://github.com/golang/sync.git

git

https://github.com/golang/crypto.git

git

https://github.com/golang/sys.gitgo包管理代理网址无法访问proxy.golang.org

env

GOPROXYhttps://goproxy.cnverifying

module:

类型匹配的一个经典错误是在比较两个不同类型的变量。

例如将字符串类型的变量与整数类型的变量进行比较。

要避免这种错误应该始终确保比较的是相同类型的变量。

或者在进行类型转换时需确保变量类型符合要求。

空指针错误

中指向空值的指针是非常常见的错误。

这通常在代码中的资源管理方面出现问题如打开和关闭文件连接到数据库等。

当处理指针变量时应该始终确保其指向一个有效的对象。

此外对于指针变量的使用应该小心谨慎以避免出现在编程过程中不同的指针指向同一个对象的情况。

内存分配错误

中大规模的并发处理是其一个显著的特点但这也带来了一些问题。

并发程序的错误处理比串行程序更为棘手因为开发者需要在多个并发执行的地方确定错误。

在开发

Golang

错误。

大多数死锁发生在程序未能释放锁或加锁太多的情况下。

更糟糕的是用户可能需要重新启动程序来解决死锁的问题。

为避免死锁可以使用并发控制的技术确保子程序无法同时访问相同的资源。

文件处理问题

中文件处理是经常进行的任务。

常见的文件处理错误包括文件无法打开读取和写入错误。

为避免这些错误应该选择一个完全合适的文件操作函数并检查文件路径是否正确。

同时应该在解析文件时检查文件的格式以确保文件中的数据已正确转换。

Golang

中数组和切片的越界访问是另一个可能的错误。

由于数组和切片的索引是从

开始计数的所以如果开发者在索引时错误地写入负数、超出边界的正数或者不同于整数的索引就可能出现越界错误。

为避免这个问题开发者可以使用循环来遍历数组和切片并始终确保数组和切片的索引值是有效的。

Golang

的学习过程中这些错误可能会使新手们不知所措但只要有足够的耐心和学习态度并遵循最佳实践就可以轻松地避免这些错误。

最近线上有个服务突然卡死了看起来是进程启动了但是请求接口则反应连接不上看错误日志也没有什么异常信息对于这种线上服务卡死的问题一直没有丰富经验来排查。

看网上一些人各自gdbsystemtap之类的工具调试线上问题很是羡慕。

strace

futex有时候有正常的刷刷刷一大堆信息。

按照我之前的经验出现wait

futex则说明进程卡死在某个channel上了。

但是现在这个卡死的进程并没有一直处于wait

futex说明可能不是卡死在某个channel上至少还有其他goroutine在正常活动中。

进程没有卡死在wait

futex但是又不能监听端口处理请求说明要么是在启动阶段还未到监听端口这一步就出现死锁卡死了要么就是监听端口的那部分代码出问题了。

来判断是否死锁了更早之前还试过用gdb调试python服务但是go的服务该用什么工具还不太了解理论上用strace和gdb也能排查到一些问题的但是这两个工具都无法识别goroutine调试起来很难。

dlv也就是delve这款工具专门为go语言打造的调试工具可以识别goroutine等。

搜了下官方文档和网上的各自介绍文章写得都不太实用好多文章就是玩具级别的介绍实际生产环境中使用很多细节都没说明。

但是只能硬着头皮看一点说明介绍就试用一下不过这种边解决问题边学习的方法效率还是很高的。

最终也是依靠dlv这款工具定位到了死锁之处以及引起问题所在。

参照官方文档先执行

github.com/go-delve/delve/cmd/dlvlatest

这样子会安装

到你的GOPATH目录下里面会生成一个dlv的可执行文件。

然后将这个dlv上传到服务器上就可以使用了。

attach和coredump

有了dlv之后第一步就是要让dlv可以接触上卡死的进程也就是使用

首先使用

可以附着到卡死的进程上了。

如果进程是使用非当前用户启动的话则要加上

sudo

连接上进程之后不管三七二十一要赶紧导出coredump因为一旦出现什么问题导致进行死掉或者卡死状态解除了就无法继续排查调试了。

有了coredump则可以一直慢慢来调试。

在dlv里执行

就会把当前整个进程的状态都记录下来那样子就可以下载coredump文件在自己的开发机上逐步调试问题所在又同时不影响线上服务。

在自己的开发机上查看coredump文件还需要提供和线上运行程序一致的二进制文件。

比如你线上运行的是

v0.22

版本要么你就直接从线上下载这个二进制文件要么你可以把代码切换到v0.22然后进行编译同时编译参数不能有任何的变化。

只有保证二进制文件与coredump对应的完全一致才可以使用。

dlv

attach和coredump的区别主要是attach是附着到一个运行中的实例中是可以执行函数调用设置断点等操作的而coredump就只能静态的去查看栈帧、内存等信息了。

因此如果线上出现了类似卡死的故障先是保存好coredump如果可以的话就直接在线上attach调试这样子会更容易排查问题。

bt查看栈帧

的错误。

即使下载了coredump文件和二进制到自己的开发机上进行调试也会出现这个问题因为二进制是另一个同事编译的Go的编译默认会带上代码的完整路径而同事的GOPATH和我是不一样的这个要怎么解决呢

终极解决办法编译参数加上

这样子编译的代码路径就会去掉你本人的文件夹路径使用相对于GOPATH的路径了别人在你编译的二进制上获取的coredump也可以正常调试了。

如果编译前没有加上这个指令

不过另一个问题也难以解决服务器上一般是不会带上Go代码及代码块的所以在服务器上进行调试的时候list指令就用不上了很难排查问题。

最终还是只能用coredump在开发机上排查调试

其实也可以开启调试服务线上开启在开发机上用dlv连接线上开启的服务就可以进行调试了。

不过这个也挺麻烦的。

还遇到一个问题是print变量的时候如果是字符串变量好像默认只打印前64个字符这明显不够可以通过设置config

max-string-len