高新刚，京东数科数据库团队负责人，负责京东数科数据库平台的管理维护工作，带领团队平稳护航多次6·18、11·11的大促活动；对数据库多业务场景架构设计，高并发解决方案，数据生态管控有着丰富的实践经验；对数据库库中间件、分布式事务数据库和自动化智能化运维平台设计开发有着深入的实践和探索；长期专注于数据库产品化输出和国产数据库的探索研究。

当我们遇到海量这个词的时候，大家第一时间会想到和数据库相关的哪些内容？比如海量的数据量、大规模的数据库的节点数、高并发的业务访问。海量的数据带来的是存储和弹性扩展的问题，大规模的数据库节点给我们带来的是批量运维的困扰，高并发访问带来的是性能的问题。

所以我认为，解决大部分的海量数据的问题，一般有三种通用的方法：

所以说今天我的议题也是从里面找了几个点，来给大家分享。通过海量运维的概述，给大家介绍一下我们是怎么去做数据生态管控的，以及我们一些数据库管控组件的功能介绍。其次想给大家介绍一下在面临大规模的数据库节点运维的时候，我们如何去搭建高可用的容灾体系，或者说如何去做高可用解决方案的选型。接下来会通过介绍资源的管理和告警信息的管理，告诉大家我们的一些自动化运维的思想是什么。最后就是我们会把海量运维的管理思想在大促备战中进行应用和实践。

首先整体来说这是我们公司的一个数据库运维拓扑图，中间是整个数据库集群，不管是单库还是水平拆分的，应用都是通过智能DNS或者vip访问数据库的，如果是单库就直接连到主从架构，如果是水平拆分就是通过Sharding-Sphere或者CDS数据库中间件产品访问后面的数据节点。

在这里我们可以在中间件这层实现数据加密和脱敏的数据管控目标。如果你要是单库的话，我们这个数据加密和脱敏是放在应用的代码里面，如果你要是用水平拆分的话，分布式中间件天然就支持加密脱敏的方法。

接下来数据写入到数据库之后，左右两侧其实就是数据的一些流转功能。DBRep和DTS主要指的是实现数据流转到AP的查询平台，流转到一些运营后台的其他业务逻辑的查询数据库里面去。左边Archiver是数据归档平台，实现数据冷热分离。还有PillBOX是备份管控的平台，可以把数据库的备份按照一定的规则策略传入到Hadoop，再传到磁带库里，这样整体来说数据库备份的整个生命周期可以得到很好的管控。从online环境传输到nearline环境，最后进入到offline的磁带库中，再结合备份保留策略以及逆向的恢复功能，备份平台可以覆盖数据库备份恢复的所有需求功能。

下面就是DBA运维的一些管控。DBCM就是一个建模平台，所有数据库的建库建表逻辑要通过这个平台来创建，如果不通过这个平台，大家可以想到，在这种大数据后期的一些建设中，你就会发现你的数据的质量会有很严重的问题，不管是元数据还是业务数据都或多或少出现数据质量问题，所以说通过建模平台我们做到了从建模源头开始规范和引导研发的业务模型设计。

其次是查询平台，研发在做开发的时候，包括业务运营人员需要对数据库进行一些数据查询、获取，查询平台里面会包含一些加密、脱敏、查询记录条数和导出的一些管控限制的功能，通过这种方式我们能够很好的做到企业级安全合规的管控和限制。

CleverDB是性能管控平台，我们可以给研发\DBA还有一些其他想关注数据库的人员一个非常友好的可视化平台，对于研发用户来说数据库就是一个黑盒产品，通过这种可视化的管理，可以讲一些专业化的性能指标转换为数字化，以可视化的解决展示给我们的需求方，这样可以驱动他们自主管理各自业务数据库。在大规模运维体系中，研发自驱管理数据库和数据库自助化服务逐渐成为新生的运维力量。

OnLine平台是一个流程管控平台，不管做变更也好，做大规模的架构调整也好，都需要一个企业级的合规流程才能完成这个动作。最后就是自动化运维平台，我们在管理上万台服务器的时候，就是通过这些平台工具提升运维效率的，总之拥有一个完整的数据库生态的工具平台，然后基于这个平台逐渐实现自动化、流程化、智能化，是驾驭海量运维场景必经之路。

资源管理其实就是以前我们在规模非常小的时候用Excel管理数据库资源，但是现在公司的规模越来越大，数据库的节点数越来越多，自动化平台建立起来之后我们会发现有很多维度的元数据需要我们做管控。

首先资源节点自动上报，例如公司采购了一百台机器，这些机器怎么录入到这个系统里面？我们是通过给每台机器装一个agent端，它会自动上报它的IP，还有这些机器所在的网段、机房、机柜等信息是通过跟IT运维系统去进行对接，通过他们提供的API接口把这些信息抓过来，这样你的信息才能健全。

第二点就是服务器使用状态的管理，比如这个服务器到底有什么样的业务在使用，有没有报错，有没有报修，它的维修进度是什么，这些都需要在我们的系统里记录。

我们在以前就出现过类似的问题，比如说我们要给这台机器去做维修了，因为一些元数据的不准确，可能那台服务器上还有一些其他业务运行，导致那个业务就因为关机而中断了服务，所以元数据的准确性也非常重要。

第三，数据库跟业务这种两个视角的同步和串联的问题。也就是说我的数据库只记录了它是什么样的架构，它跟业务的对应关系没有建立起来，是两个业务的数据库，这个数据库又被哪些业务所访问，包括这些业务是哪些研发负责人去负责的，我们需要把这些相关的信息串联起来，最后形成一个血缘关系，或者知识拓扑图，让大家能够很清晰地了解到我们的元数据的信息是什么样的。

第四，元数据的变更，比如你做了主从的切换，服务器的维修，包括一些服务器的名字的变更，所有这样的事情。以及比如说研发负责人、公司组织架构调整、部门信息的调整，对应到数据库的管控里面，元数据都会涉及到一系列的变更。

第五就是资产的管理。作为DBA要能够给到各个业务部门提供数据库服务器使用情况，能够告诉业务部门负责人，这个季度或者这半年服务器资产使用的情况，这种所谓的报表或者视图的信息，也是需要提供的。

最后就是API服务，因为作为一个数据库来说，它只是在IT系统里面其中一个平台，所以它要跟其他的平台去进行信息的交互，通过信息的交互，才能够把所有运维体系的数据串联起来。

然后给大家分享一下我们大促的整个过程，其实这个过程就分为三个部分：

首先是备战部分，备战之前基本上是提前一个月到一个半月的时候开始准备，接下来主要介绍一下在面对多大规模的服务器的时候，我们不可能把所有的数据库节点都one by one管理起来，那我们如何去做运维呢？

在这些点上如果作为DBA能够很好的管控的话，其实整个大促的过程应该还是相对比较轻松的。

下图就是大促过程中比较核心要去关注的几个点，如果你要去支持一个数据库的大促运维，或者说去做一些数据库的巡检，你应该从哪几个方面去看或者去检查你的数据库。

主要有几个点可以让研发去做，通过巡检报告、可视化平台，可以推给研发相应的信息。比如像自增信息、表分区信息、慢查询，其实你可以发给他，由他们自己去做一些相应的调整。

作为DBA来说，最主要一点是要关注最后一条“业务梳理”，帮助研发梳理业务跟数据库之间到底是不是一个强依赖的关系，一个事务到底读写操作会有多少条，上下游逻辑是什么，能不能做熔断处理。一旦业务系统出现问题是否会影响别人的系统，这些需要DBA做检查。

再一个就是硬件和机房的巡检，我们在大促过程中主要出的问题可能硬件比较多，硬件出的问题最多的就是磁盘和Raid卡，经常Raid充放电的一瞬间可能会让数据库卡顿几秒钟甚至半分钟，如果这种情况在大促的时候出现那就是灾难级的。

最后做一个总结，不管你前面做了什么样的准备，这六点是你在大促之前必须要关注的。