实施双活的银行拿什么业务做双活？能达到什么效果？

1）没有一定的具体的业务范围限制，以交通银行为例，目前整个交通银行大机上的的核心系统、贷记卡系统，小机上的网银等系统均已经实现双活。
2）交通银行主机上的双活是基于IBM SYSplex,DB2 datasharing group,CICS Plex等产品实现的，小机上的双活是基于IBM GDPC架构实现的。
3）交通银行大机和小机上双活路由的策略均是更新交易路由到主中心、查询交易路由到次中心，主中心的CPU明显下降，次中心的CPU明显上升。另外由于架构原因交易响应时间也受到不同的影响，比如主机上主中心的交易响应时间并不会明显增加，但是次中心的交易响应时间会远大于主中心；小机上2个中心的交易响应时间都大幅增加。（具体原因可以再开一帖详细说明）
4）交通银行主机和小机上的双活RTO经过生产演练均在2分钟左右，演练方式就是直接把主中心的所有服务器关闭收起

回复 5# huixiang994

1）性能问题主要是SQL语句响应时间增长造成的，有由以下几个方面：
    a. 不管是主机上的DB2 datasharing group还是开放的DB2 pureScale都是靠着一个CF来保证数据一致性的（你可以把CF认为是专门的一台服务器），SQL语句执行的时候需要向CF注册L-lock和P-lock（L-lock是常规的lock,用来控制并发的，P-lock是用来追踪哪个节点用了哪个页面的），同时可能还需要从CF中获取页面最新的副本。
         主机一般我们会配置3台CF,2台在主中心互相同步,1台在副中心作为冷备(相当于不用的,除非主中心挂掉了),路由到主中心的交易只会访问主中心的数据库节点，路由到副中心的交易只访问副中心的数据库节点。那么显而易见主中心的数据库节点由于离CF近因此SQL响应时间并没有都少增加，而副中心的DB2节点由于要访问主中心的CF需要花费一些时间在网络通讯上（前面说过的1公里5微秒，交行70公里就是3.5毫秒），因此SQL响应时间会有所增加（对于简单的SQL来说，3.5毫秒算是很大幅的增长了）。
         开放上的DB2 pureScale由于只能部2台CF,因此肯定是主中心一个,副中心一个,而且2个CF要做同步,那么就造成不管SQL发到哪里,响应时间都会大幅增加了。
    b. commit的时候需要从CF获取一个全局的日志号并且写active log文件。
        主机上我们把更新交易路由到主中心，那么就减少了commit的时候和CF通讯的时间，但是由于要写active log文件，而active log文件是有双中心的磁盘同步镜像的，commit时间就在所难免的增加了。
        开放上还是因为DB2 pureScale架构的原因，造成commit时间也会大幅增加。

2）交易路由
     a.主机上的交易路由是由CICS-Plex实现的，根据交易id，将更新交易路由到主中心，查询交易路由到副中心
     b.开放上交易路由没有什么讲究，因为不管怎么路由2边性能都不怎么样。如果真的要路由的话可以考虑通过http server根据url来路由或者包装一下厂商的jdbc驱动，通过SQL类型将SQL路由到特定的数据库节点。

3）网关
     这个是有专人负责的，我也不是很清楚，目测现在只有单侧。

以上....收起

回复 6# arrnox


很感谢，获益颇多！~收起

学习了...收起

回复 2# arrnox


感谢专业的答复。：）

部署业务双活后，对于交易业务响应时间的影响，具体原因是否是双中心线路时延/质量引起？ 以及是否有优化的策略，另外开贴讨论。：）

另外，还有一个疑问，部署业务双活方案下，交易处理请求是通过路由的策略把更新交易和查询交易引导双中心的服务器双活集群上，那么对于服务器集群处理结果返回，服务器集群的网关是部署在单侧数据中心还是双侧数据中心同时部署网关双活？响应流量是否会有跨双中心互联的链路？收起

数据库层面的双活一般以读多写少的OLTP业务为主，报表和分析型系统不适合做双活。比如民生银行的计费系统就是使用的双活架构。另外演练的话以启停一边服务就可以。收起

个人了解，已完成双活中心建设的一家银行使用的DB2 purescale，进行了读写分离，主备中心承载不同业务类型，具体灾备演练如何进行，对这银行就不太清楚。收起