標籤：

Redis 和 Memcached 各有什麼優缺點，主要的應用場景是什麼樣的？

01-15

http://my.oschina.net/ydsakyclguozi/blog/404625

出處不明了

1、顯示最新的項目列表
2、刪除與過濾
3、排行榜相關
4、按照用戶投票和時間排序
5、處理過期項目
6、計數
7、特定時間內的特定項目
8、實時分析正在發生的情況，用於數據統計與防止垃圾郵件等
9、Pub/Sub
10、隊列
11、緩存

1. MySql+Memcached架構的問題

　　實際MySQL是適合進行海量數據存儲的，通過Memcached將熱點數據載入到cache，加速訪問，很多公司都曾經使用過這樣的架構，但隨著業務數據量的不斷增加，和訪問量的持續增長，我們遇到了很多問題：

　　1.MySQL需要不斷進行拆庫拆表，Memcached也需不斷跟著擴容，擴容和維護工作佔據大量開發時間。

　　2.Memcached與MySQL資料庫數據一致性問題。

　　3.Memcached數據命中率低或down機，大量訪問直接穿透到DB，MySQL無法支撐。

　　4.跨機房cache同步問題。

　　眾多NoSQL百花齊放，如何選擇

　　最近幾年，業界不斷湧現出很多各種各樣的NoSQL產品，那麼如何才能正確地使用好這些產品，最大化地發揮其長處，是我們需要深入研究和思考的問題，實際歸根結底最重要的是了解這些產品的定位，並且了解到每款產品的tradeoffs，在實際應用中做到揚長避短，總體上這些NoSQL主要用於解決以下幾種問題

　　1.少量數據存儲，高速讀寫訪問。此類產品通過數據全部in-momery 的方式來保證高速訪問，同時提供數據落地的功能，實際這正是Redis最主要的適用場景。

　　2.海量數據存儲，分散式系統支持，數據一致性保證，方便的集群節點添加/刪除。

　　3.這方面最具代表性的是dynamo和bigtable 2篇論文所闡述的思路。前者是一個完全無中心的設計，節點之間通過gossip方式傳遞集群信息，數據保證最終一致性，後者是一個中心化的方案設計，通過類似一個分散式鎖服務來保證強一致性,數據寫入先寫內存和redo log，然後定期compat歸併到磁碟上，將隨機寫優化為順序寫，提高寫入性能。

　　4.Schema free，auto-sharding等。比如目前常見的一些文檔資料庫都是支持schema-free的，直接存儲json格式數據，並且支持auto-sharding等功能，比如mongodb。

　　面對這些不同類型的NoSQL產品,我們需要根據我們的業務場景選擇最合適的產品。

Redis最適合所有數據in-momory的場景，雖然Redis也提供持久化功能，但實際更多的是一個disk-backed的功能，跟傳統意義上的持久化有比較大的差別，那麼可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那麼何時使用Memcached,何時使用Redis呢?

如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：

1 、Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。

2 、Redis支持數據的備份，即master-slave模式的數據備份。

3 、Redis支持數據的持久化，可以將內存中的數據保持在磁碟中，重啟的時候可以再次載入進行使用。

2. Redis常用數據類型

Redis最為常用的數據類型主要有以下：

String
Hash
List
Set
Sorted set
pub/sub
Transactions

在具體描述這幾種數據類型之前，我們先通過一張圖了解下Redis內部內存管理中是如何描述這些不同數據類型的：

首先Redis內部使用一個redisObject對象來表示所有的key和value,redisObject最主要的信息如上圖所示：

type代表一個value對象具體是何種數據類型，

encoding是不同數據類型在redis內部的存儲方式，

比如：type=string代表value存儲的是一個普通字元串，那麼對應的encoding可以是raw或者是int,如果是int則代表實際redis內部是按數值型類存儲和表示這個字元串的，當然前提是這個字元串本身可以用數值表示，比如:"123" "456"這樣的字元串。

這裡需要特殊說明一下vm欄位，只有打開了Redis的虛擬內存功能，此欄位才會真正的分配內存，該功能默認是關閉狀態的，該功能會在後面具體描述。通過上圖我們可以發現Redis使用redisObject來表示所有的key/value數據是比較浪費內存的，當然這些內存管理成本的付出主要也是為了給Redis不同數據類型提供一個統一的管理介面，實際作者也提供了多種方法幫助我們盡量節省內存使用，我們隨後會具體討論。

3. 各種數據類型應用和實現方式

下面我們先來逐一的分析下這7種數據類型的使用和內部實現方式:

  • String:

Strings 數據結構是簡單的key-value類型，value其實不僅是String，也可以是數字.

常用命令: set,get,decr,incr,mget 等。

應用場景：String是最常用的一種數據類型，普通的key/ value 存儲都可以歸為此類.即可以完全實現目前 Memcached 的功能，並且效率更高。還可以享受Redis的定時持久化，操作日誌及 Replication等功能。除了提供與 Memcached 一樣的get、set、incr、decr 等操作外，Redis還提供了下面一些操作：

    • 獲取字元串長度

    • 往字元串append內容

    • 設置和獲取字元串的某一段內容

    • 設置及獲取字元串的某一位（bit）

    • 批量設置一系列字元串的內容

實現方式：String在redis內部存儲默認就是一個字元串，被redisObject所引用，當遇到incr,decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。

  • Hash

常用命令：hget,hset,hgetall 等。

應用場景：在Memcached中，我們經常將一些結構化的信息打包成HashMap，在客戶端序列化後存儲為一個字元串的值，比如用戶的昵稱、年齡、性別、積分等，這時候在需要修改其中某一項時，通常需要將所有值取出反序列化後，修改某一項的值，再序列化存儲回去。這樣不僅增大了開銷，也不適用於一些可能並發操作的場合（比如兩個並發的操作都需要修改積分）。而Redis的Hash結構可以使你像在資料庫中Update一個屬性一樣只修改某一項屬性值。

我們簡單舉個實例來描述下Hash的應用場景，比如我們要存儲一個用戶信息對象數據，包含以下信息：

用戶ID為查找的key，存儲的value用戶對象包含姓名，年齡，生日等信息，如果用普通的key/value結構來存儲，主要有以下2種存儲方式：

第一種方式將用戶ID作為查找key,把其他信息封裝成一個對象以序列化的方式存儲，這種方式的缺點是，增加了序列化/反序列化的開銷，並且在需要修改其中一項信息時，需要把整個對象取回，並且修改操作需要對並發進行保護，引入CAS等複雜問題。

第二種方法是這個用戶信息對象有多少成員就存成多少個key-value對兒，用用戶ID+對應屬性的名稱作為唯一標識來取得對應屬性的值，雖然省去了序列化開銷和並發問題，但是用戶ID為重複存儲，如果存在大量這樣的數據，內存浪費還是非常可觀的。

那麼Redis提供的Hash很好的解決了這個問題，Redis的Hash實際是內部存儲的Value為一個HashMap，並提供了直接存取這個Map成員的介面，如下圖：

也就是說，Key仍然是用戶ID, value是一個Map，這個Map的key是成員的屬性名，value是屬性值，這樣對數據的修改和存取都可以直接通過其內部Map的Key(Redis里稱內部Map的key為field), 也就是通過 key(用戶ID) + field(屬性標籤) 就可以操作對應屬性數據了，既不需要重複存儲數據，也不會帶來序列化和並發修改控制的問題。很好的解決了問題。

這裡同時需要注意，Redis提供了介面(hgetall)可以直接取到全部的屬性數據,但是如果內部Map的成員很多，那麼涉及到遍歷整個內部Map的操作，由於Redis單線程模型的緣故，這個遍歷操作可能會比較耗時，而另其它客戶端的請求完全不響應，這點需要格外注意。

實現方式：

上面已經說到Redis Hash對應Value內部實際就是一個HashMap，實際這裡會有2種不同實現，這個Hash的成員比較少時Redis為了節省內存會採用類似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，對應的value redisObject的encoding為zipmap,當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。

  • List

常用命令：lpush,rpush,lpop,rpop,lrange等。

應用場景：

Redis list的應用場景非常多，也是Redis最重要的數據結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現。

Lists 就是鏈表，相信略有數據結構知識的人都應該能理解其結構。使用Lists結構，我們可以輕鬆地實現最新消息排行等功能。Lists的另一個應用就是消息隊列，

可以利用Lists的PUSH操作，將任務存在Lists中，然後工作線程再用POP操作將任務取出進行執行。Redis還提供了操作Lists中某一段的api，你可以直接查詢，刪除Lists中某一段的元素。

實現方式：

Redis list的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，Redis內部的很多實現，包括發送緩衝隊列等也都是用的這個數據結構。

  • Set

常用命令：

sadd,spop,smembers,sunion 等。

應用場景：

Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重複數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的。

Sets 集合的概念就是一堆不重複值的組合。利用Redis提供的Sets數據結構，可以存儲一些集合性的數據，比如在微博應用中，可以將一個用戶所有的關注人存在一個集合中，將其所有粉絲存在一個集合。Redis還為集合提供了求交集、並集、差集等操作，可以非常方便的實現如共同關注、共同喜好、二度好友等功能，對上面的所有集合操作，你還可以使用不同的命令選擇將結果返回給客戶端還是存集到一個新的集合中。

實現方式：

set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

  • Sorted Set

常用命令：

zadd,zrange,zrem,zcard等

使用場景：

Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過用戶額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重複的集合列表，那麼可以選擇sorted set數據結構，比如twitter 的public timeline可以以發表時間作為score來存儲，這樣獲取時就是自動按時間排好序的。

另外還可以用Sorted Sets來做帶權重的隊列，比如普通消息的score為1，重要消息的score為2，然後工作線程可以選擇按score的倒序來獲取工作任務。讓重要的任務優先執行。

實現方式：

Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表裡存放的是所有的成員，排序依據是HashMap里存的score,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。

  • Pub/Sub

Pub/Sub 從字面上理解就是發布（Publish）與訂閱（Subscribe），在Redis中，你可以設定對某一個key值進行消息發布及消息訂閱，當一個key值上進行了消息發布後，所有訂閱它的客戶端都會收到相應的消息。這一功能最明顯的用法就是用作實時消息系統，比如普通的即時聊天，群聊等功能。

  • Transactions

誰說NoSQL都不支持事務，雖然Redis的Transactions提供的並不是嚴格的ACID的事務（比如一串用EXEC提交執行的命令，在執行中伺服器宕機，那麼會有一部分命令執行了，剩下的沒執行），但是這個Transactions還是提供了基本的命令打包執行的功能（在伺服器不出問題的情況下，可以保證一連串的命令是順序在一起執行的，中間有會有其它客戶端命令插進來執行）。Redis還提供了一個Watch功能，你可以對一個key進行Watch，然後再執行Transactions，在這過程中，如果這個Watched的值進行了修改，那麼這個Transactions會發現並拒絕執行。

4. Redis實際應用場景

Redis在很多方面與其他資料庫解決方案不同：它使用內存提供主存儲支持，而僅使用硬碟做持久性的存儲；它的數據模型非常獨特，用的是單線程。另一個大區別在於，你可以在開發環境中使用Redis的功能，但卻不需要轉到Redis。

轉向Redis當然也是可取的，許多開發者從一開始就把Redis作為首選資料庫；但設想如果你的開發環境已經搭建好，應用已經在上面運行了，那麼更換資料庫框架顯然不那麼容易。另外在一些需要大容量數據集的應用，Redis也並不適合，因為它的數據集不會超過系統可用的內存。所以如果你有大數據應用，而且主要是讀取訪問模式，那麼Redis並不是正確的選擇。

然而我喜歡Redis的一點就是你可以把它融入到你的系統中來，這就能夠解決很多問題，比如那些你現有的資料庫處理起來感到緩慢的任務。這些你就可以通過Redis來進行優化，或者為應用創建些新的功能。在本文中，我就想探討一些怎樣將Redis加入到現有的環境中，並利用它的原語命令等功能來解決 傳統環境中碰到的一些常見問題。在這些例子中，Redis都不是作為首選資料庫。

1、顯示最新的項目列表

下面這個語句常用來顯示最新項目，隨著數據多了，查詢毫無疑問會越來越慢。

SELECT * FROM foo WHERE ... ORDER BY time DESC LIMIT 10

在Web應用中，「列出最新的回復」之類的查詢非常普遍，這通常會帶來可擴展性問題。這令人沮喪，因為項目本來就是按這個順序被創建的，但要輸出這個順序卻不得不進行排序操作。

類似的問題就可以用Redis來解決。比如說，我們的一個Web應用想要列出用戶貼出的最新20條評論。在最新的評論邊上我們有一個「顯示全部」的鏈接，點擊後就可以獲得更多的評論。

我們假設資料庫中的每條評論都有一個唯一的遞增的ID欄位。

我們可以使用分頁來製作主頁和評論頁，使用Redis的模板，每次新評論發表時，我們會將它的ID添加到一個Redis列表：

LPUSH latest.comments &

我們將列表裁剪為指定長度，因此Redis只需要保存最新的5000條評論：

LTRIM latest.comments 0 5000

每次我們需要獲取最新評論的項目範圍時，我們調用一個函數來完成（使用偽代碼）：

    FUNCTION get_latest_comments(start, num_items):
    id_list = redis.lrange("latest.comments",start,start+num_items - 1)
    IF id_list.length &< num_items id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...") END RETURN id_list END

這裡我們做的很簡單。在Redis中我們的最新ID使用了常駐緩存，這是一直更新的。但是我們做了限制不能超過5000個ID，因此我們的獲取ID函數會一直詢問Redis。只有在start/count參數超出了這個範圍的時候，才需要去訪問資料庫。

我們的系統不會像傳統方式那樣「刷新」緩存，Redis實例中的信息永遠是一致的。SQL資料庫（或是硬碟上的其他類型資料庫）只是在用戶需要獲取「很遠」的數據時才會被觸發，而主頁或第一個評論頁是不會麻煩到硬碟上的資料庫了。

2、刪除與過濾

我們可以使用LREM來刪除評論。如果刪除操作非常少，另一個選擇是直接跳過評論條目的入口，報告說該評論已經不存在。

有些時候你想要給不同的列表附加上不同的過濾器。如果過濾器的數量受到限制，你可以簡單的為每個不同的過濾器使用不同的Redis列表。畢竟每個列表只有5000條項目，但Redis卻能夠使用非常少的內存來處理幾百萬條項目。

3、排行榜相關

另一個很普遍的需求是各種資料庫的數據並非存儲在內存中，因此在按得分排序以及實時更新這些幾乎每秒鐘都需要更新的功能上資料庫的性能不夠理想。

典型的比如那些在線遊戲的排行榜，比如一個Facebook的遊戲，根據得分你通常想要：

- 列出前100名高分選手

- 列出某用戶當前的全球排名

這些操作對於Redis來說小菜一碟，即使你有幾百萬個用戶，每分鐘都會有幾百萬個新的得分。

模式是這樣的，每次獲得新得分時，我們用這樣的代碼：

ZADD leaderboard & &

你可能用userID來取代username，這取決於你是怎麼設計的。

得到前100名高分用戶很簡單：ZREVRANGE leaderboard 0 99。

用戶的全球排名也相似，只需要：ZRANK leaderboard &。

4、按照用戶投票和時間排序

排行榜的一種常見變體模式就像Reddit或Hacker News用的那樣，新聞按照類似下面的公式根據得分來排序：

score = points / time^alpha

因此用戶的投票會相應的把新聞挖出來，但時間會按照一定的指數將新聞埋下去。下面是我們的模式，當然演算法由你決定。

模式是這樣的，開始時先觀察那些可能是最新的項目，例如首頁上的1000條新聞都是候選者，因此我們先忽視掉其他的，這實現起來很簡單。

每次新的新聞貼上來後，我們將ID添加到列表中，使用LPUSH + LTRIM，確保只取出最新的1000條項目。

有一項後台任務獲取這個列表，並且持續的計算這1000條新聞中每條新聞的最終得分。計算結果由ZADD命令按照新的順序填充生成列表，老新聞則被清除。這裡的關鍵思路是排序工作是由後台任務來完成的。

5、處理過期項目

另一種常用的項目排序是按照時間排序。我們使用unix時間作為得分即可。

模式如下：

- 每次有新項目添加到我們的非Redis資料庫時，我們把它加入到排序集合中。這時我們用的是時間屬性，current_time和time_to_live。

- 另一項後台任務使用ZRANGE…SCORES查詢排序集合，取出最新的10個項目。如果發現unix時間已經過期，則在資料庫中刪除條目。

6、計數

Redis是一個很好的計數器，這要感謝INCRBY和其他相似命令。

我相信你曾許多次想要給資料庫加上新的計數器，用來獲取統計或顯示新信息，但是最後卻由於寫入敏感而不得不放棄它們。

好了，現在使用Redis就不需要再擔心了。有了原子遞增（atomic increment），你可以放心的加上各種計數，用GETSET重置，或者是讓它們過期。

例如這樣操作：

INCR user:& EXPIRE

user:& 60

你可以計算出最近用戶在頁面間停頓不超過60秒的頁面瀏覽量，當計數達到比如20時，就可以顯示出某些條幅提示，或是其它你想顯示的東西。

7、特定時間內的特定項目

另一項對於其他資料庫很難，但Redis做起來卻輕而易舉的事就是統計在某段特點時間裡有多少特定用戶訪問了某個特定資源。比如我想要知道某些特定的註冊用戶或IP地址，他們到底有多少訪問了某篇文章。

每次我獲得一次新的頁面瀏覽時我只需要這樣做：

SADD page:day1:&

&

當然你可能想用unix時間替換day1，比如time()-(time()%3600*24)等等。

想知道特定用戶的數量嗎？只需要使用SCARD page:day1:&

。

需要測試某個特定用戶是否訪問了這個頁面？SISMEMBER page:day1:&

。

8、實時分析正在發生的情況，用於數據統計與防止垃圾郵件等

我們只做了幾個例子，但如果你研究Redis的命令集，並且組合一下，就能獲得大量的實時分析方法，有效而且非常省力。使用Redis原語命令，更容易實施垃圾郵件過濾系統或其他實時跟蹤系統。

9、Pub/Sub

Redis的Pub/Sub非常非常簡單，運行穩定並且快速。支持模式匹配，能夠實時訂閱與取消頻道。

10、隊列

你應該已經注意到像list push和list pop這樣的Redis命令能夠很方便的執行隊列操作了，但能做的可不止這些：比如Redis還有list pop的變體命令，能夠在列表為空時阻塞隊列。

現代的互聯網應用大量地使用了消息隊列（Messaging）。消息隊列不僅被用於系統內部組件之間的通信，同時也被用於系統跟其它服務之間的交互。消息隊列的使用可以增加系統的可擴展性、靈活性和用戶體驗。非基於消息隊列的系統，其運行速度取決於系統中最慢的組件的速度（註：短板效應）。而基於消息隊列可以將系統中各組件解除耦合，這樣系統就不再受最慢組件的束縛，各組件可以非同步運行從而得以更快的速度完成各自的工作。

此外，當伺服器處在高並發操作的時候，比如頻繁地寫入日誌文件。可以利用消息隊列實現非同步處理。從而實現高性能的並發操作。

11、緩存

Redis的緩存部分值得寫一篇新文章，我這裡只是簡單的說一下。Redis能夠替代memcached，讓你的緩存從只能存儲數據變得能夠更新數據，因此你不再需要每次都重新生成數據了。

查看原文： 論述Redis和Memcached的差異-博客-雲棲社區-阿里雲

Redis 和 Memcache 都是基於內存的數據存儲系統。Memcached是高性能分散式內存緩存服務；Redis是一個開源的key-value存儲系統。與Memcached類似，Redis將大部分數據存儲在內存中，支持的數據類型包括：字元串、哈希 表、鏈表、等數據類型的相關操作。下面我們來進行來看一下redis和memcached的區別。權威比較

Redis的作者Salvatore Sanfilippo曾經對這兩種基於內存的數據存儲系統進行過比較：

  1. Redis支持伺服器端的數據操作：Redis相比Memcached來說，擁有更多的數據結構和並支持更豐富的數據操作，通常在Memcached里，你需要將數據拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和數據體積。在Redis中，這些複雜的操作通常和一般的GET/SET一樣高效。所以，如果需要緩存能夠支持更複雜的結構和操作，那麼Redis會是不錯的選擇。
  2. 內存使用效率對比：使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis採用hash結構來做key-value存儲，由於其組合式的壓縮，其內存利用率會高於Memcached。
  3. 性能對比：由於Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。

具體為什麼會出現上面的結論，以下為收集到的資料：

1、數據類型支持不同

與Memcached僅支持簡單的key-value結構的數據記錄不同，Redis支持的數據類型要豐富得多。最為常用的數據類型主要由五種：String、Hash、List、Set和Sorted Set。Redis內部使用一個redisObject對象來表示所有的key和value。redisObject最主要的信息如圖所示：

type代表一個value對象具體是何種數據類型，encoding是不同數據類型在redis內部的存儲方式，比如：type=string代表value存儲的是一個普通字元串，那麼對應的encoding可以是raw或者是int，如果是int則代表實際redis內部是按數值型類存儲和表示這個字元串的，當然前提是這個字元串本身可以用數值表示，比如:」123″ 「456」這樣的字元串。只有打開了Redis的虛擬內存功能，vm欄位欄位才會真正的分配內存，該功能默認是關閉狀態的。

1）String

常用命令：set/get/decr/incr/mget等；

應用場景：String是最常用的一種數據類型，普通的key/value存儲都可以歸為此類；

實現方式：String在redis內部存儲默認就是一個字元串，被redisObject所引用，當遇到incr、decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。

2）Hash

常用命令：hget/hset/hgetall等

應用場景：我們要存儲一個用戶信息對象數據，其中包括用戶ID、用戶姓名、年齡和生日，通過用戶ID我們希望獲取該用戶的姓名或者年齡或者生日；

實現方式：Redis的Hash實際是內部存儲的Value為一個HashMap，並提供了直接存取這個Map成員的介面。如圖所示，Key是用戶ID, value是一個Map。這個Map的key是成員的屬性名，value是屬性值。這樣對數據的修改和存取都可以直接通過其內部Map的Key(Redis里稱內部Map的key為field), 也就是通過 key(用戶ID) + field(屬性標籤) 就可以操作對應屬性數據。當前HashMap的實現有兩種方式：當HashMap的成員比較少時Redis為了節省內存會採用類似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，這時對應的value的redisObject的encoding為zipmap，當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。

3）List

常用命令：lpush/rpush/lpop/rpop/lrange等；

應用場景：Redis list的應用場景非常多，也是Redis最重要的數據結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現；

實現方式：Redis list的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，Redis內部的很多實現，包括發送緩衝隊列等也都是用的這個數據結構。

4）Set

常用命令：sadd/spop/smembers/sunion等；

應用場景：Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重複數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的；

實現方式：set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

5）Sorted Set

常用命令：zadd/zrange/zrem/zcard等；

應用場景：Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過用戶額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重複的集合列表，那麼可以選擇sorted set數據結構，比如twitter 的public timeline可以以發表時間作為score來存儲，這樣獲取時就是自動按時間排好序的。

實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表裡存放的是所有的成員，排序依據是HashMap里存的score,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。

2、內存管理機制不同

在Redis中，並不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。當物理內存用完時，Redis可以將一些很久沒用到的value交換到磁碟。Redis只會緩存所有的key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據「swappability = age*log(size_in_memory)」計算出哪些key對應的value需要swap到磁碟。然後再將這些key對應的value持久化到磁碟中，同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由於Redis將內存中的數據swap到磁碟中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個操作，直到子線程完成swap操作後才可以進行修改。當從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那麼Redis就需要從swap文件中載入相應數據，然後再返回給請求方。 這裡就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件載入後才會相應。這種策略在客戶端的數量較小，進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大並發的情況的。所以Redis運行我們設置I/O線程池的大小，對需要從swap文件中載入相應數據的讀取請求進行並發操作，減少阻塞的時間。

對於像Redis和Memcached這種基於內存的資料庫系統來說，內存管理的效率高低是影響系統性能的關鍵因素。傳統C語言中的malloc/free函數是最常用的分配和釋放內存的方法，但是這種方法存在著很大的缺陷：首先，對於開發人員來說不匹配的malloc和free容易造成內存泄露；其次頻繁調用會造成大量內存碎片無法回收重新利用，降低內存利用率；最後作為系統調用，其系統開銷遠遠大於一般函數調用。所以，為了提高內存的管理效率，高效的內存管理方案都不會直接使用malloc/free調用。Redis和Memcached均使用了自身設計的內存管理機制，但是實現方法存在很大的差異，下面將會對兩者的內存管理機制分別進行介紹。

Memcached默認使用Slab Allocation機制管理內存，其主要思想是按照預先規定的大小，將分配的內存分割成特定長度的塊以存儲相應長度的key-value數據記錄，以完全解決內存碎片問題。Slab Allocation機制只為存儲外部數據而設計，也就是說所有的key-value數據都存儲在Slab Allocation系統里，而Memcached的其它內存請求則通過普通的malloc/free來申請，因為這些請求的數量和頻率決定了它們不會對整個系統的性能造成影響Slab Allocation的原理相當簡單。 如圖所示，它首先從操作系統申請一大塊內存，並將其分割成各種尺寸的塊Chunk，並把尺寸相同的塊分成組Slab Class。其中，Chunk就是用來存儲key-value數據的最小單位。每個Slab Class的大小，可以在Memcached啟動的時候通過制定Growth Factor來控制。假定圖中Growth Factor的取值為1.25，如果第一組Chunk的大小為88個位元組，第二組Chunk的大小就為112個位元組，依此類推。

當Memcached接收到客戶端發送過來的數據時首先會根據收到數據的大小選擇一個最合適的Slab Class，然後通過查詢Memcached保存著的該Slab Class內空閑Chunk的列表就可以找到一個可用於存儲數據的Chunk。當一條資料庫過期或者丟棄時，該記錄所佔用的Chunk就可以回收，重新添加到空閑列表中。

從以上過程我們可以看出Memcached的內存管理制效率高，而且不會造成內存碎片，但是它最大的缺點就是會導致空間浪費。因為每個Chunk都分配了特定長度的內存空間，所以變長數據無法充分利用這些空間。如圖 所示，將100個位元組的數據緩存到128個位元組的Chunk中，剩餘的28個位元組就浪費掉了。

Redis的內存管理主要通過源碼中zmalloc.h和zmalloc.c兩個文件來實現的。Redis為了方便內存的管理，在分配一塊內存之後，會將這塊內存的大小存入內存塊的頭部。如圖所示，real_ptr是redis調用malloc後返回的指針。redis將內存塊的大小size存入頭部，size所佔據的內存大小是已知的，為size_t類型的長度，然後返回ret_ptr。當需要釋放內存的時候，ret_ptr被傳給內存管理程序。通過ret_ptr，程序可以很容易的算出real_ptr的值，然後將real_ptr傳給free釋放內存。

Redis通過定義一個數組來記錄所有的內存分配情況，這個數組的長度為ZMALLOC_MAX_ALLOC_STAT。數組的每一個元素代表當前程序所分配的內存塊的個數，且內存塊的大小為該元素的下標。在源碼中，這個數組為zmalloc_allocations。zmalloc_allocations[16]代表已經分配的長度為16bytes的內存塊的個數。zmalloc.c中有一個靜態變數used_memory用來記錄當前分配的內存總大小。所以，總的來看，Redis採用的是包裝的mallc/free，相較於Memcached的內存管理方法來說，要簡單很多。

3、數據持久化支持

Redis雖然是基於內存的存儲系統，但是它本身是支持內存數據的持久化的，而且提供兩種主要的持久化策略：RDB快照和AOF日誌。而memcached是不支持數據持久化操作的。

1）RDB快照

Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。但是一個持續寫入的資料庫如何生成快照呢？Redis藉助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，然後在子進程中循環所有的數據，將數據寫成為RDB文件。我們可以通過Redis的save指令來配置RDB快照生成的時機，比如配置10分鐘就生成快照，也可以配置有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規則，不需要重啟Redis。

Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然後通過原子性rename系統調用將臨時文件重命名為RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。RDB有他的不足，就是一旦資料庫出現問題，那麼我們的RDB文件中保存的數據並不是全新的，從上次RDB文件生成到Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的。

2）AOF日誌

AOF日誌的全稱是append only file，它是一個追加寫入的日誌文件。與一般資料庫的binlog不同的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標準命令。只有那些會導致數據發生修改的命令才會追加到AOF文件。每一條修改數據的命令都生成一條日誌，AOF文件會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個進程，直接遍曆數據，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日誌還是會寫到原來老的AOF文件中，同時還會記錄在內存緩衝區中。當重完操作完成後，會將所有緩衝區中的日誌一次性寫入到臨時文件中。然後調用原子性的rename命令用新的AOF文件取代老的AOF文件。

AOF是一個寫文件操作，其目的是將操作日誌寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的流程。在Redis中對AOF調用write寫入後，通過appendfsync選項來控制調用fsync將其寫到磁碟上的時間，下面appendfsync的三個設置項，安全強度逐漸變強。

  • appendfsync no 當設置appendfsync為no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩衝區中的數據寫到磁碟上。
  • appendfsync everysec 當設置appendfsync為everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩衝區中的數據寫到磁碟。但是當這一次的fsync調用時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。所以結論就是，在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鐘會進行一次fsync操作。這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的數據，一次性將日誌寫到磁碟。
  • appednfsync always 當設置appendfsync為always時，每一次寫操作都會調用一次fsync，這時數據是最安全的，當然，由於每次都會執行fsync，所以其性能也會受到影響。

對於一般性的業務需求，建議使用RDB的方式進行持久化，原因是RDB的開銷並相比AOF日誌要低很多，對於那些無法忍數據丟失的應用，建議使用AOF日誌。

4、集群管理的不同

Memcached是全內存的數據緩衝系統，Redis雖然支持數據的持久化，但是全內存畢竟才是其高性能的本質。作為基於內存的存儲系統來說，機器物理內存的大小就是系統能夠容納的最大數據量。如果需要處理的數據量超過了單台機器的物理內存大小，就需要構建分散式集群來擴展存儲能力。

Memcached本身並不支持分散式，因此只能在客戶端通過像一致性哈希這樣的分散式演算法來實現Memcached的分散式存儲。下圖給出了Memcached的分散式存儲實現架構。當客戶端向Memcached集群發送數據之前，首先會通過內置的分散式演算法計算出該條數據的目標節點，然後數據會直接發送到該節點上存儲。但客戶端查詢數據時，同樣要計算出查詢數據所在的節點，然後直接向該節點發送查詢請求以獲取數據。

相較於Memcached只能採用客戶端實現分散式存儲，Redis更偏向於在伺服器端構建分散式存儲。最新版本的Redis已經支持了分散式存儲功能。Redis Cluster是一個實現了分散式且允許單點故障的Redis高級版本，它沒有中心節點，具有線性可伸縮的功能。下圖給出Redis Cluster的分散式存儲架構，其中節點與節點之間通過二進位協議進行通信，節點與客戶端之間通過ascii協議進行通信。在數據的放置策略上，Redis Cluster將整個key的數值域分成4096個哈希槽，每個節點上可以存儲一個或多個哈希槽，也就是說當前Redis Cluster支持的最大節點數就是4096。Redis Cluster使用的分散式演算法也很簡單：crc16( key ) % HASH_SLOTS_NUMBER。

為了保證單點故障下的數據可用性，Redis Cluster引入了Master節點和Slave節點。在Redis Cluster中，每個Master節點都會有對應的兩個用於冗餘的Slave節點。這樣在整個集群中，任意兩個節點的宕機都不會導致數據的不可用。當Master節點退出後，集群會自動選擇一個Slave節點成為新的Master節點。

redis是比memcached快的。看這個問題http://www.zhihu.com/question/19599545

1.存儲容量：memcached超過內存比例會抹掉前面的數據，而redis會存儲在磁碟

2.支持數據類型：memcached只支持string，redis支持更多。如：hash list集合 有序集合

3.持久化：redis支持兩種持久化策略，memcached無

4.主從：redis支持

5.memcached自帶連接池和配合hash， redis3.0的集群

6.

先說Redis的特點

  1. Redis 有各種豐富的數據結構，如果和業務對口，用起來會非常方便（比如Timeline, JobQueue等場合）。
  2. Redis支持數據持久化，雖然無法像資料庫那樣完善，但對於互聯網這種場景，完全夠用了。

Memcached的特點

純粹的cache，意思是一般只會expire cache而不會修改(或append)cache。區別就在於，你fetch的時候總會考慮cache missing的情況。

作為cache時，關於性能比較

  1. 兩者都經過了良好的設計，在０～300個client的並發GET/SET下，throughput 都在保持在10萬/秒以上。
  2. memcached的性能比redis要好很多(數倍)，這也比較容易理解。但往往瓶頸會在client或者網路等地方。

這裡是benchmark

http://dormando.livejournal.com/525147.html

memcached 是多線程的 redis目前是單線程

memcached 能夠保證數據一致性

redis支持更多的類型

Memcache vs. Redis?

簡譯如下：

Redis的優點如下：

  • 豐富的數據結構和命令
  • 默認就有持久化
  • 事務
  • 值有512MB（memcached最大是1MB）

Memcached的優點：

  • 可以做集群

請問,所以結論是redis已經完全可以替代memcache了嗎,如果不是,能否舉一些反例呢?

大神們，能否總結一下redis跟關係型資料庫的優缺點？

寫的質量很高，謝謝了

Haisql_memcache_1.0.35性能測試報告
目前版本的 Haisql_memcache 新功能方面沒有新增，但是性能優化後，有不少提高，版本號1.0.35主要是優化了內存分配機制，對於最常見的變數std::string，std::shared_ptr&等等都定義了自己的更高效率的內置資源池，實現更好的內存分配器和內存回收機制，第2個就是將各變數組合排列，將同時變化的放到一起，提高CPU cacheline的效率，第3個就是將網路層boost asio中的函數盡量使用更接近底層的調用函數receive/send等，減少調用的層次等等辦法。
目前查詢性能已經比 memcached 原生版本高64%，測試方法和測試軟體都是官方的 memcslap( ubuntu自帶安裝包 ) 。本機測試的時候，打開 top 可以明顯看到伺服器軟體 haisql_memcache 比測試軟體memcslap消耗的CPU資源小得多，說明了伺服器端代碼的效率確實是非常高。
一．與memcached性能對比的測試方法與結果：
1.運行伺服器
1) 運行 memcached, 需要指定8192M內存， 以便可以測試百萬以上的數據量, 指定埠號是1983，命令如下：
memcached -m 8192 -p 1983
2) 我們的程序是動態申請內存，因此，不需要指定預先分配的內存量, 直接運行就可以了，啟動運行伺服器命令如下：
./haisql_memcache_chinese
我們的軟體默認運行埠是1971
每次測試後需要清理運行環境, memcached直接ctrl_C退出就可以了.
我們的軟體因為退出時默認自動保存內存數據, 因此,需要在退出程序後,執行 rm *.txt;sync;sync 清理掉自動保存的數據, 相當於清空全部數據,這樣下次啟動時就是空數據表了.
2.使用 memcslap的測試情況
1)先測試 讀性能
測試軟體自動寫入1萬條記錄, 然後測試讀取900萬次, 我們的軟體執行時間是23.631秒, memcache執行時間是38.828秒, 我們的軟體比memcache快64%.
我們的軟體讀性能如下: 讀4.1Kbyte的數據包大小, 4核8線程3.4G主頻DDR3內存, 讀900萬次數據, 900並發, 花費時間 23.631秒, 讀性能38萬QPS。
讀性能 測試結果：
第1次是memcached的測試結果, 第2次是我們的軟體測試結果
guo@guo-desktop:~$ memcslap --concurrency=900 --servers=127.0.0.1:1983 --test=get
Threads connecting to servers 900
Took 38.828 seconds to read data

guo@guo-desktop:~$ memcslap --concurrency=900 --servers=127.0.0.1:1971 --test=get
Threads connecting to servers 900
Took 23.631 seconds to read data
2)測試 寫性能
測試軟體測試寫入100萬條記錄, 我們的軟體執行時間是3.136秒, memcache執行時間是4.078秒, 我們的軟體比memcache快30%.
我們的軟體寫性能如下: 寫4.1Kbyte的數據包大小, 4核8線程3.4G主頻DDR3內存, 寫100萬次數據, 100並發, 花費時間3.136秒, 寫性能32萬TPS.
寫性能 測試結果：
第1次是memcached的測試結果, 第2次是我們的軟體測試結果
guo@guo-desktop:~$ memcslap --concurrency=100 --servers=127.0.0.1:1983
Threads connecting to servers 100
Took 4.078 seconds to load data

guo@guo-desktop:~$ memcslap --concurrency=100 --servers=127.0.0.1:1971
Threads connecting to servers 100
Took 3.136 seconds to load data
二．與redis性能對比的測試方法與結果：
由於redis只支持單核，不支持多核，為了與redis做比較，專門找了一台雙核的機器，Intel(R) Pentium(R) CPU G3258 @ 3.20GHz,本機127.0.0.1測試, 相當於一個CPU用於測試，一個CPU用於伺服器， 以便測試對比一下與Redis的單核性能對比.
單核查詢性能還是比redis更快， 先插入10000條記錄，900連接，每連接10000次查詢，總共測試900萬次查詢，每次查詢value包大小4096位元組,redis花費93.46秒， 我們的軟體花費63.792秒, 測試方法都是官方的測試軟體，我們的單核性能比redis的單核性能快 46.5%.
測試情況如下：
guo@guo-desktop2:~$ redis-cli
127.0.0.1:6379&> flushall
OK
127.0.0.1:6379&> quit
guo@guo-desktop2:~$
guo@guo-desktop2:~$
guo@guo-desktop2:~$ redis-benchmark -t set -n 10000 -r 10000 -d 4096 -c 100
====== SET ======
10000 requests completed in 0.08 seconds
100 parallel clients
4096 bytes payload
keep alive: 1

91.61% &<= 1 milliseconds 99.99% &<= 2 milliseconds 100.00% &<= 2 milliseconds 125000.00 requests per second

guo@guo-desktop2:~$ redis-benchmark -t get -n 9000000 -r 10000 -d 4096 -c 900
====== GET ======
9000000 requests completed in 93.46 seconds
900 parallel clients
4096 bytes payload
keep alive: 1

0.00% &<= 4 milliseconds 65.86% &<= 5 milliseconds 72.01% &<= 6 milliseconds 72.98% &<= 7 milliseconds 73.56% &<= 8 milliseconds 97.70% &<= 9 milliseconds 99.45% &<= 10 milliseconds 99.72% &<= 11 milliseconds 99.80% &<= 12 milliseconds 99.97% &<= 13 milliseconds 100.00% &<= 14 milliseconds 100.00% &<= 14 milliseconds 96294.80 requests per second

guo@guo-desktop2:~$ memcslap --concurrency=900 --servers=127.0.0.1:1971 --test=get
Threads connecting to servers 900
Took 63.792 seconds to read data

memcached的客戶端支持一致性hash，可以將memcached部署到多個實例，提高系統的可用性和存儲容量

不錯

寫的太好了，多謝分享.

推薦閱讀：

※Redis 性能比 Memcached 好嗎？有哪些網站採用 Redis？使用 Memcached 的出色網站有哪些？
※redis、memcache和mongodb各自的優點是什麼，怎麼選擇呢？

TAG:Redis | Memcached |