业务导向型技术日志首日记录

基于过往业务的个人技术日志—第一天

业务背景回顾

今天开始整理过往参与的核心项目技术细节，第一个回顾的是2022年Q2负责的电商促销系统性能优化项目。该系统承载公司618大促活动，峰值QPS需支撑5万+，原系统在压测时出现响应延迟飙升和数据库连接池耗尽问题。

技术问题定位

通过阿里云ARMS监控发现以下关键瓶颈点：

1. 缓存穿透：热门商品ID被恶意遍历攻击，导致大量请求直击MySQL
2. 分布式锁竞争：秒杀场景下Redisson锁的等待队列堆积
3. 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=32

3. 数据库调整

• 为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看门狗线程失效问题的排查过程，包括：

• 线程堆栈分析方法
• 锁续期机制源码解析
• 最终解决方案设计基于过往业务的个人技术日志—第一天