https://dbaplus.cn/news-134-2970-1.htmlhtml
本文根据高新刚老师在〖2019 DAMS中国数据智能管理峰会〗现场演讲内容整理而成。redis
（点击文末连接可获取完整PPT）数据库
讲师介绍缓存
高新刚，京东数科数据库团队负责人，负责京东数科数据库平台的管理维护工做，带领团队平稳护航屡次61八、1111的大促活动。对数据库多业务场景架构设计、高并发解决方案、数据生态管控有着丰富的实践经验；对数据库库中间件、分布式数据库和自动化智能化管理平台设计开发有着深刻的实践和探索；长期专一于数据库降本增效和技术产品化输出。安全
经过这篇文章你们能够了解到京东数科数据库团队在面对大规模集群、海量数据和高并发场景下的运维概况，包括团队主要的运维目标、运维体系和运维相关的自动化智能化的产品，以及介绍完整的京东数科618大促备战的过程，解密京东数科在大流量的数据库应用场景下的应对策略。性能优化
分享概要服务器
一、运维概述网络
二、备战准备数据结构
三、618进行时架构
四、案例复盘
本次分享将围绕数据库运维，从四个部分进行：第一部分先介绍数据库团队运维的概况，接下来经过大促备战准备、618进行时、以及案例复盘这三部分分享，来介绍咱们数据库团队完整的备战过程。
1、运维概述
一、运维团队
先介绍一下咱们团队，下图为咱们团队全部成员。
之因此选择这张照片，最关键的是标语——“运责心系天下，维稳守护一辈子”。做为数据库运维人员，责任心是必须具有的属性。
咱们团队三个主要的工做方向：
1）数据库运维
咱们负责京东数科全部业务的数据库运维工做，服务于整个研发团队，保证数据库平稳高效运行。
2）自动化智能化运维产品
这个产品有一个很是好的根基，全部的需求、功能点都来自线上运维需求，来自咱们的痛点。它服务于咱们DBA运维人员，致力于提升咱们团队总体的运维效率，完善数据库周边的生态服务。
3）科技输出
把咱们在公司内部生产的优质的数据库架构、分布式数据库解决方案，以及作得比较成熟的数据库产品输出给外部的公司，帮助客户快速创建一套完整的数据库架构体系。
二、运维目标
下图的七个关键词是咱们平常运维最基本的目标，若是咱们在如下这七个方面作得很是好，那么咱们就能实现保障数据库平稳高效的目的。
1）海量数据
首先，海量数据运维。这是DBA必需要面对的话题。那么咱们如何保证海量数据库平稳高效运行呢？我认为运维规范是最重要的，按照规范作好架构规划、作好冷热数据分离，作好变动规范等等。只有这样咱们才能驾驭海量数据的运维工做。
2）架构转型
第二，架构转型。如今不少公司的业务都面临的架构转型这个难题，无论是业务发展战略的须要仍是数据库出现了性能瓶颈的问题，不少人都在作去oracle，在作分布式数据库或者利用中间件进行水平拆分的相关工做。对于DBA来讲，须要在这个过程当中作好如下服务：一是异构数据库的迁移，二是数据库之间实时同步，三是在保证架构合理的前提下严格控制成本以及保证数据安全。
3）服务可用率
第三，服务可用率。关于这一点，我以为“精细”是很是关键的。如何理解“精细”二字呢？如今不少公司都开始作本身的容灾系统，MySQL的高可用切换大都基于MHA进行二次改造开发，还有不少人用raft多副本写来一致性协议去保证数据一致性。总的来讲，在切换效率上和数据一致性保障上都有所提高。
可是在我看来，切换以前的故障探测、故障场景的分析以及切换决策的逻辑，这些方面要远远比切换自己重要。咱们要对故障的根因进行充分的分析，要很是清晰地涵盖全部极端场景，这样整个容灾系统才能保证排除掉全部异常状况，因此作好数据库故障场景精细化管理很是重要。
4）持续
第四，性能保障。这一点无需赘述，做为一个运营人员，咱们要持续保障数据库性能。关于这一点，我想说一个很重要的现象，在咱们团队中不少人不肯意去作性能保障的工做，他们更愿意作前瞻性的技术研究，作自动化、智能化的设计开发，以及科技输出的相关工做。
在咱们团队有一段时间我发现咱们的DBA把更多的精力投入到数据库的拆分迁移、投入到自动换运维产品的开发设计，投入到对外输出的项目当中去，忽略DB性能的管理优化，他们认为性能优化不容易出成绩，因此他们更愿意作新技术的研究，去开发数据库相关的产品组件，去作科技输出。其实这就偏离了DB运维的本职工做。性能优化要持续作下去，即使咱们如今有不少自动化的优化手段，也要坚持作好性能优化保障，由于咱们的运维产品尚未到达彻底人工智能的那个阶段。因此这项工做咱们要持续下去。
5）保障
第五，数据安全。数据安全对于咱们而言就是“数据不丢失、不泄露”，具体内容为储存数据快速同步、分布式事务的一致性、在关键的敏感字段上进行数据加密、数据库备份和容灾。只有作到这些才能保证数据的安全。数据安全是安身立命之本，它就是那个1，若是没有那个1，后面再多0都是无效的。
6）高效
第六，水平拆分。如今不少公司都在作中间件的开发，实现数据库的水平拆分、实现相似业务透明、分库分表等等，但如何去衡量中间件产品的好与坏呢？在我看来就是高效，不少公司作了相似的工做，尤为是中间件支持分布式的事务，可是又有几家公司敢在本身核心业务上用这个东西呢，这里就涉及到效率的问题。好的产品组件都作到了服务高效、对业务透明、研发改形成本低、有很好的数据流控管理、自动的弹性扩容还有高效的分布式事务服务，这些都是分布式数据库追求的目标。
7）价值
最后，数据服务。在完成前面六项基本运维目标之后，如何保证数据在各个系统、各个层面之间的流转？如何保证数据同步？如何结合大数据平台进行分析、计算，帮助业务人员挖掘数据的价值？须要作好数据生态管控，经过复制平台，ETL管控平台作好增值的数据服务。
以上这些就是咱们运维的基本目标。
三、运维体系
接下来介绍一下咱们的运维体系，把刚才基本的运维目标再提高一下。
咱们的核心目标是保证数据一致性、保证容灾可用性，还要符合安全合规的管控。基于这些方面，再经过运维自动化提高运维效率，保证数据治理，维护数据生态。
那么如何去实现核心目标呢？这就须要咱们按照各个业务层面的业务需求，去作相关运维自动化产品的工做，而这些产品其实都是由人为手动阶段逐渐演变出来的产品。
1）应用层
首先在应用层，业务的需求有什么？
① 数据库建模
这个工做是很是重要的，如今好多人都在说大数据、数据标准、数据治理。其实自动化的数据建模才是数据标准管控的源头，只要把数据建模作好，后面大数据的事情就很是容易了。基于咱们的需求，数据建模实现了这么一个平台DBCM。
② SQL自助查询
如今不少研发在开发调试过程当中须要查询数据库，还有一些业务人员须要查询导出一些业务数据。在整个查询过程当中须要管控，一些核心数据也要进行加密，过后还有一些查询审计的工做，最终这些需求造成了咱们查询机的产品，它可以帮助咱们进行线上运维，并帮助运营人员实现数据的快速查询。
③ SQL自助变动
之前咱们作数据运维的时候，大多数数据变动都是手动操做的，这种方式不但误操做风险大，并且DBA的工做效率极低。因此咱们作了一个工单系统MagicFlow。
这个工单系统包含三个功能：
第一，SQL审核。研发提上来的SQL是否合理？是否规范？是否有风险？经过SQL审核基本上就可以把它过滤掉。
第二，审批流。这一点很重要，研发作什么操做都要通过上级的审批，包括数据库作什么操做也须要经理或者总监作一层审批，尤为在一些大型银行或者企事业单位，这种审批仍是很是重要的。
第三，自动执行。下降DBA手动执行的风险点。自动执行模块还能根据数据库性能进行调度调整。在性能压力比较大的时候，工单是会延后执行的。
2）中间层
中间层就是数据库中间件，刚才说了数据库中间件只要作到了高效的服务就OK了。一般包含水平拆分、读写分离、弹性缩扩容、分布式事务。咱们ShardingSphere目前是Apache明星项目，具备业内影响力的开源数据分片中间件，创建了为上百家企业提供数据库解决方案的生态圈。
3）数据库层
接下来在数据库层，DBA平常的操做如今已经都概括到数据库的自动化运营平台里了，平常的部署、高可用切换、备用等操做基本上都已经涵盖在自动化平台里。
还有数据库性能，之前数据库对于研发人员就是一个黑盒，若是研发想了解数据库的性能就要找DBA去咨询；如今咱们经过数据库性能展现平台CleverDB，把全部数据库维度的信息都展示在平台上面，实现了数据库性能自助管理。在数据库出现故障的时候，咱们也会进行分析，而后快速定位这个问题。
4）大数据层
最后在大数据层面，DBA作的是数据抽取和复制订阅，这一部分有两个工具：一个是数据复制平台DBRep，它能够作到实时数据的复制和解析；再一个是大数据计算与分析平台，它可以计算海量的逻辑运算。
2、备战准备
接下来说一下618备战的具体状况，经过下图你们可以了解到，在备战这个阶段作的事情最多。咱们要作备战巡检、容量的评估、优化改造、数据归档、压力测试、切换演练和变动管控，若是把这些点作到了，618时工做人员是特别轻松的，只须要作监控和应急处理。最后，每次618或者双十一后，咱们还会对备战准备和当天出现的问题进行事件的管理，并结合案例进行总结。
一、备战巡检
① 自增主键
说到备战，首先要作的就是数据库深度巡检，首先是自增主键的问题，你们都知道自增主键为int类型时有一个上限值，有符号的时候是21亿，无符号的时候是42亿。当表中的自增主键到达这个上限时，会从1开始插入，结果表中已经有id=1的记录了，这个时候就会报主键冲突。
在这个点上咱们曾经出现过两次比较严重的问题。第一个单表记录大概是7亿左右，当时研发同事要处理一部分数据，经过清洗后再写入这个表，为了避免影响线上的正常写入，研发同事就提了一个工单，将自增主键改为了20亿，从7亿到20亿中间有足够的空间进行数据导入。结果过了一个多月，故障发生了，自增主键写满了，代码日志显示主键冲突，排查了好长时间以后DBA才意识到是这个21亿的问题，这是一个很是惨重的例子。
第二个故障是咱们有一个数据库作了水平拆分，大概是10个库，每一个库1000张表，并且这个表用了全局自增id，当时的状况就是每一个表的记录条数远远小于21亿，但全局自增id的那张表已经到达21亿的上限，也就是全部分表的总记录条数到达了21亿。这个时候后续的数据就没法写进来了。固然解决办法也很简单，就是把全局自增id表删掉，而后快速建一个bigint表，让它从21亿以后继续自增，这样就解决了，但仍是影响了一段时间写入和操做。
② 磁盘空间
第二个是磁盘空间的检查，磁盘空间的检查包含系统层面和数据库层面的检查。DB相关的就是binlog、errorlog、slowlog generallog 还有数据文件，重点关注磁盘使用率、数据增加率、剩余空间预计使用时长。这里面强调两点：第一点，咱们作了不少智能化的组件，在服务器常常会装各类client，产生一些日志，日志有时候很是大，若是运维人员不关注的话有可能会冲爆磁盘。第二点是在数据库，重点说的是general_log，有些DBA为了分析问题会把这个日志打开，结果打开以后问题分析完忘关了，隔了很长时间这个日志也会把整个数据库填满的。
③ 表分区
表分区这块，网络公司也是有作这种架构的，按照月、季度或者半年建立分区。618活动从6月1日到6月19日，因此6月份时间点很是关键，咱们要检查一下分表或者分区都有6月份以后的表，要确保分区已经建立完毕。除此以外，按月水平拆分的分表也须要注意一样的问题。
④ 链接数
在链接数方面，咱们也遇到不少问题。四年前，我在团队定过一个目标——无论什么样的活动，什么样大促的节日，咱们都不能出现链接数的故障，只要不出现咱们团队就去团建。结果四年过去了，这个目标尚未实现，你们就知道链接数的故障真的是层出不穷的。不过，虽然咱们出现了不少问题，但并不表明咱们没有应对方案。
首先在活跃链接数这部分基本上是从慢查询、事务逻辑和访问逻辑三个方面去优化。
第一，绝大部分活跃链接数高都是由于慢查询，通常状况下咱们DBA经过添加索引或者研发改写SQL均可以解决；
第二，大事务、长事务引起的锁等待，一个事务包含不少逻辑步骤，有些逻辑可能会产生排它锁，所以而引发的和这个锁相关表得查询都被堵塞了。在高并发的场景下就显得格外突出。这种状况咱们通常都会要求研发精简或者拆分事务逻辑。把大事务变成小事务；
第三，业务调用频繁，并发访问控制，写入量和查询量很是大，这个可能要从业务逻辑上去梳理，写的时候经过MQ去控制，读访问看看可否在前面添加redis缓存。好比说一秒执行1000个相同的SQL，一样，应用服务器由多台应用部署，打到数据库上的话，数据库很容易就满了，在这块若是写的操做就要加一些MQ。若是是只读操做就要经过缓冲或者优化调用逻辑。
其次最大链接数问题，研发在大促过程中常常进行应用扩容，好比说扩容100台应用server，可以保证应用层面不出现任何压力问题。但你们想一下，若是扩容了200台服务器,每一个应用的链接数是10，若是打到数据库链接是多少？以前这部分咱们是没有进行有效监控的，后来咱们把应用和数据库的元数据打通，就能知道任何一个应用服务器的台数是多少，链接的配置是多少，经过台数和链接数相乘，与最大数进行比较，这样可以在大促以前预判配置是否是合理的。
⑤ 慢查询
刚才也说到慢查询，这是一个持续优化过程，经过扫描的行数、返回的行数以及执行时间这些方面去分析。咱们如今有一个自动化的运维平台，里面有慢查询的分析，因此这部分不只有DBA在优化，每个研发也会关注本身的数据库系统。
⑥ Top SQL和热点表
对Top SQL要有一个很清晰的了解，尤为是核心的数据库。高频的SQL经过审计获取相关的信息，对高频的SQL能够得到热点的信息，哪些表被频繁访问，哪些表数据量比较大，哪些表作了水平拆分以后分布不均匀，这些均可以经过表维度获取。
⑦ 备份
接下来是备份，在大促当天或者前一天，全部的数据库都是不备份的。为了不从库的IO争用，缘由很简单，把IO让给大促的业务压力，怎么去处理这个事情呢？咱们要保证大促前几天全部的备份都是有效的，一旦出现问题时，咱们能够经过前几天的备份和日志去进行快速的恢复。
⑧ 定时调度
不只包含数据库运维层面的调度任务，还还包含业务层面的跑批任务。目的就是为了减小没必要要的IO。例如数据库备份、业务跑批、ETL抽取、信息采集。这些都不能在大促零点这一刻发生，因此咱们会把这些任务日后延，通常都是两个小时之后。咱们要确保调度任务错开大促高峰时间，因此每一个做业的开始和结束时间都须要咱们梳理。
定时调度，这里不只包含数据库运维层面的调度任务，好比信息采集 备份调度，更主要的是DBA要掌握业务跑批得时间和时长 、大数据抽取的时间和时长。咱们要确保调度任务错开大促高峰时间。因此每一个做业的开始和结束时间都是须要咱们梳理的。
⑨ 容量评估
容量评估与磁盘空间的巡检不太同样，它包含硬件的使用容量和性能使用容量，容量评估的目的是为了评估数据库的架构、性能与资源是否匹配，以此推进硬件和架构的优化工做。后面会重点就讲这块。
⑩ 硬件&机房
硬件和机房的检查其实不是咱们DBA来进行，可是像磁盘出现故障的地方必定要在大促的时候检查出来。这个每一年都作，并且硬件的厂商也会在关键的时期排售后工程师协助咱们完成这些巡检工做。
⑪ 业务梳理
业务梳理也是很是重要的，好比核心业务对数据库的依赖程度，业务对数据的依赖程度是强依赖仍是弱依赖，在咱们公司内部要求弱依赖，数据库挂了,核心业务不能挂，不能影响到终端用户。在这方面作了不少架构上的弥补，好比说加了MQ，加了Redis。
事务逻辑的读写，尤为是核心业务，在核心业务支付主链路上，任何操做的事务咱们都会去分析，保证每一个事务的效果。若是数据库宕机，业务有没有熔断的保护措施来避免终端用户受影响？业务方之间有不少接口调用的逻辑，哪些接口能够作降级保护，哪些接口有严格的超时限制，在核心业务这个范畴里，这些都须要DBA去了解清楚。
接下来是上下游的调用，经过上下游接口调用的分析，咱们要保证每个接口效率都是高效的，若是说出现了接口上的故障，整个业务要有自动熔断的能力。
下图是咱们巡检的通道，如今咱们的数据库规模已通过万，现有DBA是彻底不可能作到人工逐个巡检的，因此咱们也是经过智能化平台把这个平台开放给研发和全部DBA，经过这个平台可以快速定位问题，这样前面全部的问题都能在很短期内被发现。
二、容量评估
今年公司层面硬件服务器是零采购，在数据容量方面面临的压力是很是大的。业务发展须要服务器，可是咱们没有新的机器，那么如何对资源进行合理的管控？如何甄别资源使用不合理的业务架构呢？咱们经过如下几个维度来作。
首先是SQL质量，如何看待一个SQL的好坏呢？经过这三个维度：第一个叫CPU维度，单个CPU维度上面产生的QPS越大，说明SQL的效率越好。好比说消耗1%的CPU，QPS是2000，你就能够知道，当CPU打满的时候QPS最大可以支撑到多少。
接下来还有IO层面，也就是单个IO上面产生的QPS有多大，就说明查询的效率有多快。
经过QPS除以百分比，就能知道最大可以支撑QPS和TPS，经过这个方式作了几个分档，落在哪一个档里就能获得多少分数。经过这种方式目的是督促研发去改造它的SQL，经过这个逻辑会给每个数据库打分。分数若是合理，研发就能够继续去用；若是不合理，就会被扣分。这个分数和绩效是息息相关的，因此每一个研发都很是注意SQL的质量。
第二个是磁盘使用率，好比说磁盘空间关注的是否是接近100%？容量这部分咱们关注的是磁盘使用率是否合理，好比说超过了80%，这时候应该作什么呢？应该去作归档。若是这个数据库长期只有300G，但磁盘是7T的硬盘，咱们认为严重浪费了资源，这个DB资源须要缩容处理。因此在这方面咱们会对两头极端状况进行扣分，督促研发去改进架构。
此外，这里面会结合一些权重，好比说SQL的权重、主从库的权重、业务等级的权重，核心业务和非核心业务的权重比是不同的。
经过上图，你们能够更好地理解容量评估要作什么，也就是说，在红框内咱们认为服务器使用是合理的，在红框以外的大于70%扩容去作归档，小于30%则是资源被严重浪费，咱们要求研发作缩容处理。经过这样的方式咱们实现了今年服务器零采购，这是一个很是了不得的事情，由于京东每一年的硬件采购费用很是高。
咱们常常用这样的逻辑给研发解释为何要作这个工做。首先，一个业务刚成立时，咱们基本上会给到单机多实例的架构。也就是说，在物理机上面选择其中一个数据库实例去用（通常状况下一个物理机建立5-8个数据库实例），随着业务不断地发展，咱们会弹性扩到物理机上面，若是物理机还不能知足它的访问需求，咱们会经过CDS和SS去作水平的拆分。
经过巡检，经过容量评估，咱们基本上可以快速定位数据库服务器资源使用状况，接下来基于这些信息咱们能够在备战的时候清楚要作的事情，例如要优化哪些东西，是否是要作架构的调整等等。
三、优化改造
在自动化性能展现平台里面包含了优化的功能，SQL的优化是作一系列的采集分析，给用户优化建议，用户经过优化建议能够自动去作索引的添加或者SQL改写的工做。
配置优化也是，有些业务的数据库配置须要作一些动态的调整，好比说作一些促销活动时，某些数据库的参数须要微调，这个时候经过配置优化功能就可以快速地实现。
数据优化这部分在整个备战过程当中消耗DBA的精力很是大，由于不管是数据的归档仍是数据结构的变动，效率和时长都是很是长的。
好比说把7T的服务器里面30%的数据挪到另一台机上面去，这个过程不可以一次性操做完成，要一点点去作，并且还要考虑数据库的性能，中间可能会有停顿。咱们的数据库归档平台和数据库变动平台就是能够在数据库高并发过程当中进行有效的管控操做节奏。
架构的优化，r2m是咱们内部Redis集群，Hcenter就是HBase的集群。经过这种途径添加r2m缓存，添加MQ消息队列，把一些OLAP的查询挪到大数据上面去。代码这个层面的优化主要是基于前面巡检分析进行业务逻辑优化，好比说对一些事务要有逻辑的控制。以及关键接口添加降级熔断开关。
下图是扩缩容的逻辑图，在咱们自动化平台实现全部环节步骤。把DBA的运维思想融入到自动化平台里面去。好比说你在作扩容的时候，究竟是提升硬件服务器的配置，仍是说去作垂直拆分，仍是作水平拆分。这些逻辑都有必定的规范，整个扩容和缩容准备会进入到数据迁移的过程，在数据迁移里面会经过数据管道，相似数据复制相关的工具去帮你进行数据的搬迁，同时还会有一些数据一致性校验的工做，最后经过数据库切换实现缩扩容的动做。
四、数据归档
数据归档，有两个比较核心的点：
第一，在归档时对数据库的性能进行监控，若是性能很高或者压力很大时归档须要暂停。
第二，归档对冷热数据有很清晰的划分，这个也是根据SQL审计得来的，平常SQL访问都落在哪一个区域以内，经过分析咱们能知道数据在哪里。经过数据划分以后，咱们就能够指导研发在归档平台去作数据归档的请求。
归档基本上有如下四大类：
第一，备份、删除。这些数据须要保留不少年，这时只须要把数据库作一个备份，把线上的数据删了。
第二，历史表。若是有足够的空间，能够建立一张历史表，把历史数据挪过去，减小业务表的数据体量，这样能够保证正常业务高效的访问业务表。
第三，归档库。根据用户归档的规则，把历史数据挪到另一个归档库里面去。
第四，大数据平台。这个归档平台也能够作ETL抽取工做，能够把这些数据挪到大数据平台里面去。
五、压力测试
压测很简单，就是经过压测演练去寻找应用层面、缓存、数据库自己，以及应用接口是否有异常状况。基于预估的峰值压力，以及大促热点活动进行有针对性的压测。
六、切换演练
切换演练，这是网络公司每月都要进行的，作这个的目的很简单，就是为了提高整个团队的协做能力。由于这里涉及到研发、数据库、应用运维，因此进行一次演练可让不少团队一块儿协做。
最主要是提高团队应急故障的处理能力，还有作高可用系统的检查。由于高可用系统在初始化时有可能域名绑定的是物理IP，这时再去作切换就可能会出现问题，因此有些数据库高可用仍是须要进行检测的。
七、变动管控
在大促以前咱们都会进行封网的操做，尽可能不让研发上线作数据库改动。正常的流程是研发提了一个工单，先经过自动的审核，再通过研发总监或者经理的审核，最后DBA审核，全部审核经过以后会经过自动执行模型到数据库里面来。
在真正大促开始的时候，咱们会在研发Leader和DBA Leader之间会加一个VP的审核，也就是说会让更高层级的领导去管控变动的风险。
研发提工单最怕的是什么？他们惧怕流程不清晰、流程繁琐、审批麻烦，要作的事情在流程上体现不清晰。DBA在审核工单的时候最怕什么？他们担忧研发提交的数据源不许确、SQL语句有错误（尤为是不少语句中的其中一个是错误的）、没有where条件、须要回滚数据的工单。
因此基于这些痛点，咱们开发了工单自助系统，这个系统包含两个部分，一个是流程管控，另一部分是inception自动的审核系统。
其实咱们是不提倡在大促中间去作变动的，咱们当时有一个很是严重的故障，有一个SA作批量的装机，由于有一个应用想扩容，这哥们想扩100台虚机，在扩容的时候使用DHCP动态去分配IP，结果分配IP里面有几个是数据库的VIP。你们想想，这个动做一旦真的执行下去，会产生很严重的问题，因此经过工单流程，咱们仍是能作一些管控的。
3、618进行时
在大促零点峰值到来以前，咱们会作一些操做：第一，关闭数据库半同步，提升数据库的读写性能；第二，关闭全部的数据库信息采集。
咱们要确保在大促峰值压力过程当中，不会出现备份、ETL抽取、数据推送和业务跑批等没必要要的IO压力。总的目标就是保证业务峰值的io容量。固然这样操做一样是有必定风险和代价的。好比核心业务数据的一致性风险、备份恢复时间长、任务跑批延后等。
618当天咱们更多的是经过监控大盘去了解全部系统的运行状态。如图所示，数据是以业务的视角进行展现的，每个框都是数据库集群，业务研发人员经过这样的监控大屏能够看到全部数据库的指标。若是他看不懂能够看水位图，若是整个集群压力到达像右上角红色的部分那样的程度，则说明有问题。
DBA要关注每一台机器的性能，0点时刻咱们把上图称为“大促心跳”，全部的压力会直线上升，经过这个图能够看到哪一个机器是异常的，哪一个没有内心预期的压力大。哪些机器的性能波动不在预期范围以内，这些是咱们以后要复盘、总结的地方。
还有真的出现故障的时候，下图是性能分析的页面。也就是说，从页面层面和问题解决层面，咱们有三种不一样的视角监控数据库的状态。
在应急预案保障方便，咱们在大促以前都作了梳理，硬件层面、性能故障、服务组件故障，无论哪一个层面出现问题，咱们都有相应的应急手册作指导，规范运营人员的应急操做。
大促结束以后咱们又作了事件的管理，把大促备战和618当天发生的事件和故障记录了下来，这个是记录的维度。这个系统最主要的目的是寻求故障解决方案，把故障完全地分析一遍，经过业务的层面、架构、运维的视角，再结合安全和合规的要求，寻求最合理的优化改造方案，并持续跟踪改形成果。
4、案例分析
案例一
给你们分享两个例子，第一个例子，有一个数据库，由于扩容的缘由主库后面挂了15个从库，真正在大促0点那一刻这个数据库读写性能很是慢，后来通过分析，咱们发现就是这15个从库在向主库获取日志的时候对主库压力太大了，因此当时的解决方案是关闭了几个不过重要的从库，把主从复制断开。
这个事情经过复盘咱们仍是找出不少可以改进的点。
第一，在数据库架构里要严格控制从库的数量，超过5个之后，咱们就要用级联复制的方式或者dbrep作复制。
第二，在扩容以后研发要作二次的压测了。若是当时进行压测的话，是可以发现主库性能降低的故障问题的。
第三，自动化分析系统为何当时没有识别这个故障？就是由于对这个复制用户产生的访问压力，咱们自动化性能分析平台把它给忽略了，这一点要在之后自动化云平台上去添加自动识别的异常，若是它的并发进程过多也是有一个异常。
第四，自愈，这个问题解决方法就是要杀掉几个从库。当时咱们DBA仍是很纠结的，15个从库可能对应着不一样的业务接口，关闭哪个从库，当时咱们仍是讨论了很长时间。如何实现自愈呢？咱们把全部的业务，全部接口按照一个业务等级去作一个排序，把等级低的直接关闭，这就不须要跟研发沟通了。
第五，资源扩容的时候要有一个数量的提醒。
第六，应用接口增长容错机制。当时咱们关了几个从库，关闭以后应用接口就疯狂地报错，致使后面的一系列应用也出现了问题。虽说没有影响到终端用户，可是咱们认为接口要增长容错的机制，也就是说针对数据库挂掉的时候，应用可以有一个降级的逻辑。
案例二
第二个案例，在619你们都已经开了庆功宴，有的人都喝香槟去了，咱们DBA在619零点十八分作了一个操做，就是打开半同步。刚才讲了，大促以前要关闭半同步，要提高主库性能。咱们认为大促已经结束了该把半同步打开，结果打开一瞬间触发了一个bug，数据库重启了。
但咱们过后分析这个故障，咱们发如今两阶段提交的最后一个阶段，这个过程分为三个步骤，第一个Flush Stage，第二个Sync Stage，第三个Commit Stage。在flush stage环节会把数据写到Binlog缓冲里面去，在Sync Stage里面会把全部Binlog刷盘，第三个是根据顺序的调用存储引擎提交事务，这个就是Binlog写磁盘的操做逻辑。
整个过程当中跟半同步有什么关系呢？后来咱们分析了一下源码，也找了一些资料，发如今第一阶段，半同步在打开的时候，每个事务会往active transaction这hash表里记录提交事务的name、pos和entry标识，缓存这些信息的目的是在发送binlog时判断要不要等从库返回的ACK。这个entry的意义就是告诉从库这个event须要返回ACK，实际上就是供从库去判断要不要返回ACK应答的标识。若是从库在收到binlog的时候发现有entry值，就会返回ACK应答，若是没有它就不返回。
在第二个阶段设置binlog的相对位置，就是设置一个等待ACK返回的binlog值和pos点。若是从库返回的ACK里面包含的内容和pos点比等待的值要大，那说明这个事务就能够提交了，若是小的话就不能提交。恰好咱们DBA就在这个阶段半同步打开了操做。
这个时候你们能够想象一下，在flush阶段有一条数据写入了，写入的时候active transaction这张表里是没有entry标识的。在第二个阶段——Sync Stage阶段，从库由于没有标识，因此就不会返回ACK。可是主库由于识别了sync_master_enabled这个变量，因此它认为这个事务应该等ACK的返回，结果从库没有返回ACK,主库又一直都在等，因此出现了assertion failure的错误。
其实这个错误也很简单，在改写的时候，这个bug只须要同时验证enable和entry这两个值，若是都有的话才会去等待ACK的反馈。咱们查询官网的资料后发现5.6.35，5.7.17，8.0.1之后的版本都解决了这个问题。
经验总结
最后是经验的总结，好的地方不说了，说一下咱们须要改进的地方。
① 容灾演练
咱们常常作的演练都是模拟主从切换，但对于极端的场景咱们是没有测到的。这些极端的场景如何去作演练？这些是咱们从此要注意的地方。
② 性能优化
性能优化这部分要解决的问题也不少，咱们要多从业务视角指导研发去作优化任务，在优化过程当中还须要改进。
③ 数据治理
数据治理就是数据冷热的分离，这样可以对数据库进行保护和容灾。但冷热数据的界定还须要更加的灵活和准确。
④ 资源管控
资源管控能够帮咱们作架构和资源合理性评估，可能之后互联网公司会更加注重硬件资源的使用率，服务器采购会愈来愈少，如何在有限资源里把架构设计得更加优化，这些方面须要考虑。
⑤ 业务优化
咱们的DBA仍是要多深刻到业务层面，帮助研发减小业务逻辑在数据库层面的交互次数，简化事务逻辑。同时提出降级熔断的方案。帮助研发打造健壮的业务系统体系。
PPT连接：https://pan.baidu.com/s/1DdHBbQq-uLFyyUuqxmP4qw
> > > >
活动推荐
2020 Gdevops全球敏捷运维峰会将在北京开启年度首站！重点围绕数据库、智慧运维、Fintech金融科技领域，携手阿里、腾讯、蚂蚁金服、中国银行、平安银行、中邮消费金融、建设银行、农业银行、民生银行、中国联通大数据、浙江移动、新炬网络等技术表明，展望云时代下数据库发展趋势、破解运维转型困局。