背景简介
阿里巴巴兴于电商，电商客户的需求和痛点对于我们自然也体会的比较深。秒杀这一场景最早来自天猫双11各种商品的促销活动中，发展到现在已经有很多业务场景在使用，比如抢红包，春运抢票等。这类的场景其特点有三高：瞬时并发高，数据一致性高，热点更新频度高。这样三高的场景下往往给客户数据库造成极大的压力，大量更新数据库中的同一行，这样必然会产生数据库锁等待，导致客户数据库的性能急剧下降的问题，很容易导致客户的业务雪崩。阿里云数据库针对这个客户“痛并快乐”的场景进行专项的优化，帮助我们的客户在任何秒杀场景“稳如泰山”。

在秒杀的业务场景中，数据库成为了底层系统中最重要的瓶颈点。某电商公司是阿里云的客户，在客户使用阿里云数据库之前，我们的客户只能用最原始的升级配置，降低锁等待时间等来解决这个场景所带来的烦恼，但是由于业务量级随着商业扩展而扩大，传统的解决办法越来越难以满足这类的场景。阿里云经过几年的沉淀也诞生了很多的技术手段来进行优化，帮助我们阿里云数据库的用户轻松度过秒杀场景，让赚钱的同时不再受技术瓶颈的煎熬。

阿里云的数据库工程师发现，当大量的并发更新同一条记录时（秒杀场景），使用排队的方式来保证高并发下热点记录更新在不影响业务的同时依然能保持较好的性能，为threads_running设置一个硬上限，当并发超过此值时，数据库将拒绝执行sql，保护MySQL，我们将这个称之为高水位限流。这样就给数据库加上了一层限流的功能，使得数据库不被瞬间的高爆发请求打爆。

高水位限流实现：

  监控系统status变量threads_running，当满足拒绝条件，拒绝执行sql，返回用户：MySQL Server is too busy，判断逻辑在dispatch_command中，sql解析之后。

增加的系统variables：

 1.threads_running_ctl_mode： 限流的sql类型，有两个取值：[ALL | SELECTS]，默认SELECTS，设置为ALL需谨慎。
  2.threads_running_high_watermark： 限流水位值，只有threads_running超过此值才会触发，默认值为max_connections，当set global threads_running_high_watermark=0时自动设置为max_connections。

拒绝必要条件：

 1..threads_running超过threads_running_high_watermark。
 2..threads_running_ctl_mode与sql类型相符。

以下情况不拒绝：

 1.用户具有super权限。
 2.sql所在事务已经开启。
 3.sql为commit/rollback。

目前，阿里云的关系型数据库ApsaraDB RDS已经集成了这类秒杀场景下的参数优化，所以如果你的应用场景中具有大量并发更新同一行记录的场景，你可以打开数据库的限流参数：threads_running_ctl_mode和threads_running_high_watermark来保护数据库，让你的数据库平稳过渡。下面我们来看一则该电商某客户的生产环境的案例。

从上图中看到该数据库的活跃连接数最高的时候到达了1W，通过show processlist可以看到大量的并发更新。

我们来看一下数据库并发更新的TPS有多大：

可以看到数据库中的活跃连接数非常高，每秒的update非常不稳定。
我们在把限流开关打开后看一下性能表现：
mysql> set global rds_threads_running_high_watermark=300;
Query OK, 0 rows affected (0.00 sec)

mysql> set global rds_threads_running_ctl_mode='all';
Query OK, 0 rows affected (0.00 sec)

从上图可以明显的观察到，通过打开数据库的限流开关，数据库的活跃连接数在300左右，同时数据库的TPS也没有再出现很大的波动，这样很好的保护住了DB。

该电商用户自从使用了阿里云关系型数据库 ApsaraDB RDS，很好的解决了以往令人头疼的高并发问题场景，令该公司成功度过了几次双十一和大型促销，对其业务的增长和发展起到了至关重要的技术保障和支持。