Redis 性能比 Memcached 好嗎？有哪些網站採用 Redis？使用 Memcached 的出色網站有哪些？
這是事實，上面的回答已經說出了真實的原因。
ITeye(JavaEye)和CSDN現在都用到了Redis，採用memcached比較出色的網站有ITeye(JavaEye)
以後會考慮更多的嘗試Redis，不過Redis現在客戶端質量不行，所以還要等。
我們用memcached非常好，唯一不爽的地方是萬一伺服器掉電重啟以後的緩存預熱過程比較長，導致網站負載過高。Redis的持久化存儲可以解決這個問題。
關於Redis和Memcached的比較，可能沒有多少人能比Redis作者本人能說得更好。Redis作者的說法是，平均到單個核上的性能，在單條數據不大的情況下，Redis會更好。
因為Redis是單線程的，只能使用一個核。而Memcached是多線程的，所以對一個實例來說，性能上肯定是Memcached佔優勢。
因為Redis的單線程，導致所有IO也是串列化的，當單條數據太大，IO等待會費掉時間，而不是程序本身性能或者複雜度。
因為Redis有更複雜的數據類型，所以很多操作必然會比Memcached的get set操作更耗時。
1.首先,memcached和redis都基於內存,memcached偏向cache,redis更多扮演資料庫的角色,支持更豐富的數據類型,單從性能上比,不太具有可比性,不會有數量級的差異. 兩者也可並存,在資料庫(redis)前端布置cache(memcached)也是一種節省資源的方式;
2. 用redis的網站很多,這裡有一個列表
http://redis.io/topics/whos-using-redis
3. 使用memcached出色的網站是google,facebook,一些公司,幾千台的memcached集群很常見.
4. 如果有想法想用redis代替memcached集群,不建議,一致性哈希的實現有待成熟,還不能像memcached集群那樣動態擴容,數據規劃不得不加倍小心;
5. 如果想使用redis的持久化,那麼設計的時候,要注意redis失效的可能,畢竟還不是成熟的產品,宕機後的載入恢復也可能漫長.
btw：選擇一個產品，性能往往不是關鍵的要素，除非你這個產品成為了整個系統的瓶頸。
轉載 timyang［後端技術］ http://timyang.net/data/redis-misunderstanding/
很多開發者都認為Redis不可能比Memcached快，Memcached完全基於內存，而Redis具有持久化保存特性，即使是非同步的，Redis也不可能比Memcached快。但是測試結果基本是Redis占絕對優勢。一直在思考這個原因，目前想到的原因有這幾方面。- Libevent。和Memcached不同，Redis並沒有選擇libevent。Libevent為了迎合通用性造成代碼龐大(目前Redis代碼還不到libevent的1/3)及犧牲了在特定平台的不少性能。Redis用libevent中兩個文件修改實現了自己的epoll event loop(4)。業界不少開發者也建議Redis使用另外一個libevent高性能替代libev，但是作者還是堅持Redis應該小巧並去依賴的思路。一個印象深刻的細節是編譯Redis之前並不需要執行./configure。
- CAS問題。CAS是Memcached中比較方便的一種防止競爭修改資源的方法。CAS實現需要為每個cache key設置一個隱藏的cas token，cas相當value版本號，每次set會token需要遞增，因此帶來CPU和內存的雙重開銷，雖然這些開銷很小，但是到單機10G+ cache以及QPS上萬之後這些開銷就會給雙方相對帶來一些細微性能差別(5)。
Memcached是全內存Cache，僅此功能，數據持久化等相關都需要自己製作。可以看作是麻煩，也可以看作是自由。
Redis上面已經說了，更多扮演的是資料庫的功能，自帶數據持久化。
這也是我認為最直接的它和Redis的區別。
性能可能不是區分這兩者的最主要原因，更多的時候選擇使用Memcached而不是其他，只是因為它做的工作少，可擴展性強，個人感覺。
小站點，業務大部分基於傳統關係資料庫的，cache輔助提高速度的話，建議memcache,其原則是簡單，好用，無學習成本。
中型站點，可能部分業務會遇到資料庫瓶頸，那麼redis除了cache之外，本身強大的數據結構，可以代替部分資料庫功能，所以可以考慮代替memcache
大型展現，如中型站點，可以考慮遷移部分業務到redis服務，但是如果涉及到大規模分散式部署，那麼由於redis的分散式與memcache其實不一樣，更多可能根據架構來考慮選擇了。
redis比mc更耗內存，如果只是簡單的key value並且沒有持久化cache需求，可以考慮採用mc。大部分情況下redis可以替換mc
實踐出真知。
今日閑得無聊，測試了一下Redis和memcached的性能。環境如下圖所示：
簡單測試腳本如下：
一、單進程，腳本運行於docker實例上，redis和memcached同時運行於另一個docker實例上。分別寫入1000萬條數據。測試代碼段完全相同。
1、redis的表現：
2、memcached的表現：
結論：redis比memcached快14%左右；
二、單進程，腳本，redis，memcached全位於實體伺服器母機系統上。測試代碼相同。
1、redis的表現：
2、memcached的表現：
結論：redis比memcached快12%左右；
三、腳本，redis，memcached位於同一母機。各自開10個進程。每個進程寫入1000萬數據，共計寫入1億條數據。
1、redis的表現：
2、memcached的表現：
結論：memcached比redis快100%以上。
綜上，在單進程壓力 測試下，redis比memcached有15%的提升，在多進程壓力測試下，memcached比redis快100%以上。測試結果不代表真實應用結果。
============================================
等下開30個進程，寫3億條數據測試一下，再把對比結果發上來看看。
30個進程每個寫1000萬共計3億次寫入測試完畢，memcached共花了2714秒，最快完成的進程和最後完成的時間相差不超過2分鐘。
redis的寫入，約在450萬的時候，連接不上redis伺服器，PHP程序掛了。導致測試工作未能完成，便不再繼續進行測試。
總體來說，初步測試。兩者都是極優秀的緩存工具。由於redis只能利用單核心，因此在高並發下面，memcached因為功能更單一，所以表現得速度更強，表現得更穩定，但同時也更佔用CPU資源。 如不需要持久化或是其它redis的功能，用memcached更優。
推薦閱讀：