Redis Cluster：為高效能付出了不安全的代價 - emil

安全定義
關於“足夠安全”的含義沒有普遍的共識，也不可能有統一的共識，因為安全要求是由每個組織獨特的商業驅動因素決定的。在這裡，我將嘗試制定一個較弱的安全定義，這對於相當多的應用程式可能是明智的。我從不同行業的眾多客戶的個人經驗中汲取了經驗，我的建議是大多數從業者都會做出的合理假設。有人可能會說，這種對安全性的削弱不夠客觀；我說，如果沒有某種基線，我們就無法繼續。
一個“足夠安全”的基於leader-follower的複製狀態機通常需要滿足以下標準：

1. 領導者的單一性。最多有一個領導者可以在任何給定時間執行，並被配置中的仲裁副本（包括領導者）統一接受。前任被取代的領導者不能干涉當前領導者的行動。嚴格來說，安全屬性允許在瑣碎的情況下為零領導者；however, at some time there must be one elected leader for progress to eventually occur, thereby satisfying the liveness property.
2. 複製功效。所有副本（包括領導者）都按照領導者規定的順序忠實地將領導者發出的更新應用於其狀態機。領導者執行的所有更新都會傳遞給法定數量的副本（包括領導者）。未由完整仲裁副本接受的寫入不得由主伺服器安裝或向啟動應用程式（客戶端）確認。此屬性與 CAP 定理的 CP 約束有關。
3. 法定人數交集。根據我們之前的通訊，仲裁系統中的每個有效仲裁至少透過一個程式與其他仲裁相交。
4. 一致的副本提升。在故障轉移期間，只有一致的副本可以爭奪領導權。其他人必須保持休眠狀態。一旦該副本被選中，它就會從領導者離開的地方繼續。注意，leader 上可能有未確認的寫入待處理；安全屬性不關心這些寫入；繼任領導人可以自行決定合併他們。
5. 永續性有限的陳舊性。每個副本都附加到一個永續性儲存裝置上，該裝置可以在程式失敗後倖存下來。持久狀態反映了故障前程式的瞬態狀態，關於在某些商定的過時範圍內已被副本確認的寫入. 可以根據經過的時間或未提交記錄的數量來衡量有界過時。（後者更可取，因為它更準確地反映了最壞情況損失的大小。）在執行時，該程式不會丟棄其臨時儲存中的資料，直到持久儲存確認相關寫入。重新啟動過程可以確定最近提交的寫入的身份（偏移量、序列號等）。作為推論，重新啟動的過程絕不能自動承擔領導權，即使它在失敗之前碰巧成為領導者。

1. 仲裁系統旨在容忍f 次故障，其中f ≥ 1。換句話說，我們正在處理一個高可用性系統，其中單個程式的故障不會導致系統無法執行。實際上，對於基於多數的仲裁系統，我們至少需要三個程式。
2. 程式不受可能的共模故障的影響。共模故障涉及影響多個獨立元素的單一原因；例如，電源故障或物理入侵事件。將伺服器分散在不同的機架或更好的資料中心之間，可以降低共模故障的可能性。
3. 過程配備了*P故障檢測器。所有失敗的程式最終都會被所有活著的程式懷疑；最終不會懷疑所有實時程式。準確度-完整性二元性的精確調整雖然對活躍度具有實際意義，但不會影響安全性。
4. 弱持久的永續性。保留的資料以商定的可能性被原始地召回，該可能性隨著時間而減少。可以以足夠高的可能性檢測到資料丟失和損壞。

分析Redis
首先，來自官方檔案的幾個條款作為序言。有些甚至是非常有趣的。至少，Redis 的所有使用者都應該非常熟悉他們，無論他們對 Redis 或本文的看法如何。在整個分析過程中，我們將透過它們的編號來引用它們。

1. 透過開箱即用的預設設定，Redis 可作為半持久資料儲存執行，犧牲永續性以支援寫入的吞吐量和延遲。這在官方文件的Redis 持久化章節中有詳細說明。具體來說，AOF（僅附加檔案）的預設重新整理間隔會留下一秒的視窗，在該視窗內確認的寫入可能會不可挽回地丟失。這是appendfsync everysec選項，它是 AOF 配置中的預設選項和推薦選項。
2. 持久化規範列出了appendfsync always選項，其中所有暫存的 AOF 寫入都受制於fsync()返回之前；然而，在這種模式下，Redis的效能在官方文件中被描述為“非常[原文如此]非常慢，非常安全”。因此，appendfsync everysec推薦該選項，“非常快且非常安全”。讀者會發現 Redis 文件似乎迴避了實證或定量的斷言，而傾向於使用諸如“非常”、“慢”、“快”等定性形容詞。
3. 關於複製的章節表明 Redis 在領導者-跟隨者（用它的說法是主從）拓撲中採用非同步複製協議，其中從伺服器重放主伺服器應用的寫入，而與主伺服器對發起客戶端的響應無關。在主站響應時，從站可能會任意落後於主站。
4. 從 3.0.0 版本開始，Redis 包含WAIT命令。WAIT在客戶端上阻塞，直到所有先前的寫入在指定的超時內複製到使用者特定數量的副本，並在超時過去之前返回已確認的副本數量。表面上，WAIT把Redis的非同步複製機制變成了同步複製機制。
5. 該WAIT文件指出“WAIT不會使Redis的強一致店：同時同步複製是一個複製的狀態機的一部分，它不是唯一需要的東西”。它繼續澄清“Sentinel 和 Redis Cluster 都將盡最大努力在可用副本集中提升最佳副本。然而 [原文如此] 這只是盡力而為的嘗試 [原文如此] 因此仍有可能丟失同步複製到多個副本的寫入”。在這裡，文件沒有明確說明“盡力而為”的含義。具體而言，維護者不會公開最佳副本提升失敗的條件。我們有責任解決這個問題。
6. 該WAIT文件並未聲稱在主節點和/或副本重新整理暫存寫入之前命令會阻塞，僅宣告“命令已成功傳輸並確認”由指定的最小副本數。換句話說，該WAIT命令是對各個副本的瞬時狀態而非持久狀態的斷言。
7. 該複製章規定，“Redis的是不是一個CP系統，具有很強的一致性”和“承認寫仍然可以在故障轉移期間丟失”。它繼續說道，“WAIT在故障事件後丟失寫入的可能性大大降低到某些難以觸發的故障模式”，但沒有詳細說明導致資料丟失的特定故障模式，或量化這些事件發生的可能性。表面上，這指的是第 5 條，這是不完整的。它也可能指的是第 6 條。Redis 將細節保留為眾所周知的“讀者練習”。
8. Redis官方叢集規範描述了“從屬等級”演算法，其中從屬根據複製資料量建立相對於其對等方的等級，並將領導者選舉延遲一個與其等級大致成比例的時間。（我們說“大致”是因為等待時間包含一個隨機延遲元件。）更完整（排名接近 0）的從屬被設定為在不完整之前投票（排名接近 N-1，其中 N 是配置的副本數）奴隸。
9. 在同一部分，叢集規範指出“masters 不會以任何方式選擇最好的 slaves”。沒有機制可以確保後續的領導者在倖存的副本中排名最好。

建議
提供的唯一明智的指導是針對我們在此處考慮的各種工作負載強烈避免使用 Redis Cluster。如果系統未能證明我們弱化的安全概念，我們可能會透過降低系統暴露和易受攻擊的事件發生的可能性來使其更安全一些。因此，如果無情的約束會阻止您從 Redis 切換到更合適的永續性堆疊，那麼以下內容可能會有所啟發。
我們對髒讀無能為力；這是你需要忍受的東西。WAIT在那裡使用對您沒有幫助。
.. 

結論
Redis Cluster 在任何配置下都是不安全的，即使考慮到已經做出的所有讓步。在其預設配置中，Redis 的效能非常出色，但客觀上並不安全。當我們確定配置時，Redis 顯示出微小的改進，但即使是我們願意考慮的最寬鬆的安全屬性也無法滿足，而效能權衡變得明顯。就目前而言，可以這麼說，“在任何速度下”都是不安全的。
Redis 是針對特定工作的有效工具，並在其他關鍵領域做出了某些妥協。知道這些區域是什麼！作為磁碟支援的快取，Redis 已經是無與倫比的。它的一些資料結構是偉大的。但是，如果您追求可擴充套件的 NoSQL 資料庫，該資料庫提供一致性、永續性和某種程度的隔離（即，一個體面的安全概念），那麼您會在市場上找到客觀上更適合您需求的替代品。