【踩坑笔记】一次加锁和超时控制引起的交通事故

问题回顾

线上发现流量接入层好像扛不住,一直在被 OOM,并且客户出现大面积的超时。但是流量并没有打到后端的业务层。
在回滚代码,并且加机器之后,问题被解决了。

问题定位与解决

首先,怀疑是流量过大引起的。但是奇怪的点在于大部分流量没有打到业务层。通过分析流量接入层的日志,我们发现 有两个相邻日志输出的时间间隔比较长。而这两条日志输出之间正是有回滚的代码。所以,我们将问题定位的方向转移到了代码层面。

但是,线下压测过程中,并没有发现类似的严重耗时问题,(怀疑是测试 case 没有覆盖到)。于是,先人工 Review 一遍变动的代码。我们发现,有一个代码片段是加锁的,代码如下所示(golang 省略部分细节):

 // key1
 if val, exist := rateMap.Load(key1); exist {
 return true, val.(*RateLimit).Taken(count)
 }
 Lock.Lock()
 defer Lock.Unlock()
 if mapC, exist := RateLimitC[flag1]; exist {
 for _, val := range mapC {
 if key1_ok {
 rateLimit := NewRateLimit(val.Qps)
 rateLimit.Create()
 rateMap.Store(key1, &rateLimit)
 return true, rateLimit.Taken(count)
 }
 }
 }
 // key2
 if val, exist := rateMap.Load(key2); exist {
 return true, val.(*RateLimit).Taken(count)
 }
 for _, val := range RateLimitC[flag2] {
 if key2_ok {
 rateLimit := NewRateLimit(val.Qps)
 rateLimit.Create()
 rateMap.Store(key2, &rateLimit)
 return true, rateLimit.Taken(count)
 }
 }

这是一段 QPS 限流的逻辑,内部实现利用了令牌桶算法,(先忽略有待优化的逻辑,我们来看为什么会出现问题)
代码的大概意思是:

如果用 key1 获取到了 token,就直接返回;否则,加锁,看是 map 里是否有 flag1 代表的限流信息,如果有,则判断是否有符合 key1 条件的,如果有,则走正常获取 token 逻辑;如果没有,则尝试用 key2 获取 token,(下边逻辑类似 key1)

问题就出在线上大部分情况需要用 key2 来获取 token,所以大部分请求都会进入加锁区域。如果只是一个加锁,应该很快就能处理完,但是会有堆积性的耗时呢。
我们来看一下 val.(*RateLimit).Taken(count) 的实现:

func (this *RateLimit) Taken(count int) error {
 timer := time.NewTimer(time.Duration(count) * TimeDuration)
 defer timer.Stop()
 for i := count; i > 0; i-- {
 select {
 case <-this.BucketCh:
 case <-timer.C:
 return errors.New("not get bucket")
 }
 }
 return nil
}

里边有个超时机制,如果限定时间内没有获取到 token,则返回错误。

那么,现在的问题是,所有走通过 key2 获取 token 都会在加锁的区域串行通过,那么,当没有立即获取 token 的请求,阻塞在计时器的时候,其他等待锁的请求都会阻塞在加锁的阶段,直到上一个请求超时,或者获取到 token,他才能获得锁。
换句话说,这条路是一个单行道,一次只能有一人通过,这个人还经常卡在收费站口,那么后边来的人就可能会越积越多,等待的时间越来越长,最后把路都给压垮了。

总结

像这种错误,想到之后是很容易复现的,而且只要满足条件,这个 bug 必现。
反思:

1. 开发最了解代码,功能完成之后,需要自己想一下测试的 case,尽量可以自己覆盖到;
2. 如果只看锁的部分,不觉得有什么问题,但是跟上下文结合起来,问题显而易见(lock + timer);

另外,这种耗时问题,可以在线下用 go 官方的 pprof 包,查看一下程序的耗时情况,也是可以发现的。

本文来自:Segmentfault

感谢作者:fevin

查看原文:【踩坑笔记】一次加锁和超时控制引起的交通事故

• 编辑
• 预览