益陽哪里做網(wǎng)站,網(wǎng)站建設(shè)html5作品,如何利用電商平臺推廣,網(wǎng)站開發(fā)市場現(xiàn)在怎么樣一、 宏觀戰(zhàn)場#xff1a;不只是“快”那么簡單很多人對實(shí)時風(fēng)控有個誤區(qū)#xff0c;覺得只要用了Flink#xff0c;接了Kafka#xff0c;事兒就成了。大錯特錯。在銀行場景下#xff0c;準(zhǔn)確性#xff08;Accuracy#xff09;和低延遲#xff08;Low Latency#xff0…一、 宏觀戰(zhàn)場不只是“快”那么簡單很多人對實(shí)時風(fēng)控有個誤區(qū)覺得只要用了Flink接了Kafka事兒就成了。大錯特錯。在銀行場景下準(zhǔn)確性Accuracy和低延遲Low Latency是一對由于業(yè)務(wù)屬性天然互斥的冤家。你想想為了不誤殺用戶的正常交易比如他在出國旅游瘋狂買買買你需要更多的上下文數(shù)據(jù)歷史畫像、甚至他上一秒的地理位置但為了攔截盜刷你必須在交易完成前的幾百毫秒內(nèi)給出判定結(jié)果。所以我們的架構(gòu)設(shè)計必須圍繞“狀態(tài)State”來做文章。1. 核心鏈路設(shè)計別被那些復(fù)雜的微服務(wù)圖紙嚇到了剝?nèi)ネ鈿ず诵牡娘L(fēng)控數(shù)據(jù)流向其實(shí)就這幾步交易接入層 (Transaction Ingress)通常是核心交易系統(tǒng)通過CDCChange Data Capture或者直接發(fā)消息隊(duì)列。這里有個大坑千萬別直接消費(fèi)數(shù)據(jù)庫的Binlog除非你的數(shù)據(jù)庫是鐵打的。建議在交易網(wǎng)關(guān)直接異步推送到Kafka。實(shí)時計算層 (The Brain - Flink)這是主戰(zhàn)場。預(yù)處理數(shù)據(jù)清洗、格式統(tǒng)一。特征工程這是最耗時的。比如“過去5分鐘交易總額”。規(guī)則引擎硬代碼寫規(guī)則是找死必須動態(tài)可配。模型打分調(diào)用Python訓(xùn)練好的模型PMML或TensorFlow Serving。決策與下發(fā) (Decision Sink)結(jié)果寫入Redis供交易系統(tǒng)同步查詢或推送到告警系統(tǒng)。2. 為什么選擇Flink而不是Spark Streaming在2023年以后這已經(jīng)不是個問題了但在銀行老系統(tǒng)中還得扯皮。理由就一個Native Streaming vs Micro-batching。風(fēng)控要的是一條交易進(jìn)來立刻處理立刻輸出。Spark Streaming那種“積攢500毫秒再處理”的微批模式在平時還好一旦遇到雙十一或者黑五這種流量洪峰延遲會指數(shù)級爆炸。銀行的SLA服務(wù)等級協(xié)議通常要求風(fēng)控耗時在100ms以內(nèi)Flink的單條處理能力是唯一解。而且Flink的StateBackend狀態(tài)后端機(jī)制特別是結(jié)合RocksDB能讓我們在本地內(nèi)存和磁盤中存儲TB級別的“用戶歷史行為”這對于計算“過去30天該卡平均消費(fèi)金額”這種指標(biāo)至關(guān)重要。二、 動態(tài)規(guī)則引擎讓業(yè)務(wù)方閉嘴的藝術(shù)做風(fēng)控開發(fā)最痛苦的是什么不是寫代碼而是改需求。業(yè)務(wù)方上午說“單筆超過5萬且位于境外就報警。” 代碼剛上線下午業(yè)務(wù)方跑來說“不行誤報太多得改成‘且過去24小時無境外記錄’?！比绻忝看胃囊?guī)則都要重啟Flink作業(yè)那你離離職也不遠(yuǎn)了。重啟意味著狀態(tài)恢復(fù)State Restore這期間的數(shù)據(jù)積壓Backpressure會造成巨大的延遲波動。我們需要Broadcast State廣播狀態(tài)。1. 廣播流的設(shè)計哲學(xué)想象有兩條河流。大河交易流每秒幾萬條交易數(shù)據(jù)波濤洶涌。小溪規(guī)則流偶爾飄下來一片樹葉新的規(guī)則配置。Flink允許我們將“小溪”廣播到所有處理“大河”的并行度節(jié)點(diǎn)Task Managers上。2. 實(shí)戰(zhàn)代碼邏輯偽代碼與思路我們通常定義一個Rule實(shí)體類不僅僅包含閾值還包含Groovy腳本或者JSONPath邏輯。核心步驟如下定義規(guī)則流從My或配置中心如Nacos讀取規(guī)則變化通過CDC推送到Kafka的一個專用Topic。廣播它使用MapStateDescriptor定義規(guī)則存儲結(jié)構(gòu)。連接流TransactionStream.connect(RuleBroadcastStream)。這塊有個極其隱蔽的坑很多人第一次做都會掉進(jìn)去狀態(tài)的一致性與初始化問題。當(dāng)你新上線一個Flink Job規(guī)則流可能還沒來數(shù)據(jù)這時候交易流已經(jīng)在跑了你的系統(tǒng)就是“裸奔”狀態(tài)。所以必須在open()方法里先同步加載一份全量規(guī)則到內(nèi)存然后再依賴流式更新。// 這是一個極其精簡的示意不要直接copy到生產(chǎn)環(huán)境 public class DynamicFraudDetector extends KeyedBroadcastProcessFunctionString, Transaction, Rule, Alert { // 存儲規(guī)則的MapState private MapStateDescriptorString, Rule ruleStateDescriptor; Override public void processElement(Transaction tx, ReadOnlyContext ctx, CollectorAlert out) { // 1. 獲取當(dāng)前所有的規(guī)則 ReadOnlyBroadcastStateString, Rule rules ctx.getBroadcastState(ruleStateDescriptor); // 2. 遍歷規(guī)則進(jìn)行匹配 for (Map.EntryString, Rule entry : rules.immutableEntries()) { Rule rule entry.getValue(); // 3. 執(zhí)行規(guī)則邏輯這里通常會用策略模式或者動態(tài)腳本執(zhí)行器 if (RuleEvaluator.evaluate(tx, rule)) { out.collect(new Alert(tx.getCardId(), 觸發(fā)規(guī)則: rule.getName())); } } } Override public void processBroadcastElement(Rule rule, Context ctx, CollectorAlert out) { // 動態(tài)更新規(guī)則不需要重啟Job BroadcastStateString, Rule state ctx.getBroadcastState(ruleStateDescriptor); if (rule.isDelete()) { state.remove(rule.getId()); } else { state.put(rule.getId(), rule); } } }看明白了嗎通過這種方式業(yè)務(wù)人員在后臺點(diǎn)一下“生效”Flink作業(yè)內(nèi)部的邏輯毫秒級就會改變完全無感。這才是高級工程師該交付的系統(tǒng)。三、 時間的詭計Event Time與亂序處理在銀行數(shù)據(jù)中時間就是金錢字面意義上的。但網(wǎng)絡(luò)是不可靠的。用戶在地鐵里刷了卡10:00:01信號不好數(shù)據(jù)傳到你服務(wù)器可能已經(jīng)是10:00:05了。如果你按照服務(wù)器時間Processing Time來算“1分鐘內(nèi)的交易次數(shù)”那你就錯了。我們必須嚴(yán)格使用Event Time事件時間。但在風(fēng)控里Event Time有個致命弱點(diǎn)Watermark水位線的等待代價。1. 遲到數(shù)據(jù)的抉擇標(biāo)準(zhǔn)的Flink做法是設(shè)置一個Watermark比如延遲2秒。這意味著系統(tǒng)會等2秒確保大部分?jǐn)?shù)據(jù)都到了再計算窗口。但在反欺詐場景你等不起這2秒。假如黑客在1秒內(nèi)并發(fā)刷了10筆交易你還在等水位線錢早沒了。我的建議方案不要單純依賴Flink的Window API如TumblingEventTimeWindows而是使用KeyedProcessFunction配合Timer和ValueState自己實(shí)現(xiàn)窗口邏輯。為什么因?yàn)樵腤indow機(jī)制通常是在窗口結(jié)束時才輸出結(jié)果。而我們需要的是Trigger觸發(fā)機(jī)制——即每來一條數(shù)據(jù)立即更新狀態(tài)比如count。立即檢查當(dāng)前count是否超限。如果超限立刻報警不需要等窗口結(jié)束。窗口結(jié)束的作用僅僅是清理過期的State防止內(nèi)存溢出。2. 狀態(tài)清理的藝術(shù)這就要用到Flink的TTLTime To Live特性了。比如我們要監(jiān)控“過去24小時累計金額”。你可能會創(chuàng)建一個ValueStateDouble。 千萬別忘了配置TTLStateTtlConfig ttlConfig StateTtlConfig .newBuilder(Time.hours(25)) // 多留1小時buffer .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite) .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired) .build(); Descriptor.enableTimeToLive(ttlConfig);如果不配TTL你的RocksDB會隨著時間推移無限膨脹最后把磁盤撐爆運(yùn)維半夜會提刀來找你。相信我這種低級錯誤在很多大廠的代碼庫里都還存在。四、 特征工程CEP與復(fù)雜模式匹配簡單的“金額 10000”這種規(guī)則用或者簡單的Filter就能搞定。但真正的欺詐往往是隱蔽的模式。比如一種經(jīng)典的**“試探性盜刷”**模式先刷一筆1塊錢的小額測試卡是否有效。緊接著5分鐘內(nèi)刷一筆大額失敗余額不足。再嘗試一筆中等金額成功。這種A - B - C的時序關(guān)系是Flink CEPComplex Event Processing的強(qiáng)項(xiàng)。1. CEP不是銀彈很多教程吹噓CEP多么強(qiáng)大但在高吞吐Millions of txns/day的生產(chǎn)環(huán)境CEP的性能開銷是巨大的。每一個Pattern都是一個狀態(tài)機(jī)每條數(shù)據(jù)進(jìn)來都要去匹配狀態(tài)機(jī)的流轉(zhuǎn)。性能優(yōu)化技巧前置過濾Pre-filter不要把所有交易都扔給CEP。只有那些“可疑”的交易比如異地、大額、高風(fēng)險商戶才進(jìn)入CEP流。嚴(yán)格限制模式的生命周期.within(Time.minutes(10))。不要試圖去匹配跨度幾天的模式那會對State造成毀滅性打擊。2. 只有代碼能說明白用CEP定義上述的“試探性盜刷”大概長這樣PatternTransaction, ? fraudPattern Pattern.Transactionbegin(small-try) .where(new SimpleConditionTransaction() { Override public boolean filter(Transaction tx) { return tx.getAmount() 10.0; // 小額試探 } }) .next(big-fail) .where(new SimpleConditionTransaction() { Override public boolean filter(Transaction tx) { return tx.getAmount() 50000 tx.getStatus() FAILED; } }) .within(Time.minutes(10));看起來很優(yōu)雅對吧但實(shí)際上“next”嚴(yán)格緊鄰和**“followedBy”**非嚴(yán)格緊鄰的選擇至關(guān)重要。在信用卡流水中兩個操作之間可能會插入其他的雜項(xiàng)日志比如查詢余額。所以通常我們要用followedBy但這又會增加狀態(tài)匹配的復(fù)雜度。更狂野的做法對于頂級的高頻交易系統(tǒng)我們甚至?xí)仐塅link CEP庫直接用KeyedProcessFunction手寫狀態(tài)機(jī)。雖然代碼量多了三倍但我們可以精準(zhǔn)控制每一個Bit的狀態(tài)存儲把性能壓榨到極致。如果你是個追求極致的Geek我會推薦你手寫。五、 異構(gòu)計算的生死時速如何在流中嵌入AI模型在銀行場景下一個典型的風(fēng)控模型比如基于XGBoost或神經(jīng)網(wǎng)絡(luò)的評分模型響應(yīng)時間通常在10ms 到 50ms之間。你可能會說“這也挺快啊”對于Web服務(wù)來說是挺快但對于Flink這種每秒處理幾萬、幾十萬條數(shù)據(jù)的流引擎來說10ms 簡直就是萬年。如果你在MapFunction里直接同步調(diào)用一個 HTTP 接口去請求模型服務(wù)整個 Pipeline 的吞吐量會瞬間跌到個位數(shù)隨之而來的就是背壓Backpressure報警紅成一片。1. 救命稻草Async I/O異步I/OFlink 官方提供的AsyncDataStream是解決這個問題的標(biāo)準(zhǔn)答案但很多人只知其一不知其二。它的核心原理是不阻塞主線程發(fā)起請求后就把當(dāng)前這一“幀”掛起去處理下一條數(shù)據(jù)等結(jié)果回調(diào)了再撿起來。但在配置時有兩個參數(shù)決定了你是“救火”還是“縱火”O(jiān)rderedWait有序等待必須嚴(yán)格按照數(shù)據(jù)進(jìn)來的順序輸出。實(shí)戰(zhàn)建議千萬別用。在風(fēng)控場景下A用戶的交易判定結(jié)果和B用戶的交易誰先誰后根本不重要。強(qiáng)制有序會導(dǎo)致只要有一個請求超時后面所有處理完的數(shù)據(jù)都得排隊(duì)等著這叫“隊(duì)頭阻塞Head-of-line blocking”。UnorderedWait無序等待誰先跑完誰先出。實(shí)戰(zhàn)建議必須用這個。但這會打亂時間戳的水位線嗎會一點(diǎn)但在 Watermark 允許的容忍范圍內(nèi)這點(diǎn)亂序換來的吞吐量提升是值得的。2. 真正的“核武器”模型本地化JPMML雖然 Async I/O 解決了吞吐量問題但網(wǎng)絡(luò)延遲Network Latency依然存在。RPC調(diào)用哪怕再快也不如本地調(diào)用快。在頂級銀行的高頻交易風(fēng)控中我們通常會拒絕網(wǎng)絡(luò)調(diào)用。怎么做把模型“搬”到 Flink 里面去。大多數(shù)數(shù)據(jù)科學(xué)家用 Python 訓(xùn)練模型我們要求他們將模型導(dǎo)出為PMML (Predictive Model Markup Language)格式。這是一種跨語言的標(biāo)準(zhǔn)。然后在 Flink 的RichMapFunction中利用 的 JPMML 庫加載這個文件。public class ModelPredictionMap extends RichMapFunctionTransaction, TransactionWithScore { private Evaluator evaluator; Override public void open(Configuration parameters) { // 在作業(yè)啟動時將幾百兆的模型文件加載到堆內(nèi)存中 // 這一步雖然慢但只發(fā)生一次 File modelFile RuntimeContext.getDistributedCache().getFile(fraud-model.pmml); this.evaluator new LoadingModelEvaluatorBuilder().load(modelFile).build(); } Override public TransactionWithScore map(Transaction tx) { // 純內(nèi)存計算耗時從 20ms 壓縮到 0.5ms // 沒有網(wǎng)絡(luò)IO沒有序列化開銷 MapFieldName, FieldValue arguments prepareArgs(tx); MapFieldName, ? results evaluator.evaluate(arguments); return attachScore(tx, results); } }這種架構(gòu)的代價是什么內(nèi)存爆炸如果模型很大比如深度學(xué)習(xí)模型TaskManager 的堆內(nèi)存壓力會劇增。更新麻煩更新模型需要重啟 Flink Job 或者利用廣播流動態(tài)加載新的 PMML 字節(jié)流這屬于高階騷操作容易OOM慎用。但為了那0.5ms的極致速度這一切折騰都是值得的。六、 RocksDB馴服存儲的野獸當(dāng)你的風(fēng)控規(guī)則涉及到“過去3個月的交易行為”時內(nèi)存肯定放不下必須開啟 Flink 的 RocksDB StateBackend。RocksDB 本質(zhì)上是一個嵌入式的 KV 數(shù)據(jù)庫它把數(shù)據(jù)存在本地磁盤通常是 NVMe SSD。很多新手開啟 RocksDB 后發(fā)現(xiàn)性能從每秒 5萬 跌到了 5千為什么因?yàn)槟J(rèn)配置就是垃圾。1. 必須要懂的 BlockCacheRocksDB 讀寫分幾層MemTable內(nèi)存 - SST Files磁盤。 如果每次讀取狀態(tài)都要去摸磁盤你的系統(tǒng)就廢了。你必須顯式配置state.backend.rocksdb.memory.managed: true但這還不夠。在代碼里你需要通過RocksDBOptionsFactory來調(diào)整BlockCache的大小。簡單粗暴的原則把 TaskManager 堆外內(nèi)存的一大半都喂給 BlockCache。我們希望 90% 的熱點(diǎn)用戶比如剛才正在刷卡的人的狀態(tài)數(shù)據(jù)都能在內(nèi)存緩存里找到只有那些萬年不用一次的冷數(shù)據(jù)才去讀盤。2. Bloom Filter布隆過濾器的魔法在風(fēng)控查重場景比如“該設(shè)備是否在黑名單中”大部分時候答案是“No”。如果沒有優(yōu)化RocksDB 會去磁盤里翻箱倒柜找這個 Key最后告訴你“沒找到”。這太蠢了。開啟布隆過濾器。它是一個很小的內(nèi)存結(jié)構(gòu)能以 O(1) 的代價告訴你“這個 Key絕對不存在”或者“可能存在”。這就擋掉了 99% 無意義的磁盤 I/O。// 這是讓性能翻倍的一行代碼 columnFamilyOptions.setBloomLocality(1);不要小看這行配置在日均億級訪問的場景下它能救你的命。3. Checkpoint 的性能殺手銀行系統(tǒng)要求Exactly-Once精確一次所以 Checkpoint檢查點(diǎn)必須開。但在高負(fù)載下Checkpoint 可能會超時失敗。如何優(yōu)化增量 Checkpoint必須開。只備份修改過的狀態(tài)而不是全量備份。本地盤 vs 遠(yuǎn)程盤RocksDB 的工作目錄必須掛載在高性能的NVMe SSD上。千萬別為了省錢用普通的云盤EBSIOPS 根本扛不住 CompactionSST文件合并帶來的壓力。七、 所謂的“精確一次”與數(shù)據(jù)一致性這是銀行最敏感的話題。我們常說的 Flink Exactly-Once其實(shí)只保證了 Flink內(nèi)部狀態(tài)不丟、不重。但如果你的 Sink下游是寫入 My 或者 RedisFlink 可不管那一套。想象一下Flink 處理完一筆交易判定為欺詐把結(jié)果寫到了 Redis然后 Update 了內(nèi)部的狀態(tài) offset。就在這時機(jī)器斷電了。 Flink 重啟回滾到上一次 Checkpoint重新消費(fèi)這筆交易再次判定為欺詐再次寫入 Redis。對于冪等的操作比如Set KeyValue重復(fù)寫沒問題。 但對于非冪等操作比如Incr Counter累加計數(shù)這就出大事了。數(shù)據(jù)直接翻倍。1. 真正的端到端一致性End-to-End Exactly-Once要做到這點(diǎn)下游必須支持事務(wù)Transaction。最經(jīng)典的方案是結(jié)合Kafka 的事務(wù)機(jī)制Kafka 0.11。 Flink 開啟TwoPhaseCommitSinkFunction兩階段提交Pre-Commit數(shù)據(jù)寫入 Kafka 的一個臨時事務(wù)中此時下游消費(fèi)者比如風(fēng)控后臺是看不到這些數(shù)據(jù)的設(shè)置isolation.levelread_committed。SnapshotFlink 全局做 Checkpoint。CommitCheckpoint 成功后Flink 通知 Kafka 提交事務(wù)數(shù)據(jù)瞬間對下游可見。2. 兜底方案冪等性設(shè)計說實(shí)話兩階段提交太重了延遲也高。在實(shí)戰(zhàn)中我們更多采用**“業(yè)務(wù)冪等性”**設(shè)計。 我們在輸出結(jié)果時帶上這筆交易的唯一 IDTransactionID。 下游系統(tǒng)比如 My在插入警報時利用INSERT IGNORE或者ON DUPLICATE KEY UPDATE。寧可讓數(shù)據(jù)庫多承擔(dān)一點(diǎn)壓力也不要讓流計算邏輯過于復(fù)雜。簡單往往意味著健壯。八、 監(jiān)控與大屏讓看不見的數(shù)據(jù)被看見系統(tǒng)寫好了怎么證明它在工作老板和監(jiān)管機(jī)構(gòu)只看大屏。我們不僅要監(jiān)控 Flink 的技術(shù)指標(biāo)Delay, Checkpoint Duration, Backpressure更要監(jiān)控業(yè)務(wù)指標(biāo)。這里推薦一個Side Output側(cè)輸出流的模式。不要把監(jiān)控指標(biāo)混在主業(yè)務(wù)流里。在計算過程中隨時把統(tǒng)計數(shù)據(jù)扔到側(cè)輸出流if (tx.getAmount() 10000) { ctx.output(largeTxTag, tx); // 大額交易流 } // 實(shí)時計算 TPS ctx.output(metricTag, new Metric(TPS, 1));然后起一個完全獨(dú)立的 Flink Job 或者直接用 Telegraf InfluxDB 來消費(fèi)這些側(cè)輸出流展示到 Grafana 上。一定要監(jiān)控的關(guān)鍵業(yè)務(wù)指標(biāo)攔截率如果在某一分鐘內(nèi)攔截率突然從 0.1% 飆升到 20%要么是遭受了大規(guī)模攻擊要么是你的規(guī)則寫掛了誤殺。此時必須要有熔斷機(jī)制。規(guī)則命中分布哪條規(guī)則殺得最狠如果是某條新上的規(guī)則殺瘋了第一時間回滾它。處理延遲分位值P99 Latency不要看平均值平均值是騙人的。我們要看 P99也就是最慢的那 1% 的交易延遲了多久。這才是用戶投訴的來源。九、 容災(zāi)的殘酷哲學(xué)Fail Open 還是 Fail Close這是一個涉及幾千萬資金的哲學(xué)問題。當(dāng)你的 Flink 集群因?yàn)?Bug 崩潰了或者 Kafka 發(fā)生了嚴(yán)重的積壓此時一筆用戶的刷卡請求過來了。你是選擇 A.直接拒絕Fail Close為了安全寧可殺錯不放過。用戶會看到“交易失敗”然后憤怒地打爆客服電話。 B.直接放行Fail Open為了用戶體驗(yàn)暫時放棄風(fēng)控讓交易通過。這可能會放過幾筆盜刷。在 99% 的場景下銀行的答案是Fail Open也就是“降級”。1. 自動降級機(jī)制你不能依賴人工去監(jiān)控報警然后手動切開關(guān)那太慢了。我們需要在交易接入層API Gateway做一個熔斷器Circuit Breaker。超時熔斷如果風(fēng)控接口 200ms 還沒返回結(jié)果直接 Return Success。錯誤率熔斷如果過去 1 分鐘內(nèi)風(fēng)控接口報錯超過 5%自動跳過風(fēng)控邏輯直到系統(tǒng)恢復(fù)。但在 Flink 內(nèi)部我們也要做自我保護(hù)。 比如在反序列化 JSON 失敗時或者調(diào)用模型拋出異常時千萬不要讓整個 Job 掛掉Failover。// 這種寫法會被開除 try { Result r analyze(transaction); } catch (Exception e) { throw new RuntimeException(Crash!); // 整個集群重啟所有交易卡頓 } // 這種才是成熟的寫法 try { Result r analyze(transaction); } catch (Exception e) { // 記錄錯誤指標(biāo)靜默失敗輸出一個“未知風(fēng)險”的標(biāo)記 // 此時由下游決策系統(tǒng)決定是放行還是轉(zhuǎn)人工 metrics.inc(analysis_error); out.collect(new RiskResult(tx.getId(), RiskLevel.UNKNOWN)); }2. 雙活架構(gòu)Active-Active對于核心中的核心我們通常部署兩套完全獨(dú)立的 Flink 集群甚至分布在不同的物理機(jī)房比如上海和北京。Kafka 的數(shù)據(jù)會被鏡像復(fù)制到兩地。兩套 Flink 同時消費(fèi)同時計算。這就帶來了一個棘手的問題重復(fù)告警。如果兩套系統(tǒng)都判定這筆交易是欺詐你的 Redis 里會被寫兩次用戶會收到兩條短信。這顯得很業(yè)余。解決方案分布式鎖或搶占式寫入。在最終寫入 Redis 之前利用 Redis 的SETNXSet if Not Exists指令。集群 A 算出結(jié)果嘗試寫入SETNX alert:tx_12345 FRAUD EX 300。返回 1成功它負(fù)責(zé)發(fā)短信。集群 B 慢了 5 毫秒算出結(jié)果嘗試寫入返回 0失敗它就閉嘴什么都不做。這種架構(gòu)雖然燒錢硬件成本翻倍但它給了架構(gòu)師睡個安穩(wěn)覺的底氣。十、 時光機(jī)回溯與仿真Backtesting這是區(qū)分“玩具系統(tǒng)”和“工業(yè)級系統(tǒng)”的分水嶺。當(dāng)數(shù)據(jù)科學(xué)家訓(xùn)練出了一個新的模型或者風(fēng)控專家想出了一條新規(guī)則例如半夜2點(diǎn)在異地買珠寶 90% 概率是盜刷你敢直接上線嗎一旦誤判攔截了 VIP 客戶在巴黎買鉆戒的交易銀行損失的不僅是手續(xù)費(fèi)更是聲譽(yù)。我們需要仿真Simulation或者叫Shadow Mode暗中觀察模式。1. 影子規(guī)則Shadow Rules在我們的規(guī)則引擎中給每條規(guī)則打一個標(biāo)簽Status: ACTIVE或Status: SHADOW。ACTIVE 規(guī)則命中后輸出BLOCK信號直接阻斷交易。SHADOW 規(guī)則命中后輸出LOG_ONLY信號。交易繼續(xù)通行但在后臺日志里記下一筆“如果剛才用了這條規(guī)則這筆交易就被攔了?！盕link 跑了一周后我們把 Shadow 規(guī)則的命中記錄拿出來和最終用戶的投訴記錄True Labels做比對如果它命中的大部分真的是盜刷Precision 高那就轉(zhuǎn)正。如果它命中了一堆正常人False Positive 高那就打回去重修。2. 歷史數(shù)據(jù)回放Replay有些規(guī)則太緊急等不了一周的影子測試。我們需要立刻知道如果我在上個月用了這條規(guī)則會攔截多少人這就利用了 Kafka 和 Flink 的時間旅行能力。準(zhǔn)備環(huán)境起一個新的 Flink Job邏輯和線上一樣但規(guī)則配置成新的。重置位點(diǎn)在提交 Job 時指定 Kafka 的start-from-timestamp為 30 天前。加速處理線上數(shù)據(jù)是一秒一秒來的但回放時因?yàn)閿?shù)據(jù)已經(jīng)都在 Kafka 里了Flink 可以全速狂奔。本來 30 天的數(shù)據(jù)可能 2 小時就跑完了。這里有一個極其重要的技術(shù)細(xì)節(jié)Event Time。在回放模式下千萬不能用 Processing Time處理時間。 因?yàn)槟闶窃?2 小時內(nèi)跑完 30 天的數(shù)據(jù)如果用 Processing Time所有的Window(1 hour)都會失效因?yàn)閿?shù)據(jù)對于 Flink 來說都是“現(xiàn)在”到達(dá)的。必須嚴(yán)格使用數(shù)據(jù)自帶的時間戳作為 Event Time。這樣Flink 內(nèi)部的邏輯時鐘會隨著讀取的歷史數(shù)據(jù)飛速向前撥動完全復(fù)現(xiàn)當(dāng)時的場景。// 在回放作業(yè)中 env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime); // 此時Watermark 會隨著讀取的歷史數(shù)據(jù)瘋狂上漲 // 所有的窗口計算邏輯與當(dāng)初真實(shí)發(fā)生時一模一樣