背景：核心服务qps达到了500k+，核心数据大约占有400k+，还有100k左右的非核心数据请求，为做到服务解耦，保证核心服务的稳定性，进行系统拆分，拆分系统包括上线大约耗时1周，拆分完成之后即需要压测，压测流量单机房为总流量的1.5倍，即压测最高的qps达到150k。
压测包含两个接口，第一个是单个id查询getById(Long id)，占用流程约为60k，另外一个是批量查询batchGet(List<Long> ids)，占用流量约为40k。
技术栈：spring boot，mybatis，redis，mysql.....
单台服务器配置: 8c 16g
客户端请求 -> 查询缓存 ->查询db -> set缓存
过程：
压测单个getById(Long id)接口时，qps达到了60 * 1.5 = 90k，系统 cpu 不足80%，已经达到了压测标准。但是当压测到batchGet(List<Long> ids)，list 中 id 数量为 50，压测到 2k 的qps，cpu竟然达到了 80%，但是去查询拆分前的服务 rt_time 不超过 5 ms。由于新服务是我搭建（老服务中的这段逻辑也是我编写的），我自然而然的想到了出问题的点，在拆分出来的新服务中，为了代码简约，batchGet(List<Long> ids)查询数据时直接调用了getById(Long id)，那么当批量查询50次，和redis建立了50次的连接，最后修改了batchGet(List<Long> ids)中逻辑，改为mget调用获取缓存中的数据，rt_time的时间降到了5ms以下。但是仍然存在第一个问题，压测时使用新数据ids，rt_time和cpu都是飙升，过片刻时间就恢复了，我怀疑是新数据在缓存中不存在数据，那么就会查询db，然后在一个一个的set到缓存中，优化点当然是将一个一个set改为批量set，使用到了redis提供的技术pipeline，修改完成之后再次压测，不管是rt_time和cpu都有明显的降低。
一点点小小的优化，对性能提升是巨大的，同时感谢压测的小姐姐～
网友评论