故障现象
问题影响现象：多个接口响应缓慢
故障处理过程
10:35告警群出现告警信息
查看一小时内的链路追踪发现支付批量更新接口调用次数较多且平均响应时间较长
10:51查看链路追踪发现org的接口响应时间较长
查看org日志发现有redis报错
查看redis监控发现10:34左右出口流量使用率达到了100%
联系运维把最大私网带宽从24M/s调到72M/s
12:00左右响应时间恢复正常
故障原因
redis瞬时查询返回量过多导致出口流量打满,影响系统整体响应时间
反思与改进方案
快速修复方案:
扩容最大私网带宽到72M/s
查找出现问题的时间段内的慢查询,目前redis主要的慢查询范围基本在org服务和condition服务,org存在慢查询的主要原因是大部分接口都是调用redis获取整个对象信息,org的请求量较高,查询量大的情况下返回的量也多,对于已发现的慢查询,目前优化了一个授权管理入口的查询接口,直接从数据库查询,返回需要的值,不走redis,该优化已发生产
整体优化方案：
org服务的高频接口都需要进行优化分析,主要从传入参数数量限制和接口处理效率优化两方面考虑,由于接口调用入口非常多,可以根据调用的频率从高到低进行优化,优先优化高频接口,主要从redis监控中的慢日志入手进行分析,找到调用的场景,定位之后进行优化,org服务计划新增一个redis,condition服务的慢查询主要集中在泰格,这部分优化可能需要爱荣分析一下
redis规范整理：
redis的使用目前比较随意,最好是要有一个规范文档,列出推荐的和不推荐的使用方法,按统一的规则进行开发,避免出现一些共性的问题,这部分计划先整理一版初稿,后期再不断完善
加强redis监控：
目前redis资源使用超过上限没有相应的告警提示,需要增加主要指标的告警,目前最重要的是出口流量使用率,一旦出现异常极易引发线上故障,需要有类似慢sql统计的机制对redis的慢日志也进行统计,对于线上出现的慢日志需要经常关注,并思考如何优化,最终目的是要消除慢日志
