分類: 問答 常識詞典 編輯 : 常識 發(fā)布 : 08-22

閱讀 :325

Redis 的極限壓力為啥大于 Memcac-e？4 個答案

答案 1：

新浪微博架構(gòu)師Tim Yang對此有寫過博客：Redis不可能比Memcac-e快很多開發(fā)者都認(rèn)為Redis不可能比Memcac-ed快，Memcac-ed完全基于內(nèi)存，而Redis具有持久化保存特性，即使是異步的，Redis也不可能比Memcac-ed快。但是測試結(jié)果基本是Redis占絕對優(yōu)勢。一直在思考這個原因，目前想到的原因有這幾方面。

Libevent。和Memcac-ed不同，Redis并沒有選擇libevent。Libevent為了迎合通用性造成代碼龐大(目前Redis代碼還不到libevent的1/3)及犧牲了在特定平臺的不少性能。Redis用libevent中兩個文件修改實(shí)現(xiàn)了自己的epoll event loop(4)。業(yè)界不少開發(fā)者也建議Redis使用另外一個libevent高性能替代libev，但是作者還是堅(jiān)持Redis應(yīng)該小巧并去依賴的思路。一個印象深刻的細(xì)節(jié)是編譯Redis之前并不需要執(zhí)行./configure。

CAS問題。CAS是Memcac-ed中比較方便的一種防止競爭修改資源的方法。CAS實(shí)現(xiàn)需要為每個cac-e key設(shè)置一個隱藏的cas token，cas相當(dāng)value版本號，每次set會token需要遞增，因此帶來CPU和內(nèi)存的雙重開銷，雖然這些開銷很小，但是到單機(jī)10G+ cac-e以及QPS上萬之后這些開銷就會給雙方相對帶來一些細(xì)微性能差別(5)。

timyang.net/data...

答案 2：

最關(guān)鍵的還是redis自己實(shí)現(xiàn)了一套簡單的網(wǎng)絡(luò)庫吧..memcac-ed是被libevent給拖累的.性能上不去是卡在libevent上。cas有影響，但是影響實(shí)在有限。

答案 3：

個人測試過，單從get性能還是memcac-e最快的，redis的set比memcac-e快，還有那些memcac-e沒有的復(fù)雜數(shù)據(jù)結(jié)構(gòu)類型，這些沒法比較了，所以redis有復(fù)雜的應(yīng)用場景，沒法單純跟memcac-e進(jìn)行負(fù)載方面的比較。

答案 4：

這個是我個人的測試結(jié)果，可以參考一下 blog.sina.cn/s/blog_4...

下一篇:有沒有好點(diǎn)的搜圖網(wǎng)站？？類似全景華蓋那種的。 下一篇 【方向鍵 ( → )下一篇】

上一篇:用視高的產(chǎn)品自建-會議服務(wù)器，運(yùn)營中遇到的最大問題是什么？ 上一篇 【方向鍵 ( ← )上一篇】