摘要：目前供職于公司。哈希是從版本之后才有的數(shù)據(jù)結(jié)構(gòu)。我們來看一個例子代碼如下建立哈希并賦值列出哈希的內(nèi)容更改中的某一個值再次列出哈希的內(nèi)容發(fā)現(xiàn)，密碼已經(jīng)被更改了。

【redis是什么】

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

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

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

【redis的作者何許人也】

開門見山，先看照片

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

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

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

【誰在使用redis】

Blizzard，digg，stackoverflow，GitHub，flickr...

【學會安裝redis】

從redis.io下載最新版redis-x.y.z.tar.gz后解壓，然后進入redis-x.y.z文件夾后直接make即可，安裝非常簡單。

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

代碼如下：

$find . -type f -executable

./redis-benchmark //用于進行redis性能測試的工具

./redis-check-dump //用于修復出問題的dump.rdb文件

./redis-cli //redis的客戶端

./redis-server //redis的服務器端

./redis-check-aof //用于修復出問題的AOF文件

./redis-sentinel //用于集群管理

【學會啟動redis】

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

代碼如下：

./redis-server ../redis.conf

默認情況下，redis-server會以非daemon的方式來運行，且默認服務端口為6379。

有關(guān)作者為什么選擇6379作為默認端口，還有一段又去的典故。

【使用redis客戶端】

我們直接看一個例子：

代碼如下：

//這樣來啟動redis客戶端了

$./redis-cli

//用set指令來設置key、value

127.0.0.1:6379 > set name "xiaochuntao"

OK

//來獲取name的值

127.0.0.1:6379 > get name

"xiaochuntao"

//通過客戶端來關(guān)閉redis服務器

127.0.0.1:6379 > shutdown

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

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

1、字符串 String

2、字符串列表 lists

3、字符串集合 sets

4、有序字符串集合 sorted sets

5、哈希 hashes

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

1、key不要太長，盡量不要吵過1024字節(jié)，這不僅消耗內(nèi)存，而且會降低查找的效率；

2、key也不要太短，太短的話，key的可讀性會降低；

3、在一個項目中，key最好使用統(tǒng)一的命名模式，例如user:10000:passwd.

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

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

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

代碼如下：

set mystr "hello world!"http://設置字符串類型

get mystr //讀取字符串類型

字符串類型的用法就是這么簡單，因為是二進制安全的，所以你完全可以把一個圖片文件的內(nèi)容作為字符串來存儲。

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

代碼如下：

set mynum "2"

OK

get mynum

"2"

incr mynum

(integer) 3

get mynum

"3"

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

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

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

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

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

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

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

代碼如下：

//新建一個list叫做mylist,并在列表頭部插入元素"1"

lpush mylist "1"

//返回當前mylist中的元素個數(shù)

(integer) 1

在mylist右側(cè)插入元素"2"

rpush mylist "2"

（integer)2

//在mylist左側(cè)插入元素"0"

lpush mylist "0"

(integer)3

//列出mylist中從編號0到編號1的元素

lrange mylist 0 1

1)"0"

2)"1"

//列出mylist中從編號0到倒數(shù)第一個元素

lrange mylist 0 -1

1)"0"

2)"1"

3)"2"

lists的應用相當廣泛，隨便舉幾個例子：

1、我們可以利用lists來實現(xiàn)一個消息隊列，而且可以確保先后順序，不必像mysql那樣還需要通過order by來進行排序。

2、利用lrange還可以很方便的實現(xiàn)分頁的功能。

3、在博客系統(tǒng)中，每篇博文的評論也可以存入一個多帶帶的list中。

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

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

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

代碼如下：

//向集合myset中加入一個新元素“one”

sadd myset "one"

(integer)1

sadd myset "two"

(integer)2

//列出集合myset中的所有元素

smembers myset

1)"one"

2)"two"

//判斷元素1是否在myset中，返回0表示不存在

sismember myset "three"

(integer)0

//新建一個新的集合yourset

sadd yourset "1"

(integer) 1

sadd yourset "2"

(integer)2

smembers yourset

1)"1"

2)"2"

//對兩個集合求并集

sunion myset yourset

1)"1"

2)"one"

3)"2"

4)"two"

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

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

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

很多時候，我們都將redis中的有序集合叫做zsets，只是因為在redis中，有序集合相關(guān)的操作指令都是以z開頭的，比如zrange，zadd，zrevrange,zrangebyscore等等。

老規(guī)矩，我們先來看幾個生動的例子：

//新增一個有序集合myzset，并加入一個元素baidu.com,給他賦予的序號是1：

代碼如下：

zadd myzset 1 baidu.com

(integer)1

//向myzset中新增一個元素360.com，賦予它的序號是3

zadd myzset 3 360.com

(integer)2

//向myzset中新增一個元素google.com，賦予它的序號是2

zadd myzset 2 google.com

(integer)3

//列出myzset的所有元素，同時列出其序號，可以看出myzset已經(jīng)是有序的了。

zrange myzset 0 -1 with scores

1)"baidu.com"

2)"1"

3)"google.com"

4)"2"

5)"360.com"

6)"3"

//只列出myzset的元素

zrange myzset 0 -1

1)"baidu.com"

2)"google.com"

3)"360.com"

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

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

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

我們來看一個例子：

代碼如下：

//建立哈希并賦值

HMSET user:001 username antirez password p1pp0 age 34

OK

//列出哈希的內(nèi)容

HGETALL user:001

1)"username"

2)"antirez"

3)"password"

4)"P1pp0"

5)"age"

6)"34"

//更改hash中的某一個值

HSET user:001 password 12345

//再次列出哈希的內(nèi)容發(fā)現(xiàn)，密碼已經(jīng)被更改了。

有關(guān)hash的操作同樣很豐富，需要時，大家可以再自行查詢。

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

redis提供了兩種持久化的方式，分別是RDB（redis database）和AOF（append only file）。

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

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

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

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

【聊聊redis持久化 - RDB】

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

redis在進行數(shù)據(jù)持久化的過程中，會先將數(shù)據(jù)寫入到一個臨時文件中，待持久化過程都結(jié)束了，才會用這個臨時文件替換上次持久化好的文件。正式這種特性，讓我們可以隨時來進行備份，因為快照文件總是完整可用的。

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

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

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

【聊聊redis持久化 - AOF】

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

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

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

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

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

因為采用了追加方式，如果不作任何處理的話，AOF文件會變得越來越大，為此，redis提供了AOF文件重寫機制，即當AOF文件的大小超過所設定的閾值時，redis就會啟動AOF文件的內(nèi)容壓縮，只保留可以恢復數(shù)據(jù)的最小指令集。舉個例子或許更形象，加入我們調(diào)用了100次incr指令，在AOF文件中就要存儲100條指令，但這明顯是很低效的，完全可以把這100條指令合并成一條set指令，這就是重寫機制的原理。

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

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

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

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

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

1.備份被寫壞的AOF文件；

2.運行redis-check-aof-fix進行修復；

3.用diff -u來看下兩個文件的差異，確認問題點；

4.重啟redis，加載修復后的AOF文件；

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

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

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

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

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

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

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

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

【聊聊主從 - 用法】

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

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

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

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

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

【聊聊主從 - 同步原理】

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

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

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

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

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

【聊聊redis的事務處理】

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

在聊redis事務處理之前，要先和大家介紹四個redis指令，即multi，exec，discard，watch。這四個指令構(gòu)成了redis事務處理的基礎。

1.multi用來組裝一個事務；

2.exec用來執(zhí)行一個事務；

3.discard用來取消一個事務；

4.watch用來監(jiān)視一些key，一旦這些key在事務執(zhí)行之前被改變，則取消事務的執(zhí)行。

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

代碼如下：

multi//標記事務開始

queued

incr user_id

queued

iincr user_id

queued

ping

queued

exec //執(zhí)行

1)(integer)1

2)(integer)2

3)(integer)3

4)pong

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

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

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

1.調(diào)用exec之前的錯誤

2.調(diào)用exec之后的錯誤

“調(diào)用exec之前的錯誤”，有可能是由于語法有誤導致的，也可能是由于內(nèi)存不足導致的。只要出現(xiàn)某個命令無法成功寫入緩沖隊列的情況，redis都會進行記錄，在客戶端調(diào)用exec時，redis會拒絕執(zhí)行這一事務。我們來看一個這樣的例子：

代碼如下：

multi

OK

haha//一個明顯的錯誤的指令

(error) ERR unknown command "haha"

ping

queued

exec

//redis無情地拒絕了事務的執(zhí)行，原因是“之前出現(xiàn)了錯誤”

(error)execabort transaction discarded because of privious errors.

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

代碼如下：

multi

OK

set age 23

queued

//age不是集合，所以如下是一條明顯錯誤的指令

sadd age 15

queued

set age 29

queued

exec//執(zhí)行事務時，redis不會理睬第2條指令執(zhí)行錯誤。

OK

(error)wrongtype operation against a key holding the wrong kind of value

OK

get age

"29"http://可以看出第三條指令被成功執(zhí)行了。

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

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

代碼如下：

set age 23

OK

watch age

OK

set age 24

OK

multi

OK

set age 25

queued

get age

queued

exec//觸發(fā)exec

(nil)//事務無法被執(zhí)行

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

我們可以在啟動redis-server時之定點桿應該加載的配置文件，方法如下：

代碼如下：

$./redis-server /path/to/redis.conf

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

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

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

代碼如下:

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

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

代碼如下：

include /path/to/other.conf

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

1.通用（general）

2.快照（snapshotting）

3.復制（replication）

4.安全（security）

5.限制（limits）

6.追加模式（append only mode）

7.LUA腳本（lua scripting）

8.慢日志（slow log）

9.事件通知（event notification）

下面就來逐一講解

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

默認情況下，redis并不是以daemon形式來運行的。通過daemonize配置項可以控制redis的運行形式。如果改為yes，那么redis就會以daemon形式運行：

代碼如下：daemonize no

當以daemon形式運行時，redis會生成一個pid文件，默認會生成在/var/run/redis.pid。當然，你可以通過pidfile命令來指定pid文件生成的位置，比如：pidfile /path/to/redis.pid

默認情況下，redis會相應本機所有可用網(wǎng)卡的連接請求。當然，redis允許你通過bind配置項來指定要綁定的IP，比如： bind 192.168.1.2 10.8.4.2

redis的默認服務端口是6379，但可以通過port配置項來修改。如果端口設置為0的話，redis便不會監(jiān)聽端口了。代碼如下：port 6379

有的同學會問“如果redis不監(jiān)聽端口，還怎么與外界通信呢”，其實redis還支持通過unix socket方式來接收請求?？梢酝ㄟ^unixsocket配置項來指定unix socket文件的路徑，并通過unixsocketperm來指定文件的權(quán)限。

代碼如下：

unixsocket /tmp/redis.sock

unixsocketperm 755

當一個redis-client一直沒有請求發(fā)現(xiàn)server端，那么server端有權(quán)主動關(guān)閉這個連接，可以通過timeout來設置“空閑超時時限”，0表示永不關(guān)閉。

代碼如下：

timeout 0

TCP連接?；畈呗?，可以通過tcp-keepalive配置項來進行設置，單位為秒，加入設置為60秒，則server端每60秒向連接空閑的客戶端發(fā)起一次ACK請求，以檢查客戶端是否已經(jīng)掛掉，對于無響應的客戶端則會關(guān)閉其連接。所以關(guān)閉一個連接最長需要120秒的時間。如果設置為0，則不會進行保活檢測。

代碼如下：

tcp-keepalive 0

redis支持通過loglevel配置項設置日志登記，共分四級，即debug、verbose、notice、warning。

代碼如下：loglevel notice

redis也支持通過logfile配置項來設置日志文件的生成位置。如果設置為空字符串，則redis會將日志輸出到標準輸出。加入你在daemon情況下將日志設置為輸出到標準輸出，則日志會被寫到/dev/null中。

代碼如下：logfile ""

如果希望日志打印到syslog中，也很容易，通過syslog-enabled來控制。另外，syslog-ident還可以讓你指定syslog里的日志標志，比如：

代碼如下：syslog-ident redis

而且還支持指定syslog設備，值可以是user或local0-local7.具體可以參考syslog服務本身的用法。

代碼如下：syslog-facility local0

對于redis來說，可以設置其數(shù)據(jù)庫的總數(shù)量，假如你希望一個redis包含16個數(shù)據(jù)庫，那么設置如下：

代碼如下：

databases 16

這16個數(shù)據(jù)庫的編號將是0到15.默認的數(shù)據(jù)庫是編號為0的數(shù)據(jù)庫。用戶可以使用select來選擇相應的數(shù)據(jù)庫。

【教你看懂redis配置 - 快照】

快照，主要涉及的是redis的RDB持久化相關(guān)的配置，我們來一起看一看。

我們可以用如下的指令來讓數(shù)據(jù)保存到磁盤上，即控制RDB快照功能：

代碼如下：save

舉例來說：

代碼如下：

save 900 1 //表示每15分鐘至少有1個key改變，就觸發(fā)一次持久化

save 300 10 //表示每5分鐘且至少有10個key改變，就觸發(fā)一次持久化。

save 60 10000 //表示每60秒至少有10000個key改變，就觸發(fā)一次持久化。

如果你想禁用RDB持久化的策略，只要不設置任何save指令就可以，或者給save傳入一個空字符串參數(shù)也可以達到相同效果，就像這樣：

代碼如下：

save ""

如果用戶開啟了RDB快照功能，那么在redis持久化數(shù)據(jù)到磁盤時如果出現(xiàn)失敗，默認情況下，redis會停止接受所有的寫請求。這樣做的好處在于可以讓用戶很明確地知道內(nèi)存中的數(shù)據(jù)和次爬上的數(shù)據(jù)已經(jīng)存在不一致了。如果redis不顧這種不一致，一意孤行的繼續(xù)接收寫請求，就可能會引起一些災難性的后果。

如果下一次RDB持久化成功，redis會自動恢復接受寫請求。

當然，如果你不在乎這種數(shù)據(jù)不一致或者有其他的手段發(fā)現(xiàn)和控制這種不一致的話，你完全可以關(guān)閉這個功能，以便在快照寫入失敗時，也能確保redis繼續(xù)接受新的寫請求。配置項如下：

代碼如下：

stop-writes-on-bgsave-error yes

對于存儲到磁盤中的快照，可以配置是否進行壓縮存儲。如果是的話，redis會才有LZF算法進行壓縮。如果你不想消耗CPU來進行壓縮的話，可以設置為關(guān)閉此功能，但是存儲在磁盤上的快照會比較大。

代碼如下：

rdbcompression yes

在存儲快照后，我們還可以讓redis使用CRC64算法來進行數(shù)據(jù)校驗，但是這樣做會增加大約10%的性能消耗，如果你希望獲取到最大的性能提升，可以關(guān)閉此功能。

代碼如下：

rdbchecksum yes

我們還可以設置快照文件的名稱，默認是這樣配置的：

代碼如下：

dbfilename dump.rdb

最后，你還可以設置這個快照文件存放的路徑。比如默認設置就是當前文件夾：

代碼如下：

dir ./

【教你看懂redis配置 - 復制】

redis提供了主從同步功能。

通過salveof配置項可以控制某一個redis作為另一個redis的從服務器，通過指定IP和端口來定位到主redis的位置。一般情況下，我們會建議用戶為從redis設置一個不同頻率的快照持久化的周期，或者為從redis配置一個不同的服務端口等等。

代碼如下：

slaveof

如果主redis設置了校驗密碼的話（使用requirepass來設置），則在從redis的配置中要使用masterauth來設置校驗密碼，否則的話，主redis會拒絕從redis的訪問請求。

代碼如下：

masterauth

當從redis失去了與主redis的連接，或者主從同步正在進行中時，redis該如何處理外部發(fā)來的訪問請求呢？這里，從redis可以有兩種選擇：

第一種選擇：如果slave-serve-stale-data設置為yes（默認），則從redis仍會繼續(xù)相應客戶端的讀寫請求。

第二種選擇：如果slave-serve-stale-data設置為no，則從redis會對客戶端的請求返回“SYNC with master in progress",當然也有例外，當客戶端發(fā)來info請求和slaveof請求，從redis還是會進行處理。

你可以控制一個從redis是否可以接受寫請求。將數(shù)據(jù)直接寫入從redis，一般只適用于那些生命周期非常短的數(shù)據(jù)，因為在主從同步時，這些臨時數(shù)據(jù)就會被清理掉。自從redis2.6版本之后，默認從redis為只讀。

代碼如下：

slave-read-only yes

只讀的從redis并不適合直接暴露給不可信的客戶端。為了盡量降低風險，可以使用rename-command命令來將一些可能有破壞力的命令重命名，避免外部直接調(diào)用。比如：

代碼如下：

rename-command config b840fc02d524045429941cc15f59e41cb7be6c52

從redis會周期性的向主redis發(fā)出PING包。你可以通過repl_ping_slave_period指令來控制其周期。默認是10秒。

代碼如下：

repl-ping-slave-period 10

在主從同步時，可能在這些情況下會有超時發(fā)生：

1.以從redis的角度來看，當有大規(guī)模IO傳輸時。

2.以從redis的角度來看，當數(shù)據(jù)傳輸或PING時，主redis超時

3.以主redis的角度來看，在回復從redis的PING時，從redis超時

用戶可以設置上述超時的時限，不過要確保這個時限比repl-slave-period的值要大，否則每次主redis都會認為從redis超時。

代碼如下：

repl-timeout 60

我們還可以設置同步隊列長度。隊列長度（backlog）是主redis中的一個緩沖區(qū)，在與從redis斷開連接期間，主redis會用這個緩沖區(qū)來緩存應該發(fā)給從redis的數(shù)據(jù)。這樣的話，當從redis重新連接上之后，就不必重新全量同步數(shù)據(jù)，只需要同步這部分增量數(shù)據(jù)即可。

代碼如下：

repl-backlog-size 1mb

如果主redis等了一段時間之后，還是無法連接到從redis，那么緩沖隊列中的數(shù)據(jù)將被清理掉。我們可以設置主redis要等待的時間長度。如果設置為0，則表示永遠不清理。默認是一個小時。

代碼如下：

repl-backlog-ttl 3600

我們可以給眾多的從redis設置優(yōu)先級，在主redis持續(xù)工作不正常的情況下，優(yōu)先級高的從redis將會升級為主redis。而編號越小，優(yōu)先級越高。比如一個主redis有三個從redis，優(yōu)先級編號分別為10,100,25，那么編號為10的從redis將會被首先選中升級為主redis。當優(yōu)先級被設置為0時，這個從redis將永遠也不會被選中。默認的優(yōu)先級為100.

代碼如下：

slave-priority 100

加入主redis發(fā)現(xiàn)有超過M個從redis的連接延時大于N秒，那么主redis就停止接受外來的寫請求。這是因為從redis一般會每秒鐘都向主redis發(fā)出PING，而主redis會記錄每一個從redis最近一次發(fā)來PING的時間點，所以主redis能夠了解每一個從redis的運行情況。

代碼如下：

min-slave-to-write 3

min-slave-max-lag 10

上面這個例子表示，加入有大于等于3個從redis的連接延遲大于10秒，那么主redis就不再接受外部的寫請求。上述兩個配置中有一個被置為0，則這個特性將被關(guān)閉。默認情況下min-slaves-to-write為0，而min-slaves-max-lag為10。

【教你看懂redis配置 - 安全】

我們可以要求客戶端在向redis-server發(fā)送請求之前，先進性密碼驗證。當你的redis-server處于一個不太可信的網(wǎng)絡環(huán)境中時，相信你會用上這個功能。由于redis性能非常高，所以每秒鐘可以完成多大15萬次的密碼嘗試，所以你最好設置一個足夠復雜的密碼，否則很容易被黑客破解。

代碼如下：

requirepass zhimakaimen

這里我們通過requirepass將密碼設置成“芝麻開門”。

redis允許我們對redis指令進行更名，比如將一些比較危險的命令改個名字，避免被誤執(zhí)行。比如可以把cofig命令改成一個很復雜的名字，這樣可以避免外部的調(diào)用，同時還可以滿足內(nèi)部調(diào)用的需要：

代碼如下：

rename-command config b840fc02d524045429941cc15f59e41cb7be6c52

我們設置可以禁用掉config命令，那就是把config的名字改成一個空字符串：

代碼如下：

rename-command config ""

【教你看懂redis配置-限制】

我們可以設置redis同時可以與多少個客戶端進行連接。默認情況下為10000個客戶端。當你無法設置進程文件句柄限制時，redis會設置為當前的文件句柄限制值減去32，因為redis會為自身內(nèi)部處理邏輯留一些句柄出來。

如果達到了此限制，redis會拒絕信的連接請求，并且想這些連接請求方發(fā)出“max numer of clients reached”以作回應。

代碼如下：

maxclients 10000

我們設置可以設置redis可以使用的內(nèi)存量。一旦到達內(nèi)存使用上限，redis將會試圖移除內(nèi)部數(shù)據(jù)，移除規(guī)則可以通過max-memory-policy來指定。

如果redis無法根據(jù)移除規(guī)則來移除內(nèi)存中的數(shù)據(jù)，或者我們設置了“不允許移除”，那么redis則會針對那些需要申請內(nèi)存的指令返回錯誤信息，比如set、LPUSH等。但是對于無內(nèi)存申請的指令，仍然會正常響應，比如get等。

代碼如下：

maxmemory

需要注意的一點是，如果你的redis是主redis（說明你的redis有從redis），那么在設置內(nèi)存使用上限時，需要在系統(tǒng)中留出一些內(nèi)存空間給同步隊列緩存，只有在你設置的是“不移除”的情況下，才不用考慮這個因素。

對于內(nèi)存移除規(guī)則來說，redis提供了多達六種的移除規(guī)則。它們是：

1.volatile-lru：使用LRU算法移除過期集合中的key

2.allkeys-lru:使用LRU算法移除key

3.volatile-random:在過期集合中移除隨機的key

4.allkeys-random：移除隨機的key

5.volatile-ttl：移除那些ttl值最小的key，即那些最近才過期的key。

6.noeviction：不進行移除。針對寫操作，只是返回錯誤信息。

無論使用上述哪一種移除規(guī)則，如果沒有合適的key可以移除的話，redis都會針對寫請求返回錯誤信息。

代碼如下：

maxmemory-policy volatile-lru

LRU算法和最小的TTl算法都并非是精確的算法，而是估算值。所以你可以設置樣本的大小。加入redis默認會檢查三個key并選擇其中LRU的那個，那么你可以改變這個key樣本的數(shù)量。

后面的一些配置的介紹不再細說，可以看配置文件或者上網(wǎng)查找資料進行了解。