在遭遇异常流量高峰时，如何处理？
在实际运维场景中，客户因为业务变更或者业务高峰期会带来流量高峰，导致系统指标异常，实例CPU飙升近100%，会话SQL处理变慢，活跃连接数增加，数据库响应异常甚至不可用。可能的原因有以下两个方面：
- SQL问题：SQL执行效率慢，如对无主键、无索引的表进行查询操作时，CPU和 IO被打满。
- 流量问题：突发的流量急剧上升，数据库容量达到瓶颈，影响正常业务。
解决方案：
针对上述问题，一般会采用两种方式来处理：
方式一：先分析异常SQL，定位后手动Kill会话
方式二：简单粗暴，重启数据库。
但面对复杂问题，传统解决方案往往无法从根本上解决，定位解决问题花费时间长，导致业务受损。针对这一挑战，业界采用限流的方式来处理，不区分业务，即不会区分限流SQL所在的库或者客户端用户，这可能导致无差别的kill会话，核心业务受损。
我们今天介绍的自治限流功能是如何应对这一潜在风险呢？
自治限流，指的是通过预先设置限流策略，自动限定执行SQL的并发度，通过小部分业务受损，保障核心业务的正常运行。具体来说，可以通过以下三个策略来进行流控：
分库、分用户设置限流范围
自治限流功能支持分库、分用户两种方式设置，客户根据业务情况，识别核心业务库和客户端用户，按需选择相应的限流方式。
- 按库设置：根据业务重要程度，选择对特定的一个或者多个库进行限流，默认不区分库名。
- 按用户名设置：根据不同用户业务差异，选择对特定的一个或者多个用户进行限流，默认不区分用户。
设置限流时间：
通过设置限流时间窗（即自治限流功能只在该时间段生效）和每次最大限流时长（即自治限流生效后持续时长），方便定位SQL异常，请注意：同一天只在该时间窗内生效一次。
设置限流策略
条件1：根据业务情况，设置CPU利用率大于多少 【且/或】 活跃会话数大于多少，且上述条件持续时间大于多少分钟，会触发限流。
条件2：设置允许的最大活跃并发数，当前活跃会话数大于最大活跃会话数时，会将会话数清理到小于最大活跃会话数。
设置界面如下：
完成上述设置后，自治限流功能可以自动检测客户实例异常，触发限流策略后，根据配置的限流范围和时间，自动进行分库分用户限流处理，在保证核心业务SQL稳定运行的前提下，限制引发CPU飙升的新上业务SQL，带来活跃会话数逐渐降低，CPU下降到正常值，QPS恢复到业务正常水平，数据库实例恢复正常。
