在分散式系統中，「刪除資料」看似簡單，實際上卻是極具風險的操作。對於像 Netflix 這樣規模的系統，資料會被複製到 Cassandra、Elasticsearch、Redis 等多種儲存介面中。如果刪除不徹底，會導致儲存成本增加且違反合規性；如果刪除過猛，則可能引發系統崩潰。
本文將深入探討 Netflix 如何建構一個中心化的資料刪除平台，以平衡持久性（Durability）、可用性（Availability）與正確性（Correctness）。
刪除資料的隱形成本與風險
對於初學者來說，最直觀的刪除是執行 DELETE 指令，但在大規模系統中，刪除通常伴隨著巨大的資源開銷。
許多資料庫（如 Cassandra 或 Elasticsearch）並不立即物理刪除資料，而是建立一個 Tombstone（墓碑標記）。這是一個特殊的標記，告訴系統該筆資料已被刪除。然而，墓碑標記本身也佔用空間，且在讀取資料時，系統必須掃描這些墓碑才能確定哪些資料是有效的。
如果短時間內進行大量刪除（Bulk Deletes），會導致墓碑標記激增，進而引發以下問題： 讀取延遲增加：系統需要掃描大量墓碑標記，導致讀取逾時。 資源爭搶：後台的 Compaction（壓縮/合併）程序會為了清理墓碑而消耗大量 CPU 與 I/O，甚至引發 Compaction Storm（壓縮風暴），導致整個集群不穩定。 資料復活（Data Resurrection）：在某些分佈式系統中，如果節點故障時間過長，超過了 GC Grace Period（垃圾回收寬限期），已刪除的資料可能會在節點恢復後重新出現，變成所謂的「殭屍資料」。
安全刪除的三大支柱
為了應對上述風險，Netflix 將安全刪除拆解為三個維度：
持久性：確保資料被刪除後確實消失。針對不同儲存介面採取不同策略，例如利用 TTL（Time To Live，生存時間）讓資料自動過期，或使用 Hard Delete（硬刪除）直接移除。
可用性：確保刪除操作不會影響線上流量。 分區級刪除（Partition-level Deletes）：盡量刪除整個分區而非單筆列，以減少墓碑數量。 引入 TTL Jitter（TTL 抖動）：在設定過期時間時加入隨機偏移量，避免大量資料在同一秒鐘過期，將資源峰值平攤到全天。 動態限流（Rate Limiting）：監控下游資料庫的 CPU 與儲存利用率，當系統壓力過高時，自動降低刪除速度或暫停操作。
正確性：解決併發寫入導致的衝突。 在分佈式系統中，可能會發生「客戶端 A 正在刪除，客戶端 B 同時在寫入」的情況。Netflix 採用 Last Write Wins（最後寫入者勝）策略，並要求客戶端生成時間戳（Timestamp）而非依賴資料庫接收時間，以確保操作順序正確。 引入 Idempotency Token（冪等令牌）：為每次寫入生成唯一令牌，確保重複請求不會導致狀態錯誤。
中心化刪除平台的實作流程
為了避免每個服務各自實作刪除邏輯導致的混亂，Netflix 建立了中心化的刪除平台，其生命週期分為四個階段：
識別（Identification） 透過數據擁有者定義的規則、Schema Registry（模式註冊表）或特定標記（Annotation），找出哪些資料（例如測試帳號、已註銷用戶）需要被刪除。
審計與驗證（Audit and Validation） 為了不影響線上性能，審計工作是在 S3 的備份快照上進行的。系統會比對識別表與數據表，產生一個「可刪除清單」。在正式執行前，會再次驗證該清單，確保資料在備份後沒有被重新插入。
執行刪除（Deletion Execution） 刪除服務根據驗證後的清單，異步地將刪除指令分發到 Cassandra、RDS 或其他後端系統。所有操作都會記錄在 Journal Service（日誌服務）中，以便追蹤。
持續監控（Continuous Monitoring） 刪除並非一次性工作。系統會定期運行審計循環，捕捉任何因故障而未刪除成功的資料，將其重新加入下一次刪除隊列。
建立信任與恢復機制
將刪除權限交給中心化團隊通常會引起數據擁有者的不安。Netflix 透過以下方式建立信任：
可視化面板：提供中心化 Dashboard，讓數據擁有者隨時查看審計進度與刪除結果。 恢復機制（Recovery）：Journal Service 會在低成本的 S3 儲存中保留刪除資料的完整副本 30 天。如果發現誤刪，可以在一個月內將資料還原。 還原策略：在還原時，會將原時間戳增加 1 毫秒，以確保還原的資料能正確地插入在刪除操作之後，且不覆蓋掉刪除後新產生的合法寫入。
總結與工程啟示
對於處理大規模資料刪除的工程師，有幾個關鍵教訓： 首先，資料血緣（Lineage）至關重要，你必須清楚資料在哪些系統中有副本，否則會留下 Dangling Pointers（懸空指針），導致儲存浪費。 其次，不要信任單次刪除，必須建立「審計 $\rightarrow$ 驗證 $\rightarrow$ 刪除 $\rightarrow$ 再審計」的閉環。 最後，針對不同儲存引擎（Cassandra vs RDS vs S3）採取差異化策略，不要用同一套邏輯處理所有資料庫。
來源：infoq.com (Architecting a Centralized Platform for Data Deletion at Netflix)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。