一续滋、定義

性能：是指實(shí)時(shí)風(fēng)控系統(tǒng)從接收到請(qǐng)求，到響應(yīng)請(qǐng)求的處理時(shí)長(zhǎng)孵奶。當(dāng)然說到性能疲酌，還涉及到吞吐量的問題，這里的性能，特指【分析時(shí)長(zhǎng)】朗恳，不包含吞吐量湿颅。

二、問題

那么粥诫，在實(shí)時(shí)風(fēng)控系統(tǒng)的設(shè)計(jì)過程肖爵，會(huì)遇到哪些性能方面的挑戰(zhàn)呢？

挑戰(zhàn)1：實(shí)時(shí)風(fēng)控系統(tǒng)的性能要求很高臀脏。實(shí)時(shí)風(fēng)控系統(tǒng)要植入于相關(guān)的業(yè)務(wù)系統(tǒng)劝堪，又要對(duì)業(yè)務(wù)系統(tǒng)的影響性做到最小，所以對(duì)于分析時(shí)長(zhǎng)就會(huì)提出很高的要求揉稚，{百M(fèi)S以內(nèi)}秒啦；

挑戰(zhàn)2：實(shí)時(shí)風(fēng)控系統(tǒng)的分析邏輯復(fù)雜。實(shí)時(shí)風(fēng)控系統(tǒng)的分析邏輯搀玖，不管是基于規(guī)則余境，基于評(píng)分，還是基于統(tǒng)計(jì)的灌诅，從計(jì)算的角度芳来，都屬于復(fù)雜的邏輯運(yùn)算，從分析的角度來看猜拾，是一個(gè)CPU密集型的應(yīng)用即舌；

挑戰(zhàn)3：實(shí)時(shí)風(fēng)控系統(tǒng)的依賴數(shù)據(jù)量大。實(shí)時(shí)風(fēng)控系統(tǒng)的分析過程挎袜，處理處理負(fù)責(zé)的業(yè)務(wù)邏輯之外顽聂，還依賴于大量的外部數(shù)據(jù)，比如盯仪，如何通過查詢海量的歷史數(shù)據(jù)來支撐規(guī)則的運(yùn)算紊搪，從分析的角度來看，又是一個(gè)IO密集型的應(yīng)用全景；

在N年前有過兩個(gè)概念耀石，OLTP（online transaction processing ）和OLAP（online analytical processing），當(dāng)然現(xiàn)在已經(jīng)很少提及了爸黄，大家現(xiàn)在關(guān)注的是大數(shù)據(jù)滞伟、云計(jì)算。Google了一下OLTP和OLAP的區(qū)別：

OLAP和OLTP比較

如果回到N年前的系統(tǒng)劃分標(biāo)準(zhǔn)馆纳，實(shí)時(shí)風(fēng)控系統(tǒng)到底算是OLTP還是OLAP呢诗良，或者是OLTAP汹桦，或者什么都不是鲁驶？

三、方案

面對(duì)上述的這些要求和挑戰(zhàn)舞骆，該怎么樣來設(shè)計(jì)解決呢钥弯？

也許你要說径荔，分布式計(jì)算框架啊，從hadoop脆霎，到spark总处，到storm，隨便選睛蛛，保證藥到病除鹦马，你看那**互聯(lián)網(wǎng)企業(yè)，**社交大亨都在用忆肾。那我們來看看荸频，hadoop、spark客冈、storm是個(gè)啥旭从？

Hadoop、Spark场仲、Storm和悦，我比較淺顯的理解，都是分布式的計(jì)算框架渠缕。

分布式計(jì)算框架實(shí)現(xiàn)了什么鸽素？簡(jiǎn)而言之，基于分布式計(jì)算框架的應(yīng)用亦鳞，就是一個(gè)分布式的應(yīng)用付鹿；那么分布式的應(yīng)用解決了什么問題？簡(jiǎn)而言之蚜迅，就是將請(qǐng)求處理的業(yè)務(wù)邏輯和所需資源合理地分布到N臺(tái)服務(wù)器上舵匾。

分布式計(jì)算框架帶來了什么？除了上面描述的好處之外谁不，也有負(fù)面的影響坐梯，那就是網(wǎng)絡(luò)訪問的開銷，不要忘記刹帕，Server之間通訊是有開銷的吵血，當(dāng)然這個(gè)開銷只是MS級(jí)，但別忘記了偷溺，我們整個(gè)系統(tǒng)的設(shè)計(jì)目標(biāo)就是百M(fèi)S級(jí)的蹋辅；

分布式計(jì)算框架解決了什么？從目前情況來看挫掏，實(shí)時(shí)風(fēng)控系統(tǒng)和大數(shù)據(jù)的關(guān)系侦另，是使用大數(shù)據(jù)參與分析，而不是處理海量的風(fēng)控請(qǐng)求，所以從這點(diǎn)來說褒傅，用分布式計(jì)算框架弃锐，有點(diǎn)殺雞用牛刀了；再來看看實(shí)時(shí)風(fēng)控系統(tǒng)的計(jì)算邏輯殿托，基本上都是CPU密集型的應(yīng)用霹菊，提升的核心在于算法，以及CPU的計(jì)算能力支竹，而不在于需要N多機(jī)器一起來協(xié)作旋廷；

那既然這些高大上的分布式計(jì)算框架不能很好的解決問題，那我們?cè)撛趺崔k呢礼搁？其實(shí)招數(shù)不多柳洋，都比較土，但很有效：

1叹坦、減少磁盤IO：盡量減少一次分析過程中的磁盤IO操作熊镣，盡量轉(zhuǎn)換為內(nèi)存IO操作，祭出一招：緩存募书。但是要將大量的歷史數(shù)據(jù)裝入緩存绪囱，確實(shí)也是一件勞命傷財(cái)?shù)氖虑椤改天專起個(gè)章節(jié)來聊}

2莹捡、減少網(wǎng)絡(luò)IO：從伸縮性角度考慮鬼吵，對(duì)于一次分析過程的實(shí)現(xiàn)，還是需要分層分塊篮赢，但是務(wù)必在設(shè)計(jì)時(shí)要考慮齿椅，一次分析過程的IO訪問次數(shù)；

3启泣、數(shù)據(jù)結(jié)構(gòu)和算法：采用什么算法來實(shí)現(xiàn)Rule Engine涣脚，rete，還是針對(duì)應(yīng)用特點(diǎn)寥茫，實(shí)現(xiàn)改良性的rete遣蚀；如何在規(guī)則的運(yùn)算和規(guī)則的命中之間找到一個(gè)平衡；采用哪個(gè)查找算法效率最高纱耻；內(nèi)存的存儲(chǔ)如何保證存儲(chǔ)空間和訪問效率的平衡芭梯，等等；

4弄喘、硬件資源的配套：針對(duì)實(shí)時(shí)風(fēng)控系統(tǒng)的特點(diǎn)玖喘，對(duì)于規(guī)則分析模塊，是個(gè)CPU密集型的應(yīng)用蘑志，而對(duì)于緩存模塊累奈，是個(gè)內(nèi)存型的應(yīng)用贬派，那么在硬件資源的配備上，應(yīng)該根據(jù)應(yīng)用的特點(diǎn)费尽，選擇合適的資源；

還有羊始，其它~5旱幼、6、7突委、8~