NoSQL數據庫Redis幾個認識誤區

前幾天微博發生了一起大的系統故障，很多技術的朋友都比較關心，其中的原因不會超出James Hamilton在On Designing and Deploying Internet-Scale Service(1)概括的那幾個范圍，James第一條經驗“Design for failure”是所有互聯網架構成功的一個關鍵。互聯網系統的工程理論其實非常簡單，James paper中內容幾乎稱不上理論，而是多條實踐經驗分享，每個公司對這些經驗的理解及執行力決定了架構成敗。-
 

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

1. Redis是什么

這個問題的結果影響了我們怎么用Redis。如果你認為Redis是一個key value store, 那可能會用它來代替MySQL；如果認為它是一個可以持久化的cache, 可能只是它保存一些頻繁訪問的臨時數據。Redis是REmote DIctionary Server的縮寫，在Redis在官方網站的的副標題是A persistent key-value database with built-in net interface written in ANSI-C for Posix systems，這個定義偏向key value store。還有一些看法則認為Redis是一個memory database，因為它的高性能都是基于內存操作的基礎。另外一些人則認為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使用及代碼研究行列。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]