一、定义
性能：是指实时风控系统从接收到请求，到响应请求的处理时长。当然说到性能，还涉及到吞吐量的问题，这里的性能，特指【分析时长】，不包含吞吐量。
二、问题
那么，在实时风控系统的设计过程，会遇到哪些性能方面的挑战呢？
挑战1：实时风控系统的性能要求很高。实时风控系统要植入于相关的业务系统，又要对业务系统的影响性做到最小，所以对于分析时长就会提出很高的要求，{百MS以内}；
挑战2：实时风控系统的分析逻辑复杂。实时风控系统的分析逻辑，不管是基于规则，基于评分，还是基于统计的，从计算的角度，都属于复杂的逻辑运算，从分析的角度来看，是一个CPU密集型的应用；
挑战3：实时风控系统的依赖数据量大。实时风控系统的分析过程，处理处理负责的业务逻辑之外，还依赖于大量的外部数据，比如，如何通过查询海量的历史数据来支撑规则的运算，从分析的角度来看，又是一个IO密集型的应用；
在N年前有过两个概念，OLTP（online transaction processing ）和OLAP（online analytical processing），当然现在已经很少提及了，大家现在关注的是大数据、云计算。Google了一下OLTP和OLAP的区别：
OLAP和OLTP比较
如果回到N年前的系统划分标准，实时风控系统到底算是OLTP还是OLAP呢，或者是OLTAP，或者什么都不是？
三、方案
面对上述的这些要求和挑战，该怎么样来设计解决呢？
也许你要说，分布式计算框架啊，从hadoop，到spark，到storm，随便选，保证药到病除，你看那**互联网企业，**社交大亨都在用。那我们来看看，hadoop、spark、storm是个啥？
Hadoop、Spark、Storm，我比较浅显的理解，都是分布式的计算框架。
分布式计算框架实现了什么？简而言之，基于分布式计算框架的应用，就是一个分布式的应用；那么分布式的应用解决了什么问题？简而言之，就是将请求处理的业务逻辑和所需资源合理地分布到N台服务器上。
分布式计算框架带来了什么？除了上面描述的好处之外，也有负面的影响，那就是网络访问的开销，不要忘记，Server之间通讯是有开销的，当然这个开销只是MS级，但别忘记了，我们整个系统的设计目标就是百MS级的；
分布式计算框架解决了什么？从目前情况来看，实时风控系统和大数据的关系，是使用大数据参与分析，而不是处理海量的风控请求，所以从这点来说，用分布式计算框架，有点杀鸡用牛刀了；再来看看实时风控系统的计算逻辑，基本上都是CPU密集型的应用，提升的核心在于算法，以及CPU的计算能力，而不在于需要N多机器一起来协作；
那既然这些高大上的分布式计算框架不能很好的解决问题，那我们该怎么办呢？其实招数不多，都比较土，但很有效：
1、减少磁盘IO：尽量减少一次分析过程中的磁盘IO操作，尽量转换为内存IO操作，祭出一招：缓存。但是要将大量的历史数据装入缓存，确实也是一件劳命伤财的事情。{改天专起个章节来聊}
2、减少网络IO：从伸缩性角度考虑，对于一次分析过程的实现，还是需要分层分块，但是务必在设计时要考虑，一次分析过程的IO访问次数；
3、数据结构和算法：采用什么算法来实现Rule Engine，rete，还是针对应用特点，实现改良性的rete；如何在规则的运算和规则的命中之间找到一个平衡；采用哪个查找算法效率最高；内存的存储如何保证存储空间和访问效率的平衡，等等；
4、硬件资源的配套：针对实时风控系统的特点，对于规则分析模块，是个CPU密集型的应用，而对于缓存模块，是个内存型的应用，那么在硬件资源的配备上，应该根据应用的特点，选择合适的资源；
还有，其它~5、6、7、8~
