# spring-boot-seckill

**Repository Path**: LeeSinXu/spring-boot-seckill

## Basic Information

- **Project Name**: spring-boot-seckill
- **Description**: 从0到1构建分布式秒杀系统，脱离案例讲架构都是耍流氓
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: https://blog.52itstyle.vip/archives/2853/
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 5982
- **Created**: 2020-02-02
- **Last Updated**: 2021-03-03

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

基于[小柒2012 / spring-boot-seckill](https://gitee.com/52itstyle/spring-boot-seckill)
### 具体实现方案以及测试性能
- 本机配置： 6核计算机
- 工具： jmeter    
- 实现类: SeckillVSController

#### 方案(只测试了公平方案)
- startDBPCC_ONE 数据库悲观锁  select ... for update
- startRedisLock redisson
- redisBuffLock  redis库存+redisson
- redisBuffDecr  redis.decr（redis单线程，本来就可以抗住并发）
- atomicLong     cas机制，硬件阻塞（库存在服务器上，所以只能单机）

#### 测试结果（单位：访问量每秒）
_http://localhost:8080/seckill/seckillVS/startDBPCC_ONE?seckillId=1000_   **`1254 1235 1353`**
_http://localhost:8080/seckill/seckillVS/startRedisLock?seckillId=1000_	**`650  690  612`**
_http://localhost:8080/seckill/seckillVS/redisBuffLock?seckillId=1000_	**`1628 1737 1665`**
_http://localhost:8080/seckill/seckillVS/redisBuffDecr?seckillId=1000_    **`1988 2179 1910`** 
_http://localhost:8080/seckill/seckillVS/atomic?seckillId=1000_           **`1983 2004 2021`** 

#### 结论
可以看出单机模式下redisBuffDecr和atomicLong两种方案貌似最吊

在多服务器负载条件下的方案(SeckillVSController.atomicRedisBuffDecr)

1. 每台服务器配置库存atomicLong，过滤掉一部分（比如秒杀10件商品，4台机器负载，经过过滤后还剩下40个线程）

2. 剩下的线程经过redis.decr操作

3. 做数据库插入订单和减库存操作（订单可以通过秒杀id和用户id索引来防止刷单）