当前，随着电商节日的增多（6.18、双十一、双十二）、平台拉新趋于频繁，大促活动也越来越普遍。作为一个电商平台，每年都会有一次，甚至几次的流量“大考”。数据库作为系统的重要节点，其稳定性和性能格外重要，数据库的全力保障是一个大的挑战。电商大促，这场没有硝烟的战争很多人已有体会，在此不再赘述。现在，我们直接切入主题--数据库如何 积极应对，全力保障 大促活动。这个题目分解为三个部分进行讲解： 第一部分，准备工作；第二部分，大促进行时；第三部分，大促后复盘。
“功夫在诗外”，同样，大促活动下数据库稳定、顺畅的运行，主要工作在大促前的准备上，所以，准备工作是重点。
一.大促前准备工作
1.对大促活动应该尽可能地去了解，去熟悉。包括业务模式、业务流程以及大促可能产生的订单量、预估峰值、预估的波峰时间、是否有爆款商品等。此外，还应对参与本次大促活动的参与方有所了解，特别是IT部的主要参与人员，保证跨部门协同精准、顺畅。
2.梳理大促活动用到的系统链路，对链路上的系统和应用有个较为清晰的了解，制作大促活动全链路的数据库流程图。
3.梳理链路上的数据库资源。梳理完善成一个Excel，包括数据库的名字、数据类型、数据库版本、用途、支持的主要系统、DBkey、物理IP、虚拟IP等、数据库Size、磁盘空间和可用空间、内存、最大连接限制。
4.对链路数据库故障恢复能力检查。主要是完整备份、日志备份 Job的检查，和备份文件可用性检查。
5.检查链路上数据库的可用性检查。主要是确定数据库采用的高可用架构、节点数、从节点配置、可用性监控、状态监控、同步监控等。
6.了解数据库从节点的使用情况，注意平时和预估大促期间主从延迟问题，以及延迟可能造成的影响；有无优化方案；以及大促期间出现较长的延迟时，有无替代方案（例如，是否可以将从节点上的虚拟IP漂移到主节点上）。
7.定制大促期间数据库监控大屏，主要实现通过一个监控界面基本实现对全链路上所有的数据库主要指标的监控。（本公司数据库的监控主要是通过Zabbix实现）
8.进行链路压测。压测过程中应特别留意以下指标：TPS、事务响应时间、成功事务数、各服务器的CPU、内存以及磁盘使用情况等。针对数据库而言，压测可以发现瓶颈点，优化更有针对性。此外，压测还有一个功能就是评估出系统的最大性能。针对最大性能，在前端做一个流量限制，特别是在商品展示、购物车、支付等功能上。流量限制，既保证了用户体验，也防止过去的数据请求将Cache、DB拖累至宕机。
9.通过监控工具(例如：Zabbix)观察每一个数据库服务器资源消耗情况。建议观察最近一周的运行情况，例如CPU、内存的波动情况、峰谷、连接数、是否合理等。
10.通过监控工具、慢查询日志等对消耗资源较多的SQL语句进行梳理，针对性优化。常规的优化手段主要有：新建索引、调整索引、数据归档、有无大字段、表结构更新、数据归档、SQL语句优化等。
11.链路数据延时监控。延时的主要原因可能是请求队列过长或受网络延时影响，此时要特别注意跨机房（跨IDC）的应用请求和数据同步。
12.评估大促期间应用部署变更可能对数据库造成的影响。比如，为应对大促活动的系统请求，SA可能会增加应用的部署。
13.大促期间数据库性能阈值预估。合理的阈值是准确衡量大促情况下数据库健康程度的温度计。
14.梳理可降级的应用。例如，将数据归档的Job暂停、BI抽取数据的Task延后等。
15.应急预案的准备。应急预案应该尽可能详细，做到心里有谱，手中有尺。预案应包括：备用物理资源有哪些，常见需要DBA参与的业务数据更新需求有哪些，用于修复故障可能用到的操作命令，变更及异常处理的审批流程，虚拟IP漂移的操作命令。备用物理资源清单需细化到服务器类型、操作系统、资源规格、预装系统、IP等情况。
16.DBA值班计划编制。
二.大促进行时
1.注意对数据库监控系统及时监控。
2.链路数据延时监控。
3.对主要数据库节点及服务器进行巡检。
4.及时了解大促进展情况，特别是订单量。
5.需求变更应特别谨慎。
6.记录大促过程中出现的主要异常。
三.大促后复盘
1.完善补充大促使用的链路图，完善没有想到的节点。
2.收集汇总大促期间出现的问题点。
3.对大促期间出现的问题逐一复盘，找到解决方案，优化并持续跟踪。
4.大促活动结束后，需要及时恢复降级的服务。
,谢谢配合！！！
,谢谢配合！！！
,谢谢配合！！！