— 数据库减负之前言 —
在电商、传统数据量TPS QPS比较大的业务的场景中，DB做为所有链路的核心最低层最重要的一环，他的重要性不言而喻 ！但DB也是脆弱的，因为他不是无状态的服务（一、不能同时创建多个数据服务进入写入（MGR目前来看问题依然存在很多) 二、故障恢复的时候强烈依赖之前）压力剧增情况下 如何对他减压是一个非常值得探讨的问题，随着最近几年的发展，JAVA框架 分布式等框架崛起 云厂商更友好的支持，本文就本文以一线DBA角度出发 对关系型数据库减压进行讨探。
— 第一式 —
缓存
为业务增加缓存、提高不必要数据库请求
我们可以将数据直接从数据库取出 放入缓存中。格式list key、也可以使用缓存框架如 Redis Mem等，将一些需要频繁使用的热点数据保存在缓存中，每当用户来访问的时候，就可以直接将内存缓存中的数据返回给用户，这样可以避免繁杂物理IO消耗 有效降低服务器的压力。
— 第二式 —
CDN动静加速
优先链路质量（不光光DB层面 业务也降降负载情况）
首先先聊CDN好处
- 网站加速，利于搜索引擎排名
- 有利于提高网站的转化率
- 提升网站的稳定性和安全性
说了这么多cdn好处 那他对db有什么好处呢？
举个场景:电商场景TOP热销排行榜，如果每个用户请求热销排行榜，那么在没有缓存的情况下，DB出这个热销榜，他就会做一个非常复杂的操作流程。
首先把订单表进行统计 然后汇总 接着在排序，有些时候可能还有分库分表，只要数据级别足够多，没有这个缓存，数据库分分钟钟给你挂！
— 第三式 —
数据库执行计划优化
让数据库做正确的事情
关系型数据库有一个执行优化选择器，通过这个选择优化计算SQL耗时。一个高效SQL跟一个低效SQL 最大的区别是秒级能出的结果，一个几分钟还没有把结果返回给你。
- 低效的SQL大概率
- 没有落到主键索引上
- 增加不必要的回表
- 查询过多不需要资源
— 第四式 —
冷热数据分离
查询范围只查自己需要数据
电商或者的金融场景下，往往只需要查询最近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个纬度出发。
- 事前：整体最大量及瓶颈点
- 事中：扩容及应变方案
- 事后：复盘及规避该问题
另外压力级别 还有重要点指标：压测之后，优先扩容这个是对检验业务和实际需求点，合理扩容也是对DB减少负载的操作，DB不能工作对业务伤害力不言知明，事前预知扩容好过事后扩容
— 第九式 —
业务改造
往往忽视最关键的一点。
业务真的需要你实时的更新吗?如果减少一些时效性，让DB支持并发量。产品侧和业务侧是否会妥协，也是一个需要争取的表现点。
工作真实场景：
一个用户购买商品之后会给他的上级更加佣金，如果他上级足够多，你的更新链路就非常长（我们不考虑这个业务是否合规，但是业务产品需求就是这样的），后期跟产品沟通之后 只立马更新用户的上级。
链路上：上级的上级的..xxx.上级的人，每个人更新按一定的周期进行更新，业务的TPS好像立马从3000 变成了12000 真实案例：tps数据可能有些问题，但是真真切切 达到了DB这一侧的预期及目标。有些时候产品和研发可能只按照自己的需求点出发，忽视了DB本质，这个时候提出需求让大家一起改造 何乐而不为，自己做为DBA也产生了真真切切的价值。
从一线DBA角度出发 跟大家探讨几个重要关键方法及思路 希望能帮助大家 当然也欢迎大家补充，天下武功 唯快不破 ，希望做为DBA你乘风破浪！！！
