背景
风控对接机票新业务线，在机票创单环节和出票环节，机票带着实时订单数据调用风控接口，风控即时返回是否有风险，涉及到个人账户，航司，航班等风险，具体策略不方便透露。其中，接口性能要求100ms。
遇到问题
接口超时，不满足业务需求
分析耗时链路
问题剖析主要从链路入手，首先就回顾了整个在做什么事情以及每一步的耗时
| 序号 | 做什么事 | 耗时 |
|---|---|---|
| 1 | 机票发起请求，网络上苏州请求到北京 | 20ms |
| 2 | 进入先业务基础数据落库 | 10ms |
| 3 | 查询账户维度风险标签 | 25ms |
| 4 | 查询名单4次 | 单次10ms 共40ms |
| 5 | 根据业务基础数据用mysql计算航司 航班风险 | 单次60ms 共2次 120ms |
| 6 | 组装前面结果，回写每个订单的命中情况 | 30ms |
| 6 | 结果从北京返回到苏州 | 20ms |
分析哪些可以减少耗时
| 序号 | 位置 | 处理方式 |
|---|---|---|
| 1 | 网络耗时 | 业务机房在苏州，服务提供方机房在北京，北京到苏州专线网络耗时一来一回就需要40ms,机房如果在一起，网络耗时可以在10ms左右 |
| 2 | 多份名单查询 | 多线程批量查询 |
| 3 | mysql计算太慢 | 换redis计算 |
| 4 | 回头分析业务 | 可以接受一致性差点的走异步，实在要保障一致性的走同步 |
总结方法论
| 序号 | 内容 |
|---|---|
| 1 | 整体上看优化性能思维上不能局限在代码本身，可以从业务，代码写法本身，整体运维架构综合考虑，优先考虑效果最好的 |
| 2 | 单独提出来，需要冷静分析业务本身，哪些可以接受一致性差点，哪些一定要保障，涉及到哪些可以多线程，哪些可以异步 |
| 3 | 耗时的每一步需要明确 |
| 4 | 运维，网络，DB等因素也是需要想到的 |
