前幾天新浪微博發(fā)生了一起大的系統(tǒng)故障，很多搞技術(shù)的朋友都比較關(guān)心，其中的原因不會(huì)超出James Hamilton在On Designing and Deploying InterNET-Scale Service概括的那幾個(gè)范圍，James第一條經(jīng)驗(yàn)“Design for failure”是所有互聯(lián)網(wǎng)架構(gòu)成功的一個(gè)關(guān)鍵。互聯(lián)網(wǎng)系統(tǒng)的工程理論其實(shí)非常簡單，James paper中內(nèi)容幾乎稱不上理論，而是多條實(shí)踐經(jīng)驗(yàn)分享，每個(gè)公司對(duì)這些經(jīng)驗(yàn)的理解及執(zhí)行力決定了架構(gòu)成敗。

　　題外話說完，最近又研究了Redis。去年曾做過一個(gè)MemcacheDB, Tokyo Tyrant, Redis performance test，到目前為止，這個(gè)benchmark結(jié)果依然有效。這1年我們經(jīng)歷了很多眼花繚亂的keyvalue存儲(chǔ)產(chǎn)品的誘惑，從Cassandra的淡出(Twitter暫停在主業(yè)務(wù)使用)到HBase的興起(Facebook新的郵箱業(yè)務(wù)選用HBase)，當(dāng)再回頭再去看Redis，發(fā)現(xiàn)這個(gè)只有1萬多行源代碼的程序充滿了神奇及大量未經(jīng)挖掘的特性。Redis性能驚人，國內(nèi)前十大網(wǎng)站的子產(chǎn)品估計(jì)用1臺(tái)Redis就可以滿足存儲(chǔ)及Cache的需求。除了性能印象之外，業(yè)界其實(shí)普遍對(duì)Redis的認(rèn)識(shí)存在一定誤區(qū)。本文提出一些觀點(diǎn)供大家探討。

　　1. Redis是什么

　　這個(gè)問題的結(jié)果影響了我們?cè)趺从肦edis。如果你認(rèn)為Redis是一個(gè)key value store, 那可能會(huì)用它來代替MySQL；如果認(rèn)為它是一個(gè)可以持久化的cache, 可能只是它保存一些頻繁訪問的臨時(shí)數(shù)據(jù)。Redis是REmote DIctionary Server的縮寫，在Redis在官方網(wǎng)站的的副標(biāo)題是A persistent key-value database with built-in NET interface written in ANSI-C for Posix systems，這個(gè)定義偏向key value store。另外一些看法則認(rèn)為Redis是一個(gè)memory database，另外一些人則認(rèn)為Redis是一個(gè)data structure server，因?yàn)镽edis支持復(fù)雜的數(shù)據(jù)特性，比如List, Set等。對(duì)Redis的作用的不同解讀決定了你對(duì)Redis的使用方式。

　　互聯(lián)網(wǎng)數(shù)據(jù)目前基本使用兩種方式來存儲(chǔ)，關(guān)系數(shù)據(jù)庫或者key value。但是這些互聯(lián)網(wǎng)業(yè)務(wù)本身并不屬于這兩種數(shù)據(jù)類型，比如用戶在社會(huì)化平臺(tái)中的關(guān)系，它是一個(gè)list，如果要用關(guān)系數(shù)據(jù)庫存儲(chǔ)就需要轉(zhuǎn)換成一種多行記錄的形式，這種形式存在很多冗余數(shù)據(jù)，每一行需要存儲(chǔ)一些重復(fù)信息。如果用key value存儲(chǔ)則修改和刪除比較麻煩，需要將全部數(shù)據(jù)讀出再寫入。Redis在內(nèi)存中設(shè)計(jì)了各種數(shù)據(jù)類型，讓業(yè)務(wù)能夠高速原子的訪問這些數(shù)據(jù)結(jié)構(gòu)，并且不需要關(guān)心持久存儲(chǔ)的問題，從架構(gòu)上解決了前面兩種存儲(chǔ)需要走一些彎路的問題。

　　2. Redis不可能比Memcache快

　　很多開發(fā)者都認(rèn)為Redis不可能比Memcached快，Memcached完全基于內(nèi)存，而Redis具有持久化保存特性，即使是異步的，Redis也不可能比Memcached快。但是測(cè)試結(jié)果基本是Redis占絕對(duì)優(yōu)勢(shì)。一直在思考這個(gè)原因，目前想到的原因有這幾方面。

• Libevent。和Memcached不同，Redis并沒有選擇libevent。Libevent為了迎合通用性造成代碼龐大(目前Redis代碼還不到libevent的1/3)及犧牲了在特定平臺(tái)的不少性能。Redis用libevent中的兩個(gè)文件修改實(shí)現(xiàn)了自己的epoll event loop。業(yè)界不少開發(fā)者也建議Redis使用另外一個(gè)libevent高性能替代libev，但是作者還是堅(jiān)持Redis應(yīng)該小巧并去依賴的思路。一個(gè)印象深刻的細(xì)節(jié)是編譯Redis之前并不需要執(zhí)行./configure。
• CAS問題。CAS是Memcached中比較方便的一種防止競爭修改資源的方法。CAS實(shí)現(xiàn)需要為每個(gè)cache key設(shè)置一個(gè)隱藏的cas token，cas相當(dāng)value版本號(hào)，每次set會(huì)token需要遞增，因此帶來CPU和內(nèi)存的雙重開銷，雖然這些開銷很小，但是到單機(jī)10G+ cache以及QPS上萬之后這些開銷就會(huì)給雙方相對(duì)帶來一些細(xì)微性能差別。

　　3. 單臺(tái)Redis的存放數(shù)據(jù)必須比物理內(nèi)存小

　　Redis的數(shù)據(jù)全部放在內(nèi)存帶來了高速的性能，但是也帶來一些不合理之處。比如一個(gè)中型網(wǎng)站有100萬注冊(cè)用戶，如果這些資料要用Redis來存儲(chǔ)，內(nèi)存的容量必須能夠容納這100萬用戶。但是業(yè)務(wù)實(shí)際情況是100萬用戶只有5萬活躍用戶，1周來訪問過1次的也只有15萬用戶，因此全部100萬用戶的數(shù)據(jù)都放在內(nèi)存有不合理之處，RAM需要為冷數(shù)據(jù)買單。

　　這跟操作系統(tǒng)非常相似，操作系統(tǒng)所有應(yīng)用訪問的數(shù)據(jù)都在內(nèi)存，但是如果物理內(nèi)存容納不下新的數(shù)據(jù)，操作系統(tǒng)會(huì)智能地將部分長期沒有訪問的數(shù)據(jù)交換到磁盤，為新的應(yīng)用留出空間?，F(xiàn)代操作系統(tǒng)給應(yīng)用提供的并不是物理內(nèi)存，而是虛擬內(nèi)存(Virtual Memory)的概念。

　　基于相同的考慮，Redis 2.0也增加了VM特性。讓Redis數(shù)據(jù)容量突破了物理內(nèi)存的限制。并實(shí)現(xiàn)了數(shù)據(jù)冷熱分離。

　　4. Redis的VM實(shí)現(xiàn)是重復(fù)造輪子

　　Redis的VM依照之前的epoll實(shí)現(xiàn)思路依舊是自己實(shí)現(xiàn)。但是在前面操作系統(tǒng)的介紹提到OS也可以自動(dòng)幫程序?qū)崿F(xiàn)冷熱數(shù)據(jù)分離，Redis只需要OS申請(qǐng)一塊大內(nèi)存，OS會(huì)自動(dòng)將熱數(shù)據(jù)放入物理內(nèi)存，冷數(shù)據(jù)交換到硬盤，另外一個(gè)知名的“理解了現(xiàn)代操作系統(tǒng)”的Varnish就是這樣實(shí)現(xiàn)，也取得了非常成功的效果。

　　作者antirez在解釋為什么要自己實(shí)現(xiàn)VM中提到幾個(gè)原因。主要OS的VM換入換出是基于Page概念，比如OS VM 1個(gè)Page是4K, 4K中只要還有一個(gè)元素，即使只有1個(gè)字節(jié)被訪問，這個(gè)頁也不會(huì)被SWAP, 換入也同樣道理，讀到一個(gè)字節(jié)可能會(huì)換入4K無用的內(nèi)存。而Redis自己實(shí)現(xiàn)則可以達(dá)到控制換入的粒度。另外訪問操作系統(tǒng)SWAP內(nèi)存區(qū)域時(shí)block進(jìn)程，也是導(dǎo)致Redis要自己實(shí)現(xiàn)VM原因之一。

　　5. 用get/set方式使用Redis

　　作為一個(gè)key value存在，很多開發(fā)者自然的使用set/get方式來使用Redis，實(shí)際上這并不是最優(yōu)化的使用方法。尤其在未啟用VM情況下，Redis全部數(shù)據(jù)需要放入內(nèi)存，節(jié)約內(nèi)存尤其重要。

　　假如一個(gè)key-value單元需要最小占用512字節(jié)，即使只存一個(gè)字節(jié)也占了512字節(jié)。這時(shí)候就有一個(gè)設(shè)計(jì)模式，可以把key復(fù)用，幾個(gè)key-value放入一個(gè)key中，value再作為一個(gè)set存入，這樣同樣512字節(jié)就會(huì)存放10-100倍的容量。

　　這就是為了節(jié)約內(nèi)存，建議使用hashset而不是set/get的方式來使用Redis，詳細(xì)方法見參考文獻(xiàn)。

　　6. 使用aof代替snapshot

　　Redis有兩種存儲(chǔ)方式，默認(rèn)是snapshot方式，實(shí)現(xiàn)方法是定時(shí)將內(nèi)存的快照(snapshot)持久化到硬盤，這種方法缺點(diǎn)是持久化之后如果出現(xiàn)crash則會(huì)丟失一段數(shù)據(jù)。因此在完美主義者的推動(dòng)下作者增加了aof方式。aof即append only mode，在寫入內(nèi)存數(shù)據(jù)的同時(shí)將操作命令保存到日志文件，在一個(gè)并發(fā)更改上萬的系統(tǒng)中，命令日志是一個(gè)非常龐大的數(shù)據(jù)，管理維護(hù)成本和恢復(fù)重建成本都非常高。另外更重要的是Redis是一個(gè)內(nèi)存數(shù)據(jù)結(jié)構(gòu)模型，所有的優(yōu)勢(shì)都是建立在對(duì)內(nèi)存復(fù)雜數(shù)據(jù)結(jié)構(gòu)高效的原子操作上，這樣就看出aof是一個(gè)非常不協(xié)調(diào)的部分。

　　其實(shí)aof目的主要是數(shù)據(jù)可靠性及高可用性，在Redis中有另外一種方法來達(dá)到目的：Replication。由于Redis的高性能，復(fù)制基本沒有延遲。這樣達(dá)到了防止單點(diǎn)故障及實(shí)現(xiàn)了高可用。

　　小結(jié)

　　要想成功使用一種產(chǎn)品，我們需要深入了解它的特性。Redis性能突出，如果能夠熟練的駕馭，對(duì)國內(nèi)很多大型應(yīng)用具有很大幫助。希望更多同行加入到Redis使用及代碼研究行列。

　　參考文獻(xiàn)

1. On Designing and Deploying InterNET-Scale Service(PDF)
2. Facebook’s New Real-Time Messaging System: HBase To Store 135+ Billion Messages A Month
3. What’s wrong with 1975 programming
4. Linux epoll is now supported(Google Groups)
5. CAS and why I don’t want to add it to Redis(Google Groups)
6. Plans for Virtual Memory(Google Groups)
7. Full of keys(Salvatore antirez Sanfilippo)

it知識(shí)庫：關(guān)于Redis的幾個(gè)認(rèn)識(shí)誤區(qū)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。