vlambda博客
学习文章列表

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

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

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

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

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

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

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

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

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

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

其次我想说的是通过高可用体系的介绍，让大家去了解如何在这种海量的节点运维过程中，如何做这种容灾体系的建设或者去做选型这块的逻辑。

提供优质的容灾服务质量，RTO<10s。它主要的逻辑流程通过秒级监控可以快速感知故障，然后通过的哨兵探测逻辑，可以验证监控结果的准确性，第三步调用核心切换模块，进行切换环境检查、数据一致性校验、主从切换、vip映射关系变更、元数据信息变更、切换消息通知等。最终实现容灾管控自动化，实现故障自愈。

第二点我们要考虑到容灾体系的兼容性和适配性，因为在一个企业里面其实你的数据库的架构并不完全标准的一模一样。比如说业务会分等级，分等级之后主库从库的数量会随着业务等级的不一样会有一些变化，还有有些业务会做跨机房的容灾，还会做多活、多中心的架构。所以高可用容灾体系要具备良好的兼容性和适配性，比如要兼容不同的架构，不同的版本，不同接入方式和不同的资源环境。

当故障发生时，切换之前的故障探测、故障场景的分析以及切换决策的逻辑，这些方面要远远比切换本身重要。所以这个模型能帮助我们辨识极端场景，避免错误切换或者脑裂问题。举个例子，比如有一个人突然间身体发生了状况，首先最重要的是要及时发现他有问题，第二及时送到医院，接下来医生要及时判别他到底是什么样的问题，最后才能做紧急的治疗和抢救措施。所以说这个决策模型其实做的就是发现和诊断的过程。

第四点就是服务自身的可用性保障。也就是说如果真的出现机房级别的宕机时，其实高可用服务也是挂了的，你如何能够在另外一个机房把你的高可用服务拉起来，然后在高可用服务启动之后才能去做机房级的容灾，所以这种能力也是需要大家再去考虑的一个点。

第五点就是平台自动化的管控。通过配置的统一管理，包括切换进度、历史查询的这些功能，可以帮助我们在大规模数据库运维背景下去提高我们容灾的效率，同时丰富的API接口和可视化信息，能够提供一些非常良好的兼容性和适配性。

最后就是丰富的容灾类型。我们一般情况下都会做主库容灾，像MHA是一个主库容灾的能力，其实它不能提供从库的容灾。然后在容灾类型上面，也要考虑手动切换、自动切换，因为我们会做一些切换演练，比如我们做大促准备的时候经常做一些切换演练，主从切换、主备切换、跨机房的批量切换，这种能力都是需要在高可用体系里面去体现出来的。

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

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

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

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

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

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

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

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

告警管理也是运维体系中非常关键的管理维度，在我们机器非常多的情况下，每天会收到很多告警。许多人私底下聊天的时候经常表达今天收到好几千条告警，以此来证明他们公司数据库规模有多庞大。其实我觉得这是不对的，应该告诉大家，我们数据库规模非常大，但是我们每天只收几十条告警。以此来证明我们有非常强大的运维管控能力。

怎么做到的？其实就是通过告警的管理，通过一系列的方法去实现告警数量的降低，有效告警能够很直接，很清晰的暴露出来，而不会被海量的告警信息所淹没。

我们现在很多公司的监控告警体系都停留在第一阶段，就是我们制定各种指标的告警基线，设置告警级别，通过这种方式去给相关的业务负责人，相关的运维人员发告警短信。在这种情况下其实是没有任何过滤信息的，只要你触发了这个基线，你就会收到告警信息。

实际情况是什么样的？给大家举个例子，主从延时这件事，当你做一个大事务的时候，重复延时可能是相当长的时间，有可能是半小时或者一个小时，半个小时之内可能每隔两三分钟就收一条告警，其实对于运维人员来说，他是不在意的，他知道这是一个大事务，他知道这个事务要继续做下去，所以就会有第二个方法，就是汇总分析。

汇总分析是什么？其实说白了就是一个告警的收敛，我们会把一些连续重复的告警进行一个收敛，然后减少接收人员接收到的告警条数。

再一个就是单因多果的分析，比如说这台机器宕机了，你会收到一条宕机的告警，同时你会收到一堆其他的告警，比如连接数访问异常，还有主从中断，你会收到一堆这样的告警，其实最有用的一条告警就是机器宕机。

所以我们要通过单因多果的关联分析，最终找到根因点是什么，这也是一个我们在运维里面根因分析的一种方法，通过这个模型我们可以去把最根本的原因找出来，然后发给相关的运维人员，避免有用的信息被海量的告警信息所淹没这种情况。

第三个就是以点推面，这里有两个场景：一个就是场景就像我刚才说的在主库执行一个大事务，我肯定能够预判到在之后的未来的半个小时之内，所有的从库都会有延时，这个时候运维人员可以干预一下告警决策，告诉他半个小时之内这些从库可以不发延时告警。

再一个比如我们在大促之前会做切换容灾演练，主从切换的时候势必也会发一些告警，这些告警一般都是在夜里做容灾切换演练的，所以如果这个时候去发告警，会影响好多人的休息，比如相关、不相关的业务人员，他都会收到机器切换的告警。所以在计划内的一些切换的时候，其实我们也是可以预判到的，然后提前将这些告警信息进行一个参数的调整，去避免这样的事情。

再一个就是基线的调整。比如像大促的时候，双十一、双十二的时候，高峰之前的时候，我们能预判到整个告警基线，或者告警参数需要进行一个很大的调整。比如说并发数，比如说事务的超时时间，我们可能都要做一个调整，来满足大促峰值的冲击压力，不至于大促来临那一刻，你的手机都有可能接收过多的短信。

经过一系列的调整和模型的建设，最后达到的效果就是减少无用的告警，减少运维人员和研发人员的感官的疲劳，同时他也能够减少告警短信的成本。

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

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

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

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

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

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

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

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