引言

性能優(yōu)化是個恒久的話題，隨著產(chǎn)品的演進(jìn)，業(yè)務(wù)的增長，系統(tǒng)能力總有達(dá)到瓶頸的一天，它不可或缺的陪伴著我們走向壯大再走向衰敗，是我們面臨的不可回避的問題。下圖1展示了風(fēng)控系統(tǒng)近半年來承載流量的增長趨勢，可見最近半年來流量高速增長，且對于可預(yù)見的未來而言，接入流量還會持續(xù)高增。伴隨著流量的增長，系統(tǒng)各方面--存儲、計算、IO等都表現(xiàn)出一定的瓶頸，通過原始簡單的水平擴(kuò)容并不能解決所有的問題，而且還會帶來成本的上升。因此，我們近期對系統(tǒng)進(jìn)行了一系列優(yōu)化改造， 目的是滿足未來一段時間內(nèi)業(yè)務(wù)的增長使用，降低接口的耗時滿足某些延時敏感型業(yè)務(wù)的需要，同時也伴隨著一定的IT成本優(yōu)化。本文結(jié)合常見的性能優(yōu)化手段(預(yù)取、批量、異步、壓縮、緩存)，及在風(fēng)控系統(tǒng)中的實踐進(jìn)行總結(jié)，希望能給讀者對于性能優(yōu)化實踐帶來一些參考。

圖1：風(fēng)控引擎流量增長趨勢

預(yù)取——特征預(yù)計算

預(yù)取作為一種提速手段，通常與緩存搭配使用，在緩存空間換時間的基礎(chǔ)上更進(jìn)一步，以時間換時間，通過預(yù)加載來提升性能。常見的使用有，數(shù)據(jù)庫從磁盤加載頁時的預(yù)讀多個頁減少磁盤IO、CPU緩存加載一片連續(xù)的內(nèi)存空間提高計算的速度，也就是我們常說的CPU對數(shù)組友好對鏈表不友好的原因。

在Gaia風(fēng)控引擎中，一次業(yè)務(wù)請求在引擎內(nèi)部的執(zhí)行流程如下圖2所示，會經(jīng)歷場景因子(特征)->規(guī)則->決策的計算過程， 而計算因子是整個鏈路最耗時的部分，通常占請求響應(yīng)時間的70%以上，包括對賬號信息、名單庫、模型數(shù)據(jù)、用戶畫像、設(shè)備指紋、三方特征等多個下游的讀擴(kuò)散–特征因子獲取，加上場景的上百條規(guī)則執(zhí)行，請求耗時常規(guī)在250ms左右，這也是22年中以前我們承諾給主站大部分業(yè)務(wù)的響應(yīng)時間，直到電商業(yè)務(wù)的接入，對我們引擎的響應(yīng)時間提出了100ms以內(nèi)響應(yīng)的要求，迫使我們對引擎進(jìn)行了一些優(yōu)化，其中之一就是近線引擎帶來的特征預(yù)取優(yōu)化，其演進(jìn)流程如下圖3示：

圖2：風(fēng)控引擎一次請求執(zhí)行過程

圖3：風(fēng)控特征獲取流程

基于一個前提：對同一個主體，按照其行為時序數(shù)據(jù)消費(fèi)，slb數(shù)據(jù)源消費(fèi)處理完成大多數(shù)時候都要比業(yè)務(wù)請求風(fēng)控早。因此，我們通過對slb實時流數(shù)據(jù)消費(fèi)預(yù)讀取下游特征，并將結(jié)果緩存在redis中，當(dāng)業(yè)務(wù)請求風(fēng)控時，直接獲取redis的數(shù)據(jù)，避免或減少rpc回源特征，以此來降低風(fēng)控接口的耗時。

通過這套機(jī)制，我們按照特征變動頻率對特征分層設(shè)置不同的緩存時間，同時在一些對數(shù)據(jù)一致性要求較低的場景對特征開啟緩存讀，其緩存命中率能達(dá)到90%以上，核心業(yè)務(wù)場景如電商交易，接口響應(yīng)耗時從80ms下降到25ms。

圖4：特征緩存命中率

圖5：電商交易場景請求風(fēng)控接口TP99耗時曲線圖

批量——特征批量獲取

批量一般是對I/O操作的優(yōu)化，同樣可看作是時間換時間，通過合并、批量進(jìn)行讀取或?qū)懭胍詼p少對I/O的操作來提升吞吐和性能。常見的使用有，kafka消費(fèi)數(shù)據(jù)的時候批量拉取指定的數(shù)據(jù)條數(shù)，mysql寫入redolog/binlog時的組提交(group commit)機(jī)制，都是通過批量的優(yōu)化來減少I/O提升性能的。

在Gaia引擎中最常用的特征為對賬號管控/風(fēng)控名單值的獲取，一次業(yè)務(wù)風(fēng)險判斷請求會涉及到對請求主體(mid、buvid、ip、ua)的各種黑/白名單值獲取，以主體mid為例，往往會并發(fā)調(diào)用下游名單接口多次，判斷mid是否在同設(shè)備多賬號黑名單、虛假賬號黑名單、通用白名單等名單中，從而形成不同的因子供規(guī)則使用，這種方式就會造成對同下游的同接口的讀擴(kuò)散流量放大浪費(fèi)資源，且要保持下游接口低延遲往往需要下游進(jìn)行擴(kuò)容保證CPU等資源使用率在一定的水位以下。因此，為了降低自身及下游的服務(wù)資源和I/O，優(yōu)化的手段就是將多次請求合并為一次請求，其優(yōu)化流程如下圖6所示：

圖6：名單類因子讀取優(yōu)化流程

通過將多次獨(dú)立下游請求獲取給定黑/白名單轉(zhuǎn)化為一次批量請求獲取主體所有有效名單，同時結(jié)合本地內(nèi)存判斷因子請求名單與所有名單是否有交集來實現(xiàn)原有相同的功能，并通過local cache及singleflight優(yōu)化，降低對下游接口調(diào)用量69%。

圖7：實驗環(huán)境名單庫接口批量優(yōu)化效果

異步——累積因子同步改異步計算優(yōu)化

異步通常和同步一起對比，其區(qū)別在于發(fā)起請求之后是立即返回還是等待結(jié)果，常用于在系統(tǒng)內(nèi)部有大量I/O操作時，通過異步提升吞吐。常見的使用有，基于write-back模式向緩存寫入數(shù)據(jù)，mysql異步傳輸binlog進(jìn)行主從復(fù)制等。

在Gaia引擎中，一次請求會涉及對很多特征因子的計算，其中，最常用的是基于redis實現(xiàn)的累積因子，其包含如下幾種類型(見表1)，以count(distinct)類型為例，一次計算過程包含1寫zadd，1讀zcount，概率觸發(fā)zrem清除不在有效時間窗口內(nèi)的過期數(shù)據(jù)，其最多對redis請求3次，最少/均攤2次，且zset這幾個操作的時間復(fù)雜度都在O(log n)以上，加上一次請求往往會對多個累積因子進(jìn)行計算(讀寫擴(kuò)散)，這給redis集群帶來了較大的計算壓力，由于overload對集群實例擴(kuò)容的限制，我們對redis集群的水平擴(kuò)容也遇到了瓶頸。考慮當(dāng)前引擎流量的情況：爬蟲類業(yè)務(wù)與常規(guī)業(yè)務(wù)流量占比為1.5:1，且爬蟲類業(yè)務(wù)流量還在持續(xù)高漲，鑒于爬蟲類業(yè)務(wù)風(fēng)控的特性(非資產(chǎn)安全，容忍一定的漏過)，我們以犧牲數(shù)據(jù)一致性為代價，對爬蟲類業(yè)務(wù)的累積因子進(jìn)行了異步計算優(yōu)化，以減少對redis的調(diào)用，其計算演進(jìn)流程如下圖8所示：

表1：風(fēng)控引擎支持累積因子類型

圖8：累積因子計算(優(yōu)化前/后)流程

基于railgun（關(guān)于B站自研異步事件處理平臺,可參閱：從1到億，如何玩好異步消息？CQRS架構(gòu)下的異步事件治理實踐）提供的內(nèi)存隊列聚合功能，我們對累積因子寫操作進(jìn)行了異步化改造，并結(jié)合聚合功能，在設(shè)置的時間/數(shù)量閾值條件下，對相同累積key進(jìn)行聚合并在內(nèi)存中去重后批量寫入redis，將多次同步redis I/O減少為異步寫1次。而優(yōu)化的效果從三個角度評估，從成本角度看：其對redis的調(diào)用qps減少了35%以上(如圖9)；從接口耗時看：TP99有一定的下降; 從對風(fēng)控規(guī)則的召回影響看，前后召回趨勢基本一致，且打擊總量差距不大，在可接受的范圍內(nèi)。

圖9：單場景累積因子計算優(yōu)化前/后對redis的調(diào)用量情況

圖10：累積因子計算優(yōu)化前/后接口耗時情況

圖11：累積因子計算優(yōu)化前/后規(guī)則召回的情況

壓縮——日志存儲優(yōu)化

壓縮是常見的用于數(shù)據(jù)傳輸、持久化等過程中減少帶寬、存儲占用的方法，本質(zhì)是通過編碼的方式提高數(shù)據(jù)密度，減少數(shù)據(jù)的冗余度，一般以數(shù)據(jù)壓縮速度和壓縮率兩個指標(biāo)來衡量壓縮過程的效能。常用的無損壓縮方式有：gzip、xz、lz4、zlib、zstd等。

對于風(fēng)控業(yè)務(wù)來說，每一次風(fēng)控請求會產(chǎn)生包含輸入?yún)?shù)、計算詳情（計算規(guī)則、特征因子等中間結(jié)果的快照）、打擊決策等多個維度的日志數(shù)據(jù)。我們需要提供準(zhǔn)實時的查詢能力，用于輔助人工判定風(fēng)控決策的召回和誤傷等情況。由于一次風(fēng)控分析可能經(jīng)歷了上百條規(guī)則、上千個特征的計算，單條日志數(shù)據(jù)的平均大小達(dá)到了11KB左右，最大的高達(dá)幾十KB?；陲L(fēng)控日志的特點，我們把常用特征值（mid、buvid、ip等）和日志主體精簡出來，使用ES存儲并提供關(guān)鍵字查詢。其他詳情（參數(shù)、中間結(jié)果等）則依托于B站自研的KV存儲taishan KV，以請求traceId為key進(jìn)行g(shù)zip壓縮后存儲。查詢時先基于ES查詢?nèi)罩局黧w，再對分頁記錄點查日志詳情并合并展示，其流程如圖12所示。這些優(yōu)化幫助風(fēng)控度過了22年之前接入場景大量增長的階段，但隨著持續(xù)接入反爬蟲等大流量讀場景與降本增效帶來的雙重壓力下，風(fēng)控日志存儲陷入了瓶頸。

圖12：舊風(fēng)控日志詳情存儲與查詢過程

以taishan KV存儲的日志詳情為例，總存儲達(dá)到了16TB左右。因此，我們期望能夠利用壓縮率更高的編碼方式和壓縮算法替代json+gzip的組合，進(jìn)一步優(yōu)化日志存儲。通過調(diào)研常見壓縮算法，結(jié)合日志詳情無壓縮速度要求的特點，我們采集了線上真實日志作為實驗集，選取了protobuf、msgpack等編碼方式和xz、zstd兩種算法進(jìn)行了多次對比實驗。

在第一輪實驗中，我們對比了單條日志在不同編碼方式下不同壓縮算法的壓縮率。實驗隨機(jī)取同一場景下任意一條日志詳情進(jìn)行編碼和壓縮，重復(fù)多次后取各階段數(shù)據(jù)長度平均值。其中，由于風(fēng)控日志包含了許多嵌套和非固定結(jié)構(gòu)，難以使用protobuf等需要預(yù)定義結(jié)構(gòu)的序列化方式。因此我們嘗試了另一種高效的通用序列化框架msgpack。結(jié)果如表2所示。從結(jié)果上看，msgpack雖然編碼后比json更簡短，但由于產(chǎn)生了許多非文本結(jié)構(gòu)，最終壓縮率不及json。xz算法由于壓縮率無明顯優(yōu)勢且內(nèi)存占用較大而被棄用（圖13）。無字典模式下的zstd壓縮率略弱于gzip。

表2：風(fēng)控日志在不同編碼方式、壓縮算法下的壓縮效果（單位：字節(jié)）

圖13：各壓縮算法壓縮風(fēng)控日志的內(nèi)存占用

在第二輪實驗中，我們使用json編碼方式，對比了gzip和zstd有無字典兩種模式下的壓縮率。其中，字典1由1萬條UAT爬蟲場景日志訓(xùn)練獲得，與線上日志差異較大。字典2由10000條線上爬蟲場景日志訓(xùn)練。首先是單條日志壓縮時不同zstd字典的影響，如表3所示。結(jié)果上，不使用字典時壓縮率最差，使用不匹配的字典略有提升。而使用匹配的字典后，zstd的壓縮率有顯著的提高。然后是對爬蟲場景不同數(shù)量的日志進(jìn)行批量壓縮對壓縮率的影響，如表4所示。zstd在小日志壓縮上使用匹配的字典壓縮效率較好，隨著每批次數(shù)量增多，壓縮率會相對降低，最終與gzip相當(dāng)。批量壓縮能夠顯著提高兩種算法的總體壓縮率，但單次超過10條以后遇到了邊際效應(yīng)，收益急速降低。此外，我們基于任意單條日志進(jìn)行了多輪性能測試，表5展示了其中5輪測試結(jié)果。從壓縮性能角度分析，無論是否使用字典，zstd壓縮的效率都遠(yuǎn)超過gzip。

表3：風(fēng)控日志詳情在zstd算法下使用不同字典的壓縮效果

（單位：字節(jié)）

表4：不同數(shù)量的日志壓縮后數(shù)據(jù)大小總和與壓縮率對比（單位：字節(jié)）

表5：風(fēng)控日志在gzip與zstd算法壓縮性能對比（單位：ns/op）

綜合以上實驗，雖然zstd算法在壓縮效率上遠(yuǎn)優(yōu)于gzip，但僅在使用匹配的字典集時，對單條日志的壓縮率遠(yuǎn)優(yōu)于gzip。另外，無論哪種壓縮算法都在批量壓縮中收益明顯，最高能夠減少60%的存儲。最后，由于我們對壓縮效率的需求較低，且訓(xùn)練zstd字典等改造成本較大等原因，我們選擇對現(xiàn)有的風(fēng)控日志詳情進(jìn)行批量壓縮改造(圖14)。實現(xiàn)上，基于railgun提供的聚合隊列功能，我們將消費(fèi)的日志分成n條若干批次，分配一個批處理ID(BatchId)并存儲到日志主體中，日志以BatchId為key批量gzip壓縮后存入taishan KV。查詢時，獲取分頁下待查的BatchId，去重后批量從taishan KV拉取數(shù)據(jù)，解壓后合并到日志中。對于查詢效率，最差情況下，每個BatchId都沒有去重，即每條數(shù)據(jù)多查詢了n-1條，請求數(shù)量不變，數(shù)據(jù)量變大N倍。實際查詢中，由于大多數(shù)查詢結(jié)果都是同一時段的連續(xù)數(shù)據(jù)集，因此實際去重效果較好，查詢效率略有提升。從存儲優(yōu)化上看，taishan KV寫入QPS由8k下降至1k左右，每秒寫入量由78MB下降為55MB，降幅約30%。表存儲TTL為7天，7日存儲下降約6TB，降幅約38%。

圖14：風(fēng)控日志詳情批量存儲與查詢過程

緩存——多級緩存+布隆過濾器

緩存是最常見的加速數(shù)據(jù)交換的技術(shù)，通?；趦?nèi)存等高速存儲器實現(xiàn)，其本質(zhì)就是用空間換時間，犧牲一定的數(shù)據(jù)實時性，以減少各類IO的頻率，提升整體響應(yīng)速度。常見的緩存方案包括Cache Aside、Read/Write Through、Write-back等，適用于不同的業(yè)務(wù)場景。

在Gaia引擎中，名單庫服務(wù)是風(fēng)險特征判斷的重要組成部分，采用了最常用的Cache Aside模式。名單庫服務(wù)的需求是一種經(jīng)典的讀多寫少場景：引擎將分屬不同名單的風(fēng)險主體持久化存儲（100QPS以下），同時提供接口查詢指定主體是否屬于某一名單（上萬QPS）。因此，初期的名單庫采用了localCache+Redis Cache+MySQL存儲的模式實現(xiàn)查詢過程：寫入時刪除緩存，查詢時依次查詢Cache，直到回源DB查詢，并將實際值或空值寫入Cache。這一模式在低流量條件下表現(xiàn)優(yōu)異，直到風(fēng)控接入流量急速增長至十萬以上時，出現(xiàn)了越來越多的瓶頸問題，如：Redis CPU負(fù)載高、內(nèi)存占用高、DB回源超時等，DB存儲的名單個體數(shù)目也超過了3千萬并且持續(xù)快速增長。這迫使我們做了許多優(yōu)化來滿足后續(xù)潛在的百萬級QPS查詢需求。其中最有效的就是布隆過濾器（Bloom Filter，BF）多級緩存優(yōu)化，具體的優(yōu)化過程如圖15所示。對于寫過程來說，新增更新服務(wù)訂閱了名單表的binlog，提供BF的全量/增量更新。對于讀過程來說，在原有多級緩存前新增BF Cache查詢，在確認(rèn)特征不存在的情況下直接返回結(jié)果。

圖15：名單庫服務(wù)BF多級緩存優(yōu)化過程——新老流程對比

由于名單庫查詢時，大多數(shù)用戶并無風(fēng)險，名單庫查詢存在普遍的緩存穿透問題。因此名單庫查詢天然配適BF的使用場景，但要實際落地，仍然面臨著許多問題：

1. HotKey和BigKey問題。由于全集記錄超過3千萬條，單個BF容量越大，value越大，越容易出現(xiàn)集中訪問同一個key的熱點問題。因此需要對BF進(jìn)行合理的拆分。
2. 維護(hù)問題。BF需要維護(hù)一個全集數(shù)據(jù)，因此無論是本地還是分布式實現(xiàn)，都需要具備基于全量數(shù)據(jù)構(gòu)建的能力。從數(shù)據(jù)安全性角度出發(fā)，BF存在人為操作等導(dǎo)致非預(yù)期異常的可能，BF需要具備備份和快速恢復(fù)能力。
3. 數(shù)據(jù)一致性問題。一方面，由于BF能夠確定的表述一個key不存在于全集中，因此需要保證DB與BF的最終一致性。為了保證新記錄一定存入BF，插入BF需要支持無限重試。另一方面，由于BF存在假陽率，且不能刪除個體，隨著名單過期、key數(shù)量逼近BF容量等情況的發(fā)生，BF實際假陽率會逐級升高導(dǎo)致過濾效果變差。因此需要支持BF容量擴(kuò)充和實現(xiàn)定期重建的能力。

由于Redis布隆過濾器插件完整的支持了BF的操作和自動擴(kuò)容，我們選擇使用Redis作為BF的分布式實現(xiàn)。對于HotKey和BigKey問題，我們對BF進(jìn)行了隨機(jī)分片。為了保證BF Key分布均勻，人為的將分片總數(shù)BF_SLICE_SIZE定義為4倍Redis Slot數(shù)量，即65536個。每一個分片Key的命名格式為"{libKey_bf_" + sliceIndex + "}"，其中sliceIndex為分片序號，使用花括號來保證相同前綴的BF利用rename命令迭代替換時處于同一個Slot中。名單個體將按照sliceIndex = HashKey % BF_SLICE_SIZE計算自己所屬的分片，其中HashKey的取值為名單個體值的IEEE CRC32絕對值。此外，我們對BF設(shè)置了獨(dú)立的本地緩存以減少實際調(diào)用。由于BF只增不減的特點，對于陽性結(jié)果，我們設(shè)置了較長TTL。而對于陰性結(jié)果，則按業(yè)務(wù)容忍度設(shè)置了秒級TTL，保證及時獲取新插入個體。

對于維護(hù)問題，我們實現(xiàn)了完整的構(gòu)建工具。同時，基于安全性考慮實現(xiàn)了備份和快速恢復(fù)流程。基于狀態(tài)機(jī)，我們定義了BF的構(gòu)建過程：初始化、異步構(gòu)建、同步測試、BF更新等。整個構(gòu)建過程使用分布式鎖保證唯一性，基于railgun定時任務(wù)周期性觸發(fā)，整個過程記錄構(gòu)建進(jìn)度并提供實時展示和查詢。全過程如圖16所示。初始化時，會Dump生成正在運(yùn)行的BF備份文件并存儲到對象存儲。生成新的BF臨時分片，以"_temp"尾綴區(qū)分。更新服務(wù)基于狀態(tài)變化將增量個體雙寫到臨時BF中。異步構(gòu)建過程會分批獲取完整的名單表，批量寫入存量個體到臨時BF中。之后進(jìn)行同步測試，利用少量增量和存量個體模擬查詢臨時BF，當(dāng)所有測試個體都存在于BF時通過測試。最后，將臨時BF原子性地替換正式BF，完成構(gòu)建過程。快速恢復(fù)過程基于構(gòu)建的整體流程，部分模塊略有差異：初始化階段會獲取備份文件并嘗試restore數(shù)據(jù)到臨時BF中。異步構(gòu)建時則基于備份時間點開始獲取存量數(shù)據(jù)。

圖16：BF構(gòu)建與快速恢復(fù)流程

對于數(shù)據(jù)一致性問題，我們提供了完整的控制、評估和測試BF一致性的流程。為了保證數(shù)據(jù)安全，我們定義了BF測試模式和正常模式兩種運(yùn)行方式，并可以按比例配置運(yùn)行，如圖17所示。測試模式下，查詢的BF值不會生效，流量進(jìn)入緩存查詢流程。之后基于查詢實際值對比結(jié)果進(jìn)行監(jiān)控報點并建立真陰性比例四個9等監(jiān)控告警。處于正常模式則會對BF假陽等情況進(jìn)行報點等。實際上線后，服務(wù)長期保持一定比例的流量（當(dāng)前為0.1%）運(yùn)行測試模式，用于持續(xù)評估線上BF運(yùn)行狀態(tài)。圖18展示了BF查詢結(jié)果占比，約95%的查詢?yōu)殛幮?，?yōu)化收益明顯，如表6所示。在后續(xù)壓測中，名單庫服務(wù)具備了支撐百萬級流量的能力。

圖17：名單庫服務(wù)BF多級緩存優(yōu)化過程

圖18：名單庫服務(wù)線上流量BF查詢結(jié)果占比

表6：名單庫BF多級緩存優(yōu)化收益對比

總結(jié)

性能優(yōu)化的手段有多種方式，本篇文章只是結(jié)合近期在風(fēng)控系統(tǒng)中的應(yīng)用實踐進(jìn)行的一個總結(jié)，需要說明的是，其中有的優(yōu)化手段有利也有弊，得到的同時也在失去，可見，任何優(yōu)化手段都得以業(yè)務(wù)可接受為前提，因地制宜才是正道。正如Linux性能優(yōu)化大師Brendan Gregg一再強(qiáng)調(diào)的：切忌過早優(yōu)化、過度優(yōu)化。