运维知识库汇总

当前，随着电商节日的增多（6.18、双十一、双十二）、平台拉新趋于频繁，大促活动也越来越普遍。作为一个电商平台，每年都会有一次，甚至几次的流量“大考”。数据库作为系统的重要节点，其稳定性和性能格外重要，数据库的全力保障是一个大的挑战。电商大促，这场没有硝烟的战争很多人已有体会，在此不再赘述。现在，我们直接切入主题--数据库如何 积极应对，全力保障 大促活动。这个题目分解为三个部分进行讲解： 第一部分，准备工作；第二部分，大促进行时；第三部分，大促后复盘。

“功夫在诗外”，同样，大促活动下数据库稳定、顺畅的运行，主要工作在大促前的准备上，所以，准备工作是重点。

一.大促前准备工作

1.对大促活动应该尽可能地去了解，去熟悉。包括业务模式、业务流程以及大促可能产生的订单量、预估峰值、预估的波峰时间、是否有爆款商品等。此外，还应对参与本次大促活动的参与方有所了解，特别是IT部的主要参与人员，保证跨部门协同精准、顺畅。

2.梳理大促活动用到的系统链路，对链路上的系统和应用有个较为清晰的了解，制作大促活动全链路的数据库流程图。

3.梳理链路上的数据库资源。梳理完善成一个Excel，包括数据库的名字、数据类型、数据库版本、用途、支持的主要系统、DBkey、物理IP、虚拟IP等、数据库Size、磁盘空间和可用空间、内存、最大连接限制、数据库文件自动增加是否过小（例如，有些是默认的1M）。

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.大促活动结束后，需要及时恢复降级的服务。

 

----------------------------------------------

face to face：

1. 5分钟自我介绍
2. Java应用，CPU过高排查问题，如何定位的
3. lvs，nginx/SLB，Haproxy各应用场景和优缺点
4. kafka对消息一致性的支持？https://blog.csdn.net/csdn___lyy/article/details/85696326
5. DRDS，买家ID做索引进行分表，如何
6. 压力测试相关，pds，脚本，MySQL
7. du，df区别，看到的不一样
8. CPU load1, load5, load15与核数之间的关系
9. 大促如何保障的，见上文
10. Linux系统如何优化的，
11. Linux如何查看僵尸进程（僵尸进程是如何产生的，对系统有什么影响？）

linux下的du和df的区别

du(disk usage)是通过搜索文件来计算每个文件的大小然后累加，du能看到的文件只是一些当前存在的，没有被删除的。他计算的大小就是当前他认为存在的所有文件大小的累加和。

df(disk free)通过文件系统来快速获取空间大小的信息，当我们删除一个文件的时候，这个文件不是马上就在文件系统当中消失了，而是暂时消失了，当所有程序都不用时，才会根据OS的规则释放掉已经删除的文件， df记录的是通过文件系统获取到的文件的大小，他比du强的地方就是能够看到已经删除的文件，而且计算大小的时候，把这一部分的空间也加上了，更精确了。当文件系统也确定删除了该文件后，这时候du与df就一致了。

du和df不一致情况原因：
常见的df和du不一致情况就是文件删除的问题。当一个文件被删除后，在文件系统 目录中已经不可见了，所以du就不会再统计它了。然而如果此时还有运行的进程持有这个已经被删除了的文件的句柄，那么这个文件就不会真正在磁盘中被删除，分区超级块中的信息也就不会更改。这样df仍旧会统计这个被删除了的文件。

实际上即使你/home什么都没有，df命令依然会显示占用了一部分空间的，文件系统的元数据占了部分空间。

df和du统计的数据是不同的：
打个比方，文件是需要放到文件柜里的，就算只有一个文件，也要占用一个文件柜。文件柜占用的空间比文件要大。
df就是统计使用了多少个文件柜。
du则统计实际有多少个文件。
这样下来，df算的就大，du就小。

簡單地說，df命令是根據該卷的inode使用情況進行統計的，而du則是累加所有文件的字節數。一個文件就算只有1字節，也要佔用一個inode。