引子

最近负责的一个消息推送系统要上线了，性能方便要满足两个要求
1、对外提供的接口能达到5w条/s的tps。
2、查询功能和统计报表在数据量大的情况下要保证速度。

项目环境：
linux+tomcat8+mysql8+redis+rocketmq

优化思路

1、接口优化

接口状况：http接口，接收到短信数据库后，先进行用户身份、用户余额、黑名单、敏感词等校验，校验完成后，插入到mysql数据库。然后通过计划任务从数据库中查询出待发送的短信数据，推送到mq,发送子系统负责从mq中消费短信数据发送到运营商网关。
压测的时候发现，只能达到15条/s的tps，离5w这个目标差十万八千里。

问题分析：
校验的时候都是从redis里面取的数据，问题应该不大，那就剩下一个插入数据的操作了，刚好测试那边也反馈了数据库cpu占用100%，那么基本确定性能瓶颈就在插入数据库这里。

<<优化思路>>
当时想到两个解决办法：
a、接口接收到数据后，校验通过，直接发送mq，消息推送系统和发送子系统同时去消费，一边入库一边发到运营商网关。
b、接口接收到数据后，校验通过，先保存到redis中，再用一个计划任务轮询redis去批量入库。
批量入库参考：https://www.cnblogs.com/caica…

a计划，优点是短信数据很快的就发送到运营商网关，用户能够很快的收到。缺点就是，第一如果发送子系统已发送完毕，状态报告返回时，短信数据还没入库，这时候就比较蛋疼了。第二数据入库还是单条，数据库压力仍然很大，影响其他功能的使用。

b计划，优点是使用redis做缓存层，再通过计划任务从redis中取数据进行批量入库，接口只操作redis，性能没问题，批量入库大大减轻了数据库压力。缺点是数据入库到发送到运营商网关会有几秒的延迟，还有就是批量入库失败，数据有丢失风险。

2、查询优化

短信查询功能，需要根据一些查询条件去查询短信的数据（分页查询），需要根据发送时间降序排列，还需要根据用户权限过滤，关联表有4张左右。600万条数据，需要几十秒的查询时间，崩溃。

<<优化思路>>
在查询条件字段和排序字段加上索引，减少几张关联表（数据量很少几十条的样子，如果关联进去是用来做查询条件，可以用exists来替代，如果是用来查询某个字段的，可以在取到结果集后，再去单独查一下这个字段），优化后，0.004秒搞定。然后又发现翻页的时候，查询总数速度慢、还有查询页数越大越慢的问题。

• 总数慢的问题解决：count(1),count(*),count(字段)这几种方式都试了，没用啊，后面发现单表count快，多表就慢，于是只count一张表，其他表主要是做查询条件的，使用exists的方式改写，问题解决。
• 翻页慢的问题解决：越往后面翻页就越慢，最后一页要80多秒，使用的limit m,n来分页的，幸好有大神详细分析了这个问题，博客地址：https://www.cnblogs.com/genin…

后记

1、单机压测最终能达到5000条/s的tps，离目标5w/s的距离仍有一定距离，但是可以通过集群部署的方式来弥补。后续优化方向，增加nginx配置长连接、使用undertow服务器替换tomcat服务器，使用netty重新开发短信发送接口等。

2、查询慢的问题基本解决，后续再根据实际情况看是否需要继续优化，优化方向：表分区、分库分表。