阅读量:0
一、故障简述
在2024年7月19日19:41，系统出现了“系统繁忙，稍后再试”的错误提示，数据库CPU达到100%，接口响应超时。
二、故障影响
- 影响时间：19:41-20:16
- 影响范围：商祥页及相关优惠券活动
三、故障时间线
- 19:41：错误日志大量告警
- 19:42：收到SQL慢查告警
- 19:44：技术大群反馈系统异常
- 20:16：代码屏蔽慢查SQL上线
- 20:52：接口层面查询缓存key更换为不删除不过期key上线
四、故障根因
- 缓存策略不合理：缓存key的更新和删除策略不合理，导致一段时间内缓存不存在，直接查询数据库。
- 数据库负载过高：缓存过期后查询数据库的SQL执行慢，导致数据库CPU资源占满。
详细原因：
- 同步活动券信息Job 每2分钟执行一次维护活动数据到缓存中，19:40生成缓存key。
- 券实例状态更新Job 在19:41执行，删除过期券实例对应的活动缓存key。
- 缓存被删除后，需等待19:42的定时器重新生成缓存。在此期间，大量用户查询活动券信息接口，直接查询数据库，导致数据库负载增加。
- 券基础信息Job 每2分钟删除生效中的优惠券缓存及其活动缓存。由于数据库负载高，导致设置缓存的操作比删除缓存的操作慢。
- 执行顺序问题：导致新设置的缓存很快被删除，接口持续在无缓存的状态下查询数据库，数据库资源持续告警。
五、改进措施
- 紧急临时优化：屏蔽活动优惠券缓存失效查库逻辑。
- 代码优化：缓存查询使用不过期的key。
- 数据库索引优化：优化优惠券统计查询SQL，增加联合索引，将执行时间从1200ms降至270ms。
- 规范：完善缓存使用规范，团队内宣讲。
- 风险排查优化：核心页面接口代码review，排查并优化不合理的缓存过期删除策略；统计redis热key，review代码。
- 监控：监控核心key的缓存命中率。
- Code Review：对优惠券代码进行review。
- 复盘：故障组内复盘。
- 营销活动同步：针对大型活动，与业务部门保持紧密沟通，提前通知技术部门进行服务扩容，完善服务流量评估和扩容策略。
六、进一步优化建议
1. 缓存策略优化
- 细粒度缓存控制：为不同类型的数据设置不同的过期时间，避免因一个缓存过期导致大量数据库查询。
- 缓存预热：在缓存即将过期时，预先加载新的缓存数据，确保缓存持续可用，减少直接查询数据库的频率。
- 双缓存机制：采用双缓存机制（Double Cache），在更新缓存前，保留旧缓存，直到新缓存数据加载完成再替换，避免缓存更新期间的数据缺失。
2. 数据库优化
- 分库分表：将高频查询的表进行分库分表，减少单个数据库的压力。
- 读写分离：使用主从复制，将读请求分发到从数据库，减轻主数据库的压力。
- SQL优化：对慢查询进行进一步优化，减少查询的数据量和复杂度。
3. 异步处理和队列
- 异步更新缓存：将缓存更新操作放入消息队列中异步处理，避免因缓存更新导致的同步阻塞问题。
- 队列降压：在高峰期间，使用队列对请求进行限流，防止突发流量直接打到数据库上。
4. 监控和告警
- 精细化监控：对关键缓存key、数据库查询、接口响应时间等进行更细化的监控，及时发现潜在问题。
- 智能告警：使用机器学习模型或自适应算法，对异常流量和性能指标进行智能分析和预警，提前采取措施。
5. 应急预案和演练
- 应急预案：制定详细的应急预案，包括故障检测、快速降级、切换备份方案等，确保在故障发生时能够快速响应和恢复。
- 故障演练：定期进行故障演练，模拟各种可能的故障场景，提高团队的应急响应能力。
6. 业务协同
- 流量预测与扩容：与业务部门协同，提前预测大型活动的流量，提前进行服务扩容和性能优化，确保系统在高并发情况下的稳定性。
- 平滑发布：对于关键功能和策略的调整，采用灰度发布策略，逐步放量，观察系统性能后再全量发布，降低风险。
7. 用户体验优化
- 降级策略：在系统压力过大时，采用部分功能降级策略，保证核心功能的可用性。比如，在优惠券系统不可用时，仍然保证商品浏览和购买功能的正常运行。
- 缓存友好接口：设计接口时，尽量减少对缓存的频繁读写操作，避免单一接口对系统性能造成过大影响。
通过以上优化措施和建议，能够进一步提升系统的稳定性和性能，减少因缓存和数据库问题导致的系统故障，提高用户体验和业务连续性。希望这篇技术文章能够帮助团队在未来避免类似的故障发生，为系统的稳定运行提供保障。
