Re-Architecting the Video Gatekeeper(一)

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

本文介紹了了內容配置工程團隊使用Hollow，一個Netflix OSS技術，從新架構與簡化咱們內容管道上的基礎組件 - 在流程中交付巨大業務價值。

上下文

每一個在Netflix服務上的電影和秀都被精心處理以提供最佳的觀看體驗。團隊對處理主要負責標題運營(Title Operation)。標題運營會確認，除了：

• 咱們確保合同符合規範 - 咱們爲每一個標題配置的視頻日期時間段與位置是正確的。
• 視頻的標題，字幕，第二音軌都被翻譯並被正確分發到世界各地。
• 標題名與概要均可用並被翻譯。
• 每一個國家都有合適的觀影等級

當標題達到了以上需求的最低要求，它就能夠發佈到服務上上線。Gatekeeper是在Netflix負責評估網站上視頻和資產的「活躍度」。在Gatekeeper批准前標題對於會員是不可見的 - 若是它驗證不了設置，它會指出從客戶體驗基線上缺了什麼來輔助標題運營(Title Operation)。

Gatekeeper經過聚合多個上游系統的數據來完成預處理任務，使用合適的業務邏輯，生產和輸出每一個國家每一個視頻的詳細狀態。

技術

Hollow, 是咱們幾年前發佈的OSS技術。並被描述爲一種靠近緩存的全高密度(total high-density near cache)技術：

• 全：在每一個節點上都緩存着這個數據集 - 沒有驅逐策略，沒有緩存命中丟失。
• 高密度：編碼，解碼，反重複技術都被用來數據集上的內存指紋。
• 靠近：在每一個須要存取數據集的實例上都有RAM上的緩存。

對於這個全(total)技術有一個使人興奮的內容 - 由於咱們不須要擔憂清除內存中的數據項，咱們能夠對內存中的數據集展現作一些假設與預計算，沒有這個特性是不可能的。結果是，對許多數據集，提升了很大的內存使用效率。而在傳統的部分緩存方案上你可能會想是否你只緩存了5%的數據集，或者你須要被10%保留足夠的空間用來獲得一個可接受的命中/丟失率 - 使用一樣的內存Hollow能夠緩存100%的數據集數據並獲得100%的命中率。

很明顯，若是你有100%的命中率，你能夠消除全部訪問你數據的IO需求 - 並能夠更有效的提升數據訪問效率，能夠開啓更多可能性。

現狀

在不久之前，Gatekeeper是一個徹底的事件驅動系統。當任何上游系統對視頻有改動，系統會發送給Gatekeeper發送一個事件。Gatekeeper會對那條事件進行響應，進入每個它的上游服務，收集必要的輸入數據來評估視頻與它的對應資產的活躍性。它會產生一條輸出記錄來輸出這條視頻的詳細狀態。

這個模型有一些相關的問題：

• 這個進程徹底與IO綁定，並對上游系統產生了很大的負載。
• 所以，這些事件會將一天的吞吐隊列化併產生處理的延遲，致使標題的處理不能及時的上線。
• 更壞的，事件可能偶爾丟失，這將致使標題不能上線，知道某一個標題運營人員發現可能有問題。

爲了減輕這些問題能夠「清掃」目錄讓視頻能夠匹配特定的查詢條件(好比，計劃下週上線)可讓事件自動注入處處理隊列中。不幸的是，這種方式會往隊列中增長更多的事件，會使問題更加惡化。

很明顯，頗有必要改變方向。

---

本文來自微信公衆號「麥芽麪包，id「darkjune_think」轉載請註明。微信掃一掃關注公衆號。交流Email: zhukunrong@yeah.net