共計 3213 個字符，預計需要花費 9 分鐘才能閱讀完成。

本篇內容介紹了“Redis 要比 Memcached 更火的原因有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

要分析它們的區別，主要從以下幾個方面對比：

  線程模型

  數據結構

  淘汰策略

  管道與事務

  持久化

  高可用

  集群化

線程模型

要說性能，必須要分析它們的服務模型。

Memcached 處理請求采用多線程模型，并且基于 IO 多路復用技術，主線程接收到請求后，分發給子線程處理。

這樣做好的好處是，當某個請求處理比較耗時，不會影響到其他請求的處理。

當然，缺點是 CPU 的多線程切換必然存在性能損耗，同時，多線程在訪問共享資源時必然要加鎖，也會在一定程度上降低性能。

Redis 同樣采用 IO 多路復用技術，但它處理請求采用是單線程模型，從接收請求到處理數據都在一個線程中完成。

這意味著使用 Redis，一旦某個請求處理耗時比較長，那么整個 Redis 就會阻塞住，直到這個請求處理完成后返回，才能處理下一個請求，使用 Redis 時一定要避免復雜的耗時操作。

單線程的好處是，少了 CPU 的上下文切換損耗，沒有了多線程訪問資源的鎖競爭，但缺點是無法利用 CPU 多核的性能。

由于 Redis 是內存數據庫，它的訪問速度非常地快，所以它的性能瓶頸不在于 CPU，而在于內存和網絡帶寬，這也是作者采用單線程模型的主要原因。同時，單線程對于程序開發非常友好，調試起來也很方便。開發多線程程序必然會增加一定的調試難度。

因此，當我們的業務使用 key 的數據比較大時，Memcached 的訪問性能要比 Redis 好一些。如果 key 的數據比較小，兩者差別并不大。

 “    嚴格來說，Redis 的單線程指的是處理請求的線程，它本身還有其他線程在工作，例如有其他線程用來異步處理耗時的任務。

Redis6.0 又進一步完善了多線程，在接收請求和發送請求時使用多線，進一步提高了處理性能。

數據結構

Memcached 支持的數據結構很單一，僅支持 string 類型的操作。并且對于 value 的大小限制必須在 1MB 以下，過期時間不能超過 30 天。

而 Redis 支持的數據結構非常豐富，除了常用的數據類型 string、list、hash、set、zset 之外，還可以使用 geo、hyperLogLog 數據類型。

使用 Memcached 時，我們只能把數據序列化后寫入到 Memcached 中。然后再從 Memcached 中讀取數據，再反序列化為我們需要的格式，只能“整存整取”。

而 Redis 對于不同的數據結構可以采用不同的操作方法，非常靈活。

 list：可以方便的構建一個鏈表，或者當作隊列使用

 hash：靈活地操作我們需要的字段，進行“整存零取”、“零存整取”以及“零存零取”

 set：構建一個不重復的集合，并方便地進行差集、并集運算

 zset：構建一個排行榜，或帶有權重的列表

 geo：用于地圖相關的業務，標識兩個地點的坐標，以及計算它們的距離

 hyperLogLog：使用非常少的內存計算 UV

總之，Redis 正是因為提供了這么豐富的數據結構，近幾年在內存數據庫領域大放異彩，為我們的業務開發提供了極大的便利。

淘汰策略

Memcached 必須設置整個實例的內存上限，數據達到上限后觸發 LRU 淘汰機制，優先淘汰不常用使用的數據。

但它的數據淘汰機制存在一些問題：剛寫入的數據可能會被優先淘汰掉，這個問題主要是它本身內存管理設計機制導致的。

Redis 沒有限制必須設置內存上限，如果內存足夠使用，Redis 可以使用足夠大的內存。

同時 Redis 提供了多種淘汰策略：

 volatile-lru：從過期 key 中按 LRU 機制淘汰

 allkeys-lru：在所有 key 中按 LRU 機制淘汰

 volatile-random：在過期 key 中隨機淘汰 key

 allkeys-random：在所有 key 中隨機淘汰 key

 volatile-ttl：優先淘汰最近要過期的 key

 volatile-lfu：在所有 key 中按 LFU 機制淘汰

 allkeys-lfu：在過期 key 中按 LFU 機制淘汰

我們可以針對業務場景，使用不同的數據淘汰策略。

管道與事務

Redis 還支持管道功能，客戶端一次性打包發送多條命令到服務端，服務端依次處理客戶端發來的命令。這樣可以減少來回往來的網絡 IO 次數，提供高訪問性能。

另外它還支持事務，這里所說的事務并不是 MySQL 那樣嚴格的事務模型，這種事務模型是 Redis 特有的。

一般事務會配合管道一塊使用，客戶端一次性打包發送多條命令到服務端，并且標識這些命令必須嚴格按順序執行，不能被其他客戶端打斷。同時執行事務之前，客戶端可以告訴服務端某個 key 稍后會進行相關操作，如果這個客戶端在操作這個 key 之前，有其他客戶端對這個 key 進行更改，那么當前客戶端在執行這些命令時會放棄整個事務操作，保證一致性。

持久化

Memcached 不支持數據的持久化，如果 Memcached 服務宕機，那么這個節點的數據將全部丟失。

Redis 支持將數據持久化磁盤上，提供 RDB 和 AOF 兩種方式：

 RDB：將整個實例中的數據快照到磁盤上，全量持久化

 AOF：把每一個寫命令持久到磁盤，增量持久化

Redis 使用這兩種方式相互配合，完成數據完整性保障，最大程度降低服務宕機導致的數據丟失問題。

高可用

Memcached 沒有主從復制架構，只能單節點部署，如果節點宕機，那么該節點數據全部丟失。業務需要對這種情況做兼容處理，當某個節點不可用時，把數據寫入到其他節點以降低對業務的影響。

Redis 擁有主從復制架構，兩個節點組成主從架構，從可以實時同步主的數據，提高整個 Redis 服務的可用性。

同時 Redis 還提供了哨兵節點，在主節點宕機時，主動把從節點提升為主節點，繼續提供服務。

主從兩個節點還可以提供讀寫分離功能，進一步提高程序訪問的性能。

集群化

Memcached 和 Redis 都是由多個節點組成集群對外提供服務，但他們的機制也有所不同。

Memcached 的集群化是在客戶端采用一致性哈希算法向指定節點發送數據，當一個節點宕機時，其他節點會分擔這個節點的請求。

而 Redis 集群化采用的是每個節點維護一部分虛擬槽位，通過 key 的哈希計算，將 key 映射到具體的虛擬槽位上，這個槽位再映射到具體的 Redis 節點。

同時每個 Redis 節點都包含至少一個從節點，組成主從架構，進一步提高每個節點的高可用能力。

當增加或下線節點時，需要手動觸發數據遷移，重新進行哈希槽位映射。

Redis 官方的集群化解決方案為 Redis cluster，它采用無中心化的設計。另外也有第三方的采用中心化設計 proxy 方式的集群化解決方案，例如 Codis、Twemproxy。

總結

從以上幾個方面進行對比分析，總結如下表。

#MemcachedRedis 線程模型多線程單線程數據結構僅支持 string、value 最大 1M、過期時間不能超過 30 天 string、list、hash、set、zset、geo、hyperLogLog 淘汰策略 LRULRU、LFU、隨機等多種策略管道與事務不支持支持持久化不支持支持高可用不支持主從復制 + 哨兵集群化客戶端一致性哈希算法主從復制 + 哨兵 + 固定哈希槽位

整體來說，Redis 提供了非常豐富的功能，而且性能基本上與 Memcached 相差無幾，這也是它最近這幾年占領內存數據庫鰲頭的原因。

如果你的業務需要各種數據結構給予支撐，同時要求數據的高可用保障，那么選擇 Redis 是比較合適的。

如果你的業務非常簡單，只是簡單的 set/get，并且對于內存使用并不高，那么使用簡單的 Memcached 足夠。

“Redis 要比 Memcached 更火的原因有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！