让数据库学会减负九阳神功

— 数据库减负之前言 —

在电商、传统数据量TPS QPS比较大的业务的场景中，DB做为所有链路的核心最低层最重要的一环，他的重要性不言而喻 ！但DB也是脆弱的，因为他不是无状态的服务（一、不能同时创建多个数据服务进入写入（MGR目前来看问题依然存在很多) 二、故障恢复的时候强烈依赖之前）压力剧增情况下 如何对他减压是一个非常值得探讨的问题，随着最近几年的发展，JAVA框架 分布式等框架崛起 云厂商更友好的支持，本文就本文以一线DBA角度出发 对关系型数据库减压进行讨探。

— 第一式 —

缓存

为业务增加缓存、提高不必要数据库请求

我们可以将数据直接从数据库取出 放入缓存中。格式list key、也可以使用缓存框架如 Redis Mem等，将一些需要频繁使用的热点数据保存在缓存中，每当用户来访问的时候，就可以直接将内存缓存中的数据返回给用户，这样可以避免繁杂物理IO消耗 有效降低服务器的压力。

— 第二式 —

CDN动静加速

优先链路质量（不光光DB层面 业务也降降负载情况）

首先先聊CDN好处

1. 网站加速，利于搜索引擎排名
2. 有利于提高网站的转化率
3. 提升网站的稳定性和安全性

说了这么多cdn好处 那他对db有什么好处呢？

举个场景:电商场景TOP热销排行榜，如果每个用户请求热销排行榜，那么在没有缓存的情况下，DB出这个热销榜，他就会做一个非常复杂的操作流程。

首先把订单表进行统计 然后汇总 接着在排序，有些时候可能还有分库分表，只要数据级别足够多，没有这个缓存，数据库分分钟钟给你挂！

— 第三式 —

数据库执行计划优化

让数据库做正确的事情

关系型数据库有一个执行优化选择器，通过这个选择优化计算SQL耗时。一个高效SQL跟一个低效SQL 最大的区别是秒级能出的结果，一个几分钟还没有把结果返回给你。

1. 低效的SQL大概率
2. 没有落到主键索引上
3. 增加不必要的回表
4. 查询过多不需要资源

— 第四式 —

冷热数据分离

查询范围只查自己需要数据

电商或者的金融场景下，往往只需要查询最近1-3月订单，这个时候可以把3个月以为的数据以归档或者把历史数据数据转移的方式，让DB减少查询的范围。

用户系统中 剥离热点用户，如果业务比较复杂情况下，把用户纬度以冷热形式进行表的拆分（该方法只讨论DB层面，应用层面肯定还有好的方法来解决该问题）

— 第五式 —

合并数据操作

让数据库减少在网络和磁盘消耗

并行操作和好过串行操作，如果条件允许的话，把多次请求合并成一次，当然查询量比较大的情况下 不适用

— 第六式 —

读写分离

让从库也一起工作

让数据库读写压力分开，在oracle ADG/(oracle rac 增加只操作的资源) 和 mysql 主从的情况下，就是大大优化 让所有数据库架构点都工作起来，在电商业务场景读写1:4情况下，横向扩展从库，大大提升了资源率和 主Master压力。不成文的扩展价格对比，横向扩机器1台，费用增加1倍；纵向扩容主机，费用增加4倍，达到效果是一样的。

另早期阿里去oracle也有这个考量点。不仅仅是版权：主要早期oracle 10g 备份库没有查询的功能。一方面主库压力也比较大，另一方面造成资源和成本的大大浪费。MYSQL很好了解决了这个问题。

引用云厂商第三方产品： 腾讯云opensearsh,AWS EMR都快速把读的压力分担到第三SAAS产品层

— 第七式 —

分布式中间件

降低业务耦合性

通过消息消费(rocketmq)的方式让数据库降低顺时的写入流量.另外让DB在故障及快速升缩的情况下，对业务不产生影响

此局肯定大大提升了代码的复杂度及加大了对应用和程序员的要求

— 第八式 —

数据库监控报警

了解掌握数据库预期。

对数据库情况更加洞期是对一个DBA的负责最低的要求。很多时候，很多不把这件事情前半段看的很重要，只在出报警的时候对DB进行解决。数据库健康度一定要从3个纬度出发。

1. 事前：整体最大量及瓶颈点
2. 事中：扩容及应变方案
3. 事后：复盘及规避该问题

另外压力级别 还有重要点指标：压测之后，优先扩容这个是对检验业务和实际需求点，合理扩容也是对DB减少负载的操作，DB不能工作对业务伤害力不言知明，事前预知扩容好过事后扩容

— 第九式 —

业务改造

往往忽视最关键的一点。

业务真的需要你实时的更新吗?如果减少一些时效性，让DB支持并发量。产品侧和业务侧是否会妥协，也是一个需要争取的表现点。

工作真实场景：

一个用户购买商品之后会给他的上级更加佣金，如果他上级足够多，你的更新链路就非常长（我们不考虑这个业务是否合规，但是业务产品需求就是这样的），后期跟产品沟通之后 只立马更新用户的上级。

链路上：上级的上级的..xxx.上级的人，每个人更新按一定的周期进行更新，业务的TPS好像立马从3000 变成了12000 真实案例：tps数据可能有些问题，但是真真切切 达到了DB这一侧的预期及目标。有些时候产品和研发可能只按照自己的需求点出发，忽视了DB本质，这个时候提出需求让大家一起改造 何乐而不为，自己做为DBA也产生了真真切切的价值。

从一线DBA角度出发 跟大家探讨几个重要关键方法及思路 希望能帮助大家 当然也欢迎大家补充，天下武功 唯快不破 ，希望做为DBA你乘风破浪！！！