供应链金融风控系统的流程是怎样的？
预备准备
获得足够的数据来支持它
做一个灵活的分析平台来分析数据。
输出风险事件以阻止风险。
量化风险拦截的价值，不断分析案例，优化策略。
风险控制技术评估研究
日志选择:通过增量日志记录存储，通过hadoop或spark分析，将集群同步到客户端机器，制定同步策略，对不同纬度的数据做统计处理和计算。
实时监控:监控各环节的交易量和高风险操作，进行阈值报警和默认规则处理。
Dns防范:防止http拦截dns，手动记录拦截的交易流程，转存储中心系统处理，给用户提示。
报警提醒:在发生重大灾害时，需要有完善的系统提醒风控人员参战，并以短信或电话的形式向用户发送通知。
数据灾难:数据的历史记录要有完整的数据库准备记录。这个操作不是必须的，而是必须的。为防止管理员误操作造成数据灾难，应恢复启东应急预案。
日志选择:在原有基础上对集群数据进行分析后，需要有一个统一的分析平台，有一个入口，可以对不同维度的计算规则进行汇总和复制。这里可以用elk来清洗数据，做相关的分析研究。实时读取数据库是不可取的。增量数据库只保留历史数据，我们可以按时进行相关约定，在查询平台进行相关调整。
方案的选择和实施
针对目前的数据规则，需要对各方已有数据进行分析，做一个数据仓库，从需要风控的不同数据中计算出相应的报表数据，形成各种渠道。如何通过查询海量历史数据来支持规则的运行，从分析的角度来看是另一个IO密集型的应用。使用OLTP(联机事务处理)和OLAP(联机分析处理)做相关维度计算，主要针对用户、功能、数据切片、存储空间、DB设计做维度计算和方案优化调整。
大到可以用hadoop做数据聚类算法分析，也可以用spark和storm。
简而言之就是分布式框架，那么什么是分布式框架呢？
分布式计算框架实现了什么？简而言之，基于分布式计算框架的应用就是分布式应用；那么分布式应用解决什么问题呢？简而言之就是将请求处理的业务逻辑和所需资源合理的分配到N台服务器上，这里就不做过多介绍了。
基于C/S模式的原理，从客户端到服务器的应用程序收集所需的数据。服务器之间的通信有开销，但这种开销是MS级的。系统的定位也是基于百万级的应用。
基于分层的概念，每个风控模块都需要在特定的时间进行调整。缓存的应用:如果是历史数据，可以使用redis和cache来防止I/O读写操作的减少，减少存储压力的开销。基于支付时间维度的风控系统计算，需要我们考虑数据的节点，批量处理。对于多变的数据，建议使用高可用存储设计，基于DB设计，数据结构基于范式(NF)设计，不能有冗余，避免频繁返工。
数据分离的优先级选择
数据库读写分离机制:在最初的从动中，风控系统一般极其简单。此时，数据库与交易系统风控系统数据的同步和读写分离一般通过数据库主从复制/读写分离/slave等机制来保证。通常，风险控制系统只读取所需的客户/账户数据和交易数据。
缓存/内存数据库机制:无论是交易系统还是风控系统，高效的缓存系统都是提升性能的一大杀手锏。通常，经常使用的数据会存储在Redis等缓存系统中。比如风控系统包括风控规则、风控案例库、中间结果集、黑白名单、预处理结果等数据。对于交易系统，它包括交易参数、收费模板、清算和结算规则、利润分享规则、银行路由策略等内容。对于一些高频交易，基于性能考虑，会采用内存数据库(通常结合SSD硬盘)。
RPC/SOA架构:为了降低交易系统与风控系统的耦合度，在初期系统服务较少的情况下，一般直接使用RabbitMQ/ActiveMQ或RPC等消息中间件来实现系统间服务的调用。如果系统服务比较多，存在服务治理问题，就会使用Dubbo等SOA中间件来实现系统服务调用。在此期间，我们需要用异步消息来支持rabbitMQ的消息的推/拉处理机制，以处理非法数据和异常数据提取。