前阵子和一个做数据库服务的朋友交流，他们承接了某个企业的国产分布式数据库的运维工作，安排了一个该数据库的认证工程师驻场做服务，不过从半年的工作情况来看，效果并不好。作为分布式数据库的运维，平时小问题也不需要DBA介入，分布式数据库的故障自愈能力能够很好的屏蔽这些小问题，并且能够在短时间内完成自愈。如果真的出了大问题，DBA面对数十个节点的分布式数据库环境又束手无策，很难定位问题，这种情况让他们感到很困惑。
实际上这个问题还是挺复杂的，涉及到分布式数据库这种典型的分布式系统与集中式数据库之间在架构与功能上的巨大差异。在传统的数据库运维上，我们习惯于查看一些指标，例如CPU负载，锁超时，活跃会话数、错误率等。对于分布式数据库来说，这些指标实际上并没有相对于集中式数据库环境那么重要，因为分布式数据库从体系架构上具有极高的容错能力。数据库的某个物理节点、某个服务、某个分区、某个副本都可以出故障，此时数据库内部虽然已经存在故障，但是你一点都不需要为此担心，数据库依然能够很好的对外提供服务。这些指标实际上都没有正确的反映出数据库是否能够为客户端流量提供正常的服务，而这些才是用户需要关注的。
在“具有动态纠错能力”并且“可以自动扩展、动态负载均衡”的分布式数据库中，如果单个服务无法实现完整的数据库功能，那么单个服务是否处于“启动”或者“活跃”状态并不重要，因为这些很可能都不会影响分布式数据库对外提供服务，这使得像ping延时、CPU使用率这样的简单检查几乎毫无用处。虽然利用传统的监控理念，判断某个服务是否宕掉并不复杂，但要确定处于活动状态的数据库服务是否健康要困难得多。
也可以通过一些比较简单的方式来判断分布式数据库的服务是否正常。服务很有可能处于“启动”状态，并且并能够对外提供数据库服务，但是它无法在服务的 99分位延迟内完成给定的工作任务(比如完成一条标准SQL的执行)，那么这个数据库就是不健康的。
对于分布式数据库来说，无法在P99延时内执行完某条SQL，但是数据库服务还是能承接相关业务的，这种情况是比较常见的故障场景，也是我们的DBA面对的束手无策的常见场景。这种场景大多数情况下与数据库的某些组件流量过载有关，在高并发服务中，“高并发的重负载”会在分布式数据库中受到某些串行化机制的影响，正常情况下，通过资源管理器与队列机制有序的排序。但是如果某个组件出现过载，那么队列会产生溢出，这可能导致 RPC 调用的延迟增加。一般情况下遇到这种情况，下游服务将简单地使请求超时并进行重试，这种机制将会导致高负载情况下出现分布式系统的效率下降的问题，此时分布式数据库的总体性能会有所下降。而如果此时叠加一些其他的因素，比如某块硬盘的IO延时过大、某个网卡出现丢包、某个节点的操作系统出现严重换页，那么整个分布式数据库环境就有可能出现了正常的处理逻辑无法承受的临界状态，再叠加上数据库本身就存在的一些对此类情况处理不周的BUG，那么数据库出现严重的问题，甚至出现无法对外提供服务的情况，也是必然的。
而且分布式数据库一旦进入这样的状态，要想通过自身的容错能力与资源调度能力恢复系统运行，那就不是秒钟级甚至分钟级能够完成的了。此时最好的方法应该是彻底关闭数据库系统，解决掉出现问题的根源问题，然后重新启动数据库。但是对于分布式数据库这种大型系统而言，在出现故障的时候关闭数据库在大多数场景中也是不现实的。因此我们只有退而求其次，降低数据库当前的复杂，解决掉故障问题是退而求其次的解决方案。如果这个方法还是无法执行，那么就只能先解决掉导致问题的故障，再慢慢等着系统恢复了。
综上所述，分布式数据库的某个服务在其生命周期中很可能在不同程度的“健康状态”之间波动，从完全正常，能够以预期的并发级别运行下降到接近不正常，此时可能某些高负载导致某的队列溢出，如果问题持续恶化，数据库将进入“不正常”状态，此时数据库服务质量大幅下降。对于分布式数据库而言，自适应、自我修复的能力在大部分情况下可以自动处理这种波动，并力求自动恢复。可惜的是这种最佳预期并不总是在生产环境中得以实现，分布式数据库可能存在某些BUG;而高并发负载的持续时间可能超出硬件的能力范围;面包掉在地上黄油朝下的概率也极高。因此分布式数据库可以解决一切集中式数据库运维中的问题，达到极高的可用性的说法并不成立。
对于分布式数据库运维来说，小问题无需介入，大问题介入不了是一种常态。其最主要的问题还是我们无法对分布式数据库的健康状态有一个十分准确的评估。如果我们能够了解分布式数据库的内部状态，并提前做出预警，那么很多故障还是可以避免的。比如负载过高达到硬件资源极限可以通过切断部分流量来实现快速恢复。而如果能够在问题发生的更早期介入，数据库的恢复时间也会缩短很多。
比较麻烦的是，分布式数据库的健康评估是比较复杂的，对于分布式数据库来说，健康评估更像是一个布鲁姆过滤器。你发现数据库有问题，那么数据库肯定有问题。但是如果你检查数据库的状态是健康的，那么数据库仅仅是“可能处于健康状态”，我们必须通过其他的因素来确认其实健康的。
基于上面的认知，我们觉得针对分布式数据库的健康度需要从几个方面来做综合评估，传统的指标当然还是需要的，我们需要从操作系统负载与性能、数据库负载、数据库并发、集群与网络、负载均衡度、数据库容量等数个方面进行评估。
除此之外针对分布式数据库，我们还需要引入新的评估要素，那就是数据库功能的健康度评估，简单查询、简单写入、全表扫描、索引扫描、并行扫描、DDL操作等多种数据库业务的响应时间是否合理(比如是否超出P99延时)，不同计算节点执行相同的简单操作的延时是否均衡等，也应该作为健康评估的内容。必须如此，才能解决分布式数据库健康评估的“布鲁姆过滤器陷阱”。
仅仅实现准确的健康评估还不足够，更重要的是发现健康问题之后还需要能够进行问题溯源与解决方案分析。要想实现这一点，必须从两个方面做监控的增强。一方面是更加准确与全面的采集分布式数据库的指标，并能够高效的进行异常检测，从而能够全面的发现数据库指标的异常;另外一方面是能够快速的积累故障模型，构建常见故障的分析诊断与应急处置的标准化方法。
比如上面是某国产分布式数据库的一个故障场景，该场景会导致业务响应变慢。只要拥有充分的指标数据，通过规则引擎很容易描述出其中的场景，并形成自动化分析与诊断的工具。一切恐惧都来自于未知，正是因为我们对国产分布式数据库的运维经验积累还不充分，才导致了遇到问题时的手足无措。二十多年前，我们面对Oracle数据库的时候，也是如此的，随着应用场景的丰富以及运维经验被不断的积累，这些问题都会慢慢好起来的。