Home | 简体中文 | 繁体中文 | 杂文 | 知乎专栏 | Github | OSChina 博客 | 云社区 | 云栖社区 | Facebook | Linkedin | 视频教程 | 打赏(Donations) | About
知乎专栏多维度架构 微信号 netkiller-ebook | QQ群:128659835 请注明“读者”

第 32 章 金融交易系统异地灾备方案

http://netkiller.github.io/journal/trader.html

目录

32.1. 背景
32.1.1. 建立容灾系统需要考虑哪些因素
32.1.2. 目前容灾系统的实现方式
32.1.3. 系统灾难恢复等级划分
32.1.4. 做灾备你面临最大的挑战是什么?
32.2. 灾备整体解决方案
32.2.1. 双活互备方案
32.2.2. 三机房互备方案
32.3. 数据中心网络
32.3.1. 单机房高可用双活互备解决方案
32.3.2. 双机房互备异地灾备方案
32.3.3. 三机房互备异地灾备方案
32.4. 服务器部署
32.4.1. 网站
32.4.2. 数据源
32.4.3. 数据库
32.5. 软件开发
32.5.1. 交易软件分布式交易
32.5.1.1. 分布式交易解决方案一
32.5.1.2. 分布式交易解决方案一
32.5.1.3. 分布式交易解决方案一
32.5.2. 交易终端
32.5.2.1. 用户分流
32.5.2.2. 会话保持
32.5.3. API 应用程序接口
32.5.4. 大数据的问题
32.5.4.1. 第一个阶分区表
32.5.4.2. 第二个阶分库分表
32.5.5. 数据校对
32.6. 自动化运维
32.7. 灾备培训和演练
32.7.1. 培训内容
32.7.1.1. 培训对象
32.7.1.2. 操作流程
32.7.2. 演练环境设置
32.7.3. 演练级别与方式
32.7.4. 开始演练
32.7.4.1. 切换前操作
32.7.4.2. 切换操作
32.7.4.3. 切换后检查
32.7.5. 演练结果检查
32.7.6. 可能存在的风险
32.7.6.1. 主交易系统短期无法恢复
32.7.6.2. 切换灾备系统后业务的影响
32.7.6.3. 数据不同步产生的影响
32.7.7. 灾备系统备份
32.7.8. 系统运营维护
32.8. FAQ
32.8.1. 实现双活最大的障碍是什么?
32.8.2. 双活怎么解决数据冲突问题

本文从灾备角度出发,并不局限于灾备,而是从多维度让你看到完成灾备需要做哪些工作,解决哪些问题。

灾备不仅仅是运维的工作,一个完善的灾备系统需要多个部门的努力,网络拓扑需要做特别的调整,服务器需要特别的部署,软件方面需要配合灾备做特别的开发,才能满足灾备的需求,最终实现真正的7*24*365灾备,并且尽量做到无人值守故障转移。

32.1. 背景

随着各种金融交易的推出,金融市场必将非常活跃,交易量的快速增加对交易系统产生了更大的压力,如何使交易系统平稳运行,成为金融公司的头等大事。 随着客户风险意识的增强,保证关键核心业务系统持续成功运作的需要,将发生风险的损失降到最低,保证企业的核心竞争力,金融公司对交易系统的可靠性提出了更高的要求。 目前金融公司普遍安装了热备份系统,达到了一定程度上的备份,但无法应对整个机房或大楼的灾难事故,这就需要在异地建立一套金融交易系统,一旦主系统发生问题,且无法启动热备的情况下,马上切换到异地灾备系统进行交易。

32.1.1. 建立容灾系统需要考虑哪些因素

与简单地将一部分数据从一台机器拷贝到另一台机器相比,企业内业务数据的复制要复杂的多。灾备系统必须满足以下所有业务需求:

  1. 数据的高可用性:灾备系统应具有可靠性,同时灾备系统的计算机系统故障不应影响业务的正常操作,达到 (Recovery Time Objective) “恢复时间目标”的要求。
  2. 减少数据丢失:达到 RPO (Recovery Point Objective)“恢复点目标”的要求。作为灾备的系统,最主要的功能是将交易过程中的数据能在最短的延时情况下,同步到灾备系统,最低限度丢失数据。
  3. 高性能:灾备系统不应影响数据源系统的正常运行,应当高效地利用网络,并允许各点采用最优化的方法存取本地数据。
  4. 提高投资回报率:利用备份系统来支撑其他业务,以提高系统的利用率

32.1.2. 目前容灾系统的实现方式

传统的容灾方式

  1. 基于存储复制的容灾,通过复制磁盘IO块复制的方式,从生产中心向容灾中心进行数据容灾,根据复制设备的不同,又可以分为:基于主机,基于磁盘阵列,基于智能SAN,虚拟存储设备
  2. 基于数据库的容灾,通过复制数据库日志或者数据文件方式,从生产中心向容灾中心进行数据容灾
  3. 基于应用的容灾,应用指向2个同时运作的数据中心,在任意一个中心活动情况下继续工作

以上的容灾方案都显得过时,这些老旧的容灾方案依靠IOE(IBM,Oracle, EMC)提供的解决方案,IOE的方案通常是通用很强,你只能按照他们要求实施,IOE并不清楚我们的业务逻辑,所以方案不一定是最好的,另外一旦使用了IOE产品,就会被他们绑架,金钱投入无休止。

随着开源软件技术发展,IOE的产品优势越来越不明显,技术固步自封,影响到了用户甚至成为企业发展的瓶颈,IOE投资回报率没有性价比,不符合当下互联网时代。

32.1.3. 系统灾难恢复等级划分

系统灾难恢复有国际标准,我国也有自己的系统灾难恢复标准,一般分为六个等级,但我觉得都较为过时,不符合互联网时代 。

我国灾难恢复等级划分国信办文件 2005 “重要信息系统灾难恢复指南”

  1. “第1级”:数据介质转移(备份介质异地存放和定期更新)
  2. “第2级”:备用场地支持(异地介质存放和备份中心支持)
  3. “第3级”:电子传送和部分设备支持
  4. “第4级”:电子传送和完整设备支持
  5. “第5级”:实时数据传送及完整设备支持
  6. “第6级”:零数据丢失

我认为等级划分应该为

灾难恢复等级划分

  1. 第一级:冷备份

  2. 第二级:双机热设备份(HA高可用, 通常为 Active Standby)

  3. 第三级:双活互备份(Active-Active 双机互备)

  4. 第四级:负载均衡(随时新增节点,移除节点,横向扩展)

  5. 第五级:异地灾备

  6. 第六级:全球负载均衡(分布式灾备)

从第二级开始就具备“零数据丢失”,远远高于国家标准与国际标准。一级可能需要人工介入,但从第二级开始都是无人值守,到第三级可以达到7*24*365不停机运转,实现智能故障转移。

32.1.4. 做灾备你面临最大的挑战是什么?

What are your biggest disaster recovery challenges?

  1. Scalability(可扩展性)
  2. Availability(可用性)
  3. Performance(性能)
  4. Flexibility(灵活性)