记一次接口调优

前言

前段时间，进行了一次接口调优，现进行简单记录。
需求是这样的，推出了切水果的玩法，用户切水果会爆出分数、虚拟货币，并积攒积分，积分可以兑换相应的商城积分。

需要解决的问题

切完水果之后需要将爆出的积分、虚拟货币等实时性较高的返回。初始期望是能在100个用户同时玩的情况下，每秒两次的调用，测试能保持在平均200ms的响应时长。
每次切水果需要扣除相应的虚拟货币，而且，每次切水果都跟用户之前获取的情况，平台获取的情况相关联。

解决过程

分解需求

在需求评审之后，针对实时性的问题，给出一些方案，如：

• 1.将原有单个水果的操作改为多个水果一次性切除。
• 2.将可以后续不影响主体功能的代码做异步处理。
• 3.将一些使用频繁，但是变更较少的操作改为本地变量。如：爆出概率
• 4.其他前期可以预见的问题。

通过以上的分析，特别是第一条，可以提前让前端做出一些调整，比如怎么样比较合适合并请求多个请求，而不影响用户操作感知。
针对第三条，针对数据变化要通过redis广播通知

code review

首先，组织组内成员对相关功能进行code review，针对一些常见的问题进行发现修改。如：

• 1.循环调用问题
• 2.逻辑错误问题
• 3.边界问题
• 4.能异步的进行异步操作

压测

准备100个用户数据，通过jmeter动态入参，对接口进行压测。
先压测底层dubbo接口，jmeter支持dubbo直接压测，按照100个用户，每隔0.5秒进行调用，进行长时间压测，观察总结结果，根据结果值，查询当前接口可优化的点。
然后压测http接口，模仿真实用户调用，同时，查看房间效果。
为了更便于压测，可以在每一步大的功能点，都加入相应的日志，分析日志可以看到哪里消耗最大。ps：如果大家有开源的更好的方案，欢迎补充。

最终，测试服的压测结果稳定在200ms，基本达到要求，可投入生产。
在压测过程中，也针对用户体验也发现了问题，反馈给产品和运营，可以说一举多得。

上线

因为此功能相对独立，在上线之后，也在线上环境进行了压测，基本稳定在50ms。

总结

在此次调优过程中，经过各方的配合，对细节的排查，提出一些建设性的建议，的确基本保证了基础要求，因为某些原因，该项目虽然上线，但是还未提供给用户，后续开放，也会持续进行关注。

以上的一些调优方案，属于基础的调优方案，如果大佬能够有更好的调优方案，欢迎私聊、评论，相互提高，谢谢。