一、两地三中心是什么？
“两地三中心”的意思是生产中心、同城容灾中心、异地容灾中心，从意义上来看就是，兼具同城容灾和异地容灾，结合起来就叫两地三中心。
如建行已经构建了北京主中心、上海一期和二期数据中心，形成两地三中心的灾备架构模式，其中一个建行上海中心只是专门作为 备份的数据中心，为建行全国系统带来灾备服务。与此同时，上海外高桥数据中心作为灾备中心自然可以与建行上海一期数据中心形成同城灾备关系，与北京主中心形成异地灾备关系，从而可以防范建行在异地、同城情况下的灾难情况。
两地三中心的技术选择度量标准：
在构建容灾系统时，首先考虑的是结合实际情况选择合理的数据复制技术。 在选择合理的数据复制技术时主要考虑以下因素：
1、灾难承受程度 ：明确计算机系统需要承受的灾难类型，系统故障、通信故障、长时间断电、火灾及地震等各种意外情况所采取的备份、保护方案不尽相同。
2、业务影响程度 ：必须明确当计算机系统发生意外无法工作时，导致业务停顿所造成的损失程度，也就是定义用户对于计算机系统发生故障的最大容忍时间。这是设计备份方案的重要技术指标。
3、数据保护程度 ：是否要求数据库恢复所有提交的交易 ， 并且要求实时同步 ，保证 数据的连续性和一致性， 这是 备份方案复杂程度的重要依据。
以上内容参考：
凤凰网-灾备建设中两地三中心的几种建设方案
二、为什么采用两地三中心GDPS 双活解决方案
为什么采用两地三中心gdps 双活解决方案？
澄清一个概念，如果我们仅仅是指两地三中心gdps灾备解决方案的话，那么早在七－八年前国内很多大行就已经做到了这一点，具体的实现多是通过同城两个中心的gdps pprc解决方案联合异城两个中心的gdps z/os global mirror或者gdps global mirror解决方案．我们这里提到的两地三中心gdps双活解决方案是近三年来很火的一个专题，而且因为今年在某一大行的成功实施，使得这个主题无数次被提及，那么为什么要采用两地三中心gdps 双活解决方案呢？哪些场景下可以用到这个解决方案？
想来大家都应该看到过：银行营业网点或者银行官网上会发出因为某系统升级或者故障从凌晨几点到几点无法做交易的消息． 事实上无论是计划内的应用，数据库，中间件，系统和硬件升级维护，或者计划外的系统综合休(sysplex）级的故障，还是突如其来的火灾，地震，水灾，以及最要命的恐怖袭击，都有可能造成银行系统的不可用，进而造成业务的中断．各大行都迫切希望减少计划内和计划外停机的业务不可用时间，最好能够在面对各种极端情况时，依然能够保证业务的持续可用性，让用户感觉不到有任何故障存在，故两地三中心gdps 双活业务持续可用解决方案应运而生．该解决方案在不同城市的两个数据中心间沿用已经存在的gdps z/os global mirror灾备解决方案，其核心则在于同城两个数据中心间的gdps双活方案，从而使得关键应用运行于同城的任一个数据中心，在这两个数据中心之间做到自如地站点级别切换，一个站点的应用故障不会影响到另外一个站点的应用操作．
gdps双活的英文全称是geographically dispersed parallel sysplex active-active，即地理分散并行系统综合体双活解决方案． 该解决方案由两个分布于不同数据中心的并行系统综合体组成，这两个数据中心的功能分布是1:1模式，同时对外提供服务，数据中心间实现负载均衡，任何一个中心具备100%生产支持能力，具备无缝业务切换能力，减少应用停机时间，从而保证业务的持续可用性．
说到gdps 双活解决方案的适用场景，我们需要明确gdps双活解决方案是一个新生的且持续发展的解决方案，总共分成三个阶段，第一阶段为gdps active-standby, 第二阶段为 gdps active-query, 第三阶段为 gdps active-active, 当前处于第二个阶段．
在当前gdps active-query通常的配置中，两个active 的站点a和b，站点a是生产站点，主要用于运行核心业务，包含oltp(联机事务处理) 和批量作业, 站点b则只用于运行只读的query(查询)，并且随时准备着运行oltp和批量作业. 如果在站点b上监控到端到端的延时超过预定义的阈值，那么query能够自动地switch到站点a去做运行，当然这里我们可以在一分钟内通过sa rexx从监控表里抽几次样，如果几次都超过的话，再做切换，会更为合适．对于站点a而言，如果行里要对站点a的生产系统进行升级和改造，以前在行里通常需要请求三到五个小时的停机时间窗口(遇到问题的话，可能会更久)，在这个过程中，站点a是无法对外界提供服务的，但是现在采用了gdps 双活方案后，因为站点 b可以无缝接管站点a的业务，所以可以通过gdps a-a作站点级切换，把oltp workload 定向到站点b，由b站点对外界提供业务，此时所有的oltp和query workload都运行在了站点b，整个过程对于客户而言，都是透明的．然后对站点a进行升级，可以是升级应用程序，硬件，db2z版本，甚至z/os, 到升级完成后，在b站点停oltp workload,反向同步站点b改变的数据到站点a, 再把oltp workload回切到站点a. 整个过程中，站点切换耗时大概2分钟左右，回切基本上是相近时间，在站点b停oltp workload并反向同步数据耗时大概是10分钟，加到一起整个升级过程把对外界不能提供业务的时间控制在了十分钟的级别，与原有的三至五个小时相比有了巨大的改进
三、两地三中心redis部署是什么模式
这个方案是主从架构模式。
如果系统的qps超过10w+，甚至是百万以上的访问，单机的redis无法支撑，而采用主从架构的redis可以支撑高并发系统，一般高并发的应用，写的请求比较少，大量的请求都是读，所以采用主从架构+读写分离，可以支撑10w+的读qps的系统。
