1. 分布式风控概述：为什么需要分布式风控、核心挑战与CAP理论

大家好，我是老张。在风控这个领域摸爬滚打了十几年，今天咱们聊聊分布式风控。

说实话，我刚入行那会儿，风控系统还是单机版的。一台服务器，一个数据库，搞定所有规则。后来业务量上来了，单机扛不住了，才开始接触分布式。嗯，这个过程，踩过的坑真不少。

1.1 为什么需要分布式风控？

你想想看，一个电商平台，双十一每秒几万笔交易。每笔交易都要做风控——查黑名单、算额度、跑规则模型。单机能撑住吗？显然不能。

我经历过一个项目，日活从100万涨到1000万。原来的单机风控系统，CPU直接飙到99%，响应时间从50ms变成2秒。用户下单后，等半天才出结果。这谁受得了？

所以，分布式风控的核心驱动力就三点：

• 高并发：每秒几万甚至几十万笔交易，单机扛不住
• 高可用：风控挂了，业务就得停。分布式可以做到故障转移
• 低延迟：用户可不想等。50ms以内是基本要求

说白了，分布式风控不是炫技，是被逼出来的。

1.2 核心挑战：一致性、延迟、可用性

分布式风控，听着高大上，其实核心挑战就三个字：一致性、延迟、可用性。

我举个例子你就明白了。

假设用户A在手机端和PC端同时下单。风控系统需要判断：这个用户是不是在盗刷？

如果两个请求落到不同的风控节点上，节点1说「正常」，节点2说「异常」。那到底信谁的？这就是一致性问题。

再比如，风控系统需要查用户的历史交易数据。数据在数据库里，查一次要10ms。如果网络抖动，查一次要100ms。那整个交易就得等100ms。这就是延迟问题。

还有，风控节点挂了怎么办？如果只有一个节点，挂了就全完了。如果有多个节点，其中一个挂了，其他节点能不能顶上？这就是可用性问题。

这三个挑战，互相制约。你追求强一致性，延迟就上去了。你追求高可用，一致性就可能打折扣。嗯，这就是CAP理论要讲的东西。

1.3 CAP理论在风控中的体现

CAP理论，说白了就是：分布式系统，在一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）这三者中，最多只能同时满足两个。

在风控场景下，这个理论怎么体现？

我直接说结论：风控系统，通常选择AP（可用性+分区容错性），牺牲强一致性。

为什么？

• 分区容错性（P）：必须选。分布式系统，网络分区是常态。节点之间断连了，系统还得继续工作。
• 可用性（A）：必须选。风控挂了，业务就停了。用户下单失败，那损失就大了。
• 一致性（C）：可以牺牲。风控允许短暂的不一致。比如，用户刚被加入黑名单，但某个节点还没同步到。这个节点可能放行一笔交易。但没关系，事后可以补偿。

我做过一个支付风控项目，就遇到过这种情况。用户A在10:00:00被标记为高风险，但节点2在10:00:01才收到这个更新。这1秒的窗口期，节点2可能放行了一笔交易。事后我们通过离线对账，把这笔交易追回来了。

所以，风控系统的一致性，通常是最终一致性，而不是强一致性。

1.4 知识体系总览

下面这张图，是我自己画的。它展示了分布式风控的核心知识体系。你看一眼，心里就有数了。

1.5 避坑指南

最后，分享几个我踩过的坑。

• 别迷信强一致性：风控场景，最终一致性就够了。强一致性带来的延迟，你扛不住。
• 别忽略网络分区：分布式系统，网络分区是常态。你的系统必须能处理节点断连的情况。
• 别忘记补偿机制：最终一致性，意味着会有短暂的不一致。你得有补偿机制，比如离线对账、定时任务。

好了，这一章就到这里。分布式风控的核心挑战和CAP理论，你心里有数了吧？下一章，咱们聊聊具体的架构设计。