Redis:30分鐘從入門到精通 - 1P

做者好牛逼，我不懂的他全都懂。

Redis: Zero to Master in 30 minutes - Part 1

---

再說一次，老子以爲你若是是真的程序員，30分鐘就能精通 Redis。這充分證實了 Redis 有多牛逼而且是多顯而易見的簡單。不過話說回來，以你的水平，你真以爲你真的能在30分鐘內精通 Redis？額呵呵呵呵呵呵~~

不服你來試試看啊。在這章咱們來說講什麼是 Redis。下一章咱們作一個簡單的例子。嘛，剩下的時間，一邊玩去。

Redis 簡介

Redis 一般被描述爲一個"鍵值存儲引擎"，沒錯，就是這樣，啊，不過超難理解對不對。好吧，我以爲把它當作一個數據結構引擎看起來比較通俗易懂。怎麼說呢，Redis 支持五種不一樣的元素，只要你收集到這五種不一樣的元素，就什麼都不會發生: strings, hashes, lists, sets 和 ordered sets。每一種數據結構有它的特色和支持的指令。無論哪一種類型，都是用 Key 訪問 Value。而 Key 是以 byte array 形式保存所以能夠很複雜，不過以你的水平，我以爲你大多數狀況下會用 string 保存，額呵呵呵呵呵呵~。

來看看每種類型:

Strings:

Strings 是五元素中最簡單的，同時也最沒名堂的，嗯，好比你說"String"，人家都不知道你想說啥。或者你能夠說"Single"或者"Simple"，更容易讓人理解。提到 Redis ，或者說鍵值對的時候，一般會想到 String 結構(記住哦，只是五分之一而已)。就像 Key，一個 String 的 Value 也能夠是任何的字節數組。你能夠用來存增加的Integer計數器，或者實際的字符串，或者序列化的對象(blob)。全部的這些都很常見，最多見的字符串操做是 GET 和 SET。

<!-- lang: js -->
SET pages:about "about us"
GET pages:about
about us

固然你還能夠拿它作不少事情，由於還有許多其餘的命令(好比 INCR 或者 GETRANGE)，並且咱們不單能夠把一個數字存成字符串，好比，咱們還能夠拿 String 結構來存用戶，Key 是用戶的 Email，而 Value 是序列化的用戶對象。

Hashes

Hash 結構，就像你想的那樣(一個 hash/dictionary)。處理的時候不是直接操做 Key (好比說 String 結構)，而是 Key 的字段。所以咱們不單是get/set一個哈希值，而是get/set一個哈希字段:

<!-- lang: js -->
HSET goku power 9001
HGET goku power
9001

和 Redis 其餘部分同樣，字段和值的最終形態是字節數組，所以也能夠是任何東西。字段，好比說 Key， 通常來講是字符串。我以爲你如今腦子裏面必定想，我操，和字符串有啥區別。想得好！好比說，下面這兩個有啥區別？(用 json 來表示一個複雜的值，你能夠把它序列化成一個字節數組的。)

<!-- lang: js -->
SET users:goku {race: 'sayan', power: 9001}
HSET users:goku race sayan
HSET users:goku power 9001

嗯，區別在於你接下來準備怎麼玩它。若是你須要對單個字段進行控制，而且你不但願把整個對象都弄到你應用裏面，用哈希，要否則用字符串也挺好。

Lists

Lists 讓你把一組值關聯到一個 Key 上。實際上，你能夠(或者說應該)把他們想成動態的數組。你能夠插(insert)，添(append)，彈(pop)，推(push)，掐(trim)，以及嗯，之類的手段玩它。 Redis 不支持二級索引。因此你能夠訪問數組的 Key，填補這一空白(固然這也不是惟一用途)。

<!-- lang: js -->
length = redis.lpush('users:newest', 'user:goku')
if length > 100
  #trim is to we only keep 100 "newest" users
  redis.rpop('users:newest')
end

上面的代碼在列表中維護了一個最新註冊用戶的引用。在這裏咱們實時維護列表的長度，能夠把它仍到後臺去。怎麼作呢?:

<!-- lang: js -->
# get the 10 newest users
keys = redis.lrange('users:newest', 0, 10)
#multi get the actual 10 user objects
redis.mget(*keys)

傳統上，開發者應該避免這樣的屢次查詢。可是 Redis， 這很常見，超快(由於全部的東西都在內存)。

Sets

Set 和 List 差很少，不過 Set 就是Set(不容許有重複值)。你能夠比較兩個Set，經過用 SDIFF，或者組合，經過用 SUNION/ SUNIONSTORE (若是你想把結果保存在另一個 Set 而不是直接返回的話)，等等。Set 一樣能夠用在跟蹤朋友圈和標籤上:

<!-- lang: js -->
SADD friends:leto ghanima
SADD friends:leto duncan
SADD friends:paul duncan
SADD friends:paul gurney
SINTER friends:leto friends:paul
1) "duncan"

Sorted Sets

一般咱們不說一種數據結構比另一種數據結構牛逼。由於原本就是獨立解決需求的。不過 Soted Set 真的好牛逼。一個 Sorted Set 和 Set 很像，可是它的值和排序權重關聯。也就是說，當你往 Sorted Set 裏面追加一個值的時候，你能夠指定一個權重，這決定你插到哪裏。好比說前面的例子，咱們能夠給數據加上一個權重:

<!-- lang: js -->
ZADD friends:leto 1000 ghanima
ZADD friends:leto 994 duncan
ZADD friends:leto 2 farad'n
ZRANGEBYSCORE friends:leto 500 1000
1) "duncan"
2) "ghanima"

上面這個例子拿到了權重在 500-1000 的朋友數據。

Sorted set 固然不只僅用在朋友圈，權重屬性能夠被用在時間序列(好比說用從1970年到如今的毫秒作權重)，或者，好比說我，我用玩家的遊戲得分來排序他們。

Redis 查詢

在 Redis 中，只能用它的 key 來查詢數據。及時你用了 Hash， 咱們也不能說: 嘿，把那個 race 字段等於 sayan 的 keys 給我。咱們看看 List，咱們是怎樣建立咱們的二級索引的。管理你的二級索引會超痛苦，有時候還很難擴展。不過，這裏有兩件事應該記住。首先，不論是簡單仍是複雜的場景，你都應該在敲定以前，先把玩把玩，沒啥大不了的，花不了幾分鐘。第二，don't get hung up with hitting Redis multiple times.

除了五種結構， Redis 還有便利全部 Key的命令(所謂的 key-commands)。好比說 DEL，EXISTS 和 RENAME。也許最經常使用的是 KEYS 命令，會給你返回 keys。好比說， mogade.com 把平常的排行榜以keys來存儲，看起來像這樣: ranks:daily:GAME_ID:20110830。若是我但願把八月份的數據全刪了，那麼我會:

<!-- lang: js -->
keys = redis.keys("ranks:daily:*:201108*")
redis.del(*keys)

注意: keys 命令會遍歷你全部的 keys 來查找匹配值。這會很是慢。文檔建議你只在調試或者開發的時候用它。

補充

Redis 很是容易安裝和維護，數據在硬盤上以單文件形式保存，你要備份的時候就拷貝多一份就能夠了。只要一個簡單的配置文件就能驅動它。

你的全部數據應該適合放到內存中。它支持虛擬內存，不過看起來(做者)失敗了。它過期了，也許在將來會被從功能裏面移除。

Redis 支持 master-slave replication。但是它不支持自動失效備援，也不會作任何形式的分片。你須要本身去作這些事情，好比說用HAProxy。Redis Cluster 聽說會對這些進行補充，咱們應該很快就會看到一個早期發行版。(若是你感興趣，你能夠從這裏找到它)。

Redis 還有許多超讚的特性。好比說它支持事務，有好多命令，不少管理功能，Key 能夠自動實現，以及訂閱發佈 API，等等。以我這種挑剔的眼光來開，我也對 Redis 文檔和參考文檔佩服得五體投地。

何時用 Redis

Redis 比其餘不少存儲解決方案都要專業。複雜的系統中正確的打開方式是按功能特性來劃分，不須要看考慮整個系統。它要求把全部的東西都扔內存裏面，多少讓你以爲不太爽。可是，當你給合適的功能賦予合適的模型的時候，絕對爽死。Redis超快而API簡單到死。我已經把幾百行的查詢代碼轉成了只要幾個參數的方法了。

最後，再說一次，Redis 簡單到爆，你面對一個問題的時候，超容易判斷，是否是適合用 Redis。有時候適用有時候又不適用。

結論

把 Redis 單純看做一個鍵值存儲是不對的，它比這牛逼多了。也就是說，你應該用不一樣的方式來考慮你的數據模型。有時候它不起做用，可是一旦用起來了...好爽。(你覺得你是段譽的六脈神劍麼)。

也許咱們應該去撒泡尿？看看 Redis 的網站？oh，開始 Part 2 吧。