按照现在的状态，绝大部分机构都只选了一两个应用作双活的试点，积累经验，研究技术趋势。最难的是数据库双活。应用服务双活和任务分配技术很成熟，可以先从应用层，接入层的双活开始做。...

如果应用能双活而不需要考虑底层的服务器存储，那就太完美了。这是能够做到的。至少我知道银联的核心系统是从应用角度解决了数据库双写的问题（虽然那不是为了双中心建设）。现在流行的思路分两种：一种是分库分表，放到双中心，完全能实现多活的目标，但是要做到不容易，和应用的逻辑有...

说说数据库层面的双活数据库的双活存储双活一般是同步写对于oracle 的Extended RAC，底层存储可以基于gpfs/vplex/asm，oracle官方不是很建议，只有一个extended rac的白皮书，各个架构在业内均有实施案例；对于DB2的gdpc，基于gpfs+purescale等，在业内也有实施案例；数据库的双活，其实就...

针对数据库，远程复制技术，基于数据库log(日志)的结构化数据复制它通过解析源数据库在线log或归档log获得数据的增、删、改变化，再将这些变化应用到目标数据库，使源数据库与目标数据库同步,以达到多站点间数据库可双活甚至多活，实现业务持续可用和容灾的目的，例如Oracle的Data G...

双活系统的建设一般情况下受带宽延迟和环境因素影响多数会考虑在同城进行。我们不能简简单单从技术层面考虑就能够称为双活系统，应该从灾备七要素全面考虑，包括：备用网络系统、备用数据处理系统、备用基础设施、数据备份系统、灾难恢复预案、运行维护管理能力和技术支持能力...

异地双活是我们从灾备中心转变为数据中心角色转变的首个重要任务，现在开放平台的top系统基本上实现双活，无法双活的容灾应用基本具备5分钟一键切换的能力。主机核心系统容灾切换已完成，今年准备实施双活。NONSTOP主机目前已经实现双活。...

我觉得可以先考虑做应用层/渠道类，轻数据类的应用双活，再考虑数据库级的双活。网络的双活有很多方法可以解决