问题
在风控系统的设计与实践中，我们经常会遇到两难：
- 事中：需要快速、实时决策，保证低延迟。
- 事后：需要完整的数据闭环，用于分析和模型优化。
在落地时会遇到类似的问题：
- 事前和事后数据几乎完全一致，原系统不得不重复组装一份数据发给风控，造成大量冗余。
- 风控系统只做了决策，却不知道最终结果，无法闭环优化策略。
- 挑战验证（人脸 / 短信 / 滑块） 涉及跨阶段状态保持，一旦断链，就会导致数据缺失和安全漏洞。
在前文也写过相关的，但是随着认识加深和实践经验加强，感受和理解也不太相同的。
决策流程
本篇文章讨论的前提都是此项目，而且更多是闭源分支，请谅解。
现在的决策流程大致是这样的，之前讲过每有一个接入配置，就对应了三个接口，分别是/{code}/sync（同步实时决策数据接入）、/{code}/async（异步，非决策类数据接入，包含同步的结果通知）
详细的就不展开了，关键是业务如何对接？
业务接入
首先得理解业务接入风控的是什么？通常来说一个完整的业务流程都不是那么简单，根据自己的需求决定要接入风控的点。
比如，一个业务TX0000，想要接入风控决策，本身TX0000是一个完整的业务，现在要接入风控决策。
拆分
拆分也就是分步，如拆分成TX0000_1和TX0000_2分别表示决策前后，当然这只是针对接入风控决策，本身对于业务系统还是一个完整的。
在风控记录中对应的是两条
| 事件ID | 字段 | 指标 | 决策记录 | 等 |
|---|---|---|---|---|
| 1000001 | 。。。 | 。。。 | 。。。 | 。。。 |
| 1000002 | 。。。 | 。。。 | 。。。 | 。。。 |
关键流程：
1、业务系统通过sync将完整数据接入风控
2、风控进行实时决策，返回决策结果和风控事件ID
3、业务系统处理决策结果（这里省去部分）
4、业务系统通过async同步结果，依然包含完整数据
5、风控计算事后指标，同样生成事件ID
这里我们举两个指标的例子
1、7天内同一设备ID发起业务TX0000的数量，如下
因为是发起，所以这里配置的TX0000_1，表示只是要做这个业务，是否完成还是看TX0000_2的情况。
2、7天内统一设备完成业务TX0000的数量，如下
因为是完成，所以配置的是TX0000_2且结果需要是成功的。这个结果可以是风控决策加强验证的成功失败也是可以正常业务流程的任何成功失败，密码错误、下游超时等等。
这里使用了"事件结果"作为结果字段，这个随意怎么定义都行，约定好就行，也可以是步骤1、2、3，都行。
不拆分
如果是不拆分，那么就保留TX0000接入风控决策
在风控记录中对应的是一条
| 事件ID | 字段 | 指标 | 决策记录 | 等 |
|---|---|---|---|---|
| 1000003 | 。。。+ | 。。。+ | 。。。 | 。。。 |
关键流程：
1、业务系统通过sync将完整数据接入风控
2、风控进行实时决策，返回决策结果和风控事件ID
3、业务系统处理决策结果（这里省去部分）
4、业务系统通过async同步结果（需要包含风控事件ID）
5、风控根据事件ID确认是否结果同步，补充更新数据，计算事后指标
对比于上，还是这两个指标
1、7天内同一设备ID发起业务TX0000的数量
需要注意这里额外配置了事件结果为空的条件，这样处理是因为，作为结果同步，会通过事件ID补充之前的数据，补充后的数据会作为一次独立的指标计算，指标计算并没有事后结果的区分，有可能会重复计算，所以条件上就需要有区别。
还是从例子说明
a、决策时TX0000，完整数据，指标计算，实时决策
b、TX0000的结果同步，补充上完整数据，指标计算
本身这是同一业务的不同阶段，如果不加以区分，会被认为是不同的两笔事件计算两次（虽然项目使用了zset并且使用事件ID作为member的模版，理论上不会出现重复计算，但是配置上体现会直接省去这部分计算流程，从而节省资源）。
2、7天内统一设备完成业务TX0000的数量
差别
最后再总结一下区别
拆分：就是把一个完整的业务主动拆分开
- 优点：清晰，风控配置、计算简单
- 缺点：需要重复上送数据
不拆分：保留完整业务数据一体
- 优点：数据一体，更贴合实际业务
- 缺点：风控处理复杂，尤其是补数据，重复计算上
另外，如果要做历史数据重跑，又是一大很关键的问题。
前面说过的如果是拆分，那么对应记录就是两条，如果是不拆分对应记录就是一条，系统是否能保证重跑历史数据仍然保证正确的计算，这其实是有点流计算和批计算的意思了。
目前系统对于两种模式都是支持的：
1、想要接入风控，但是只是想做事后指标计算，发/async接口，需要完整的数据，因为不存在数据补充，只会依赖本次数据计算
2、想要接入风控决策，需要实时同步响应，发/sync接口，需要完整数据，非常推荐结果同步发/async接口，此时只需要补充数据即可
3、另外还有会话豁免功能，前面也讲过了，简单讲就是同一会话中高级别的验证通过，就不给低于这个级别的决策了，可选。
小结
最后废话一下，每次从有想法到实践，都不是那么一帆风顺的过程，其中也有很多挣扎，方案设计，重来，推翻过去。。。不那么容易。
我现在工作模式也就这样，如下图，两列
左列：类似于代办，每完成一项后，将其勾掉，但是首次勾掉并不删除，而是保留一段时间，具体删除的时间取决于下次什么时候看到，如果还能回想起来并确认确实是完成了，那么就删除，如果回想不起来就再检查一下，确认是否真的完成了。
右列：规划中的可能不是最近一段时间要做的，而且一些也只是临时的想法，很有可能其实后面是不要做的，所以它去向有，1、不需要的，那么就会删除掉；2、确实需要，但是当下还有更重要的，放着不动；3、很紧急，最近要做掉，那么就移动到左列。
另外，一些特别的文章记录一下，发出来或者整理到系统文档里。