1. 秒杀系统架构设计与技术选型
秒杀系统作为电商领域最具挑战性的业务场景之一，其核心难点在于如何应对瞬时高并发流量。去年双十一期间，某头部电商平台的秒杀系统峰值QPS达到惊人的50万+，这对系统架构提出了极高要求。我们这套基于SpringBoot+Vue+MySQL的解决方案，经过多次压测验证，在4核8G的标准服务器配置下可稳定支撑2万+的并发请求。
1.1 为什么选择SpringBoot+Vue技术栈
SpringBoot的后端选择主要基于以下考量：
- 自动配置特性大幅减少XML配置，内置Tomcat容器实现快速部署
- Starter依赖机制让Redis、RabbitMQ等中间件集成变得极其简单
- Actuator端点提供完善的系统监控能力，这对秒杀系统的健康检查至关重要
- 与Spring生态无缝集成，可以方便地使用Spring Security做鉴权、Spring Data JPA操作数据库
前端选用Vue.js主要因为：
- 响应式数据绑定特别适合秒杀倒计时、库存实时更新等动态场景
- 组件化开发模式便于复用秒杀按钮、商品卡片等UI元素
- Vuex状态管理能优雅处理全局的秒杀活动状态
- 相比传统jQuery，Vue的虚拟DOM在频繁更新界面时性能更优
1.2 数据库设计的核心考量
MySQL表设计遵循了几个关键原则：
- 所有表都包含create_time字段，便于后续数据分析
- 数值型ID全部使用BIGINT，避免未来数据量增长带来的溢出风险
- 金额字段使用DECIMAL(10,2)确保计算精度
- 状态字段采用TINYINT配合枚举值，比字符串更节省空间
活动表(seckill_activity)与商品表(seckill_product)采用一对多关系设计，这种解耦方式使得：
- 同一商品可以参与不同时段的活动
- 活动配置变更不会影响已上架商品
- 便于按活动维度进行数据统计
2. 高并发场景下的关键技术实现
2.1 分布式锁解决超卖问题
超卖是秒杀系统最致命的问题。我们采用Redis+Lua脚本实现分布式锁，具体流程如下：
java复制// 减库存Lua脚本
String script = "if redis.call('exists', KEYS[1]) == 1 then\n" +
" local stock = tonumber(redis.call('get', KEYS[1]))\n" +
" if stock > 0 then\n" +
" redis.call('decr', KEYS[1])\n" +
" return stock - 1\n" +
" end\n" +
" return -1\n" +
"end\n" +
"return -2";
// 执行脚本
Long result = redisTemplate.execute(
new DefaultRedisScript<>(script, Long.class),
Collections.singletonList("seckill:stock:" + productId),
Collections.emptyList());
这种方案相比简单的Redis decrement命令有三个优势：
- 判断库存和减库存是原子操作
- 避免网络延迟导致的并发问题
- 脚本在Redis单线程执行，无需额外锁机制
2.2 多级缓存架构设计
我们的缓存策略分为三层：
- 浏览器缓存：静态资源设置Cache-Control: max-age=3600
- CDN缓存：将商品图片等静态内容分发到边缘节点
- 服务端缓存：
- Redis缓存热点商品信息
- 本地Caffeine缓存活动配置
缓存更新采用"先更新数据库再删除缓存"的策略，配合消息队列保证最终一致性：
java复制@Transactional
public void updateProduct(SeckillProduct product) {
// 1. 更新数据库
productMapper.updateById(product);
// 2. 发送缓存更新事件
rabbitTemplate.convertAndSend(
"cache.update.queue",
new CacheUpdateEvent("product", product.getId()));
}
// 消费者端
@RabbitListener(queues = "cache.update.queue")
public void handleCacheUpdate(CacheUpdateEvent event) {
if("product".equals(event.getType())){
redisTemplate.delete("product:" + event.getId());
}
}
2.3 流量削峰方案
我们采用三级流量控制策略：
| 层级 | 实现方式 | 阈值设置 | 效果 |
|---|---|---|---|
| 前端 | 按钮防重复点击 | 300ms内禁止重复提交 | 减少30%无效请求 |
| 网关 | 令牌桶限流 | 每秒5000令牌 | 控制总流量规模 |
| 服务 | 队列缓冲 | RabbitMQ积压10万消息 | 平滑数据库压力 |
特别值得注意的是秒杀按钮的实现细节：
vue复制<template>
<button
:disabled="isSeckilling || countdown > 0"
@click="handleSeckill">
{{ buttonText }}
</button>
</template>
<script>
export default {
data() {
return {
isSeckilling: false,
countdown: 0
}
},
methods: {
async handleSeckill() {
this.isSeckilling = true;
try {
await seckillApi(this.productId);
} finally {
setTimeout(() => {
this.isSeckilling = false;
}, 300); // 强制300ms冷却期
}
}
}
}
</script>
3. 系统部署与性能调优
3.1 服务器配置建议
经过压测验证的推荐配置：
| 组件 | 配置要求 | 说明 |
|---|---|---|
| Web服务器 | 4核8G，带宽10Mbps | 建议部署2台做负载均衡 |
| Redis | 8G内存，开启持久化 | 必须部署主从架构 |
| MySQL | 16G内存，SSD磁盘 | 需要配置读写分离 |
| RabbitMQ | 4核8G，磁盘100G | 消息队列需要足够磁盘空间 |
3.2 JVM参数优化
SpringBoot应用的JVM调优参数示例：
bash复制java -jar -Xms2048m -Xmx2048m -XX:MetaspaceSize=256m \
-XX:MaxMetaspaceSize=512m -XX:+UseG1GC \
-XX:MaxGCPauseMillis=200 \
-XX:ParallelGCThreads=4 \
-XX:ConcGCThreads=2 \
seckill.jar
关键参数说明：
- G1垃圾回收器适合大内存应用
- MaxGCPauseMillis控制GC停顿时间
- Metaspace大小需要根据类加载情况调整
- 并行GC线程数建议设置为CPU核数的1/4
3.3 MySQL性能调优
秒杀场景下的数据库优化要点：
- 索引优化：
sql复制ALTER TABLE seckill_order
ADD INDEX idx_user_product (user_id, product_id);
- 参数调整：
ini复制[mysqld]
innodb_buffer_pool_size = 12G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
sync_binlog = 100
- 连接池配置（建议使用HikariCP）：
yaml复制spring:
datasource:
hikari:
maximum-pool-size: 50
minimum-idle: 10
connection-timeout: 3000
idle-timeout: 600000
max-lifetime: 1800000
4. 常见问题排查手册
4.1 典型错误与解决方案
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 库存扣减成功但订单未生成 | 消息队列堆积 | 增加消费者数量 |
| Redis连接超时 | 连接池耗尽 | 调整maxTotal和maxIdle参数 |
| 秒杀按钮点击无响应 | 前端防抖逻辑冲突 | 检查按钮disabled状态绑定 |
| 活动结束后仍可下单 | 缓存未及时失效 | 添加活动结束时的缓存清理逻辑 |
4.2 压测异常排查流程
当JMeter压测出现异常时，建议按照以下步骤排查：
- 检查基础指标：
bash复制# CPU使用率
top -H -p `pgrep -f seckill`
# 内存占用
jstat -gcutil `pgrep -f seckill` 1000
# 网络连接
netstat -ant | grep 8080 | wc -l
- 分析GC日志：
bash复制# 添加JVM参数生成GC日志
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log
# 使用GCViewer分析
java -jar gcviewer.jar gc.log
- 检查慢查询：
sql复制-- 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
-- 分析慢查询
mysqldumpslow -s t /var/log/mysql/mysql-slow.log
4.3 线上应急方案
当系统出现雪崩时，应立即执行以下操作：
- 降级策略：
- 关闭非核心功能（如用户评价、推荐系统）
- 将秒杀结果页改为静态页面
- 启用本地缓存替代Redis查询
- 限流措施：
java复制// 使用Sentinel实现限流
@SentinelResource(value = "seckill", blockHandler = "handleBlock")
public Result seckill(Long productId) {
// 业务逻辑
}
public Result handleBlock(Long productId, BlockException ex) {
return Result.error("系统繁忙，请稍后再试");
}
- 数据修复：
sql复制-- 核对库存一致性
SELECT p.product_id, p.stock_count,
(SELECT COUNT(*) FROM seckill_order o WHERE o.product_id = p.product_id) as sold
FROM seckill_product p;
-- 修复库存
UPDATE seckill_product
SET stock_count = 100 - (SELECT COUNT(*) FROM seckill_order WHERE product_id = 123)
WHERE product_id = 123;
这套系统在实际项目中已经验证过稳定性，但部署到生产环境时还需要根据具体业务需求调整参数。特别是在大促前，建议做好以下准备：
- 进行全链路压测
- 准备应急预案文档
- 搭建监控大盘（建议使用Prometheus+Grafana）
- 提前扩容云资源
我在实际部署时发现，Nginx的keepalive_timeout设置对长连接场景影响很大，建议调整为：
nginx复制keepalive_timeout 65;
keepalive_requests 10000;