【本教程目錄】

1.redis是什么
2.redis的作者何許人也
3.誰在使用redis
4.學(xué)會安裝redis
5.學(xué)會啟動redis
6.使用redis客戶端
7.redis數(shù)據(jù)結(jié)構(gòu) – 簡介
8.redis數(shù)據(jù)結(jié)構(gòu) – strings
9.redis數(shù)據(jù)結(jié)構(gòu) – lists
10.redis數(shù)據(jù)結(jié)構(gòu) – 集合
11.redis數(shù)據(jù)結(jié)構(gòu) – 有序集合
12.redis數(shù)據(jù)結(jié)構(gòu) – 哈希
13.聊聊redis持久化 – 兩種方式
14.聊聊redis持久化 – RDB
15.聊聊redis持久化 – AOF
16.聊聊redis持久化 – AOF重寫
17.聊聊redis持久化 – 如何選擇RDB和AOF
18.聊聊主從 – 用法
19.聊聊主從 – 同步原理
20.聊聊redis的事務(wù)處理
21.教你看懂redis配置 – 簡介
22.教你看懂redis配置 -通用
23.教你看懂redis配置 – 快照
24.教你看懂redis配置 – 復(fù)制
25.教你看懂redis配置 – 安全
26.教你看懂redis配置 -限制
27.教你看懂redis配置 – 追加模式
28.教你看懂redis配置 – LUA腳本
29.教你看懂redis配置 – 慢日志
30.教你看懂redis配置 – 事件通知
31.教你看懂redis配置 – 高級配置

【redis是什么】

redis是一個開源的、使用C語言編寫的、支持網(wǎng)絡(luò)交互的、可基于內(nèi)存也可持久化的Key-Value數(shù)據(jù)庫。

redis的官網(wǎng)地址，非常好記，是redis.io。（特意查了一下，域名后綴io屬于國家域名，是british Indian Ocean territory，即英屬印度洋領(lǐng)地）

目前，Vmware在資助著redis項(xiàng)目的開發(fā)和維護(hù)。

【redis的作者何許人也】

開門見山，先看照片：

是不是出乎了你的意料，嗯，高手總會有些地方與眾不同的。

這位便是redis的作者，他叫Salvatore Sanfilippo，來自意大利的西西里島，現(xiàn)在居住在卡塔尼亞。目前供職于Pivotal公司。

他使用的網(wǎng)名是antirez，如果你有興趣，可以去他的博客逛逛，地址是antirez.com，當(dāng)然也可以去follow他的github，地址是http://github.com/antirez。

【誰在使用redis】

Blizzard、digg、stackoverflow、github、flickr …

【學(xué)會安裝redis】

從redis.io下載最新版redis-X.Y.Z.tar.gz后解壓，然后進(jìn)入redis-X.Y.Z文件夾后直接make即可，安裝非常簡單。

make成功后會在src文件夾下產(chǎn)生一些二進(jìn)制可執(zhí)行文件，包括redis-server、redis-cli等等：

【學(xué)會啟動redis】

啟動redis非常簡單，直接./redis-server就可以啟動服務(wù)端了，還可以用下面的方法指定要加載的配置文件：

有關(guān)作者為什么選擇6379作為默認(rèn)端口，還有一段有趣的典故，英語好的同學(xué)可以看看作者這篇博文中的解釋。

【使用redis客戶端】

我們直接看一個例子：

【redis數(shù)據(jù)結(jié)構(gòu) – 簡介】

redis是一種高級的key:value存儲系統(tǒng)，其中value支持五種數(shù)據(jù)類型：

1.字符串（strings）
2.字符串列表（lists）
3.字符串集合（sets）
4.有序字符串集合（sorted sets）
5.哈希（hashes）

而關(guān)于key，有幾個點(diǎn)要提醒大家：

1.key不要太長，盡量不要超過1024字節(jié)，這不僅消耗內(nèi)存，而且會降低查找的效率；
2.key也不要太短，太短的話，key的可讀性會降低；
3.在一個項(xiàng)目中，key最好使用統(tǒng)一的命名模式，例如user:10000:passwd。

【redis數(shù)據(jù)結(jié)構(gòu) – strings】

有人說，如果只使用redis中的字符串類型，且不使用redis的持久化功能，那么，redis就和memcache非常非常的像了。這說明strings類型是一個很基礎(chǔ)的數(shù)據(jù)類型，也是任何存儲系統(tǒng)都必備的數(shù)據(jù)類型。

我們來看一個最簡單的例子：

另外，我們還可以通過字符串類型進(jìn)行數(shù)值操作：

看，在遇到數(shù)值操作時，redis會將字符串類型轉(zhuǎn)換成數(shù)值。

由于INCR等指令本身就具有原子操作的特性，所以我們完全可以利用redis的INCR、INCRBY、DECR、DECRBY等指令來實(shí)現(xiàn)原子計(jì)數(shù)的效果，假如，在某種場景下有3個客戶端同時讀取了mynum的值（值為2），然后對其同時進(jìn)行了加1的操作，那么，最后mynum的值一定是5。不少網(wǎng)站都利用redis的這個特性來實(shí)現(xiàn)業(yè)務(wù)上的統(tǒng)計(jì)計(jì)數(shù)需求。

【redis數(shù)據(jù)結(jié)構(gòu) – lists】

redis的另一個重要的數(shù)據(jù)結(jié)構(gòu)叫做lists，翻譯成中文叫做“列表”。

首先要明確一點(diǎn)，redis中的lists在底層實(shí)現(xiàn)上并不是數(shù)組，而是鏈表，也就是說對于一個具有上百萬個元素的lists來說，在頭部和尾部插入一個新元素，其時間復(fù)雜度是常數(shù)級別的，比如用LPUSH在10個元素的lists頭部插入新元素，和在上千萬元素的lists頭部插入新元素的速度應(yīng)該是相同的。

雖然lists有這樣的優(yōu)勢，但同樣有其弊端，那就是，鏈表型lists的元素定位會比較慢，而數(shù)組型lists的元素定位就會快得多。

lists的常用操作包括LPUSH、RPUSH、LRANGE等。我們可以用LPUSH在lists的左側(cè)插入一個新元素，用RPUSH在lists的右側(cè)插入一個新元素，用LRANGE命令從lists中指定一個范圍來提取元素。我們來看幾個例子：

lists的應(yīng)用相當(dāng)廣泛，隨便舉幾個例子：

1.我們可以利用lists來實(shí)現(xiàn)一個消息隊(duì)列，而且可以確保先后順序，不必像MySQL那樣還需要通過ORDER BY來進(jìn)行排序。
2.利用LRANGE還可以很方便的實(shí)現(xiàn)分頁的功能。
3.在博客系統(tǒng)中，每片博文的評論也可以存入一個單獨(dú)的list中。

【redis數(shù)據(jù)結(jié)構(gòu) – 集合】

redis的集合，是一種無序的集合，集合中的元素沒有先后順序。

集合相關(guān)的操作也很豐富，如添加新元素、刪除已有元素、取交集、取并集、取差集等。我們來看例子：

對于集合的使用，也有一些常見的方式，比如，QQ有一個社交功能叫做“好友標(biāo)簽”，大家可以給你的好友貼標(biāo)簽，比如“大美女”、“土豪”、“歐巴”等等，這時就可以使用redis的集合來實(shí)現(xiàn)，把每一個用戶的標(biāo)簽都存儲在一個集合之中。

【redis數(shù)據(jù)結(jié)構(gòu) – 有序集合】

redis不但提供了無需集合（sets），還很體貼的提供了有序集合（sorted sets）。有序集合中的每個元素都關(guān)聯(lián)一個序號（score），這便是排序的依據(jù)。

很多時候，我們都將redis中的有序集合叫做zsets，這是因?yàn)樵趓edis中，有序集合相關(guān)的操作指令都是以z開頭的，比如zrange、zadd、zrevrange、zrangebyscore等等

老規(guī)矩，我們來看幾個生動的例子：
//新增一個有序集合myzset，并加入一個元素baidu.com，給它賦予的序號是1：

【redis數(shù)據(jù)結(jié)構(gòu) – 哈?！?/strong>

最后要給大家介紹的是hashes，即哈希。哈希是從redis-2.0.0版本之后才有的數(shù)據(jù)結(jié)構(gòu)。

hashes存的是字符串和字符串值之間的映射，比如一個用戶要存儲其全名、姓氏、年齡等等，就很適合使用哈希。

我們來看一個例子：

有關(guān)hashes的操作，同樣很豐富，需要時，大家可以從這里查詢。

【聊聊redis持久化 – 兩種方式】

redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Append Only File）。

RDB，簡而言之，就是在不同的時間點(diǎn)，將redis存儲的數(shù)據(jù)生成快照并存儲到磁盤等介質(zhì)上；

AOF，則是換了一個角度來實(shí)現(xiàn)持久化，那就是將redis執(zhí)行過的所有寫指令記錄下來，在下次redis重新啟動時，只要把這些寫指令從前到后再重復(fù)執(zhí)行一遍，就可以實(shí)現(xiàn)數(shù)據(jù)恢復(fù)了。

其實(shí)RDB和AOF兩種方式也可以同時使用，在這種情況下，如果redis重啟的話，則會優(yōu)先采用AOF方式來進(jìn)行數(shù)據(jù)恢復(fù)，這是因?yàn)锳OF方式的數(shù)據(jù)恢復(fù)完整度更高。

如果你沒有數(shù)據(jù)持久化的需求，也完全可以關(guān)閉RDB和AOF方式，這樣的話，redis將變成一個純內(nèi)存數(shù)據(jù)庫，就像memcache一樣。

【聊聊redis持久化 – RDB】

RDB方式，是將redis某一時刻的數(shù)據(jù)持久化到磁盤中，是一種快照式的持久化方法。

redis在進(jìn)行數(shù)據(jù)持久化的過程中，會先將數(shù)據(jù)寫入到一個臨時文件中，待持久化過程都結(jié)束了，才會用這個臨時文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時來進(jìn)行備份，因?yàn)榭煺瘴募偸峭暾捎玫摹?/p>

對于RDB方式，redis會單獨(dú)創(chuàng)建（fork）一個子進(jìn)程來進(jìn)行持久化，而主進(jìn)程是不會進(jìn)行任何IO操作的，這樣就確保了redis極高的性能。

如果需要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù)，且對于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

雖然RDB有不少優(yōu)點(diǎn)，但它的缺點(diǎn)也是不容忽視的。如果你對數(shù)據(jù)的完整性非常敏感，那么RDB方式就不太適合你，因?yàn)榧词鼓忝?分鐘都持久化一次，當(dāng)redis故障時，仍然會有近5分鐘的數(shù)據(jù)丟失。所以，redis還提供了另一種持久化方式，那就是AOF。

【聊聊redis持久化 – AOF】

AOF，英文是Append Only File，即只允許追加不允許改寫的文件。

如前面介紹的，AOF方式是將執(zhí)行過的寫指令記錄下來，在數(shù)據(jù)恢復(fù)時按照從前到后的順序再將指令都執(zhí)行一遍，就這么簡單。

我們通過配置redis.conf中的appendonly yes就可以打開AOF功能。如果有寫操作（如SET等），redis就會被追加到AOF文件的末尾。

默認(rèn)的AOF持久化策略是每秒鐘fsync一次（fsync是指把緩存中的寫指令記錄到磁盤中），因?yàn)樵谶@種情況下，redis仍然可以保持很好的處理性能，即使redis故障，也只會丟失最近1秒鐘的數(shù)據(jù)。

如果在追加日志時，恰好遇到磁盤空間滿、inode滿或斷電等情況導(dǎo)致日志寫入不完整，也沒有關(guān)系，redis提供了redis-check-aof工具，可以用來進(jìn)行日志修復(fù)。

因?yàn)椴捎昧俗芳臃绞剑绻蛔鋈魏翁幚淼脑?，AOF文件會變得越來越大，為此，redis提供了AOF文件重寫（rewrite）機(jī)制，即當(dāng)AOF文件的大小超過所設(shè)定的閾值時，redis就會啟動AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集。舉個例子或許更形象，假如我們調(diào)用了100次INCR指令，在AOF文件中就要存儲100條指令，但這明顯是很低效的，完全可以把這100條指令合并成一條SET指令，這就是重寫機(jī)制的原理。

在進(jìn)行AOF重寫時，仍然是采用先寫臨時文件，全部完成后再替換的流程，所以斷電、磁盤滿等問題都不會影響AOF文件的可用性，這點(diǎn)大家可以放心。

AOF方式的另一個好處，我們通過一個“場景再現(xiàn)”來說明。某同學(xué)在操作redis時，不小心執(zhí)行了FLUSHALL，導(dǎo)致redis內(nèi)存中的數(shù)據(jù)全部被清空了，這是很悲劇的事情。不過這也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件還沒有被重寫（rewrite），我們就可以用最快的速度暫停redis并編輯AOF文件，將最后一行的FLUSHALL命令刪除，然后重啟redis，就可以恢復(fù)redis的所有數(shù)據(jù)到FLUSHALL之前的狀態(tài)了。是不是很神奇，這就是AOF持久化方式的好處之一。但是如果AOF文件已經(jīng)被重寫了，那就無法通過這種方法來恢復(fù)數(shù)據(jù)了。

雖然優(yōu)點(diǎn)多多，但AOF方式也同樣存在缺陷，比如在同樣數(shù)據(jù)規(guī)模的情況下，AOF文件要比RDB文件的體積大。而且，AOF方式的恢復(fù)速度也要慢于RDB方式。

如果你直接執(zhí)行BGREWRITEAOF命令，那么redis會生成一個全新的AOF文件，其中便包括了可以恢復(fù)現(xiàn)有數(shù)據(jù)的最少的命令集。

如果運(yùn)氣比較差，AOF文件出現(xiàn)了被寫壞的情況，也不必過分擔(dān)憂，redis并不會貿(mào)然加載這個有問題的AOF文件，而是報錯退出。這時可以通過以下步驟來修復(fù)出錯的文件：

1.備份被寫壞的AOF文件
2.運(yùn)行redis-check-aof –fix進(jìn)行修復(fù)
3.用diff -u來看下兩個文件的差異，確認(rèn)問題點(diǎn)
4.重啟redis，加載修復(fù)后的AOF文件

【聊聊redis持久化 – AOF重寫】

AOF重寫的內(nèi)部運(yùn)行原理，我們有必要了解一下。

在重寫即將開始之際，redis會創(chuàng)建（fork）一個“重寫子進(jìn)程”，這個子進(jìn)程會首先讀取現(xiàn)有的AOF文件，并將其包含的指令進(jìn)行分析壓縮并寫入到一個臨時文件中。

與此同時，主工作進(jìn)程會將新接收到的寫指令一邊累積到內(nèi)存緩沖區(qū)中，一邊繼續(xù)寫入到原有的AOF文件中，這樣做是保證原有的AOF文件的可用性，避免在重寫過程中出現(xiàn)意外。

當(dāng)“重寫子進(jìn)程”完成重寫工作后，它會給父進(jìn)程發(fā)一個信號，父進(jìn)程收到信號后就會將內(nèi)存中緩存的寫指令追加到新AOF文件中。

當(dāng)追加結(jié)束后，redis就會用新AOF文件來代替舊AOF文件，之后再有新的寫指令，就都會追加到新的AOF文件中了。

【聊聊redis持久化 – 如何選擇RDB和AOF】

對于我們應(yīng)該選擇RDB還是AOF，官方的建議是兩個同時使用。這樣可以提供更可靠的持久化方案。

【聊聊主從 – 用法】

像MySQL一樣，redis是支持主從同步的，而且也支持一主多從以及多級從結(jié)構(gòu)。

主從結(jié)構(gòu)，一是為了純粹的冗余備份，二是為了提升讀性能，比如很消耗性能的SORT就可以由從服務(wù)器來承擔(dān)。

redis的主從同步是異步進(jìn)行的，這意味著主從同步不會影響主邏輯，也不會降低redis的處理性能。

主從架構(gòu)中，可以考慮關(guān)閉主服務(wù)器的數(shù)據(jù)持久化功能，只讓從服務(wù)器進(jìn)行持久化，這樣可以提高主服務(wù)器的處理性能。

在主從架構(gòu)中，從服務(wù)器通常被設(shè)置為只讀模式，這樣可以避免從服務(wù)器的數(shù)據(jù)被誤修改。但是從服務(wù)器仍然可以接受CONFIG等指令，所以還是不應(yīng)該將從服務(wù)器直接暴露到不安全的網(wǎng)絡(luò)環(huán)境中。如果必須如此，那可以考慮給重要指令進(jìn)行重命名，來避免命令被外人誤執(zhí)行。

【聊聊主從 – 同步原理】

從服務(wù)器會向主服務(wù)器發(fā)出SYNC指令，當(dāng)主服務(wù)器接到此命令后，就會調(diào)用BGSAVE指令來創(chuàng)建一個子進(jìn)程專門進(jìn)行數(shù)據(jù)持久化工作，也就是將主服務(wù)器的數(shù)據(jù)寫入RDB文件中。在數(shù)據(jù)持久化期間，主服務(wù)器將執(zhí)行的寫指令都緩存在內(nèi)存中。

在BGSAVE指令執(zhí)行完成后，主服務(wù)器會將持久化好的RDB文件發(fā)送給從服務(wù)器，從服務(wù)器接到此文件后會將其存儲到磁盤上，然后再將其讀取到內(nèi)存中。這個動作完成后，主服務(wù)器會將這段時間緩存的寫指令再以redis協(xié)議的格式發(fā)送給從服務(wù)器。

另外，要說的一點(diǎn)是，即使有多個從服務(wù)器同時發(fā)來SYNC指令，主服務(wù)器也只會執(zhí)行一次BGSAVE，然后把持久化好的RDB文件發(fā)給多個下游。在redis2.8版本之前，如果從服務(wù)器與主服務(wù)器因某些原因斷開連接的話，都會進(jìn)行一次主從之間的全量的數(shù)據(jù)同步；而在2.8版本之后，redis支持了效率更高的增量同步策略，這大大降低了連接斷開的恢復(fù)成本。

主服務(wù)器會在內(nèi)存中維護(hù)一個緩沖區(qū)，緩沖區(qū)中存儲著將要發(fā)給從服務(wù)器的內(nèi)容。從服務(wù)器在與主服務(wù)器出現(xiàn)網(wǎng)絡(luò)瞬斷之后，從服務(wù)器會嘗試再次與主服務(wù)器連接，一旦連接成功，從服務(wù)器就會把“希望同步的主服務(wù)器ID”和“希望請求的數(shù)據(jù)的偏移位置（replication offset）”發(fā)送出去。主服務(wù)器接收到這樣的同步請求后，首先會驗(yàn)證主服務(wù)器ID是否和自己的ID匹配，其次會檢查“請求的偏移位置”是否存在于自己的緩沖區(qū)中，如果兩者都滿足的話，主服務(wù)器就會向從服務(wù)器發(fā)送增量內(nèi)容。

增量同步功能，需要服務(wù)器端支持全新的PSYNC指令。這個指令，只有在redis-2.8之后才具有。

【聊聊redis的事務(wù)處理】

眾所周知，事務(wù)是指“一個完整的動作，要么全部執(zhí)行，要么什么也沒有做”。

在聊redis事務(wù)處理之前，要先和大家介紹四個redis指令，即MULTI、EXEC、DISCARD、WATCH。這四個指令構(gòu)成了redis事務(wù)處理的基礎(chǔ)。

1.MULTI用來組裝一個事務(wù)；
2.EXEC用來執(zhí)行一個事務(wù)；
3.DISCARD用來取消一個事務(wù)；
4.WATCH用來監(jiān)視一些key，一旦這些key在事務(wù)執(zhí)行之前被改變，則取消事務(wù)的執(zhí)行。

紙上得來終覺淺，我們來看一個MULTI和EXEC的例子：

在上面的例子中，我們看到了QUEUED的字樣，這表示我們在用MULTI組裝事務(wù)時，每一個命令都會進(jìn)入到內(nèi)存隊(duì)列中緩存起來，如果出現(xiàn)QUEUED則表示我們這個命令成功插入了緩存隊(duì)列，在將來執(zhí)行EXEC時，這些被QUEUED的命令都會被組裝成一個事務(wù)來執(zhí)行。

對于事務(wù)的執(zhí)行來說，如果redis開啟了AOF持久化的話，那么一旦事務(wù)被成功執(zhí)行，事務(wù)中的命令就會通過write命令一次性寫到磁盤中去，如果在向磁盤中寫的過程中恰好出現(xiàn)斷電、硬件故障等問題，那么就可能出現(xiàn)只有部分命令進(jìn)行了AOF持久化，這時AOF文件就會出現(xiàn)不完整的情況，這時，我們可以使用redis-check-aof工具來修復(fù)這一問題，這個工具會將AOF文件中不完整的信息移除，確保AOF文件完整可用。

有關(guān)事務(wù)，大家經(jīng)常會遇到的是兩類錯誤：

1.調(diào)用EXEC之前的錯誤
2.調(diào)用EXEC之后的錯誤

“調(diào)用EXEC之前的錯誤”，有可能是由于語法有誤導(dǎo)致的，也可能時由于內(nèi)存不足導(dǎo)致的。只要出現(xiàn)某個命令無法成功寫入緩沖隊(duì)列的情況，redis都會進(jìn)行記錄，在客戶端調(diào)用EXEC時，redis會拒絕執(zhí)行這一事務(wù)。（這時2.6.5版本之后的策略。在2.6.5之前的版本中，redis會忽略那些入隊(duì)失敗的命令，只執(zhí)行那些入隊(duì)成功的命令）。我們來看一個這樣的例子：

而對于“調(diào)用EXEC之后的錯誤”，redis則采取了完全不同的策略，即redis不會理睬這些錯誤，而是繼續(xù)向下執(zhí)行事務(wù)中的其他命令。這是因?yàn)椋瑢τ趹?yīng)用層面的錯誤，并不是redis自身需要考慮和處理的問題，所以一個事務(wù)中如果某一條命令執(zhí)行失敗，并不會影響接下來的其他命令的執(zhí)行。我們也來看一個例子：

好了，我們來說說最后一個指令“WATCH”，這是一個很好用的指令，它可以幫我們實(shí)現(xiàn)類似于“樂觀鎖”的效果，即CAS（check and set）。

WATCH本身的作用是“監(jiān)視key是否被改動過”，而且支持同時監(jiān)視多個key，只要還沒真正觸發(fā)事務(wù)，WATCH都會盡職盡責(zé)的監(jiān)視，一旦發(fā)現(xiàn)某個key被修改了，在執(zhí)行EXEC時就會返回nil，表示事務(wù)無法觸發(fā)。

【教你看懂redis配置 – 簡介】

我們可以在啟動redis-server時指定應(yīng)該加載的配置文件，方法如下：

接下來，我們就來講解下redis配置文件的各個配置項(xiàng)的含義，注意，本文是基于redis-2.8.4版本進(jìn)行講解的。

redis官方提供的redis.conf文件，足有700+行，其中100多行為有效配置行，另外的600多行為注釋說明。

在配置文件的開頭部分，首先明確了一些度量單位：

可以看出，redis配置中對單位的大小寫不敏感，1GB、1Gb和1gB都是相同的。由此也說明，redis只支持bytes，不支持bit單位。

redis支持“主配置文件中引入外部配置文件”，很像C/C++中的include指令，比如：

如果你看過redis的配置文件，會發(fā)現(xiàn)還是很有條理的。redis配置文件被分成了幾大塊區(qū)域，它們分別是：

1.通用（general）
2.快照（snapshotting）
3.復(fù)制（replication）
4.安全（security）
5.限制（limits)
6.追加模式（append only mode)
7.LUA腳本（lua scripting)
8.慢日志（slow log)
9.事件通知（event notification）

下面我們就來逐一講解。

【教你看懂redis配置 -通用】

默認(rèn)情況下，redis并不是以daemon形式來運(yùn)行的。通過daemonize配置項(xiàng)可以控制redis的運(yùn)行形式，如果改為yes，那么redis就會以daemon形式運(yùn)行：