异地多活数据中心系统架构需要如何考虑？

所谓“多活”，其实有多种不同的定义。是需要各站点实时同步所有数据并提供相同的服务？还是应用分区，数据互相同步备份？如果是后者，其实对用户来讲和前者没有差别。比如我们上网银操作不在乎后台的Server是在北京还是上海，只要北京的server掉了，后台能自动用上海的server继续服务，我们也感觉不到。
说到难点，归根结底是距离和光速限制。电信号每走来回100英里（还没算设备延迟），大概会延时1ms，而在数据库底层，io的延迟一般是ms级的（指顶级存储），现在的SSD盘会更快，大约0.1-0.4ms级别。也就是说，如果采用同步复制技术，超过100公里就会对顶级的应用系统（如银行核心）性能产生明显影响。所以2地3中心，通常远的站点是异步复制。收起

异地多活数据中心系统架构 这个国内没有一个实现的
有也是假的收起

能否实现异地多活与应用类型有着密切的关系，银行的账务系统很难实现严格意义的多活，类似于银联的渠道非账务是可以实现的。收起

楼主，你对“活”的概念是如何定义的，概念不同最终的结果差异很大收起

实时性要求高的系统可以做双活，可以借助成熟的产品如netapp的metrocluster和emc的vplex metro等，对于可以容忍一定RTO和RPO要求的，可以用异步的复制，比如vplex结合RP，受限于成本考虑，同时考虑业务的SLA要求，大多数企业还是采用的异步的灾备同步方式收起

异地多活不仅实现了业务的负载均衡，也同样起到了灾备作用。前天的支付宝问题，他们在异地多活上明显出现了问题，对我们传统银行企业来说，这个是不可想象的，在这个方面不知道有什么同行再搞了？或者说是做的不错了，能分享些收起