个人完全同意前面专家们的说法，同城双活核心系统有必要同时采取数据库同步和存储底层同步两种模式。也还要看数据中心所具备的条件和人员技术储备情况，来选择具体方案。1. 如果具有同城几十公里内非常稳定且带宽足够的网络条件，那可以按照一步到位的真正A-A双活、同城数据...

通常都会有的，例如应用集群里的日志文件的共享，业务文件的共享，解决方案也比较多。有的企业有专门的文件传输平台或者业务总线，可以提供应用节点间的文件互通，除此之外，还可以考虑使用nas进行共享，但是性能相对较差点，GPFS是一个比较好的共享方案，性能比nas更高。...

也要区分当生产库不可用的原因，如果是生产库非正常宕机并且无法拉起的时候，则需要进行数据库的failover操作强制将备库设置为读写库。此时如果应用是基于dns配置链接串的，则需要修改dns将域名指向备库应用才能连接上，如果是基于service name配置的，则需要将该服务在备库上拉...

目前我们看到城商行级别最核心的一类和二类服务器，选择成熟稳定UNIX小型机的用户还是占大多数。原因在于小型机架构部署核心应用，安全稳定且成功案例丰富。考虑到跨数据中心的容灾和双活，小型机配合存储及数据库层的解决方案也众多，可以比较全面地满足用户从本地高可用、到数...

可以通过跨中心的负载均衡GTM实现，策略配置成双中心的应用同时双活或者配置成本中心的应用全部故障时将业务转发到同城的应用服务器上。

物理机，本地硬盘。

1、网关只是流量入口，不做任何业务处理，只负责转发2、尽可能接口见名知意，不要使用参数来确定接口类型3、后端服务非常多，可以使用分布式日志服务或者分布式调用链（推荐skywalling，无需开发直接使用Agent接入）...

以下纯属个人观点：1）中型商业银行在准备核心分布式数据库选型时，除了必须要考虑的强一致性、高可用性的原则，还应考虑哪些问题？业务系统改造成本：需要考虑sql兼容性（mysql or oracle），事务采用悲观锁模型还是乐观锁模型，数据分片是否对业务透明等产品可靠性和自主可控能力：产品是否...

核心系统应用服务器，在应用架构设计层面，采用分布式部署，少量服务器节点故障不会对业务产生影响。基础资源池本身的高可用和稳定性，作为辅助，不能作为最后的依靠。

由于灾难演练过程时间窗口有限，在生产切到在灾备做真实的业务演练后，会产生很多演练数据，值得关注的是账务数据和真实客户数据，据我了解，通用的做法有三种： 1、建立了生产和灾备存储间的实时/异步同步和切换后的反向复制，当生产切到灾备后，复制关系也将同步反转，由灾备存储实时/...