秒杀场景是电商行业经常遇到的场景，比如针对某款热门限量产品的抢购，对应到关系型数据库的模型就是，一款产品对应二维表中的一条记录，抢购对应着这个记录的库存值的update更新。

因为要维护事务特性，抢购对应的update语句在事务级别没有并行性可言，必须串行完成，所以，当有大并发请求到达时，在InnoDB引擎层(假设使用InnoDB)，需要排队维护事务级阻塞关系，
伴随着死锁检测的开销越来越大，主机计算资源严重消耗，吞吐量随着并发请求越来越大而急剧下跌，响应延时增大，形成雪崩效应，最终导致业务中断。

AliSQL在针对秒杀场景有多套解决方法，可以组合使用。无一例外，都是基于排队论的思想，期望在大并发的时候，保证数据库
持续稳定，维持高吞吐能力，进而保护应用链条， 这里简单介绍三种方法：

1. InnoDB引擎层排队：使用innodb_thread_concurrency参数控制在引擎层入口进行排队。
2. Server层排队：使用hint的方式，在parse后进行排队。
3. 高低水位：使用high-water-marks 进行fast fail，以防止排队过长，拖垮应用。

下面针对Server层的排队，进行测试

主机配置:
CPU: Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
OS kernel: Linux 2.6.32
Memory: 512 G
Disk: SSD

AliSQL采用RDS配置的8C-16G的规格进行测试，具体参数参考AliSQL-8C-16G.cnf

打开Server层排队的开关：set global rds_ic_reduce_hint_enable=ON

测试采用sysbench标准测试，测试场景为alisql_ic.lua
update COMMIT_ON_SUCCESS ROLLBACK_ON_FAIL QUEUE_ON_PK 1 TARGET_AFFECT_ROW 1 t1 set c=c+1 where id=1;

Sysbench主要参数：

--max-requests=0  
--max-time=900  
--oltp_tables_count=1 or 8
--oltp_table_size=1  
--report-interval=10  
--num-threads=$count 
--oltp_inventory_mysql_type=alisql // needed for AliSQL

本次测试共对比了两个版本， AliSQL 5.6.32，Oracle 5.6.32。

测试数据如下：

1. 单条记录更新

   Thread	Oracle 5632	AliSQL 5632	AliSQL 5632 VS Oracle 5632
   8	4360	5182	18.85%
   16	4366	5115	17.16%
   32	4314	5131	18.94%
   64	4185	5112	22.15%
   128	2283	5158	125.93%
   256	596	5146	763.42%
   512	143	5150	3501.40%
   1024	99	5050	5001.01%
   1536	38	4930	12873.68%
   2048	1	4896	489500.00%

2. 八条记录更新

   Thread	Oracle 5632	AliSQL 5632	AliSQL 5632 VS Oracle 5632
   8	16737	17298	3.35%
   16	20538	24145	17.56%
   32	20349	24074	18.31%
   64	20139	23824	18.30%
   128	19030	23876	25.47%
   256	16376	23984	46.46%
   512	8981	23973	166.93%
   1024	6759	23743	251.28%
   1536	3720	23550	533.06%
   2048	2241	23406	944.44%

从上面的压力测试情况，在秒杀的场景下，AliSQL可以保持持续稳定的吞吐能力。