### 异地双活
同城双活可以应对大部分的灾备情况，但是碰到大面积停电，或者自然灾害的时候，服务依然会中断。对上面的两地三中心进行改造，在异地也部署前端入口节点和应用，在城市1停止服务后将流量切到城市2，可以在降低用户体验的情况下，进行降级。但用户的体验下降程度非常大。
所以大多数的互联网公司采用了异地双活的方案。
上图是一个简单的异地双活的示意图。流量经过LB后分发到两个城市的服务器集群中，服务器集群只连接本地的数据库集群，只有当本地的所有数据库集群均不能访问，才failover到异地的数据库集群中。
在这种方式下，由于异地网络问题，双向同步需要花费更多的时间。更长的同步时间将会导致更加严重的吞吐量下降，或者出现数据冲突的情况。吞吐量和冲突是两个对立的问题，你需要在其中进行权衡。例如，为了解决冲突，引入分布式锁/分布式事务；为了解决达到更高的吞吐量，利用中间状态、错误重试等手段，达到最终一致性；降低冲突，将数据进行恰当的sharding，尽可能在一个节点中完成整个事务。
对于一些无法接受最终一致性的业务，饿了么采用的是下图的方式：
> 对于个别一致性要求很高的应用，我们提供了一种强一致的方案（Global Zone），Globa Zone是一种跨机房的读写分离机制，所有的写操作被定向到一个 Master 机房进行，以保证一致性，读操作可以在每个机房的 Slave库执行，也可以 bind 到 Master 机房进行，这一切都基于我们的数据库访问层（DAL）完成，业务基本无感知。
>
> 《饿了么异地多活技术实现（一）总体介绍》
也就是说，在这个区域是不能进行双活的。采用主从而不是双写，自然解决了冲突的问题。
实际上，异地双活和异地多活已经很像了，双活的结构更为简单，所以在程序架构上不用做过多的考虑，只需要做传统的限流，failover等操作即可。但其实双活只是一个临时的步骤，最终的目的是切换到多活。因为双活除了有数据冲突上的问题意外，还无法进行横向扩展。
