本內容是對知名性能評測博主 Anton Putra Redis vs Memcached Performance Benchmark 內容的翻譯與整理, 有適當刪減, 相關指標和結論以原作為準
在本視頻中，我們將對比 Redis 和 Memcached。我會介紹一些功能上的不同，但主要關注 性能。
首先，我們會衡量緩存系統最重要的指標之一---延遲（latency），使用 p99 百分位數。緩存系統最常見的操作是 set（寫入） 和 get（讀取），因此我們將重點測試這兩個操作。此外，我們還會衡量：
- 吞吐量（throughput）：即每秒可處理的操作數
- 飽和度（saturation）：通過監控 CPU 使用率、內存使用率 以及 網絡流量 來評估
所有測試均在 AWS 上運行，并使用與生產環境完全相同的基礎設施。本次測試中，我們使用 m7a.medium 實例來運行 Redis 和 Memcached。眾所周知，Redis 主要依賴 單線程，因此垂直擴展能力有限。
接下來，我會介紹測試設計。此外，我還使用了 EKS（Elastic Kubernetes Service） 集群，運行 Graviton 實例來部署監控組件，同時運行客戶端以模擬負載。
什么是緩存？
假設你有一個典型的 三層架構：
- 客戶端層：可能是瀏覽器或移動應用
- 邏輯層：運行應用程序和業務邏輯
- 數據層：用于持久化存儲數據
舉個例子，假設你運營一個 電商網站，所有 用戶數據 和 商品信息 都存儲在 關系型數據庫 中。每當客戶登錄賬戶時，你需要展示他們的 姓名、收貨地址 以及其他詳細信息。
這些數據并不會頻繁變更，但每次請求時，仍然需要查詢數據庫。如果你的用戶數量較少，這還可以接受，但如果有成千上萬的用戶，這些查詢 會變得越來越慢。
解決方案是：
當用戶登錄時，查詢數據庫并將數據存儲在緩存中（例如 60 秒）。
這樣可以 提高用戶體驗，加快網站加載速度，并減少數據庫負載。
你還可以緩存其他 SQL 查詢，比如 最暢銷商品，以便在首頁展示。這就是緩存系統最初解決的問題---緩存 SQL 查詢結果，存入臨時存儲。
之后，緩存系統的使用場景不斷擴展，并發展出了 持久化存儲 等額外功能。
目前，Memcached 仍主要用于 緩存數據庫查詢，而 Redis 則發展出了 豐富的功能集。
測試設計
為了保證測試的公平性，我每次都會使用 Terraform 從 零 創建所有基礎設施。
- 本次測試使用 medium（中等）實例，因為 Redis 是單線程的，只能通過 水平擴展（Redis 集群） 進行擴展。
- 另外，我創建了一個 EKS 集群，并部署 Prometheus、Grafana 等監控組件，還配置了 每種緩存 20 個客戶端 來模擬負載。
- 我會 逐步增加客戶端數量，直到 Redis 和 Memcached 都達到極限。
- 每次測試通常運行 1.5 - 2 小時。
配置概覽
- 我使用當前最新版本：
- Redis 7.4.1
- Memcached 1.6.32
- Redis
- 采用最小化配置，保留大部分默認設置
- 禁用持久化
- 最大連接數設為 10,000
-
Memcached
- 默認內存從 64MB 增加到 4GB（與 VM 限制一致）
- 最大連接數同樣設為 10,000
-
客戶端
- 使用 Go 語言開發
- 內部集成 Prometheus 指標
- 采用 最流行、最高效的驅動
- 不使用內部緩存指標，而是通過 相同的直方圖桶 從客戶端端測量延遲，以確保測試更加準確。
第一次測試
接下來，我們開始運行測試。
在下方的圖表中，你可以看到我們逐步增加客戶端數量。
Redis 的 set（寫入）延遲從一開始就比 Memcached 略慢，但 get（讀取）延遲在最初幾分鐘幾乎相同。
然而，當負載增加時，情況開始發生變化。
- CPU 使用率 在整個測試過程中幾乎相同
- 內存使用情況 也相似，但呈現出不同的模式：
- set 操作設置 20 秒的過期時間，因此 Redis 和 Memcached 每 20 秒都會刪除數據
- 但 兩者的內存清理方式不同
- 網絡傳輸的數據量 也有一些不同
當操作數達到 50,000 次/秒 時，Redis 開始落后于 Memcached，并且 延遲上升到 10 - 15 毫秒。
相比之下，Memcached 在整個測試過程中保持穩定。
在網絡上，你可能會看到 Memcached 的性能比 Redis 更強，但 延遲才是最關鍵的指標。
更高的延遲意味著網頁加載更慢，最終影響用戶體驗。
盡管 Redis 具有豐富的功能，但你真的需要它們嗎？
Redis 集群難以擴展和維護，你可能需要不斷添加 新的分片（shard） 并進行 重新平衡。
通常，很多人一開始自己管理 Redis，但隨著負載增加，他們會轉向 Redis 集群，
經歷幾次 生產事故 后，最終可能會選擇 昂貴的托管 Redis（AWS 或其他云服務）。
相比之下，Memcached 非常容易運行，如果你 只是想緩存 SQL 查詢 以加速數據庫，Memcached 是一個不錯的選擇。
測試結果
在 CPU 資源耗盡之前：
- Redis 最高處理能力：94,000 請求/秒
- Memcached 最高處理能力：112,000 請求/秒
但 最重要的還是延遲。
根據本次測試結果，你可以自己決定：
- 是選擇簡單、低延遲的 Memcached
- 還是選擇功能強大的 Redis
請記住，維護 Redis 集群非常困難，很多公司甚至專門雇人 只負責維持 Redis 的正常運行。
現在，我們查看整個測試期間的各項指標：
- 每秒操作數（Operations per second）
- 在 50,000 ops/sec 時，Redis 和 Memcached 的性能開始出現差異
- 可以清楚地看到 每種緩存的最大處理能力
- SET（寫入）操作的延遲
- 延遲差異 非常明顯
- 在 Redis 過載時，延遲甚至接近 SQL 查詢本身的延遲（35ms）
- 但在 CPU 使用率低于 15% 時，兩者的延遲都很穩定且較低
- GET（讀取）操作的延遲
- 趨勢類似，但 GET 操作的平均時間約為 SET 操作的一半
- Redis 最高 GET 延遲約為 20ms
- CPU 使用率
- 兩者表現幾乎相同，在 CPU 滿載前都能維持穩定
- 內存使用
- 兩者模式稍有不同
- 網絡使用
- 有一定的區別
總結
這些測試都使用的是 默認配置。
如果你能優化 Redis 或 Memcached，歡迎提交 PR（Pull Request），我會給予 署名，并分享如何改進性能。
