数据库双活时延(数据库双活技术)

双活与多活

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

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

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

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

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

所以双活并不是终点，多活也可以有。

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

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

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

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

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

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

任何一种技术或架构，都有其固有的优势和劣势，所以在选择要不要上双活，还需要从自身业务实际需求出发，光看文章，是不是行的，你说，是不数据库双活时延！