3、技术选型：为什么选择Flink作为计算引擎、Redis与HBase的选型对比、消息队列（Kafka/RocketMQ）的选择依据
好，咱们接着聊技术选型。这一章很关键，说白了就是决定你整个风控系统的骨架用什么材料搭。选错了，后面改起来成本极高。我见过不少团队，一开始图省事用MySQL硬扛实时计算，结果流量一上来直接崩了。嗯，咱们得把这事想清楚。
3.1 为什么选择Flink作为计算引擎
实时风控，核心就两个字：快和准。你要在几十毫秒内判断一笔交易是不是盗刷，还要保证不出错。传统的批处理框架，比如Spark Streaming，其实本质上是微批处理，延迟在秒级。对于风控场景，这个延迟有时候会出大问题。
我个人习惯，选计算引擎主要看三点：
- 真正的流处理：Flink是逐条处理数据，不是攒一批再算。延迟可以做到毫秒级。
- 状态管理：风控经常要算“过去5分钟这个用户失败了几次”，这需要维护状态。Flink的状态后端做得非常成熟。
- 精确一次语义：钱的事，不能多算也不能少算。Flink能保证数据不丢不重。
我在项目中遇到过一件事。之前用Spark Streaming做实时反欺诈，某次大促流量暴增，微批处理窗口积压，导致一批交易判断延迟了十几秒。结果呢？几笔盗刷交易已经完成了。后来换成Flink，同样的流量，延迟稳定在20毫秒以内。这个差距，在风控场景里就是真金白银。
核心结论：Flink的“事件驱动”架构天然适合风控。它不像Spark那样需要你手动调优批处理大小，而是像流水线一样，数据来了就处理。你想想看，这多省心。
避坑指南：我曾经以为Flink的Checkpoint机制是万能的，结果有一次状态后端配成了RocksDB，但没调优RocksDB的缓存大小，导致频繁Full GC。记住，状态大小超过10GB时，一定要给RocksDB分配足够的内存。
3.2 Redis与HBase的选型对比
存储选型，是风控系统里最容易纠结的地方。Redis和HBase，一个快，一个能存海量数据。怎么选？我一般这么看：
| 维度 | Redis | HBase |
|---|---|---|
| 读写延迟 | 微秒级（纯内存） | 毫秒级（依赖HDFS） |
| 数据容量 | 受内存限制（一般几百GB） | PB级（横向扩展） |
| 数据结构 | 丰富（String、Hash、List、Set、Sorted Set） | 稀疏表（列族设计） |
| 持久化 | 弱（AOF/RDB有丢数据风险） | 强（基于HDFS，数据可靠） |
| 典型场景 | 实时计数器、黑名单、限流 | 历史行为存储、特征回溯 |
说白了，Redis适合存“热数据”。比如用户最近5分钟的登录失败次数、IP黑名单、设备指纹缓存。这些数据访问频率极高，但总量不大。HBase适合存“温数据”或“冷数据”。比如用户过去一年的交易记录、设备历史行为。这些数据量大，但查询频率低一些。
我个人的经验是：风控系统里，Redis和HBase不是二选一，而是搭档。Redis扛实时计算，HBase做离线分析和回溯。举个例子，判断一笔交易是否异常，先查Redis里的实时计数器（比如“该设备5分钟内交易次数”），如果超过阈值，再查HBase里的历史行为（比如“该设备过去30天是否出现过类似交易”）。
注意：千万别把Redis当数据库用。我曾经见过一个项目，把所有风控规则和特征都塞进Redis，结果内存爆了，数据丢失后整个系统瘫痪。Redis的持久化机制并不适合做数据主存储。HBase才是那个能扛住海量数据且保证不丢的“老黄牛”。
3.3 消息队列的选择依据：Kafka vs RocketMQ
消息队列是风控系统的“血管”。数据从业务系统流过来，经过消息队列，再进入Flink计算。选哪个？我直接说结论：大部分场景选Kafka，特定场景选RocketMQ。
为什么？
- Kafka的优势：吞吐量极高（百万级/秒）、生态成熟（Flink、Spark原生支持）、数据持久化能力强。适合做“日志总线”。
- RocketMQ的优势：支持事务消息、延迟消息、消息轨迹。适合需要“精确投递”和“业务回滚”的场景。
在风控场景里，大部分数据是“日志型”的。比如用户点击、交易请求、设备信息。这些数据量大，但不需要事务保证。Kafka的“至少一次”语义配合Flink的“精确一次”处理，完全够用。
但有一种情况我会选RocketMQ：当风控系统需要和业务系统做分布式事务时。比如，用户发起提现，风控系统判断通过后，需要通知业务系统扣款。如果风控判断成功但通知失败，就会出问题。RocketMQ的事务消息可以保证“风控判断”和“消息发送”要么都成功，要么都失败。
我的建议：如果你刚开始搭建风控系统，直接上Kafka。它简单、稳定、社区活跃。等业务复杂到需要事务消息时，再考虑引入RocketMQ。别一开始就搞复杂了，容易把自己绕进去。
嗯，这里要注意一点：消息队列的Topic设计。我习惯按“数据源”分Topic，比如“交易事件”、“登录事件”、“设备事件”。每个Topic再按“事件类型”分Partition。这样Flink消费时，可以按Partition并行处理，不会出现数据倾斜。
避坑指南：我曾经为了省事，把所有风控事件都塞进一个Topic。结果某个业务线流量暴增，导致其他业务线的消息被积压。后来改成按业务线分Topic，问题就解决了。记住，消息队列的隔离性很重要。
3.4 知识体系总览
最后，我用一张图把这三者的关系串起来。你一看就明白：
这张图很直观。数据从业务系统出发，经过消息队列缓冲，进入Flink做实时计算，最后结果写入Redis或HBase。三者各司其职，缺一不可。
好了，技术选型这块就聊到这。记住一句话：没有最好的技术，只有最合适的组合。Flink、Redis、HBase、Kafka，这套组合拳在实时风控领域经过了大量验证，值得你信赖。