基于过往业务的个人技术日志—第一天
业务背景回顾
今天开始整理过往参与的核心项目技术细节，第一个回顾的是2022年Q2负责的电商促销系统性能优化项目。该系统承载公司618大促活动，峰值QPS需支撑5万+，原系统在压测时出现响应延迟飙升和数据库连接池耗尽问题。
技术问题定位
通过阿里云ARMS监控发现以下关键瓶颈点：
- 缓存穿透：热门商品ID被恶意遍历攻击，导致大量请求直击MySQL
- 分布式锁竞争：秒杀场景下Redisson锁的等待队列堆积
- SQL慢查询：订单历史表缺少
user_id索引，200万数据全表扫描
优化实施记录
1. 缓存层改造
- 实现布隆过滤器拦截非法请求（使用Guava BloomFilter，误判率设为0.01%）
- 增加本地缓存Caffeine二级缓存（配置最大容量1000，TTL 30秒）
- 示例代码：
// 布隆过滤器初始化BloomFilter<String>filter=BloomFilter.create(Funnels.stringFunnel(Charset.defaultCharset()),1000000,0.01);2. 锁优化方案
- 将商品库存分段（如1000库存分为10个segment）
- 采用Redis+Lua实现原子扣减，避免分布式锁竞争
- 关键配置：
redisson.threads=64 redisson.nettyThreads=323. 数据库调整
- 为
order_history表添加联合索引(user_id,create_time) - 将冷数据迁移至PolarDB列存节点
- 执行计划对比：
# 优化前 | id | select_type | rows | Extra | |----|-------------|--------|----------------| | 1 | SIMPLE | 198万 | Using filesort | # 优化后 | id | select_type | rows | Extra | |----|-------------|------|-------------| | 1 | SIMPLE | 15 | Using index |效果验证
压测报告显示：
- 平均响应时间从487ms降至89ms
- 数据库CPU利用率从92%下降到35%
- 大促期间零故障告警
明日计划
整理该项目中遇到的Redisson看门狗线程失效问题的排查过程，包括：
- 线程堆栈分析方法
- 锁续期机制源码解析
- 最终解决方案设计基于过往业务的个人技术日志—第一天
