高頻增量告警查詢中的輕量級區間LRU緩存方案

一、需求背景：高性能告警查詢

在告警監控場景中，值守人員經常需要按時間段查詢告警列表或其它相關信息。尤其在需要進行實時分析的自動化告警評估和推薦業務中，由于需要對時間段內全部告警進行評估，如果每次都要從數據庫中加載完整數據，會產生很高的I/O負載，響應速度也不盡如人意。

安全事件應急響應分秒必爭，系統能否及時處理用戶的高頻查詢請求，不僅影響用戶操作體驗，更是決定應急處置速度的關鍵因素，不容疏失。

二、現有技術瓶頸

既然問題出在高頻查詢的I/O性能上，我們可能需要某種數據緩存機制來應對它。

但經初步調研，現有的常規緩存算法大多針對Key-Value鍵值對型結構，但在安全運營場景中的告警查詢通常是以時間段為條件的，難以直接應用。

講到這里，可能有的讀者會問，如果只是為了解決時間段查詢需求與鍵值緩存算法不匹配的問題，可以簡單地將告警數據按一定時間周期進行切片并緩存，然后在每次查詢時對查詢目標范圍所涉及的所有切片進行查詢，再去掉兩端可能多余的部分即可。

但這樣一來，就會面臨一個兩難問題：

1、如果選擇較大的切片長度，那么當實際查詢片段較小或較為分散時，就會浪費很多資源。例如切片長度為1小時，若要查詢某5分鐘內的告警而未命中緩存，就不得不為此加載1小時的數據（甚至2小時，如果查詢目標時間段剛好跨過分片邊界的話），這極有可能導致添加緩存機制后的整體性能不升反降；

圖1：長分片鍵值緩存響應區間查詢

2、如果選擇較小的切片長度，那么當實際查詢片段較長時，就需要多次查詢索引并加載緩存。例如切片長度為1分鐘，若要查詢某一天內的告警而未命中緩存，就需要執行多達1440次索引查詢和加載。尤其對于使用哈希索引的緩存來說，這同樣會導致查詢性能低下。

圖2：短分片鍵值緩存響應區間查詢

此外，由于在很多實際場景中，現場未必能夠提前部署高性能設備，導致告警評估系統經常需要安裝在現場人員的筆記本電腦上，這就要求系統需要盡可能降低部署成本，避免依賴過于大型的外部組件。

綜上，針對鍵值對結構的緩存系統確實不適合安全防守中需要高性能響應區間查詢的場合。

三、實現思路

其實從上面的案例可以看到，緩存機制本身并沒有問題，普通的基于鏈表的LRU緩存方案等都是可以的，只是常規緩存的索引結構（哈希表或二叉樹等）不適配區間查詢的場景。

那么重點就在于如何構建適合區間查詢的索引了。一般想來，最適合這個場景的應該是區間樹了，但初步實驗中又遇到了問題：

由于告警查詢最常見的場景就是“不斷查詢最新一定時間的告警”，導致區間樹總是沿右子樹方向生長，深度急劇增加。下圖為模擬從1:00起每10分鐘一次查詢最近1小時告警的情況，可見區間樹很快就變成了一個效率低下的形狀：

圖3：其中橙色節點是包含實際數據的葉節點

但是，區間樹不同于常規二叉樹，只有葉節點包含數據，實現旋轉操作時需要修改枝節點的區間邊界（而非簡單交換節點父子關系），與常規的平衡二叉樹略有不同：

圖4：平衡區間樹的旋轉過程

至此，區間緩存結構最關鍵的部分就已經實現完畢了。關于LRU緩存算法的其余部分，以及數據合并切分的具體實現，由于與現有常規方法沒有什么區別，本文不再贅述。

四、效果測試

我們接下來嘗試查詢1個小時的告警，可見此時緩存為空，實際耗時與沒有緩存機制時基本相同，包含評估過程共耗時約36秒，其中數據加載消耗約28秒：

圖5：初次查詢的時間開銷

然后再次提交完全相同的查詢，可見總耗時迅速縮短到了約7秒，其中數據加載耗時基本可以忽略：

圖6：再次查詢的時間開銷

但普通緩存結構顯然也能做到這一點。接下來我們將查詢時間段向后移動10分鐘，可見實際需要加載的數據只有多出來的10分鐘部分，數據加載僅耗時8秒：

圖7：增量查詢的時間開銷

可見緩存結構確實能夠極大提高告警數據區間查詢的時間效率。

五、后記

系統性能優化的道路仍然漫長，點滴積累，貴在堅持。

更多前沿資訊，還請繼續關注綠盟科技研究通訊。

如果您發現文中描述有不當之處，還請留言指出。在此致以真誠的感謝~