AliSQL秒杀场景测试报告样例

/ 0评 / 0

背景介绍

秒杀场景:

秒杀场景是电商行业经常遇到的场景,比如针对某款热门限量产品的抢购,对应到关系型数据库的模型就是,一款产品对应二维表中的一条记录,抢购对应着这个记录的库存值的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=20
--oltp_table_size=200000
--report-interval=10
--num-threads=$count

测试对比和结果

本次测试共对比了两个版本, 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可以保持持续稳定的吞吐能力。

发表评论

电子邮件地址不会被公开。 必填项已用*标注