前言
對於應用程序來說，使用多個數據存儲是一種常見的模式，其中每個數據存儲都用於滿足特定的需求，如存儲形式化數據（MySQL等）、提供高級搜索功能（ElasticSearch等）、緩存（Memcached等）等等。通常，在使用多個數據存儲時，其中一個用作主存儲，其他用作次存儲。現在的挑戰是如何保持這些數據存儲的同步。
我們已經觀察到了一系列不同的模式，試圖解決多數據存儲的同步問題，比如雙寫、分佈式事務等等。然而，這些方法在可行性、健壯性和可維護方面有侷限性。除了數據同步之外，一些應用程序還需要通過調用外部服務來增強數據。
爲了應對這些挑戰，我們開發了Delta。Delta是一個最終一致的、事件驅動的數據同步和增強平臺。
現有的解決方案
雙寫
爲了保持兩個數據存儲的同步，可以執行雙寫操作，即在對一個數據存儲執行寫操作之後，對另一個數據存儲執行寫操作。第一個寫操作可以重試，如果第一個寫操作在用完重試次數之後失敗，則可以中止第二個寫操作。但是，如果第二個數據存儲寫入失敗，這兩個數據存儲就會失去同步。一種常見的解決方案是構建一個修復例程，週期性地將第一個存儲區中的數據重新應用到第二個存儲，或者只有在檢測到差異時才這樣做。
問題：
實現修復例程通常是專用的，可能無法重用。另外，在應用修復例程之前，存儲之間的數據是不同步的。如果涉及兩個以上的數據存儲，則解決方案會變得越來越複雜。最後，修復例程會在主數據源活動期間給其增加大量的壓力。
變更日誌表
當一組表發生變動（如插入、更新和刪除）時，更改項會作爲同一事務的一部分添加到日誌表中。另一個線程或進程不斷輪詢日誌表中的事件，並將它們寫入一個或多個數據存儲中，在所有數據存儲確認後可選擇從日誌表中刪除事件。
問題：
這需要作爲一個庫來實現，並且在理想情況下不需要對使用它的應用程序進行代碼更改。在多語言環境中，需要對每種支持的語言重複實現這個庫，並且很難確保跨語言時特性和行爲的一致性。
模式更改的捕獲還存在另一個問題，有些系統（如MySQL）不支持事務性模式更改[1][2]。因此，執行更改（如模式更改）並以事務方式將其寫入變更日誌表的模式並不總是有效。
分佈式事務
分佈式事務可用於實現跨多個異構數據存儲的事務，以便將寫操作提交給所有相關存儲或不提交。
問題：
事實證明，分佈式事務跨異構數據存儲是有問題的。本質上講，它們只能依賴於參與系統的最小公分母。例如，如果應用程序進程在準備階段失敗，XA事務將阻塞執行；此外，XA不提供死鎖檢測，也不支持樂觀併發控制方案。而且，某些系統（如ElasticSearch）不支持XA或其他任何異構事務模型。因此，對於應用程序[3]來說，要保證跨不同存儲技術的寫操作的原子性仍然是一個具有挑戰性的問題。
Delta
開發Delta是爲了解決現有數據同步解決方案的侷限性，並允許動態地增強數據。我們的目標是從應用程序開發人員中抽象出這些複雜性，這樣他們就可以專注於實現業務特性。下面，我們將描述“電影搜索”，這是Netflix內部使用Delta的一個實際用例。
在Netflix，微服務架構被廣泛採用，每個微服務通常只處理一種類型的數據。核心電影數據駐留在一個稱爲Movie Service的微服務中，而諸如電影交易、人才、供應商等相關數據則由多個其他的微服務（例如Deal Service、Talent Service和Vendor Service）提供。Netflix工作室的企業用戶通常需要根據不同的標準搜索電影以便跟蹤製作情況，因此，對他們來說，能夠搜索與電影相關的所有數據至關重要。
在採用Delta之前，電影搜索團隊在索引電影數據之前必須從多個其他的微服務獲取數據。此外，團隊必須構建一個系統，通過查詢其他人的更改來定期更新他們的搜索索引，即使根本沒有更改。這個系統很快就變得非常複雜且難以維護。
圖1 採用Delta之前的輪詢系統
在上了Delta之後，系統被簡化爲一個事件驅動系統，如下圖所示。CDC （Change-Data-Capture）事件由Delta-Connector發送到Keystone Kafka主題。使用Delta流處理框架構建的Delta應用程序會消費該主題中的CDC事件，然後調用其他微服務來增強每個事件，並最終將增強後的數據發送到Elasticsearch中的搜索索引。整個過程幾乎是實時的，這意味着只要將更改提交到數據存儲，搜索索引就會更新。
圖2 使用Delta實現的數據管道
在接下來的部分中，我們將描述連接到數據存儲並將CDC事件發佈到傳輸層的Delta-Connector。傳輸層則將CDC事件路由到Kafka主題的實時數據傳輸基礎設施。最後，我們將描述應用程序開發人員可以用來構建他們的數據處理和增強邏輯的Delta流處理框架。
CDC（變更數據捕獲）
我們開發了一個名爲Delta-Connector的CDC服務，它能夠實時捕獲數據存儲中提交的更改並將其寫入流。實時更改是從數據存儲的事務日誌和轉儲中捕獲的。之所以採用轉儲，是因爲事務日誌通常不包含更改的完整歷史記錄。更改通常被序列化爲Delta事件，因此，如果更改來自事務日誌或轉儲，使用者就無需擔心。
連接器提供多種先進的功能，如：
- 除Kafka之外，還能夠寫進自定義輸出。
- 能夠在任何時候觸發針對所有表、特定表或特定主鍵的手動轉儲。
- 可以以塊的形式獲取轉儲，因此在出現故障時不需要從頭開始重做一遍。
- 不需要獲取表鎖，這對於確保數據庫上的寫流量不會被我們的服務阻塞是至關重要的。
- 通過跨AWS可用性區域的備用實例實現高可用。
我們目前支持MySQL和Postgres，包括部署在AWS RDS及其Aurora版本中的時候。此外，我們支持Cassandra（多主機）。我們將在以後的博文中更詳細地介紹Delta-Connector。
Kafka&傳輸層
Delta事件的傳輸層基於Keystone平臺的消息服務構建。
從歷史上看，Netflix的消息發佈是針對可用性而不是持久性進行優化的（參見以前的博客）。折中的結果是各種邊緣場景中可能出現代理數據不一致。例如，不潔羣首選舉將導致消費者可能重複或丟失事件。
對於Delta，我們需要更強的持久性保證，以確保CDC事件能夠到達次存儲。爲了實現這一點，我們提供了一個特殊用途的Kafka集羣作爲一個一等公民。下面是一些代理配置。
在Keystone Kafka集羣中，不潔羣首選舉通常有利於生產者可用性。當一個不同步的副本被選爲羣首時，可能會導致消息丟失。對於新的高耐久性Kafka集羣，爲了防止這樣的信息丟失，不潔羣首選舉被禁用。
我們還將複製因子從2增加到3，並將最小同步副本從1增加到2。寫入此集羣的生產者需要所有存儲的應答，以確保3個副本中有2個擁有由生產者寫入的最新消息。
當代理實例終止時，一個新實例將替換終止的代理。然而，這個新的代理將需要更新不同步的副本，這可能需要幾個小時。爲了提高此場景的恢復時間，我們開始使用塊存儲卷（Amazon Elastic block Store）代替代理上的本地磁盤。當新實例替換已終止的代理時，它現在就會附加已終止實例擁有的EBS卷，並開始捕捉新消息。這個過程將捕獲時間從幾小時減少到幾分鐘，因爲新實例不再需要從空白狀態複製。通常，存儲和代理生命週期的獨立大大降低了代理替換的影響。
爲了進一步最大化我們的交付保證，我們使用了消息跟蹤系統來檢測由於極端情況造成的任何消息丟失（如分區羣首的時鐘漂移）。
流處理框架
Delta的處理層基於Netflix SPaaS平臺構建，該平臺提供Apache Flink與Netflix生態系統的集成。該平臺提供了一個自助服務UI，在我們的容器管理平臺Titus上管理Flink作業部署和Flink集羣編排。自助服務UI還管理作業配置，並允許用戶進行動態配置更改，而不必重新編譯Flink作業。
Delta提供了一個基於Flink和SPaaS的流處理框架，該框架使用註解驅動的DSL（領域特定語言）來進一步抽象技術細節。例如，要定義一個通過調用外部服務來增強事件的步驟，用戶只需編寫以下DSL，框架會將其轉換爲一個由Flink執行的模型。
圖3 Delta應用程序中用於增強事件的DSL示例
處理框架不僅縮短了學習曲線，還提供了常見的流處理功能，如重複數據刪除、規範化、彈性和容錯，以解決一般的操作問題。
Delta流處理框架由兩個關鍵模塊組成：DSL&API模塊和運行時模塊。DSL&API模塊提供基於註解的DSL和UDF（用戶定義函數）API，供用戶編寫自定義處理邏輯（如過濾器和轉換）。運行時模塊提供DSL解析器實現，用於構建DAG模型中處理步驟的內部表示。執行組件解釋DAG模型，初始化實際的Flink操作符並最終運行Flink應用程序。
圖4 Delta流處理框架架構
這種方法有幾個好處：
- 用戶可以專注於他們的業務邏輯，而不需要學習Flink或SPaaS框架的細節。
- 可以通過對用戶透明的方式進行優化，並且可以在不對用戶代碼（UDF）進行任何更改的情況下修復Bug。
- 操作Delta應用程序對於用戶來說非常簡單，因爲框架提供了開箱即用的彈性和容錯能力，並收集了多種粒度的可用於警報的指標。
生產使用情況
Delta已經運行了一年多，在Netflix Studio的許多應用程序中都扮演了重要角色。它幫助團隊實現搜索索引、數據倉庫和事件驅動的工作流等用例。下面是Delta平臺的高層架構圖。
圖5 Delta高層架構圖
我們將在後續的博文中發佈關於關鍵組件（如Delta-Connector和Delta流處理框架）的技術細節。敬請期待。如果你有任何問題，也可以隨時聯繫作者。
本文最初發佈於Netflix 技術博客，由InfoQ中文站翻譯並分享。
原文鏈接：