背景
最近上线了一个kafka的消费者，数据规模大概是低峰期单机每分钟消费88W条，QPS 14666。上线后看了下数据，进程CPU到了132%。8核的机器，单进程CPU132倒也还好，但还是想看看，到底是咋回事。
过程
第一次排查&优化（协程池化->约为0优化）
于是就开始采集pprof的数据。golang pprof的采集是十分便捷的，在main.go引入net/http/pprof包，包里pprof.go文件的init()方法就会自动注册相关的http路由。CPU的火焰图看着就有点不合理，光是runtime的部分，居然耗费了1/3的CPU。首先怀疑是goroutine创建过多的问题，我们消费者框架如下图，服务从kafka消费到一条msg后，会分发给每一个plugin，为了plugin之间互不影响，所以都是异步调用plugin的。
所以这里每条消息会有放大的问题，这个服务有3个plugin，每条消息就会创建3个goroutine，也就是每秒创建14666*3约45000 goroutine。解决办法也简单，就是池化，以达到goroutine复用的目的，也就是老生常谈的协程池了。这里用了我司的一位go社区大牛的协程池库ants[1](可惜这位大牛已经江湖见了我哭死)，有协程池需求的可吃波安利。
标签：err,trace,pprof,性能,goroutine,调度,kafka,调优,CPU From： https://www.cnblogs.com/77cxw/p/18145098