Redis 的極限壓力為啥大於 Memcache？

01-23

新浪微博架構師Tim Yang對此有寫過博客：

Redis不可能比Memcache快

很多開發者都認為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)。

http://timyang.net/data/redis-misunderstanding/

最關鍵的還是redis自己實現了一套簡單的網路庫吧..

memcached是被libevent給拖累的.性能上不去是卡在libevent上。

cas有影響，但是影響實在有限。

我覺得可能是網路層的鍋，memcache和redis的改進餘地很大，很多古老的思路，架構也不夠先進，網路層我這邊主要是先進的boost asio庫，另外我們研發了比std unordered_set/map快70%的hash_map/set庫，我們小團隊用C++從頭開始做KV資料庫，只用了一年時間，查詢性能已經遠遠超過memcache和redis了，tcp/ip下的查詢性能比memcache快70%，單核下也比redis快很多，我們還是直接new/delete動態分配內存的，不象memcache預分配內存，內存方面弄個池子的話，性能還可以提升。just do it.下載測試 http://www.haisql.com

單從代碼上來看，redis不會比memcache快，memcache使用一個dispatch+n個工作進程的方式，造成了桶鎖的開銷，然後像redis作者說的平均到單個核上的性能redis牛逼，好吧你贏了。

Redis極限不如Memcache啊

我壓過，簡單場景下Redis 10W &<-&> Memcache 60W

Memcache默認4線程，每個線程一個EventLoop，而Redis只有一個線程

這個是我個人的測試結果，可以參考一下

http://blog.sina.com.cn/s/blog_497dbcd10100syj5.html

個人測試過，單從get性能還是memcache最快的，redis的set比memcache快，還有那些memcache沒有的複雜數據結構類型，這些沒法比較了，所以redis有複雜的應用場景，沒法單純跟memcache進行負載方面的比較。

我覺得還是各方面都很重要吧, 性能體現的就是演算法/網路/優化/多線程等各方面, 網路層的開銷不可忽略, 但也只是一個方面吧. 我們的軟體的網路層是Boost Asio庫, 能夠在所有操作系統下運行, 按理說性能不會比裸epoll高, 但是由於使用了大量新的先進演算法後, 各方面綜合就遠遠超越傳統演算法的軟體.

目前國產的haisql_memcache 更快, 與memcache在指令集上兼容, 查詢性能已經比memcache大約高出64%，插入/更新性能比memcache高出30%，單核查詢性能比Redis快 46.5%。

軟體下載地址是: 服務支持 / 產品下載_烏魯木齊雲山雲海信息技術有限責任公司

測試方法：
1) 運行 memcached, 需要指定8192M內存，以便可以測試百萬以上的數據量, 指定埠號是1983
memcached -m 8192 -p 1983

我們的程序是動態申請內存，因此，不需要指定預先分配的內存量, 直接運行就可以了
haisql_memcache_chinese
我們的軟體默認運行埠是1971

每次測試後需要清理運行環境, memcached直接ctrl_C退出就可以了.
我們的軟體因為退出時默認自動保存內存數據, 因此,需要在退出程序後,執行 rm *.txt;sync;sync 清理掉自動保存的數據, 相當於清空全部數據,這樣下次啟動時就是空數據表了.

測試情況：
先測試讀性能測試軟體自動寫入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

測試寫性能測試軟體測試寫入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只支持單線程，我們在多核CPU下比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%，
測試情況如下：都是清空數據後，先插入1萬條記錄，然後讀900萬次，檢查查詢時間，都是官方的測試軟體。

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

r 和m應該結合使用才能發揮最大的優勢