DAS支持自动限流功能,您可自定义设置触发条件,当相关条件满足时会自动触发SQL限流。本文以RDS MySQL为例介绍如何使用自动SQL限流。
前提条件
背景信息
- 流量问题:出现缓存穿透或异常调用情况,导致某类SQL并发量急剧上升。
- 数据问题:存在大订单数据的账号,该账号的相关SQL占用大量数据库资源。
- SQL问题:未创建索引的SQL被大量调用,影响正常业务。
案例视频
自动SQL限流流程图

- 异常检测
该模块通过机器学习对实例历史性能数据进行离线训练获得相关模型,并利用该模型对实时指标数据进行异常检测。相比于阈值告警,7x24小时的异常检测能更及时的发现异常。
- 根因定位
该模块会订阅实例的异常事件并采集出现异常时的会话信息,结合SQL审计中的全量SQL和performance_schema中的统计信息进行判断,定位实例异常的原因。 我们将根因分为以下4种场景:
- 阻塞型SQL
DAS能够通过分析实时会话、锁等待和运行中的事务,判断是否存在DDL变更、锁等待和大事务等情况。同时DAS还能分析和判断被影响会话的数量和执行时间,如果被影响的会话比较多或执行时间很长,则该异常无需通过限流SQL来解决,而是Kill异常会话。
- 资源消耗型SQL(即烂SQL)
该场景中,可能SQL的并发量不大,但会消耗大量的CPU、IO或网络资源,并且会持续不断地提交。
- 流量型SQL
大量的正常SQL在数据库中同时运行,触发数据库的资源瓶颈,导致甚至KV类的查询SQL的响应时间都出现异常。
- 其他
其他未包含上述3种情况的场景。
- 阻塞型SQL
- 自动限流
当发现实例存在上述根因分析中的第2和第3种场景(即资源消耗型SQL和流量型SQL)时,DAS会自动提取SQL特征,并对异常SQL进行限流(用户授权的情况下触发)。
- 特征选取
如果发现需要限流的异常SQL,下一步就需要确定SQL的特征进行精确限流,防止特征选取错误而导致业务全面受损。理想情况是特征是唯一的,只对识别到的异常SQL进行限流而不影响其它SQL。这里首先要区分SQL模版限流和SQL文本限流。
- SQL模板限流
SQL模板是指将SQL文本的具体参数抽象化后的文本。这类SQL并发度高都会产生问题,但与具体参数无关,因此特征只需要包含模板特征即可。这类限流主要应对突增流量、无索引等场景。
- SQL文本限流
同一类模板中一些SQL执行正常,但另一些执行异常,特征中既要包含SQL模板信息,又要包含具体参数信息。这类限流主要应对数据倾斜的场景。
对于SQL模板限流,如果SQL中包含模板ID信息,会优先使用ID类信息(如使用数据库中间件根据模板自动生成的SQL ID或者开发人员在SQL模板中添加的HINT信息)。使用ID的优点是容易保证模板唯一,不会对其它模板的SQL造成影响;缺点是同样的SQL如果不带ID信息(比如通过命令行手动执行)则不受限流并发度控制,仍然可以执行。
如果SQL中不包含模板ID信息,那就需要提取文本信息。SQL模板在我们分析过程中已经计算获得。如下所示的SQL1和SQL2计算后分别可以得到模板1和模板2。那我们对模板1进行限流,可以获得的最全特征为
select id, name, age from students where name
。使用该特征进行限流优点是不管通过哪种连接方式发送的SQL,只要满足该特征都受限流并发度控制;缺点是存在误限的可能性,比如模板2包含模板1中的所有特征。/* SQL文本1 */ select id,name,age from students where name='张三'; /* SQL模板1 */ select id,name,age from students where name = ?; /* SQL文本2 */ select id,name,age from students where name='张三' and sid='唯一ID'; /* SQL模板2 */ select id,name,age from students where name=? and sid=?
- SQL模板限流
- 自动优化
当根因分析发现存在可优化的异常SQL时,除了发起限流应急处理外,还会将异常SQL发送到自动优化模块,自动创建索引进行优化。
- 跟踪和回滚
自动限流后,DAS会持续跟踪,如果发现限流后,数据库的负载并未降低或降低的流量同预估出现偏差,则会自动回滚限流操作,并再次启动根因定位。