12-场景

1、秒杀场景

应对策略：

1）秒杀系统独立部署

2）秒杀商品页面静态化

3）租借秒杀活动带宽（将秒杀页面缓存到CDN）

4）动态生成下单URL，防止用户直接访问下单页面URL

5）按钮置灰，5秒内不可重复点击

6）集群中的每台服务器都只接受固定数量请求，其他直接响应秒杀活动结束

7）友好设计：所有异常都应捕获，即使服务器瘫痪，应返回“秒杀活动结束”

Mysql层面优化，丁奇：

测试显示，在6线程时，TPS达到顶峰1.9W，随着线程数增加TPS急剧下降

问题：当线程并发时，Innodb内部存在太多线程

1）关掉死锁检测，正常的业务死锁会变成超时，治标不治本，效果微弱

2）修改源码：将排队队列提到进入引擎层之前（放到server层），随着线程数增加TPS稳定在1.5W

3）优化排队，组提交策略，TPS提升稳定至8.5W

如何防止超卖

以下3种办法：

1、将提交操作变成两段式，先申请后确认。

1.1利用Redis的原子自增操作（相比较MySQL的自增来说没有空洞），同时利用Redis的事务特性来发号，

  保证拿到小于等于库存阀值的号的人都可以成功提交订单。

1.2数据异步更新到DB中。

优点：解决超卖问题，库存读写都在内存中，故同时解决性能问题。

缺点：由于异步写入DB，可能存在数据不一致。另可能存在少买，也就是如果拿到号的人不真正下订单，可能库存减为0，但是订单数并没有达到库存阀值。

2、数据库层面

2.1设计2张表：

第一张：判重表(buy_record)，该用户有没秒杀过该商品

字段: id, uid, goods_id, addtime

第二张表：商品表 goods

字段： goods_id  goods_num

2.2对（uid,goods_id）加唯一索引！

start transaction;

insert into buy_record。。。

if(唯一索引报错？)

    抛异常，已经秒过了，回滚。。。

update goods set goods_num=goods_num-1  where goods_id=$goods_id and goods_num>0 ;

if(受影响行数<=0)

    抛异常，商品秒完了，回滚。。。

该方法完美的解决了超卖与select排它锁导致的并发低的问题。极大提升性能

3、Mysql优化，改源码

丁奇在DTCC2013上分享的《秒杀场景下MySQL的低效》

1）关掉死锁检测，正常的业务死锁会变成超时，治标不治本，效果微弱

2）修改源码：将排队队列提到进入引擎层之前（放到server层），随着线程数增加TPS稳定在1.5W

3）优化排队，组提交策略，TPS提升稳定至8.5W