选型核心指标：性能、一致性、持久化与集群能力
好，咱们直接切入正题。上一章聊了选型前的准备工作，这一章我重点讲讲四个硬指标。说白了，这四个指标就是内存数据库的「四根柱子」，哪根短了，你的风控系统都可能塌。
我个人习惯，在选型前会先画一张图，把四个维度的关系理清楚。你看下面这张图，就明白它们之间是怎么互相制约的了。
1. 性能：吞吐量与延迟，一个都不能少
性能这块，我见过太多人只盯着 QPS 看。其实风控场景下，延迟比吞吐量更致命。你想想看，一个支付请求过来，你告诉用户「请稍等，我在查黑名单」，等个 200 毫秒，用户早跑了。
我一般会这样评估：
- 延迟：P99 延迟必须控制在 5ms 以内。注意，是 P99，不是平均值。平均值骗人的，我踩过坑。
- 吞吐量：单节点至少支撑 10 万 QPS。风控系统在双十一这种场景下，流量峰值是平时的 10 倍以上。
关键点：内存数据库的延迟主要卡在网络开销和序列化/反序列化上。选型时，优先看那些支持「零拷贝」或「直接内存访问」的产品。
举个例子，Redis 的 P99 延迟通常在 1ms 以内，但如果你用了大量 Lua 脚本或者大 Key，延迟会飙升到 10ms+。我在项目中遇到过，一个简单的 ZRANGEBYSCORE 操作，因为集合里有 100 万个元素，直接拖垮了接口响应。
2. 数据一致性模型：强一致性还是最终一致性？
这个问题，说白了就是「你要多准的数据」。风控场景下，我把它分成两类：
| 场景 | 一致性要求 | 推荐模型 |
|---|---|---|
| 实时风控规则（如黑名单） | 强一致性 | Redis 主从同步 + WAIT 命令 |
| 离线风控特征（如用户画像） | 最终一致性 | Redis 异步复制 / 多级缓存 |
| 分布式锁 | 强一致性 | RedLock / ZooKeeper |
嗯，这里要注意。很多人觉得 Redis 默认就是强一致的，其实不是。Redis 的主从复制默认是异步的，主节点挂了，数据可能丢。我建议，对于关键的风控规则数据，一定要用 WAIT 命令确认从节点同步完成。
我的经验：如果业务允许，尽量用最终一致性。强一致性会牺牲一半以上的性能。我曾经为了追求强一致，把 Redis 集群的写入 QPS 从 20 万降到了 8 万，后来发现大部分场景根本不需要那么「准」。
3. 持久化策略：数据不能丢，但也不能太慢
持久化这块，我把它比作「保险」。你希望数据不丢，但买保险不能影响你正常生活。内存数据库的持久化，常见的有三种：
- RDB（快照）：定期把内存数据 dump 到磁盘。优点是恢复快，缺点是可能丢数据（两次快照之间的数据）。
- AOF（追加日志）：每条写操作都记录日志。优点是数据更安全，缺点是文件大、恢复慢。
- 混合持久化：RDB + AOF 结合。Redis 4.0 之后支持，我个人比较推荐。
我一般这样配置：
# 风控系统推荐配置
save 900 1 # 15分钟内有1次写入就触发快照
save 300 10 # 5分钟内有10次写入就触发快照
save 60 10000 # 1分钟内有10000次写入就触发快照
appendonly yes
appendfsync everysec # 每秒刷一次磁盘，平衡性能和安全避坑指南：我曾经把 appendfsync 设为 always，结果写入性能直接掉了 80%。后来发现，风控场景下，每秒刷一次盘完全够用。除非你的数据涉及资金安全，否则别用 always。
4. 集群部署能力：别等流量来了才想扩容
集群能力，说白了就是「能不能扛得住」。风控系统最怕什么？最怕流量突增时，数据库先挂了。
我评估集群能力时，主要看三点：
- 分片机制：数据怎么分散到多台机器上？Redis Cluster 用的是哈希槽，一致性哈希也有不少产品在用。
- 副本机制：主节点挂了，从节点能不能自动顶上？这个在风控场景下特别重要，因为风控系统通常是 7x24 小时的。
- 容灾能力：跨机房部署时，数据怎么同步？我建议至少做「同城双活」或「异地多活」。
实战建议：选型时，优先选那些支持「在线扩缩容」的产品。你想想看，双十一前你发现集群不够用了，难道还要停机扩容吗？我经历过一次，那叫一个惨。
举个例子，Redis Cluster 默认支持 16384 个哈希槽，理论上可以扩展到 1000 个节点。但实际项目中，我建议单集群不要超过 100 个节点，否则网络开销会拖垮性能。
好了，这四个指标讲完了。记住一句话：没有完美的数据库，只有合适的选型。下一章我会结合实际案例，带大家走一遍完整的选型流程。
最后一个小技巧：选型时，把这四个指标画成一个雷达图，每个维度打分。哪个维度低于 60 分，就重点考察。这样不容易漏掉关键点。