GO语言是非常适合高并发场景的，那么，业务系统具体会遇到哪些高并发的场景呢？该如何考虑性能开销呢？那么本文就笔者在业务系统常常遇到的问题来抛砖引玉~
请求合并
这是什么场景呢？回源！回源DB，二进制流回源源站等等~高并发的场景下，大量用户访问同一个对象，那么做请求合并可以节省非常可观的资源，singleflight~当然这是进程内的用法。
批量协议
好像和请求合并有点像？不太一样。比较经典的case就是redis的pipeline，业务接口更是如此。能批量就批量，减少请求放大，减少太多的封包解包，减少cpu和带宽~
merge请求
额~~merge什么？比如一个视频id更新计数，那么9->18->25......对了，计数从1涨到100，难道我要写100次db吗？很明显，可以内存里merge~~
并行请求
这个用法在网关服务就非常常见啦~当你的服务需要聚合A、B、C这3个系统的数据，而A、B和C之间没有依赖，那么完全可以并行请求。golang里常用errgroup去实现。
减少锁以及系统调用
有些情况锁是很难避免的，但是可以通过一些锁粒度拆分优化去减少锁的开销。系统调用对cpu的开销都是挺明显的，具体可以压测看profile，也可以查看top，us%的开销在90%以上，说明性能优化还是可以的。
序列化协议，json和pb
这里既包括API的协议，也同时包括缓存对象的序列化协议。缓存的访问常常会几倍于api请求，经常有放大，所以更要重视。
异步处理，使用channel，而不是无限制go func()
比如更新缓存的场景。这点挺容易理解，无限制的goroutine会带来大量的context切换，浪费cpu。当然channel的长度要做限制和监控。消费者goroutine数可以适当配置。