專屬伺服器上的 Redis 與 Memcached 比較：如何選擇快取
Redis 與 Memcached 都是記憶體快取系統，但兩者在資料結構、持久化能力及營運控制方面有不同取向。在專屬伺服器上選擇哪一種快取，會影響記憶體規劃、失效處理、故障復原，以及應用程式需要承擔多少快取邏輯。
最適合的快取不一定是在合成基準測試中速度最高的一種。團隊應先了解要儲存的資料、應用程式如何讀取及讓資料失效、快取未命中時的影響，以及專屬伺服器可提供的資源。Redis 通常功能較完整；Memcached 則適合簡單而可以重新建立的暫存物件。
Redis 與 Memcached 的設計定位
快取位於應用程式與較慢的資料來源（例如資料庫或 API）之間。Redis 提供多種資料類型、可選的持久化及複寫功能，按設計可以支援的不只是一般物件快取。Memcached 是輕量的鍵值快取，主要圍繞短期資料、到期時間及淘汰機制運作；它通常被視為可以丟棄的快取，而不是資料來源。
如要了解更廣泛的快取層，Dataplugs 的善用 Cache 內容快取：提升網站載入速度文章說明物件快取如何配合 CDN 及來源伺服器效能工作。
- Redis 可以儲存字串、列表、集合、有序集合、雜湊及其他資料結構
- Redis 適合計數器、速率限制、工作佇列、工作階段及經過審慎設計的協調流程
- Memcached 以鍵值儲存不透明的資料，序列化及快取未命中處理由應用程式負責
- 兩者都可以減少重複的資料庫工作，但除非有明確的復原設計，否則不應視為可以取代持久資料
- 快取未命中、資料被淘汰或服務重啟時，應用程式必須有清晰的處理方式
Redis 較適合的情況
當快取需要較豐富的操作，或團隊可能需要持久化、複本及受控資料搬移時，Redis 通常較合適。它的資料結構可以把部分操作留在資料層完成，減少重複讀取及應用程式自行維護的工作。不過，這種靈活性亦代表更多設定、記憶體考慮及較大的營運範圍。
如果 Redis 或 Memcached 是伺服器調校方案的一部分，Dataplugs 的如何自訂您的洛杉磯專屬伺服器以達到最佳效能文章說明如何按應用程式工作負載配合 CPU、記憶體、儲存及網絡選項。
- 當應用程式需要的不只是每個鍵值對應一個不透明物件時，使用 Redis
- 當服務設計包括持久化或以複本復原時，使用 Redis
- 對需要原生操作的計數器、排行榜、速率限制或類似佇列的流程，使用 Redis
- 為複寫緩衝區、持久化工作、記憶體碎片及故障切換預留記憶體
- 記錄哪些 Redis 資料需要復原，以及哪些資料可以在淘汰後重新建立
Memcached 較適合的情況
當應用程式只需要一個快速、分散式的序列化物件快取，並且每個值都可以從持久資料來源重新產生時，Memcached 可以是合適的選擇。它刻意保持簡單，令快取擁有權及失效規則較容易理解，適合頁面片段、資料庫查詢結果及短期工作階段資料。
如果網站流量會突然上升，Dataplugs 的優化資源分配以應對季節性網站流量高峰文章把快取規劃與 CPU、記憶體、儲存、頻寬及來源伺服器容量的量度連結起來。
- 當資料彼此獨立、可以替換而且容易序列化時，使用 Memcached
- 當應用程式已有可靠的資料庫或 API 作為後備時，使用 Memcached
- 在各個應用程式實例之間，保持項目大小、到期時間及命名空間規則一致
- 為服務重啟、資料淘汰或節點更換後的冷快取情況作好準備
- 如果遺失資料會令業務記錄不一致，不要把該狀態放在 Memcached
提示：如果資料可以丟棄，應先量度快取未命中的成本，再決定是否需要持久化。如果快取承載應用程式狀態或協調工作流程，就應把 Redis 設定、備份及故障切換視為應用程式架構的一部分。
專屬伺服器上的 Redis 與 Memcached 資源規劃
專屬伺服器可以為快取提供較可預測的 CPU、記憶體、儲存及網絡資源，但如果架構沒有分開角色，快取仍會與應用程式及資料庫競爭。Redis 支援較豐富的資料結構及可選持久化功能，按使用方式可能需要更多記憶體。Memcached 的記憶體模型較簡單，但仍要計算 slab 分配、項目額外開支及預期工作集。
- 應使用命中率、未命中率、項目大小、淘汰率、指令延遲及高峰連線數規劃服務。當 Redis 啟用持久化、快照、日誌或復原副本時，NVMe 儲存尤其值得考慮；對暫存性 Memcached 層而言，RAM 及網絡表現通常比本地磁碟速度更重要。
- 按工作集加上記憶體碎片、緩衝區及故障切換餘裕規劃 RAM
- 把快取記憶體與資料庫及應用程式程序所需的記憶體分開計算
- 以 CPU 及網絡數據找出序列化、壓縮或連線瓶頸
- 設定明確的記憶體上限及淘汰策略，不要讓程序不受控制地佔用主機資源
使用與正式流量相同的並發量及項目大小分佈測試快取
持久化、複寫及故障規劃
Redis 可以使用 RDB 快照、AOF 日誌、不使用持久化，或按需要組合使用，取決於資料是否可以重新建立，以及重啟後復原的重要程度。Redis 複寫一般是非同步的，因此複本可能落後於主節點。復原計劃需要定義可接受的資料遺失、提升權限，以及用戶端如何找到新的端點。
Memcached 通常在節點故障後，從資料庫或其他來源重新建立。對快取而言這可以完全合理，但應用程式必須能夠處理冷啟動，並避免大量請求同時重新產生相同物件而形成驚群效應。請求合併、分階段預熱及有上限的重試都有助保護來源服務。
- 先定義快取是加速層、工作階段儲存，還是有狀態服務
- 在選擇持久化或複本前，先訂立復原點及復原時間目標
- 測試節點遺失、重啟、整個快取預熱、故障切換及過期用戶端連線
- 以請求合併、速率限制或背景刷新保護資料庫免受快取驚群影響
- 把備份及復原副本放在故障節點以外，並測試還原流程
安全、監察及部署
Redis 及 Memcached 都不應直接暴露到公開互聯網。應把服務綁定到私有介面、限制防火牆規則、按支援情況使用驗證及加密，並把管理存取與應用程式流量分開。專屬伺服器提供設定這些邊界的控制權，但仍需要由營運人員正確設定及維護。
監察應把快取行為與業務及來源系統的影響連結起來。高命中率未必代表資料沒有過期、鍵值分佈沒有傾斜或網絡沒有飽和；低命中率也可能由 TTL 不合適、鍵值構建不一致或工作集超出記憶體造成。除了平均快取回應時間，也應追蹤淘汰原因及未命中的延遲。
- 追蹤命中率、未命中率、淘汰、記憶體碎片、項目大小及指令延遲
- 監察來源資料庫負載，避免快取重啟變成一次非預期的資料庫壓力測試
- 為不同應用程式或環境使用獨立命名空間及擁有權規則
- 以可回復方式推出設定變更，並準備排空或預熱快取的方法
- 記錄快取層的修補、存取控制、告警負責人及事故處理流程
總結
當需要較豐富的資料結構、持久化、複寫或原生協調功能，而且可以承擔額外營運複雜度時，Redis 通常是較好的選擇。當需求是簡單、可丟棄的物件快取，並且重視低開支、直接的失效處理及容易重新建立時，Memcached 往往更合適。在專屬伺服器上，選擇應與記憶體上限、儲存需要、網絡設計、監察及復原流程一併決定。
如要為快取節點及應用程式伺服器規劃可預測的單租戶資源，Dataplugs 的專屬伺服器方案提供可配置 CPU、記憶體、儲存及網絡選項，詳情可聯絡 sales@dataplugs.com。