引言
性能調優也是有跡可尋的,本文梳理了在實際開發程序中沉淀的通用性能優化策略,并且結合風控系統服務內使用場景,幫助讀者理解性能調優相關可行策略,從而建立性能優化 SOP 概念,以后出現問題即可參照優化流程改造即可,
性能優化策略

時空轉換
刷過演算法題目的都知道評分條件有:時間復雜度、空間復雜度,兩樣消耗都很小的話,評分越高,即優秀的演算法,
但在實際開發程序中,一般二者不可兼得,要么占用空間小運行時間長一點,要么追求效率則占用空間就多一點,我們要做的就是在特定的需求場景中,極力優化其中的一方,此時往往需要犧牲另一方來達到目的,
空間換時間
在當前業務場景下,追求的是極致性能,即回應速度要足夠快,比如開屏頁的打開速度,如果每次打開 H5 都去服務端請求頁面的渲染資料,再加上用戶所在城市不同,從紐約用戶訪問北京,比北京本地用戶訪問肯定慢很多,那此時就有了 **CDN **這種工具,運營商的 CDN 節點遍布全球,頁面在開發完畢后,直接推送到全球各地的 CDN 中快取起來,這樣用戶訪問時只需要命中最近的 CDN 節點,速度自然而然就上去了,但是付出了空間的成本,

在風控場景內也有類似場景,決策引擎為了極致性能,也需要空間換取時間:
- 配置資料快取:決策流資料關聯復雜,如果每次都去和 DB 或者資料中心互動,I/O 耗時大,得不償失,本地快取一道 + 更新觸發反而是更好的選擇,
- 短期快取:熱點資訊且在一段時間內不會改變的(或者能容忍一段時間不變的),接入快取會更利于查詢速度,
時間換空間
此策略反其道而行,用時間換取空間,此時,“空間比較寶貴”,比如記憶體相對于磁盤來說就很寶貴,但是存放在磁盤內再調度起來使用時,需要一定的時間來獲取,

在風控場景內,同樣存在很多場景:
- 節省空間成本:“云上”服務器相對“云下”自建 IDC 機房是更貴的空間資源,所以風控將大量非實時的資料放在云下服務器計算,云上服務需要用的時候,需要付出一定的呼叫時間即可:跨機房呼叫(專線帶寬爭搶占用)需要額外多消耗 5~10 ms
- 設備指紋采集資料壓縮上傳:風控依賴設備指紋,設備指紋是內嵌在應用 APP 內采集機器本身資訊的 SDK,大量的設備資訊如果不壓縮上傳會占用很多帶寬,影響占用了正常的用戶請求,壓縮后,節省了空間,但是付出的代價就是,每次都需要額外付出壓縮/解壓的耗時,
預處理/后處理
提前處理
預處理主要是為了提速,比如 CPU 和記憶體的預取操作,將記憶體中的指令和資料,提前存放到快取中,從而加快執行的速度,
決策引擎為了保證策略的執行 RT 控制到 200ms 內,需要優化壓縮執行策略的時間,假設一個策略再怎么優化,執行時間也是超過 200ms 的,那此時可以在上一個事件(場景)提前觸發預處理操作,
舉例:用戶發單時需要判定群組風險,但訪問群組是比較耗時,那可以在用戶進入發單前先觸發查詢群組資訊并緩住,真正發單時直接讀取上次結果即可,同樣的,我們可以在用戶登錄時觸發一些操作,利于后續風控事件感知,
延后處理
不到必要時刻堅決不執行,節省成本,運用這一策略最有名的例子,就是 COW(Copy On Write,寫時復制),假設多個執行緒都想操作一份資料,一般情況下,每個執行緒可以自己拷貝一份,放到自己的空間里面,但是拷貝的操作很費時間,系統如果采用惰性處理,就會將拷貝的操作推遲,如果多個執行緒對這份資料只有讀的請求,那么同一個資料資源是可以共享的,因為“讀”的操作不會改變這份資料,當某個執行緒需要修改這一資料時(寫操作),系統就將資源拷貝一份給該執行緒使用,允許改寫,這樣就不會影響別的執行緒,

延后操作在風控中主要為了節省成本,決策引擎為了極致的性能,很多變數(或者叫特征/指標)都是一次性并行加載的,但此時有的變數是第三方收費指標,比如 IP、同盾、蟻盾等,預加載的好處顯而易見,但是也極大的增加了成本:用戶有可能還未走到付費變數決策節點時就被拒或者白名單直接通過,此時這部分用戶提前請求三方就是極大的浪費,只有真正走到付費策略時,才會去請求,此時成本最小,
并行/異步操作
并行
一個人干不完的活,那就多找幾個人一起干!并行操作,處理效率高(前提是機器多核心),時間大大縮短,極大縮短了 RT 時間,絕大多數互聯網服務器,要么使用多行程,要么使用多執行緒來處理用戶的請求,以充分利用多核 CPU,另外一種情況就是在有 IO 阻塞的地方,也是非常適合使用多執行緒并行操作的,因為這種情況 CPU 基本上是空閑狀態,多執行緒可以讓 CPU 多干點活,

決策引擎如果執行策略都是同步執行的話,幾分鐘可能都執行不完,運用并行,充分發揮 CPU 多個核心的性能,那么此時性能瓶頸就是最長的那塊木板,只要專攻優化它就好了,
異步
異步相對同步來說,就是是否等待結果還是立即回傳,同步操作在碰到內部有大量 I/O 操作時,性能損耗極大,此時采用異步操作,系統的吞吐行會有極大的提升,但是有利有弊,異步操作也增加了程式的復雜度,需要考慮失敗補償等額外的操作,
此類場景在風控系統中也是隨處可見:
- MQ 訊息:天然的異步處理,依托于訊息消費機制削峰填谷特性,在大耗時操作動作,且業務不需要同步回傳情況下,非常適合用訊息來處理,比如離線決策,
- 埋點、監控采樣:不在業務關心的流程內發起的操作,為了不影響 RT,需要將額外的操作異步處理,
快取/批量合并
資料快取
快取的目的就是為了加速,這個我們從學習程式語言開始就基本達成的共識,基本上各個系統內只要有性能考慮的,多少都會用到快取,我們常用的一些工具,也穿插了快取的影子,比如:
- IOC 控制反轉:不僅僅是依賴注入,同時也節省了創建 bean 的時間
- 執行緒池中活躍執行緒:池化概念目的是增速,池本身就是一個快取容器,頻繁的創建池內物件,得不償失,此時固定一批在池內,用完即還,極大的避免了創建新物件的開銷,

批量合并處理
批操作一般是遇到 I/O 操作時才會使用,一次性盡量多的查詢到多的資料,減少網路耗時時間(注意,這不是絕對,思考一下為何需要分頁,在時間和空間找平衡),
常見批操作如下:
- 資料庫查詢批處理:在處理多條資料時一次性 in 查詢出來,避免頻繁的單潭訓圈查詢
- redis 掃描資料:可以使用 scan 類命令,而不是頻繁的 get (注:會造成 redis hold 住,需要平衡 key 的個數)
總結
性能調優可以有多種手段,有時從不同的角度,能發揮奇效,當然前提是得在業務可接受的成本內,不考慮實際是不切實際的,
如上介紹的性能調優策略,這些是在日常開發程序中總結思考沉淀的,希望能夠幫助讀者建立一個性能優化 SOP,能有通用的摸排手段,做到用時心中有數,
往期精彩
- 風控決策引擎——決策流構建實戰
- 從 0 到 1 智能風控決策引擎構建
- 我是怎么入行做風控的
歡迎關注公眾號:咕咕雞技術專欄
個人技術博客:https://jifuwei.github.io/

參考:
- 20-性能優化十大策略:如何系統地有層次地優化性能問題
- 常見性能優化策略的總結
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/517789.html
標籤:架構設計
下一篇:計算多列的對值?
