根據(jù)目前風(fēng)控系統(tǒng)運(yùn)行情況來(lái)看，遇到如下的問題
1. redis 中的key 太多，在存量卡號(hào)比較大的情況下百框，redis 中key的存儲(chǔ)過于龐大。
2. redis 本身RDB 和 AOF 的問題牍汹。 線上開啟AOF 重寫出差情況下铐维，會(huì)阻塞redis 主線程柬泽。
基于以上問題，我們發(fā)現(xiàn)redis 開啟AOF 和 RDB 帶來(lái)許多麻煩方椎。第一點(diǎn) 是冷熱key 的問題聂抢，redis中存儲(chǔ)了大量的key，而這些key 是用來(lái)累計(jì)各種衍生變量的棠众。但是其中很大一部分是冷key琳疏。這些key 其實(shí)可以置換到SSD 這種存儲(chǔ)設(shè)備上的。
因此為了解決冷熱key 的問題闸拿，我們引入了額外的中間件 areospike空盼。 冷熱key的置換和一致性的維護(hù)，是比較困難的新荤，何為冷key揽趾，可以熱key呢?? 我們沒有嚴(yán)格按照冷熱key的標(biāo)準(zhǔn)來(lái)做，我們根據(jù)業(yè)務(wù)來(lái)做苛骨。天篱瞎，周，月 等累計(jì)或者統(tǒng)計(jì)痒芝，都是放在areospike 里面進(jìn)行的俐筋。 但是天以內(nèi)的小時(shí)級(jí)別的累計(jì)，因?yàn)橐髮?shí)現(xiàn)滑動(dòng)窗口严衬，對(duì)準(zhǔn)確性和實(shí)時(shí)性比較高, 因而延續(xù)redis 的方式去實(shí)現(xiàn)澄者。那么對(duì)于風(fēng)控中各種窗口的累計(jì)和維護(hù)變成如下的變動(dòng):
1.?areospike 統(tǒng)計(jì) 天， 周请琳， 月 等緯度的累計(jì)粱挡，默認(rèn)是一天長(zhǎng)度的滾動(dòng)窗口
2. 24小時(shí)內(nèi)的衍生變量計(jì)算，繼續(xù)使用redis做滑動(dòng)窗口的計(jì)算俄精。
針對(duì)第二問題询筏，我們也沒有發(fā)現(xiàn)線上產(chǎn)生這種原因具體是什么，但是可以懷疑的是
線上單臺(tái)redis 太大竖慧，有120G屈留，如果AOF 重寫出錯(cuò)，需要從頭開始同步更多的數(shù)據(jù)测蘑。一邊應(yīng)用對(duì)redis 有大量的寫操作灌危，一邊 redis 本身有AOF 大量重寫。
對(duì)于這種問題碳胳，我們沒有找到本質(zhì)原因勇蝙，但是我們將120G redis 變成了 60G的大小，切成兩臺(tái)挨约。同時(shí)只開了RDB味混。 問題就沒有再出現(xiàn)過产雹。
對(duì)于risk 后面的規(guī)劃是在實(shí)時(shí)風(fēng)控那塊變成Flink 模式。 批量風(fēng)控目前hive／clickhouse 可以解決翁锡，系統(tǒng)還在逐步的演化蔓挖。
