原文: https://medium.com/netflix-techblog/re-architecting-the-video-gatekeeper-f7b0ac2f6b00

想法

我們決定部署一個全高密度近場緩存(Hollow)來解決我們的IO瓶頸。對於我們的每個上游系統，我們要建一個能讓Gatekeeper執行這次評估的包括所有數據的Hollow數據集。每個上游系統現在都需要保證它的緩存保持最新。

使用這個模型，活躍性評估將數據從上游系統中隔離出來了。相對於對事件進行響應，Gatekeeper會以一個重覆的周期從遍佈全世界的視頻數據中持續的處理活躍性數據。迭代周期從Netflix的每個視頻上線開始，計算它們的活躍性信息。在每個周期的結束，它產出一個經過計算的表示全世界所有視頻的活躍性明細信息的輸出(包括Hollow數據集)。

我們希望這個持續處理模型是可行的，這樣我們可以徹底移除我們IO上的瓶頸，可以保證操作順序更有效。我們也期望通過遷移到這個模型，我們可以對業務產生更正面的影響。

• 作為對Gatekeeper對上游系統產生的過大的負載的最終解決方案
• 徹底消除活躍性處理的延遲和錯過上線日期的問題。
• 緩解內容配置工程團隊在性能相關問題的時間消耗。
• 改進活躍性處理的可調試性和可見性

問題

Hollow可以被想象為一個時間機器。作為一個數據一直在變化的數據集，通過將變更分成一系列的時間線的數據狀態並將變更發送給消費方。每份數據狀態都表示為整個數據集在當時時刻的一份快照。

通常，Hollow數據集的消費者將載入的最新的數據狀態並將產生的新狀態保存到他們的混存中。當然，它們可能會將狀態替換到之前的樣子 - 導致將整個數據集指向之前的一個狀態。

傳統產生數據狀態的方式是維護一個運行重覆周期的生產者。在一個周期中，生產者從元數據中迭代所有記錄。在迭代中，它對Hollow庫中增加每條數據。Hollow則在之後計算數據的變化併在最後的周期將數據填加上去，將數據狀態發佈到一個已知地址的消費者。

這個基於真實數據源的迭代模型的問題是它可能會需要很長時間。在這個場景中一些我們的上游系統，這需要幾小時。數據傳播延遲是不可接受的 - 我們不能為活躍性處理等待幾個小時，比如，標題運營給電影增加了一個評級並需要立即發佈上線。

改進

我們需要一個更快的時間機器 - 它可以更頻繁的產出狀態，讓消費方可以更快的識別到變化。

為了達到這個目標，我們建立了一套很強的Hollow基礎設施，平衡了之前Hollow library做的工作，與流處理團隊在Target生產環境做的先鋒性工作(現在是公開的非beta的API)

使用這套基礎設施，每次變更都可以在源應用中唄檢測到，更新過的記錄會被編碼併發送給Kafka topic。一個不屬於源應用的新組件，Hollow增量生產服務，以一個預定義的節奏執行一個重覆周期。 在每個周期，它讀取自從上個周期所有增加到topic的消息，並讓Hollow狀態引擎反映出更新過的記錄的最新狀態。

如果一個Kafka topic中的消息包含了已經在Hollow數據集中已經反映出來的相同數據，不會有任何變動。

為了緩解丟失事件產生的影響，我們實現了一套周期性從整個數據集清掃的機制。當它執行時，它將每條記錄的內容發送給Kafka topic。通過這種方式，任何可能丟失的更新都會反映到Hollow數據集上。並且，這不是更新傳播到Hollow數據集上的主要方式，它不需要像傳統Hollow使用方式那樣很快很頻繁的在源上迭代運行。

Hollow增量生產者有從Kafka topic中讀取大量消息並快速轉變成Hollow狀態的能力 - 所以我們可以將這個周期配置的非常短(我們目前的預設配置是30秒)。

這就是我們如何構建一個更快時間機器的方式。現在，如果標題運營給電影增加了一條評級，在30秒內，數據就可以在Hollow數據集上可用。

—

本文來自微信公眾號「麥芽麵包，id「darkjune_think」
轉載請註明。微信掃一掃關註公眾號。
交流Email: [email protected]