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