应用视角出发的数据库流量治理(一)| 学习笔记

简介: 快速学习应用视角出发的数据库流量治理。

开发者学堂课程【应用视角出发的数据库流量治理 :应用视角出发的数据库流量治理(一)】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/1212/detail/18212


应用视角出发的数据库流量治理

 

内容介绍:

一、SQL 洞察

二、给予 SQL 的流控降级与容错

三、连接词治理;

四、数据库灰度

 

分享的主题是从应用的视角出发来治理数据库的流量,为什么要讲这个题目?或者从应用视角出发的一个数据库流量治理跟传统的一个数据库有什么区别呢?或者说为什么要做这样的一个事情?

首先都知道在分布式的一个微服务系统中微服架构中所有的流量都是端到端的,可以说是每个请求都会经过很多层的处理,从入口网关再到一个 web  serve ,再到服务间的调用, 最后再到服务访问的一个缓存或者是访问数据库,从这个角度来看,对于系统来讲,其实数据库是非常重要的一块,因为无论是在稳定性的质地上还是在开发提效这些场景下,数据库相关的流量治理其实都是系统所必需的一个能力,常常会遇到一些这样的场景:比如某个系统对外提供一些查询的接口,由于的一个 SQL 语句可能涉及到多边的一个交映,或者查询的数据量非常大,某些情况下可能会触发慢调用,耗时是非常长的,最终可能会导致应用的一个连接词被打满,从而导致 contact 的一个连接现场设备打满,最后导致整个应用的不可用,应用不可用之后可能就会拖垮上游的应用,从而导致整个系统出现不可用的一个情况;

第二,由于 SQL 可能慢调用时可能查询的时间比较长,同时请求非常大,很可能会导致数据库的抖动,数据库本身出现了 cpu 打满或者卡死的现象,那对于应用来说就相当于毁灭性的打击,同时还有在应用的视角出发还有非常多的场景,比如说应用刚启动时可能由于数据库的连接词还在初始化,那此时如果有大量的请求进入,如果是W应用,可能就会导致达不到一个线程尺码,之前有遇到过类似的现象,在帮助客户排查时,通过 stack 等发现许多的线程在初始化数据库连接的过程中,由于等待可能会导致线程池满,从而会引发大量业务请求报错,在开发提效的场景下,比如灰度能力,如果新版应用更改了数据库、表中的内容,如果试用一个库跟灰度两根线用同一个数据库,那么数据灰度的流量可能会导致线上数据库的一个数据错乱,出现这种情况会导致一个数据出现污染,可能对于业务的同学来说出了这样的问题可能要连夜去手动的盯着线上数据。

当然还有一些非常多的情况,比如说在项目的初期可能对 SQL 的性能没有做好考量,或者说即使做好了考量,但是随着业务的发展用户量级的增加,线上总会遗留一些老的接口的 SQL,他们会逐渐成为应用的一个性能瓶颈,因此需要一个有效的深刻洞察的能力来帮助发现遗留的 SQL,并且及时的进行性能的优化,

以上讲的所有的场景都是从应用的视角出发来分析一个微服务应用在访问数据库时需要具备的哪些能力,然后针对以上这些场景总结了从应用视角出发的数据库治理的能力。首先对慢 SQL,或者说对 SQL 执行情况需要有一个深刻洞察或者说可观测的一个配套,答案是从应用视角出发的,要时时的知道 SQL 的执行对应用哪些接口甚至对整个应用服务造成怎样的影响,同时要迅速发现哪些慢调用的 SQL,对应用的稳定性造成的影响以及需要有具备 SQL 采样的统计能力以及 SQL 的异常诊断,做得好甚至还可以有基于经验括,可以结合来做 SQL 优化的建议。

image.png

 

一、 SQL 洞察

首先要需要具备基本的一个 SQL 深刻洞察能力,来帮助及时的发现一些问题,比如线上的一个 SQL 语句可能处理得非常长,可能会导致线上业务接口出现大量的慢调用,那么就需要有这样的一个 SQL 深刻洞察能力来帮助快速定位有问题的慢 SQL,然后基于这样的手段定位之后,就可以通过一定的治理手段,比如隔离、或者垄断等方式来来将有问题的 SQL 给干掉,或者说垄断掉,来帮助业务来快速的恢复。因此在微服务访问数据库时,实时的 SQL 深刻洞察能力是非常有必要的,它可以帮助快速的定位到一些慢的 SQL 调用,对于大多数后端应用来讲,其实系统的瓶颈主要受限于数据库,当然也有复杂的一些业务,复杂的业务场景的操作离不开数据库的操作,因此数据库的问题其实是整个后端系统,是一个非常重要的工作,数据库的治理也可以认为是微服务治理中必不可少的一个环节,讲完四个洞察,其实在上面就有提到发现了慢 SQL 之后要有一系列的数据库稳定性智力的一个能力,比如 SQL 留空、MYSQL 熔断、慢 SQL 的一个并发隔离,然后按照参数来熔断,比如,同样的一个查询语句,可能部分小用户、部分接口可能查询的一个量是非常小的,但是可能由于某个事物,某个大客户的一个用户 ID,他要查的数据量是非常大的,可能就会有一些慢参数、某些个别的参数导致的 SQL 出现慢调用的情况,那需要对他进行熔断,其实就是 SQL 慢参数的熔断,比如像数据库连接的过程中可能会出现异常,比如某个 SQL 可能调用某些 SQL 的时候会出现一些异常情况,要对这些异常的连接要及时的发现并且做到一个自动剔除的能力来保证整个连接池中连接的稳定性、健康度来保证整个应用访问数据库的稳定性。这是一个稳定性治理的部分。第二模块其实也比较常见,比如说独显流量分离,他当然也可以帮助提高数据库的稳定性以及提升应用的稳定性,当然还有数据的负载均衡,数据库的灰度,比如像刚才提到的全度灰度场景需要考虑数据库,端到端环节全度灰度能力可以说不会造成数据的污染。图上右下部份从应用视角出发来治理数据库流量的完整的解决方案,目前 Mse 提供了这五个能力,首先就是 SQL 洞察,基于提供秒级的一个 SQL 动产能力,具备完善的 SQL 执行的审计能力,可以帮助有效的评估系统的整体表现。

 

二、 给予 SQL 的流控降级与容错

第二块就是基于 SQL 的一个留空间距容错能力,他提供了基于 SQL 洞察,再次和洞察 SQL 一个完整的流量防护能力,发现慢 SQL 或者说某个 SQL 的调用量非常大,进行流量控制对于慢 SQL 可以进行并发隔离甚至对有问题的应用可以进行熔断降级,也可以对于 SQL 的慢参数进行熔断或者进行热点流量的访问参数的限流。

 

三、 连接词治理

第三块就是连接池治理。首先提供一个完整的实时的连接池的指标,以及相关配套的完整的连接治理方案,比如之前有提到的异常,连接自动剔除可以认为是坏连接的一个剔除,同时在应用启动过程中也可以做到提前建联,对有些连接就是连不上,可以对它提前建联,同时也会对一些连接的操作做一些访问控制,可能禁止哪些应用去访问某个数据库的表以及在连接层面做一些访问控制能力黑白名单等访问控制的能力,来保护数据库的安全。


四、 数据库灰度

第四就是数据库灰度的能力。其实可以理解为是一个全链路灰度或者说开发环境隔离的必备的场景,系统服务治理能力的一个特点就是无需任何的代码改造,只要在控制台操作一下就可以具备这样的能力。

相关文章
|
数据采集 存储 运维
聊一聊,如何做好垂直域稳定性(2)
聊一聊,如何做好垂直域稳定性
122 0
|
SQL 关系型数据库 MySQL
应用视角出发的数据库流量治理(二)| 学习笔记
快速学习应用视角出发的数据库流量治理。
131 0
应用视角出发的数据库流量治理(二)| 学习笔记
|
SQL 缓存 运维
全链路灰度在数据库上我们是怎么做的? | 学习笔记
快速学习全链路灰度在数据库上我们是怎么做的?
533 0
全链路灰度在数据库上我们是怎么做的? | 学习笔记
|
存储 Oracle 关系型数据库
数据库技术学习中遇到的重点与难点
记录一下数据库技术学习中遇到的重点与难点
|
弹性计算 负载均衡 网络协议
实验:云上业务(二)|学习笔记
快速学习实验:云上业务(二)
125 0
实验:云上业务(二)|学习笔记
|
数据库
《重新出发:阿里云数据库开源整体策略》电子版地址
重新出发:阿里云数据库开源整体策略.ppt
60 0
《重新出发:阿里云数据库开源整体策略》电子版地址
|
SQL 算法 关系型数据库
【学习资料】第8期PostgreSQL 规格评估 - 微观、宏观、精准 多视角估算数据库性能(选型、做预算不求人)
大家好 ,这里是PostgreSQL 规格评估 - 微观、宏观、精准 多视角估算数据库性能(选型、做预算不求人)
【学习资料】第8期PostgreSQL 规格评估 - 微观、宏观、精准 多视角估算数据库性能(选型、做预算不求人)
|
安全 大数据 数据安全/隐私保护
带你读《数据自治》第二章数据治理2.5小结
《数据自治》第二章数据治理2.5小结
|
存储 SQL Oracle
【学习资料】第7期企业数据库选型规则
大家好,这里是企业数据库选型规则
|
SQL 存储 Oracle
PostgreSQL 递归应用实践 - 非“传销”的高并发实时藤、树状佣金分配体系
标签 PostgreSQL , 佣金分配 , 树状 , 藤状 , 递归查询 , 传销 背景 早在十年前,PostgreSQL 8点几的版本就支持了递归查询,递归查询的应用非常的广泛,如下: 《PostgreSQL 递归妙用案例 - 分组数据去重与打散》 《PostgreSQL Oracle 兼...
1516 0