golang 高频服务延时抖动追因

一，背景

策略组同学反馈有个服务上线后 redis 写超时非常严重，严重到什么地步呢，写redis 毛刺超过100ms！ 而且不是随机出现，非常多，而且均匀，导致整个接口超时严重。因为用的redis 库是由我们组维护，所以任务落我们组小伙伴头上了。

这个项目有非常复杂的业务逻辑，有密集型io(调度问题)+定时任务(cpu问题)+常驻内存cache(gc问题)，频繁访问redis，在定时逻辑中，业务逻辑需要一个request 可能达到上千次redis Hmget+get(先不讨论合理性)。 背景比较复杂， 是个golang 服务，接口延迟要求百ms级。

go version : 1.8，机器是8核+16G 容器，没有开runtime 监控，redis 的同事初步反馈没有slowlog。因为rd 也追了很久，到我们这边来的时候，redis 的超时指标监控已经给我们加了。

redis get 接口的耗时监控显示如下，因为高频请求，大部分耗时是小于10ms 的，但是这毛刺看着非常严重，是不可忍受了。

系统cpu问题比较严重，抖动非常大，内存并没有太大问题，但是占用有点大，比较有意思的事，因为用了local-cache，其实，我们刚开始以为是local-cache 导致的gc引起的。

因为没有加runtime 监控，其他信息暂不可知。

二，解决思路

因为追查接口毛刺比较复杂，我们的原则是不影响业务的情况下，尽量少上线的将业务问题解决。

我们初步给了个追查思路：

第一，首先排查是不是网络问题，对redis slowlog(redis 本身自带监控)；

第二， 本地抓包，看日志中redis 的get 时间跟真实网络的时间是否对的上(抓包最可靠)；

第三，对机器负载，是否对的上毛刺时间(cpu 资源不够，调度不过来毛刺也正常)；

第四，查redis sdk，这库我们维护的，看源码，看实时栈，看是否有阻塞(sdk 用了pool，sdk 本身也要压测下)；

第五，查看当前的gc pause ，看gc stw 时间是否影响redis(go 1.8 gc 性能比1.10-1.12 差很多)；

第六，抓trace ，看调度时间和调度时机是否有问题(并发协程数，GOMAXPROCS cpu负载都会影响调度)；

整个分析下来，只能用排除法了。

三， 现场分析

3.1 网络分析

因为服务的并发量比较大，其实查起来非常耗时。

• 1， redis slowlog 本身是正常的。这里类似类似redis， redis 有SLOWLOG。这里感谢redis 团队的支持。

• 2&#x