——我们需要什么样高可用？
金融、电商、互联网等行业，数据库的可用性直接关系到收入和用户利益，企业在谈论“RTO”“零停机”系统，一些数据库厂商也不断宣称越来越玄的高可用和RTO，RTO是什么？它是客户的终级目标吗？数据库厂商为什么要在RTO上不断拔高？企业到底需要怎样的高可用方案？
RTO是什么
RTO是Recovery Time Objective的缩写。是指当系统（如数据库）发生故障或停机时，可接受的应用程序停机时间的最大量。通常也用时间单位来衡量。然而，从理论到事实，零停机是技术上的一个理想，需要考虑的因素远不止技术本身，还包括实际的客户需求和成本。
客户真的需要零停机吗？
首先，零停机的真正必要性通常取决于业务场景。在金融行业，比如股票交易系统、支付网关，任何一刻的停机都可能导致直接的经济损失或信任危机。举个例子，2024年，某证券交易所因为爆单导致系统一度宕机，严重影响市场交易；再比如，某电商平台“双十一”时段，因系统局部故障，导致部分用户的支付功能受到影响，进而影响销售额和用户口碑。因此，对于这类业务，零停机是不可妥协的目标。
然而，是不是所有行业和企业都必须追求零停机呢？以大型企业的通用型业务和多数的中小型企业务来说，虽然高可用性对他们来说也很重要，但如果数据丢失的风险较低，或者容忍少许停机不影响整体业务，追求零停机的代价可能就远远超过了收益。比如某些内部管理系统或是非实时性的数据分析应用，几分钟的停机不会对业务产生太大影响。
即便是对于高可用要求极高的金融行业，参考《JR/T 0205-2020分布式数据库技术金融应用规范 灾难恢复要求》，根据应用于金融领域的分布式事务数据库的业务系统的重要程度和发生故障或瘫痪的影响范围、危害程度，将其容灾能力等级划分为6级，其最高6级的RTO(恢复时间目标)为≤1分钟。
然而，我们发现一些数据库厂商显然不够淡定，从30S到10S、8S，甚至直接大声宣称自己的产品ROT＝0，以及高可用8个9，9个9等等。这些，浮夸之风，一方面是有对技术的客观规律认识不足的，另一方面，国内外产业环境和少数人的“热情”使然，涉嫌违反《广告法》发布虚假广告，同时，还将影响数据库行业健康发展，以及对数据库行业的信心，对此，要保持警惕。
零停机的技术挑战与现实
从技术层面讲，实现零停机也绝非易事甚至可能，尤其是在复杂的企业环境中。大多数高可用性架构，比如Oracle RAC、PostgreSQL Patroni 或 MySQL Group Replication，通过数据复制和故障转移等手段，尽可能减少停机时间。然而，完全的零停机依然非常困难。
举个例子，PostgreSQL Patroni 配置的高可用性架构中，尽管通过ETCD或Consul来实现主备切换，但整个切换过程仍然需要时间。假设某个大规模数据库集群出现了故障，从故障检测到新主节点的选举和数据同步，往往需要几秒到几分钟的时间。即便是同步复制，也可能因为网络延迟和I/O问题，导致延迟加大，进而影响系统响应时间。
更重要的是，数据一致性也是零停机实现的一个难点。如果你使用同步复制，为了确保数据不丢失，必须保证主备节点的数据在同一时刻一致，这对系统性能提出了更高的要求。如果网络较慢，或者节点间的地理位置过于远离，同步复制的延迟会影响故障切换的速度，甚至造成短暂的服务中断，无法实现真正的“零停机”。
即便是Oracle的零停机目标也只是在理论上可实现，Oracle通过使用其 Data Guard 和 Active Data Guard 功能，配合 Oracle RAC（Real Application Clusters）和 Fast-Start Failover 等技术，可以在故障发生时迅速切换到备用节点，最大限度地减少停机时间。但事实上，任何故障检测、节点切换、数据同步等过程中的微小延迟，都会影响零停机的实现。
零停机的成本
零停机并非技术能够单纯解决的问题，更多的是成本问题。首先，高可用架构通常要求企业进行多地部署和冗余设计。例如，跨地域部署需要搭建两个数据中心，并配置跨数据中心复制，这不仅增加了硬件和网络带宽的成本，而且带来了管理的复杂性。对于大企业来说，可能这种投资是必要的，但对于一些中小型企业来说，零停机的成本就显得不那么划算了。
再比如，运维方面，零停机的架构需要24X7监控，这意味着不仅要有高素质的技术团队进行故障检测和修复，还要投入大量资源进行日常维护和优化。根据Gartner的研究，企业平均每年在数据库维护上的成本占到IT预算的20%到25%。而为实现零停机，企业通常需要配置更复杂的监控工具和自动化恢复系统，这势必会提高运维的复杂度和成本。
举个实际案例，某大型电商平台在设计数据库高可用架构时，曾考虑过是否需要实现完全的零停机。最终，经过成本效益分析，他们决定选择RTO（恢复时间目标）为5分钟的方案，而不是追求零停机。虽然这样做无法避免所有的停机，但整体维护成本却节省了30%以上，且在高峰期间，系统的容错能力仍然能够满足大多数业务需求。
什么是合适的高可用方案
零停机虽然是一个理想的目标，但并非所有企业都需要追求它。企业在设计数据库高可用架构时，首先要明确的是业务需求。如果你的业务非常依赖实时交易或客户互动，那么零停机的目标是必须的。但如果你的应用不具备那么高的实时性要求，或者可以容忍一定的恢复时间，建议选择RTO为几分钟的高可用方案。并在一些不需要极高实时性的应用中，可以通过设置数据库备份和灾难恢复策略，并结合定期的自动化故障切换来保持服务的高可用性。这样一来，既保证了业务连续性，又不会让高可用架构成为企业的沉重负担。
综上，数据库的零停机目标并非适用于所有企业，也不是唯一的高可用性标准。企业在追求零停机时，必须考虑客户需求和成本效益，合理设置恢复时间目标（RTO），并选择符合自己业务特性的高可用方案。对于一些大规模的交易平台，零停机是必要的，但对于大部分普通企业，高可用性足以满足需求，同时也能够更好地控制成本。
在追求零停机的路上，企业需要明智地判断，是否值得为这一近乎不可能实现目标的投入过多的资源和精力。量力而行，根据业务的不同需求划分等级，做出合理的技术选择，才是最明智的决策。
