3. 评分通道技术选型：Python Web框架对比与数据层设计
评分通道作为风控系统的核心决策链路，其技术选型直接影响接口响应速度、并发承载能力和维护成本。本章从Web框架、数据库、缓存三个维度进行系统性对比，帮助你在不同业务规模下做出合理选择。
3.1 Python Web框架对比：Flask / FastAPI / Django
三个框架在风控评分场景中的核心差异集中在异步支持、序列化性能和内置功能三个维度。以下从评分通道的实际需求出发进行对比。
| 对比维度 | Flask | FastAPI | Django |
|---|---|---|---|
| 异步原生支持 | 需额外安装插件（如 Quart） | 原生 async/await | 3.1+ 支持异步视图 |
| 请求序列化 | 手动处理 / Marshmallow | Pydantic 自动校验 + 序列化 | DRF 序列化器 |
| 性能（QPS） | 中等（同步阻塞） | 高（异步 + Uvicorn） | 中等（同步为主） |
| 内置ORM | 无（需集成 SQLAlchemy） | 无（需集成 SQLAlchemy / Tortoise） | 内置 Django ORM |
| 管理后台 | 无 | 无 | 内置 Admin |
| 适合评分场景 | 轻量原型 / 低并发通道 | 高并发实时评分通道 | 含管理后台的综合风控平台 |
选型建议：若评分通道需要承载 1000+ QPS 的实时请求，优先选择 FastAPI；若团队熟悉 Django 生态且需要快速搭建管理后台，可选择 Django 配合异步视图；Flask 更适合快速原型验证或内部低并发通道。
3.2 数据库选型：关系型 vs 时序型 vs 文档型
评分通道涉及三类数据：规则配置（低频读写）、评分日志（高频写入）、特征快照（结构化查询）。单一数据库难以同时满足三类需求，通常采用混合存储架构。
| 数据类别 | 推荐数据库 | 读写模式 | 关键指标 |
|---|---|---|---|
| 规则配置 / 通道元数据 | PostgreSQL / MySQL | 读多写极少 | 事务一致性、ACID |
| 评分请求日志 | ClickHouse / TimescaleDB | 写多读少（批量分析） | 写入吞吐、压缩比 |
| 特征快照 / 中间结果 | RedisJSON / MongoDB | 高并发读写 | 响应延迟 < 5ms |
实践要点：评分通道的数据库选型应遵循“读写分离 + 冷热分层”原则。热数据（最近1小时的特征快照）放在 Redis 或内存表中，温数据（最近7天的评分日志）放在 ClickHouse，冷数据（历史归档）定期转存对象存储。
3.3 缓存策略：多级缓存与一致性保障
评分通道的缓存设计直接影响接口延迟。合理的缓存策略可将 P99 延迟从 50ms 降低至 5ms 以内。以下是三级缓存架构的典型设计。
- L1 本地缓存（进程内）：使用
cachetools或lru_cache，缓存规则配置、通道路由表。TTL 建议 30-60 秒，避免频繁更新。 - L2 分布式缓存（Redis）：缓存特征计算结果、评分中间值。使用 Redis Cluster 分片，单 Key 不超过 10KB。
- L3 数据库查询缓存：ORM 层开启查询缓存（如 SQLAlchemy 的
caching_query），适用于低频变化的配置表。
3.4 缓存一致性方案
评分通道对数据一致性要求严格，尤其是规则配置变更后，必须确保所有缓存节点在短时间内失效。推荐采用主动失效 + 被动过期的双重保障。
- 主动失效：配置变更时，通过消息队列（Redis Pub/Sub 或 RabbitMQ）广播缓存失效通知，各节点监听后删除本地缓存。
- 被动过期：设置合理的 TTL（本地缓存 30s，Redis 缓存 120s），即使主动失效未到达，缓存也会自动过期。
- 兜底策略：评分引擎在缓存 miss 时直接查询数据库，并异步回填缓存，避免缓存雪崩。
避坑提醒：不要在评分通道中使用“先删缓存再更新数据库”的模式，这会导致并发请求读到旧数据。推荐使用“先更新数据库，再删除缓存”的 Cache-Aside 模式，配合延迟双删（Delayed Double Delete）解决缓存与数据库的短暂不一致。
3.5 技术选型总结矩阵
以下矩阵将上述选型建议汇总为可执行的决策参考，适用于不同规模的评分通道项目。
| 项目规模 | Web框架 | 关系数据库 | 日志存储 | 缓存层 |
|---|---|---|---|---|
| 原型 / 内部工具 | Flask | SQLite / PostgreSQL | 文件日志 | Flask-Caching（本地） |
| 中等规模（< 500 QPS） | FastAPI | PostgreSQL | MySQL 分表 | Redis 单机 |
| 大规模（> 1000 QPS） | FastAPI + Uvicorn | PostgreSQL 读写分离 | ClickHouse | Redis Cluster + 本地缓存 |
技术选型没有银弹，关键在于理解评分通道的流量特征和数据一致性要求。建议在项目初期采用 FastAPI + PostgreSQL + Redis 的组合，后续根据实际压测结果逐步引入 ClickHouse 和本地缓存优化。