独立风控引擎技术落地规划

本方案承接《数字资产风控架构设计》，详细阐述如何用 3 个月时间，将风控中心（Risk Center）作为一个完全独立的旁路系统建设并落地。该系统以“零侵入、高可用、毫秒级熔断”为核心原则。

1. 技术栈选型

模块	技术栈	说明
数据采集 (CDC)	Debezium / Canal	读取业务库 MySQL 的 Binlog，转化为 JSON 事件流。
消息队列 (MQ)	Kafka (或 Redpanda)	高吞吐削峰，确保对账事件的绝对时序性。
风控计算引擎	Go (Goroutines) / Flink	消费 Kafka，执行滑动窗口对账与 UBA 规则。
状态/缓存层	Redis (Cluster/Sentinel)	存储滑动窗口数据、用户风险状态 (`User_Risk_Status`)、熔断开关。
持久化存储	PostgreSQL 15+ / MySQL 8	存储风控事件流水、影子账本快照、AML 标签库。
链上溯源层	Python (Celery)	轻量级异步任务，对接全节点 RPC 做 N-hop 地址穿透。

2. 核心架构流转图

┌─────────────────┐       ┌─────────────────┐
│  Asset DB (A库) │       │  Order DB (B库) │
└────────┬────────┘       └────────┬────────┘
         │                         │
         ▼ (Binlog)                ▼ (Binlog)
┌───────────────────────────────────────────┐
│            Debezium / Canal Cluster       │
└─────────────────────┬─────────────────────┘
                      ▼
┌───────────────────────────────────────────┐
│               Kafka Topics                │
│  (topic: asset_events, topic: tx_events)  │
└─────────────────────┬─────────────────────┘
                      ▼
┌───────────────────────────────────────────┐
│            Risk Engine (Go)               │
│                                           │
│  ┌──────────────┐     ┌────────────────┐  │
│  │ 滑窗对账引擎   │     │  行为规则引擎    │  │
│  │ (3s容差消除)  │     │ (T+N, 快进快出)  │  │
│  └──────┬───────┘     └───────┬────────┘  │
└─────────┼─────────────────────┼───────────┘
          │ (写判决)              │ (写判决)
          ▼                       ▼
┌───────────────────────────────────────────┐
│              Redis Cluster                │
│  (GLOBAL_PANIC = 0)                       │
│  (USER_RISK_UID_xxx = ALLOW/BLOCK)        │
└─────────────────────┬─────────────────────┘
                      │ (强制校验)
          ┌───────────┴────────────┐
          │     Wallet Signer      │
          │  (多签 / 离线签名网关)   │
          └───────────┬────────────┘
                      ▼
               [ 链上广播网络 ]

3. 数据库表结构规划

风控引擎必须有自己的独立数据库，不与业务库抢 IO。

3.1 影子账本快照表 (`shadow_ledger`)

记录风控系统认为的正确余额（用于大盘对账与断言）。

CREATE TABLE shadow_ledger (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id VARCHAR(64) NOT NULL,
    currency VARCHAR(20) NOT NULL,
    balance DECIMAL(36, 18) NOT NULL DEFAULT 0,
    last_event_offset VARCHAR(255) COMMENT 'Kafka 消费的最后一个偏移量，用于故障恢复',
    updated_at DATETIME(3) DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3),
    UNIQUE KEY uk_user_curr (user_id, currency)
);

3.2 资金对账异常事件表 (`risk_reconciliation_events`)

当滑窗（3秒）到期后，依然未能平账的“孤儿事件”，落库并触发告警。

CREATE TABLE risk_reconciliation_events (
    id VARCHAR(36) PRIMARY KEY,
    event_source VARCHAR(50) COMMENT '如: ASSET_DB_BINLOG',
    user_id VARCHAR(64) NOT NULL,
    currency VARCHAR(20) NOT NULL,
    amount_diff DECIMAL(36, 18),
    matched_status VARCHAR(20) DEFAULT 'unmatched',
    raw_payload JSON COMMENT '原始 Binlog 报文',
    created_at DATETIME(3) DEFAULT CURRENT_TIMESTAMP(3),
    INDEX idx_user (user_id),
    INDEX idx_created (created_at)
);

3.3 AML 标签库合集 (`aml_address_tags`)

沉淀自第三方（Beson, 漫雾）和自有 N-hop 爬虫计算的地址标签。

CREATE TABLE aml_address_tags (
    address VARCHAR(255) PRIMARY KEY,
    chain_id VARCHAR(50) NOT NULL,
    risk_level ENUM('SAFE', 'LOW', 'MEDIUM', 'HIGH', 'CRITICAL') NOT NULL,
    tags JSON COMMENT '如: ["mixer", "exchange", "phishing"]',
    provider_scores JSON COMMENT '各家供应商的原始打分映射',
    last_scanned_at DATETIME(3) DEFAULT CURRENT_TIMESTAMP(3),
    INDEX idx_risk (risk_level)
);

3.4 提币阻断与风控动作日志 (`risk_actions_log`)

记录是谁/什么规则触发了阻断。

CREATE TABLE risk_actions_log (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id VARCHAR(64) NOT NULL,
    action_type ENUM('FREEZE_WITHDRAW', 'GLOBAL_PANIC', 'REQUIRE_KYC', 'PASS') NOT NULL,
    trigger_rule VARCHAR(100) COMMENT '如: UBA_FAST_IN_OUT, RECONCILIATION_FAILED',
    action_detail TEXT COMMENT '拦截原因或凭证',
    created_at DATETIME(3) DEFAULT CURRENT_TIMESTAMP(3)
);

4. 实施路线图 (3 个月计划)

Phase 1 (M1)：基础设施与“不作恶”底座建设

目标：让风控引擎“长”上眼睛，不影响任何业务，建立旁路核对能力。

W1-W2：部署 Debezium/Canal，接通核心资产表与流水表的从库，跑通 Kafka 流。
W3：开发基于 Go 的滑窗对账逻辑，配置内存容差（如 T+3s），只打印日志，不发阻断指令。
W4：开发 Redis GLOBAL_PANIC 和 USER_BLOCK 的状态键；钱包团队在签名机挂载读取动作（若键存在则拒签），完成物理熔断链路打通。

Phase 2 (M2)：UTXO 防盗对接与快进快出拦截

目标：解决慢链的延迟误报，防止黑钱快出。

W5-W6：钱包独立数据库改造，明确标出 Unlocked UTXO 和 Locked UTXO。
W7：风控引擎接入钱包数据库和链上 RPC 节点，跑通“业务库 == 钱包 Unlocked UTXO <= 链上实际余额”的三维对账。
W8：开发 UBA 拦截规则（如：提币申请时检查距离上笔充值 < 2小时），命中即写入 Redis USER_BLOCK，由多签机拦截。

Phase 3 (M3)：图谱下沉与自动化申诉

目标：降低外部标签的误封率，建立自动化的洗钱溯源能力。

W9-W10：开发 N-hop 链上追溯 Worker。当 Mempool 发现大额入金，自动往前爬取 5 跳。
W11：融合第三方 AML（Beson等）分数。如果是“强特征黑钱（如混币器）”则进黑名单；如果是“交易所标签”则降级为人工复核。
W12：提供给客服/合规部门一个可视化的“风控阻断追踪看板”。客服可点击“解除该笔风控锁定”，将指令打回系统完成闭环。

5. 常见运维与降级策略 (Runbook)

Kafka 挂了怎么办？
- 降级：业务系统（提币、交易）不受影响，继续跑。但对账中止，丧失秒级防盗能力。
- 报警：此时多签机应立即转入手动（Manual）审核模式，直到 Kafka 恢复。
Redis 宕机，多签机读不到 User_Risk_Status 怎么办？
- 策略：Fail-Closed（默认拒绝）。出于资金安全考虑，如果读不到 Redis，多签机立刻罢工，人工介入。

1. 技术栈选型​

2. 核心架构流转图​

3. 数据库表结构规划​

3.1 影子账本快照表 (shadow_ledger)​

3.2 资金对账异常事件表 (risk_reconciliation_events)​

3.3 AML 标签库合集 (aml_address_tags)​

3.4 提币阻断与风控动作日志 (risk_actions_log)​

4. 实施路线图 (3 个月计划)​

Phase 1 (M1)：基础设施与“不作恶”底座建设​

Phase 2 (M2)：UTXO 防盗对接与快进快出拦截​

Phase 3 (M3)：图谱下沉与自动化申诉​

5. 常见运维与降级策略 (Runbook)​