单活和双活

要说双活，就得先说说单活。

单活就是一主一备。主和备有明显的功能划分，正所谓一主一备，主会很累，主每天要处理各种请求，忙得不可开交；而备却很清闲，每天把处理好的数据抄一份就好了，并且只有在灾难发生时才会干活。

花一样的钱，却不干一样的事儿，这不是浪费吗？不能忍？所以干脆，备也别闲着了，给你升个级，一起干活吧。

于是，单活就变成了双活。

主备都同时承担用户的业务，以前一个人的活，现在两个人干，当然干得更快，而且也更安全了，即使一方挂了，另一方可快速进行接管，实现梦寐以求的RPO＝0，RTO≈0。另一个意外的发现是，双活这货不仅可以起到容灾的作用，还可以实现业务流量在不同数据中心间的调度与分担，实现负载均衡的目的。

RTO 和 RPO 都是企业灾难恢复（Disaster Recovery, DR）需要考虑的关键指标，这两个指标可以用来指导企业来制定合适的业务系统服务或数据的恢复方案。

RPO， Recovery Point Objective，数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量。零RPO，指的是已提交的数据都不会被丢失。单个RPO的范围通常为24小时、12小时、8小时、4小时。以秒为单位测量到接近零。只要对生产系统的影响最小，8小时以上的RPO就可以利用现有的备份解决方案。4小时的RPO将需要计划的快照复制，而接近零的RPO将需要连续复制。在RPO和RTO都接近于零的情况下，将连续复制与故障转移服务结合使用，以实现接近100%的应用程序和数据可用性。

RTO，RecoveryTime Objective，数据恢复时间，是指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门运作，业务恢复运营之时，此两点之间的时间段。也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期，此两点之间的时间段称为RTO。RTO不仅仅是业务损失和恢复之间的持续时间。这个目标还包括IT部门必须采取的步骤来恢复应用程序及其数据。如果IT已经投入高优先级应用程序的故障转移服务，那么它们可以在几秒钟内安全地表达RTO(IT部门必须恢复本地环境，但由于应用程序正在云中进行处理，因此IT部门可能需要一些时间)。

1.相同点与不同点

RTO 和 RPO 都是使用时间来度量。

对于 RTO 时间，是指灾难发生到服务恢复的时间，这个时间也包含了数据恢复的时间。对于 RPO 时间，是指灾难发生到数据上一次备份的时间。

虽然 RTO 和 RPO 都使用时间来度量，但是使用它们的目的却不相同。

RTO 关注于应用或系统的可用性，RTO 虽然包含数据恢复的时间，但更多地是描述应用停机的时间限制。RPO 关注于数据的完整性，描述所能容忍的最大数据丢失限制。业务系统服务不可用会带来经济损失，但如果丢失的是客户交易数据则导致的损失更是灾难性的。

两者属于数据恢复领域的概念。
所以双活并不是终点，多活也可以有。

但因为双活需要同步复制，所以双活数据中心一般是在同一座城市搭建，否则如果数据中心距离太远的话同步复制的延时会太大，延时大了，性能也就下降了。道理很简单，速度慢了，单位时间内传输到量也就小了。

双活在提升了业务连续性方面表现优异，但消极的一面却是牺牲了备份的作用，换句话说，不再有备份这个功能，所以，万一同一个地区的两个数据中心同时宕掉…

为了解决这个问题，聪明的IT人员脑洞一开，“两地三中心”的概念应运而生，即在双活的基础上增加一个异地备份的功能。再然后，由于异地备份中心依然存在可能无法及时恢复或切换的问题，而且预算又十分充足，于是又将异地备份数据中心也改为双活，进而演变出了异地双活。

当然，双活这事儿不是拍脑袋、写篇文章就可以实现的。

要实现数据中心的双活，需要保证包括存储层、数据库层、网络层、应用层等都能实现双活，现在，针对不同层级所提供的双活产品也很多，比如针对存储双活的IBM的SVC和EMC的VPLEX，针对数据库双活的英方i2Active等。

理想很丰满，现实很骨感。以数据中心双活的重要基础——存储双后为例，就需要解决数据时序一致性、高时延链路导致的IO性能降低、死锁等诸多问题，双活另一个缺陷就是，无法解决逻辑错误的问题，一旦发生操作失误、病毒等，双活将同时被感染，双活有可能变成了“双死”。