Goroutine的上下文存储

元家昕 · · 2544 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

后端开发中,问题分析通常是请求级别的,如果能通过一个唯一的请求号对日志进行过滤,能对分析问题带来不少的便捷。我们的项目中也希望在请求相关的日志中,嵌入请求号。

Golang在http.Request中提供了一个Context用于存储kv对,我们可以通过这个来存储请求相关的数据。在请求入口,我们把唯一的requstID存储到context中,在后续需要调用的地方把值取出来打印。如果日志是在controller中打印,这个很好处理,http.Request是作为入参的。但如果是在更底层呢?比如说是在model甚至是一些工具类中。我们当然可以给每个方法都提供一个参数,由调用方把context一层一层传下来,但这种方式明显不够优雅。

那么Golang有没有提供一个静态方案获取当前context呢?答案是否定的。有没有提供类似ThreadLocal这样的机制获取Goroutine的上下文呢?答案也是否定的。

理由是Andrew Gerrand认为通过线程上下文这种方式传参“带来的问题比解决的问题多”。

We wouldn't even be having this discussion if thread local storage wasn't useful. But every feature comes at a cost, and in my opinion the cost of threadlocals far outweighs their benefits. They're just not a good fit for Go.

官方不但不提供这样的方法,还不遗余力的让第三方也无法提供--Golang不提供任何可以让你获知当前GoroutineID的方法。

不过,哪里有压迫,哪里就有反抗。还是有第三方的库做了类似的功能。

首先是一个库做了一个获取当前所在GoRoutine的方法,https://github.com/bradfitz/http2/blob/dc0c5c000ec33e263612939744d51a3b68b9cece/gotrack.go

原理是利用了runtime.Stack的字符串格式

可以看到在Stack的开头打印了一个类似于goroutineID的东西。有了goroutineID,GoRoutine的local storage实现方式也就是顺理成章了,只要把context存放在以goroutineID为key的map中即可。

另外有一个库jtolds/gls,它的实现方式就奇特多了。同在runtime包下面,有一个Callers方法,可以获取当前调用栈的pc列表。这个gls库就是利用这个Callers方法。

gls库预先定义了16个可嵌套的空方法,调用方需要用到GoRoutineLocal功能时,需要把用到这个功能的根方法作为参数传入到gls中,gls按顺序生成未被使用的GoRoutineID,然后把GoRoutineID种入到调用栈中。具体的方法就是利用前面所述的16个空方法进行编码,每个方法使用与否分别代表一个bit的0或1,最终通过这16个方法编码成16个bit的GoRoutineID。解码时,只需通过Callers方法获取pc列表,与16个方法的pc进行匹配即可把GoRoutineID解码出来。

第一种方法利用的是golang打印格式,虽说这种打印格式不太可能会在golang的未来版本发生改变,但毕竟恶心;第二种方法脑回路清奇,似乎也没有什么限制,但要用在生产上的话,还是算了吧。


有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:元家昕

查看原文:Goroutine的上下文存储

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

2544 次点击  
加入收藏 微博
2 回复  |  直到 2020-07-13 02:14:01
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传