RPO和RTO是什么？

在衡量系统高可用的时候，我们经常能看到几个专业词汇，RPO和RTO，以做到RPO=0，RTO<30s，RPO和RTO代表了什么？

RTO，Recovery Time Objective，他是指灾难发生后，从IT系统当机导致业务停顿之时开始，到IT系统恢复至可以支持各部门运作、恢复运营之时，此两点之间的时间段称为RTO。

RPO，Recovery Point Objective，是指从系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。这种更新程度可以是上一周的备份数据，也可以是上一次交易的实时数据。

可以看出来，RTO和RPO服务于不同的目标，其中：

RTO涉及应用程序和系统，但主要描述应用程序停机时间的限制。

RPO主要与失败事件后丢失的数据量有关。

因此，从客户的角度，如果某个服务节点发生了故障，肯定希望数据不丢(RPO=0)，而且能尽快恢复(RTO 越小越好)。

理论上讲主从复制技术是可以利用强同步模式(例如Oracle Data Guard中采用Max Protection模式，或者DB2 HADR中采用Sync模式)做到RPO=0，但实际应用中，像银行核心系统这样的关键业务里却不会采用。为什么？因为这种模式将主节点和从节点以及主从节点之间的网络环境紧紧地绑在了一起，主节点的稳定性将不再由他自己决定，而要同时看从节点和网络环境的脸色。一旦从节点或者网络环境稍微抖动一下，主节点的性能就会受到直接影响。如果主节点和从节点之间是跨机房甚至跨城市部署，发生这种问题的概率会更大，影响也会变得更加显著。从某种程度上讲，和单节点模式相比，这种模式下主节点的稳定性不但没有增加，反而是降低了。除非你的业务，只关注RPO，不关注性能的稳定性情况，或者能接受不稳定的可能，但是必须保证RPO=0。

造成这一情况的根本原因，是“主从复制”模式下从节点不具备自动切主的能力。由于“主从复制“模式中缺少第三方仲裁者的角色，当主从节点之间的心跳信号异常时，从节点无法靠自己判断到底是主点故障了，还是主从之间的网络故障了。此时，如果从节点认为是主节点故障而将自己自动切换成主节点，就极容易导致“双主”、“脑裂”(brain-split)的局面，对用户来说这是绝对无法接受的结果。Oracle的DG提供了broker和Fast-Start Failover结合进行主备自动切换的功能，但是可能一般很少直接用，中间还是会穿插人的判断。如果从节点自动切换为主节点的功能，一定要由“人”来确认主节点确实故障了，并手工发起从节点的切主动作，这就大大增加了系统恢复的时间(RTO)。

除了传统数据库的高可用技术，现在逐渐被越来越多的技术厂商所采用的技术，是分布式多副本数据一致性技术，通常是基于Paxos协议或者Raft协议来实现。这种技术会将数据保存在多份副本上，每一次对数据的修改操作都会强同步到多数派副本上，在保证了数据冗余的同时，不再像“主从复制”技术那样依赖某个数据节点的稳定性，从而消除了传统主从复制技术下从节点给主节点带来的风险。同时，在主节点故障的情况下，其余节点会自动选举出新的主节点以实现高可用(个别从节点故障则完全不影响服务)，整个过程非常快速且完全无需人工干预。因此，这种技术不仅能保证RPO=0，而且大大减小了RTO，相比传统“主从复制”技术来说可以提供更强大的高可用能力。

另外，为了抵御机房级灾难和城市级灾难，可以将多份副本分散部署在多个机房里甚至多个城市中，以避免机房级灾难或者城市级灾难损毁多数派副本。这样就具备了机房级容灾和城市级容灾的能力，进一步加强了高可用的能力。