Re-Architecting the Video Gatekeeper(二)

原文: https://medium.com/netflix-te...

想法

咱們決定部署一個全高密度近場緩存(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: zhukunrong@yeah.net