第1章容灾概述

一、容灾概述：金融行业为什么需要容灾？

大家好，我是老张。在金融系统这行摸爬滚打了十几年，今天咱们聊聊容灾。

说实话，我刚入行那会儿，对容灾的理解很浅。觉得不就是多备几台机器嘛？直到有一次，我亲眼见证了一个核心交易系统因为机房电力故障，整整宕了4个小时。

那4个小时，每分钟都是钱。交易中断、客户投诉、监管问询……嗯，从那以后，我再也不敢小看容灾了。

说白了，金融系统对数据的要求就三个字：不能丢。

你想想看，银行的核心账务系统，如果丢了1秒钟的交易数据，那是什么概念？账对不上，客户资产不翼而飞，这可不是闹着玩的。

我个人总结，金融行业需要容灾的原因有这几点：

核心观点：容灾不是成本，是保险。平时看着没用，真出事的时候能救命。

做容灾设计，有两个指标你必须刻在脑子里：RPO 和 RTO。

我记得有一次给某城商行做容灾方案，业务部门说「我们要求数据零丢失」。我说行，那RPO=0。又问「恢复要多快？」他们说「越快越好」。我说那RTO=0。结果一算成本，他们沉默了。

为什么会这样？因为这两个指标直接决定了你的技术选型和投入成本。

指标	全称	含义	金融行业典型值
RPO	Recovery Point Objective	数据能丢多少？允许丢失的时间范围	核心系统：0-5分钟
RTO	Recovery Time Objective	恢复要多快？从故障到恢复的时间	核心系统：15-30分钟

避坑指南：我曾经见过一个项目，业务部门说RTO要5分钟，结果实际恢复演练花了2小时。为什么？因为只考虑了数据库恢复，没算上网络切换、应用启动、负载均衡预热的时间。记住，RTO是端到端的恢复时间。

说到容灾等级，就绕不开 SHARE 78。这是美国一个叫SHARE的组织在1978年提出的标准，虽然年代久远，但至今仍是业界参考的基准。

SHARE 78 把容灾分成了7个等级，从Tier 0到Tier 6。我挑几个重点说说：

注意：金融行业的核心系统，通常要求达到Tier 4以上。我见过一些中小银行，为了省钱只做到Tier 2，结果一次机房火灾，数据全没了。嗯，后来他们被监管罚得很惨。

「两地三中心」这个词，在金融圈几乎人人都在说。但真正理解它的人，其实不多。

什么叫两地三中心？就是两个城市，三个数据中心。

为什么要这么设计？我举个例子你就明白了。

假设主中心所在的城市发生了大地震，整个城市都瘫痪了。这时候同城灾备中心也保不住，因为距离太近。但异地灾备中心在另一个城市，完全不受影响。数据虽然可能丢几秒钟，但至少系统还能跑起来。

下面我画了一张图，帮你理解这个架构：

这张图里，生产中心和同城灾备中心之间是光纤直连，延迟极低，可以实现数据实时同步。异地灾备中心则通过广域网连接，考虑到带宽和延迟，通常采用异步同步方式。

实战经验：我在做某股份制银行的容灾项目时，发现同城灾备中心虽然数据实时同步，但应用切换时还是会有几秒钟的延迟。为什么？因为数据库的redo log要等确认。后来我们调整了同步策略，把同步级别从「强同步」改成「半同步」，性能提升了不少，数据安全性也没打折扣。

好了，这一章的内容就到这里。总结一下：