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