[轉載]Redis幾個認識誤區_TIM YANG

另一些人則認爲Redis是一個data structure server，由於Redis支持複雜的數據特性，好比List, Set等。對Redis的做用的不一樣解讀決定了你對Redis的使用方式。

互聯網數據目前基本使用兩種方式來存儲，關係數據庫或者key value。可是這些互聯網業務自己並不屬於這兩種數據類型，好比用戶在社會化平臺中的關係，它是一個list，若是要用關係數據庫存儲就須要轉換成一種多行記錄的形式，這種形式存在不少冗餘數據，每一行須要存儲一些重複信息。若是用key value存儲則修改和刪除比較麻煩，須要將所有數據讀出再寫入。Redis在內存中設計了各類數據類型，讓業務可以高速原子的訪問這些數據結構，而且不須要關心持久存儲的問題，從架構上解決了前面兩種存儲須要走一些彎路的問題。

2. 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)。

3. 單臺Redis的存放數據必須比物理內存小

Redis的數據所有放在內存帶來了高速的性能，可是也帶來一些不合理之處。好比一箇中型網站有100萬註冊用戶，若是這些資料要用Redis來存儲，內存的容量必須可以容納這100萬用戶。可是業務實際狀況是100萬用戶只有5萬活躍用戶，1周來訪問過1次的也只有15萬用戶，所以所有100萬用戶的數據都放在內存有不合理之處，RAM須要爲冷數據買單。

這跟操做系統很是類似，操做系統全部應用訪問的數據都在內存，可是若是物理內存容納不下新的數據，操做系統會智能將部分長期沒有訪問的數據交換到磁盤，爲新的應用留出空間。現代操做系統給應用提供的並非物理內存，而是虛擬內存(Virtual Memory)的概念。

基於相同的考慮，Redis 2.0也增長了VM特性。讓Redis數據容量突破了物理內存的限制。並實現了數據冷熱分離。

4. Redis的VM實現是重複造輪子

Redis的VM依照以前的epoll實現思路依舊是本身實現。可是在前面操做系統的介紹提到OS也能夠自動幫程序實現冷熱數據分離，Redis只須要OS申請一塊大內存，OS會自動將熱數據放入物理內存，冷數據交換到硬盤，另一個知名的「理解了現代操做系統(3)」的Varnish就是這樣實現，也取得了很是成功的效果。

做者antirez在解釋爲何要本身實現VM中提到幾個緣由(6)。主要OS的VM換入換出是基於Page概念，好比OS VM1個Page是4K, 4K中只要還有一個元素即便只有1個字節被訪問，這個頁也不會被SWAP, 換入也一樣道理，讀到一個字節可能會換入4K無用的內存。而Redis本身實現則能夠達到控制換入的粒度。另外訪問操做系統SWAP內存區域時block進程，也是致使Redis要本身實現VM緣由之一。

5. 用get/set方式使用Redis

做爲一個key value存在，不少開發者天然的使用set/get方式來使用Redis，實際上這並非最優化的使用方法。尤爲在未啓用VM狀況下，Redis所有數據須要放入內存，節約內存尤爲重要。

假如一個key-value單元須要最小佔用512字節，即便只存一個字節也佔了512字節。這時候就有一個設計模式，能夠把key複用，幾個key-value放入一個key中，value再做爲一個set存入，這樣一樣512字節就會存放10-100倍的容量。

這就是爲了節約內存，建議使用hashset而不是set/get的方式來使用Redis，詳細方法見參考文獻(7)。

6. 使用aof代替snapshot

Redis有兩種存儲方式，默認是snapshot方式，實現方法是定時將內存的快照(snapshot)持久化到硬盤，這種方法缺點是持久化以後若是出現crash則會丟失一段數據。所以在完美主義者的推進下做者增長了aof方式。aof即append only mode，在寫入內存數據的同時將操做命令保存到日誌文件，在一個併發更改上萬的系統中，命令日誌是一個很是龐大的數據，管理維護成本很是高，恢復重建時間會很是長，這樣致使失去aof高可用性本意。另外更重要的是Redis是一個內存數據結構模型，全部的優點都是創建在對內存複雜數據結構高效的原子操做上，這樣就看出aof是一個很是不協調的部分。

其實aof目的主要是數據可靠性及高可用性，在Redis中有另一種方法來達到目的：Replication。因爲Redis的高性能，複製基本沒有延遲。這樣達到了防止單點故障及實現了高可用。

小結

要想成功使用一種產品，咱們須要深刻了解它的特性。Redis性能突出，若是可以熟練的駕馭，對國內不少大型應用具備很大幫助。但願更多同行加入到Redis使用及代碼研究行列。

參考文獻

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)