1. 容灾与高可用概述：为什么风控系统需要容灾？
大家好，我是你们这堂课的老朋友。今天咱们聊聊风控系统的容灾与高可用。说实话，我见过太多风控系统在关键时刻掉链子的案例了。有一次，某大促活动刚开始，风控系统直接挂了，结果黑产刷单刷了整整两个小时才被发现。嗯，那场面，真是惨不忍睹。
你想想看，风控系统要是挂了，意味着什么？意味着所有交易、所有支付、所有信贷审批，全都失去了保护。说白了，就是给坏人开了绿灯。所以，容灾和高可用，不是锦上添花，而是雪中送炭。
为什么风控系统需要容灾？
我个人的理解是，风控系统是金融业务的最后一道防线。这道防线要是破了，后果不堪设想。具体来说，有这几个原因：
- 业务连续性要求：风控系统一旦中断，交易审批就会停滞。我在项目中遇到过，某支付平台风控宕机15分钟，直接导致数百万笔交易无法处理，用户投诉电话打爆了客服中心。
- 损失控制：风控系统失效期间，欺诈交易会大量涌入。我记得有个案例，某银行风控系统故障40分钟，被黑产盗刷了超过2000万。这个数字，够吓人的吧？
- 合规与监管：金融监管机构对系统可用性有明确要求。比如，支付清算协会要求核心系统可用性不低于99.99%。达不到？那等着罚款和整改吧。
- 品牌声誉：系统挂了，用户不会管你是硬件故障还是软件bug，他们只知道你的平台不安全。信任一旦崩塌，重建可就难了。
核心观点：风控系统的容灾，不是为了应付检查，而是为了在灾难发生时，你的业务还能正常运转，你的用户还能放心交易。
核心概念：RPO、RTO、SLA
聊容灾，这三个概念绕不开。我刚开始做运维时，也经常搞混它们。后来踩过坑，才真正理解了。
| 概念 | 全称 | 通俗解释 | 风控场景举例 |
|---|---|---|---|
| RPO | Recovery Point Objective | 你能容忍丢多少数据？ | 风控规则库丢失1分钟的数据，可能漏掉一批欺诈交易 |
| RTO | Recovery Time Objective | 你能容忍系统停多久？ | 风控决策服务中断5分钟，业务方可能就要跳脚了 |
| SLA | Service Level Agreement | 你跟业务方签的承诺书 | 承诺风控接口99.95%可用，每月宕机不超过21分钟 |
这里我分享一个避坑指南：RPO和RTO不是拍脑袋定的。我曾经见过一个团队，把RPO定成0（零数据丢失），RTO定成30秒。结果呢？实现成本高得离谱，最后项目直接黄了。合理的做法是，跟业务方一起评估：丢多少数据可以接受？停多久不会造成重大损失？然后根据预算和技术能力，找到那个平衡点。
个人经验：我一般建议风控系统的RPO控制在1分钟以内，RTO控制在5分钟以内。这个标准，大部分公司用主备切换+实时同步就能实现，成本可控，效果也还行。
高可用与容灾的区别与联系
这个问题，我经常被问到。很多人觉得高可用就是容灾，容灾就是高可用。其实不然。我打个比方你就明白了：
- 高可用：就像你开一辆车，备了一个备胎。爆胎了，换上备胎继续开。目标是让车一直能跑。
- 容灾：就像你开一辆车，还准备了一辆拖车。车彻底坏了，拖车把车拖走，换另一辆车继续开。目标是车坏了之后，还能有办法继续前进。
说白了，高可用解决的是单点故障，比如服务器挂了、进程挂了。容灾解决的是区域性灾难，比如机房断电、光纤被挖断、甚至整个城市地震。
它们之间的联系也很紧密：
- 高可用是容灾的基础。没有高可用，容灾就是空中楼阁。
- 容灾是高可用的延伸。当高可用手段失效时，容灾机制就要顶上。
- 两者共同的目标：保证业务连续性，降低损失。
注意：别以为做了高可用就不用做容灾了。我见过一个公司，做了双机热备，觉得万事大吉。结果机房空调坏了，两台服务器一起过热宕机。这就是典型的「高可用做了，容灾没做」的教训。
知识体系总览
下面这张图，是我自己画的，把本章的核心逻辑串起来了。你一看就明白：
这张图把本章的三个核心模块串起来了。左边是「为什么需要」，中间是「用什么衡量」，右边是「怎么区分」。你把这三点吃透了，后面讲具体技术方案时，理解起来就轻松多了。
小结
好了，这一章就聊到这儿。总结一下：
- 风控系统必须做容灾，因为业务不能停、损失不能大、监管不能违、口碑不能坏。
- RPO、RTO、SLA是容灾设计的三个核心指标，定多少，要跟业务方一起商量着来。
- 高可用解决单点问题，容灾解决区域问题，两者相辅相成，缺一不可。
下一章，我会带你看看常见的容灾架构模式，比如主备、双活、多活。这些都是我实际项目中用过的，有些坑，我会提前告诉你。