优化高并发下的秒杀性能

.检测UPDATE语句的执行返回值，如果返回1证明中奖成功，否则证明该奖品被其他人抢了

为什么要添加乐观锁

正常情况下获取奖品、然后把奖品更新给指定用户是没问题的。如果不添加user_id=0时，高并发场景下会出现下面的问题：

1. 两个用户同时查询到了1个未中奖的奖品(发生并发问题)
2. 将奖品的中奖用户更新为用户1，更新条件只有ID=奖品ID
3. 上述SQL执行是成功的，影响行数也是1，此时接口会返回用户1中奖
4. 接下来将中奖用户更新为用户2，更新条件也只有ID=奖品ID
5. 由于是同一个奖品，已经发给用户1的奖品会重新发放给用户2，此时影响行数为1，接口返回用户2也中奖
6. 所以该奖品的最终结果是发放给用户2
7. 用户1就会过来投诉活动方了，因为抽奖接口返回用户1中奖，但他的奖品被抢了，此时活动方只能赔钱了

添加乐观锁之后的抽奖流程

1. 更新用户1时的条件为id=红包ID AND user_id=0 ,由于此时红包未分配给任何人，用户1更新成功，接口返回用户1中奖
2. 当更新用户2时更新条件为id=红包ID AND user_id=0，由于此时该红包已经分配给用户1了，所以该条件不会更新任何记录，接口返回用户2中奖

乐观锁优缺点

优点

• 性能尚可，因为无锁
• 不会超发

缺点

• 通常不满足“先到先得”的活动规则，一旦发生并发，就会发生未中奖的情况，此时奖品库还有奖品

压测

在MacBook Pro 2018上的压测表现如下(Golang实现的HTTP服务器,MySQL连接池大小100，Jmeter压测)：

• 500并发 500总请求数 平均响应时间331ms 发放成功数为31 吞吐量458.7/s

Redis实现

可以看到乐观锁的实现下争抢比太高，不是推荐的实现方法，下面通过Redis来优化这个秒杀业务。

Redis高性能的原因

• 单线程 省去了线程切换开销
• 基于内存的操作 虽然持久化操作涉及到硬盘访问，但是那是异步的，不会影响Redis的业务
• 使用了IO多路复用

实现流程

1.活动开始前将数据库中奖品的code写入Redis队列中

2.活动进行时使用lpop弹出队列中的元素

3.如果获取成功，则使用UPDATE语法发放奖品

（编辑：揭阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!