超強(qiáng)、超詳細(xì)Redis數(shù)據(jù)庫(kù)入門教程
【本教程目錄】
1.redis是什么
2.redis的作者何許人也
3.誰(shuí)在使用redis
4.學(xué)會(huì)安裝redis
5.學(xué)會(huì)啟動(dòng)redis
6.使用redis客戶端
7.redis數(shù)據(jù)結(jié)構(gòu) – 簡(jiǎn)介
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配置 – 簡(jiǎn)介
22.教你看懂redis配置 -通用
23.教你看懂redis配置 – 快照
24.教你看懂redis配置 – 復(fù)制
25.教你看懂redis配置 – 安全
26.教你看懂redis配置 -限制
27.教你看懂redis配置 – 追加模式
28.教你看懂redis配置 – LUA腳本
29.教你看懂redis配置 – 慢日志
30.教你看懂redis配置 – 事件通知
31.教你看懂redis配置 – 高級(jí)配置
【redis是什么】
redis是一個(gè)開源的、使用C語(yǔ)言編寫的、支持網(wǎng)絡(luò)交互的、可基于內(nèi)存也可持久化的Key-Value數(shù)據(jù)庫(kù)。
redis的官網(wǎng)地址，非常好記，是redis.io。（特意查了一下，域名后綴io屬于國(guó)家域名，是british Indian Ocean territory，即英屬印度洋領(lǐng)地）
目前，Vmware在資助著redis項(xiàng)目的開發(fā)和維護(hù)。
【redis的作者何許人也】
開門見(jiàn)山，先看照片：
是不是出乎了你的意料，嗯，高手總會(huì)有些地方與眾不同的。
這位便是redis的作者，他叫Salvatore Sanfilippo，來(lái)自意大利的西西里島，現(xiàn)在居住在卡塔尼亞。目前供職于Pivotal公司。
他使用的網(wǎng)名是antirez，如果你有興趣，可以去他的博客逛逛，地址是antirez.com，當(dāng)然也可以去follow他的github，地址是http://github.com/antirez。
【誰(shuí)在使用redis】
Blizzard、digg、stackoverflow、github、flickr …
【學(xué)會(huì)安裝redis】
從redis.io下載最新版redis-X.Y.Z.tar.gz后解壓，然后進(jìn)入redis-X.Y.Z文件夾后直接make即可，安裝非常簡(jiǎn)單。
make成功后會(huì)在src文件夾下產(chǎn)生一些二進(jìn)制可執(zhí)行文件，包括redis-server、redis-cli等等：
$ find . -type f -executable
./redis-benchmark //用于進(jìn)行redis性能測(cè)試的工具
./redis-check-dump //用于修復(fù)出問(wèn)題的dump.rdb文件
./redis-cli //redis的客戶端
./redis-server //redis的服務(wù)端
./redis-check-aof //用于修復(fù)出問(wèn)題的AOF文件
./redis-sentinel //用于集群管理
【學(xué)會(huì)啟動(dòng)redis】
啟動(dòng)redis非常簡(jiǎn)單，直接./redis-server就可以啟動(dòng)服務(wù)端了，還可以用下面的方法指定要加載的配置文件：
./redis-server ../redis.conf
默認(rèn)情況下，redis-server會(huì)以非daemon的方式來(lái)運(yùn)行，且默認(rèn)服務(wù)端口為6379。
有關(guān)作者為什么選擇6379作為默認(rèn)端口，還有一段有趣的典故，英語(yǔ)好的同學(xué)可以看看作者這篇博文中的解釋。
【使用redis客戶端】
我們直接看一個(gè)例子：
//這樣來(lái)啟動(dòng)redis客戶端了
$ ./redis-cli
//用set指令來(lái)設(shè)置key、value
127.0.0.1:6379> set name "roc"
OK
//來(lái)獲取name的值
127.0.0.1:6379> get name
"roc"
//通過(guò)客戶端來(lái)關(guān)閉redis服務(wù)端
127.0.0.1:6379> shutdown
127.0.0.1:6379>
【redis數(shù)據(jù)結(jié)構(gòu) – 簡(jiǎn)介】
redis是一種高級(jí)的key:value存儲(chǔ)系統(tǒng)，其中value支持五種數(shù)據(jù)類型：
1.字符串（strings）
2.字符串列表（lists）
3.字符串集合（sets）
4.有序字符串集合（sorted sets）
5.哈希（hashes）
而關(guān)于key，有幾個(gè)點(diǎn)要提醒大家：
1.key不要太長(zhǎng)，盡量不要超過(guò)1024字節(jié)，這不僅消耗內(nèi)存，而且會(huì)降低查找的效率；
2.key也不要太短，太短的話，key的可讀性會(huì)降低；
3.在一個(gè)項(xiàng)目中，key最好使用統(tǒng)一的命名模式，例如user:10000:passwd。
【redis數(shù)據(jù)結(jié)構(gòu) – strings】
有人說(shuō)，如果只使用redis中的字符串類型，且不使用redis的持久化功能，那么，redis就和memcache非常非常的像了。這說(shuō)明strings類型是一個(gè)很基礎(chǔ)的數(shù)據(jù)類型，也是任何存儲(chǔ)系統(tǒng)都必備的數(shù)據(jù)類型。
我們來(lái)看一個(gè)最簡(jiǎn)單的例子：
set mystr "hello world!" //設(shè)置字符串類型
get mystr //讀取字符串類型
字符串類型的用法就是這么簡(jiǎn)單，因?yàn)槭嵌M(jìn)制安全的，所以你完全可以把一個(gè)圖片文件的內(nèi)容作為字符串來(lái)存儲(chǔ)。
另外，我們還可以通過(guò)字符串類型進(jìn)行數(shù)值操作：
127.0.0.1:6379> set mynum "2"
OK
127.0.0.1:6379> get mynum
"2"
127.0.0.1:6379> incr mynum
(integer) 3
127.0.0.1:6379> get mynum
"3"
看，在遇到數(shù)值操作時(shí)，redis會(huì)將字符串類型轉(zhuǎn)換成數(shù)值。
由于INCR等指令本身就具有原子操作的特性，所以我們完全可以利用redis的INCR、INCRBY、DECR、DECRBY等指令來(lái)實(shí)現(xiàn)原子計(jì)數(shù)的效果，假如，在某種場(chǎng)景下有3個(gè)客戶端同時(shí)讀取了mynum的值（值為2），然后對(duì)其同時(shí)進(jìn)行了加1的操作，那么，最后mynum的值一定是5。不少網(wǎng)站都利用redis的這個(gè)特性來(lái)實(shí)現(xiàn)業(yè)務(wù)上的統(tǒng)計(jì)計(jì)數(shù)需求。
【redis數(shù)據(jù)結(jié)構(gòu) – lists】
redis的另一個(gè)重要的數(shù)據(jù)結(jié)構(gòu)叫做lists，翻譯成中文叫做“列表”。
首先要明確一點(diǎn)，redis中的lists在底層實(shí)現(xiàn)上并不是數(shù)組，而是鏈表，也就是說(shuō)對(duì)于一個(gè)具有上百萬(wàn)個(gè)元素的lists來(lái)說(shuō)，在頭部和尾部插入一個(gè)新元素，其時(shí)間復(fù)雜度是常數(shù)級(jí)別的，比如用LPUSH在10個(gè)元素的lists頭部插入新元素，和在上千萬(wàn)元素的lists頭部插入新元素的速度應(yīng)該是相同的。
雖然lists有這樣的優(yōu)勢(shì)，但同樣有其弊端，那就是，鏈表型lists的元素定位會(huì)比較慢，而數(shù)組型lists的元素定位就會(huì)快得多。
lists的常用操作包括LPUSH、RPUSH、LRANGE等。我們可以用LPUSH在lists的左側(cè)插入一個(gè)新元素，用RPUSH在lists的右側(cè)插入一個(gè)新元素，用LRANGE命令從lists中指定一個(gè)范圍來(lái)提取元素。我們來(lái)看幾個(gè)例子：
//新建一個(gè)list叫做mylist，并在列表頭部插入元素"1"
127.0.0.1:6379> lpush mylist "1"
//返回當(dāng)前mylist中的元素個(gè)數(shù)
(integer) 1
//在mylist右側(cè)插入元素"2"
127.0.0.1:6379> rpush mylist "2"
(integer) 2
//在mylist左側(cè)插入元素"0"
127.0.0.1:6379> lpush mylist "0"
(integer) 3
//列出mylist中從編號(hào)0到編號(hào)1的元素
127.0.0.1:6379> lrange mylist 0 1
1) "0"
2) "1"
//列出mylist中從編號(hào)0到倒數(shù)第一個(gè)元素
127.0.0.1:6379> lrange mylist 0 -1
1) "0"
2) "1"
3) "2"
lists的應(yīng)用相當(dāng)廣泛，隨便舉幾個(gè)例子：
1.我們可以利用lists來(lái)實(shí)現(xiàn)一個(gè)消息隊(duì)列，而且可以確保先后順序，不必像MySQL那樣還需要通過(guò)ORDER BY來(lái)進(jìn)行排序。
2.利用LRANGE還可以很方便的實(shí)現(xiàn)分頁(yè)的功能。
3.在博客系統(tǒng)中，每片博文的評(píng)論也可以存入一個(gè)單獨(dú)的list中。
【redis數(shù)據(jù)結(jié)構(gòu) – 集合】
redis的集合，是一種無(wú)序的集合，集合中的元素沒(méi)有先后順序。
集合相關(guān)的操作也很豐富，如添加新元素、刪除已有元素、取交集、取并集、取差集等。我們來(lái)看例子：
//向集合myset中加入一個(gè)新元素"one"
127.0.0.1:6379> sadd myset "one"
(integer) 1
127.0.0.1:6379> sadd myset "two"
(integer) 1
//列出集合myset中的所有元素
127.0.0.1:6379> smembers myset
1) "one"
2) "two"
//判斷元素1是否在集合myset中，返回1表示存在
127.0.0.1:6379> sismember myset "one"
(integer) 1
//判斷元素3是否在集合myset中，返回0表示不存在
127.0.0.1:6379> sismember myset "three"
(integer) 0
//新建一個(gè)新的集合yourset
127.0.0.1:6379> sadd yourset "1"
(integer) 1
127.0.0.1:6379> sadd yourset "2"
(integer) 1
127.0.0.1:6379> smembers yourset
1) "1"
2) "2"
//對(duì)兩個(gè)集合求并集
127.0.0.1:6379> sunion myset yourset
1) "1"
2) "one"
3) "2"
4) "two"
對(duì)于集合的使用，也有一些常見(jiàn)的方式，比如，QQ有一個(gè)社交功能叫做“好友標(biāo)簽”，大家可以給你的好友貼標(biāo)簽，比如“大美女”、“土豪”、“歐巴”等等，這時(shí)就可以使用redis的集合來(lái)實(shí)現(xiàn)，把每一個(gè)用戶的標(biāo)簽都存儲(chǔ)在一個(gè)集合之中。
【redis數(shù)據(jù)結(jié)構(gòu) – 有序集合】
redis不但提供了無(wú)需集合（sets），還很體貼的提供了有序集合（sorted sets）。有序集合中的每個(gè)元素都關(guān)聯(lián)一個(gè)序號(hào)（score），這便是排序的依據(jù)。
很多時(shí)候，我們都將redis中的有序集合叫做zsets，這是因?yàn)樵趓edis中，有序集合相關(guān)的操作指令都是以z開頭的，比如zrange、zadd、zrevrange、zrangebyscore等等
老規(guī)矩，我們來(lái)看幾個(gè)生動(dòng)的例子：
//新增一個(gè)有序集合myzset，并加入一個(gè)元素baidu.com，給它賦予的序號(hào)是1：
127.0.0.1:6379> zadd myzset 1 baidu.com
(integer) 1
//向myzset中新增一個(gè)元素360.com，賦予它的序號(hào)是3
127.0.0.1:6379> zadd myzset 3 360.com
(integer) 1
//向myzset中新增一個(gè)元素google.com，賦予它的序號(hào)是2
127.0.0.1:6379> zadd myzset 2 google.com
(integer) 1
//列出myzset的所有元素，同時(shí)列出其序號(hào)，可以看出myzset已經(jīng)是有序的了。
127.0.0.1:6379> zrange myzset 0 -1 with scores
1) "baidu.com"
2) "1"
3) "google.com"
4) "2"
5) "360.com"
6) "3"
//只列出myzset的元素
127.0.0.1:6379> zrange myzset 0 -1
1) "baidu.com"
2) "google.com"
3) "360.com"
【redis數(shù)據(jù)結(jié)構(gòu) – 哈希】
最后要給大家介紹的是hashes，即哈希。哈希是從redis-2.0.0版本之后才有的數(shù)據(jù)結(jié)構(gòu)。
hashes存的是字符串和字符串值之間的映射，比如一個(gè)用戶要存儲(chǔ)其全名、姓氏、年齡等等，就很適合使用哈希。
我們來(lái)看一個(gè)例子：
//建立哈希，并賦值
127.0.0.1:6379> HMSET user:001 username antirez password P1pp0 age 34
OK
//列出哈希的內(nèi)容
127.0.0.1:6379> HGETALL user:001
1) "username"
2) "antirez"
3) "password"
4) "P1pp0"
5) "age"
6) "34"
//更改哈希中的某一個(gè)值
127.0.0.1:6379> HSET user:001 password 12345
(integer) 0
//再次列出哈希的內(nèi)容
127.0.0.1:6379> HGETALL user:001
1) "username"
2) "antirez"
3) "password"
4) "12345"
5) "age"
6) "34"
有關(guān)hashes的操作，同樣很豐富，需要時(shí)，大家可以從這里查詢。
【聊聊redis持久化 – 兩種方式】
redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Append Only File）。
RDB，簡(jiǎn)而言之，就是在不同的時(shí)間點(diǎn)，將redis存儲(chǔ)的數(shù)據(jù)生成快照并存儲(chǔ)到磁盤等介質(zhì)上；
AOF，則是換了一個(gè)角度來(lái)實(shí)現(xiàn)持久化，那就是將redis執(zhí)行過(guò)的所有寫指令記錄下來(lái)，在下次redis重新啟動(dòng)時(shí)，只要把這些寫指令從前到后再重復(fù)執(zhí)行一遍，就可以實(shí)現(xiàn)數(shù)據(jù)恢復(fù)了。
其實(shí)RDB和AOF兩種方式也可以同時(shí)使用，在這種情況下，如果redis重啟的話，則會(huì)優(yōu)先采用AOF方式來(lái)進(jìn)行數(shù)據(jù)恢復(fù)，這是因?yàn)锳OF方式的數(shù)據(jù)恢復(fù)完整度更高。
如果你沒(méi)有數(shù)據(jù)持久化的需求，也完全可以關(guān)閉RDB和AOF方式，這樣的話，redis將變成一個(gè)純內(nèi)存數(shù)據(jù)庫(kù)，就像memcache一樣。
【聊聊redis持久化 – RDB】
RDB方式，是將redis某一時(shí)刻的數(shù)據(jù)持久化到磁盤中，是一種快照式的持久化方法。
redis在進(jìn)行數(shù)據(jù)持久化的過(guò)程中，會(huì)先將數(shù)據(jù)寫入到一個(gè)臨時(shí)文件中，待持久化過(guò)程都結(jié)束了，才會(huì)用這個(gè)臨時(shí)文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時(shí)來(lái)進(jìn)行備份，因?yàn)榭煺瘴募偸峭暾捎玫摹?/p>
對(duì)于RDB方式，redis會(huì)單獨(dú)創(chuàng)建（fork）一個(gè)子進(jìn)程來(lái)進(jìn)行持久化，而主進(jìn)程是不會(huì)進(jìn)行任何IO操作的，這樣就確保了redis極高的性能。
如果需要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù)，且對(duì)于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
雖然RDB有不少優(yōu)點(diǎn)，但它的缺點(diǎn)也是不容忽視的。如果你對(duì)數(shù)據(jù)的完整性非常敏感，那么RDB方式就不太適合你，因?yàn)榧词鼓忝?分鐘都持久化一次，當(dāng)redis故障時(shí)，仍然會(huì)有近5分鐘的數(shù)據(jù)丟失。所以，redis還提供了另一種持久化方式，那就是AOF。
【聊聊redis持久化 – AOF】
AOF，英文是Append Only File，即只允許追加不允許改寫的文件。
如前面介紹的，AOF方式是將執(zhí)行過(guò)的寫指令記錄下來(lái)，在數(shù)據(jù)恢復(fù)時(shí)按照從前到后的順序再將指令都執(zhí)行一遍，就這么簡(jiǎn)單。
我們通過(guò)配置redis.conf中的appendonly yes就可以打開AOF功能。如果有寫操作（如SET等），redis就會(huì)被追加到AOF文件的末尾。
默認(rèn)的AOF持久化策略是每秒鐘fsync一次（fsync是指把緩存中的寫指令記錄到磁盤中），因?yàn)樵谶@種情況下，redis仍然可以保持很好的處理性能，即使redis故障，也只會(huì)丟失最近1秒鐘的數(shù)據(jù)。
如果在追加日志時(shí)，恰好遇到磁盤空間滿、inode滿或斷電等情況導(dǎo)致日志寫入不完整，也沒(méi)有關(guān)系，redis提供了redis-check-aof工具，可以用來(lái)進(jìn)行日志修復(fù)。
因?yàn)椴捎昧俗芳臃绞?，如果不做任何處理的話，AOF文件會(huì)變得越來(lái)越大，為此，redis提供了AOF文件重寫（rewrite）機(jī)制，即當(dāng)AOF文件的大小超過(guò)所設(shè)定的閾值時(shí)，redis就會(huì)啟動(dòng)AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集。舉個(gè)例子或許更形象，假如我們調(diào)用了100次INCR指令，在AOF文件中就要存儲(chǔ)100條指令，但這明顯是很低效的，完全可以把這100條指令合并成一條SET指令，這就是重寫機(jī)制的原理。
在進(jìn)行AOF重寫時(shí)，仍然是采用先寫臨時(shí)文件，全部完成后再替換的流程，所以斷電、磁盤滿等問(wèn)題都不會(huì)影響AOF文件的可用性，這點(diǎn)大家可以放心。
AOF方式的另一個(gè)好處，我們通過(guò)一個(gè)“場(chǎng)景再現(xiàn)”來(lái)說(shuō)明。某同學(xué)在操作redis時(shí)，不小心執(zhí)行了FLUSHALL，導(dǎo)致redis內(nèi)存中的數(shù)據(jù)全部被清空了，這是很悲劇的事情。不過(guò)這也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件還沒(méi)有被重寫（rewrite），我們就可以用最快的速度暫停redis并編輯AOF文件，將最后一行的FLUSHALL命令刪除，然后重啟redis，就可以恢復(fù)redis的所有數(shù)據(jù)到FLUSHALL之前的狀態(tài)了。是不是很神奇，這就是AOF持久化方式的好處之一。但是如果AOF文件已經(jīng)被重寫了，那就無(wú)法通過(guò)這種方法來(lái)恢復(fù)數(shù)據(jù)了。
雖然優(yōu)點(diǎn)多多，但AOF方式也同樣存在缺陷，比如在同樣數(shù)據(jù)規(guī)模的情況下，AOF文件要比RDB文件的體積大。而且，AOF方式的恢復(fù)速度也要慢于RDB方式。
如果你直接執(zhí)行BGREWRITEAOF命令，那么redis會(huì)生成一個(gè)全新的AOF文件，其中便包括了可以恢復(fù)現(xiàn)有數(shù)據(jù)的最少的命令集。
如果運(yùn)氣比較差，AOF文件出現(xiàn)了被寫壞的情況，也不必過(guò)分擔(dān)憂，redis并不會(huì)貿(mào)然加載這個(gè)有問(wèn)題的AOF文件，而是報(bào)錯(cuò)退出。這時(shí)可以通過(guò)以下步驟來(lái)修復(fù)出錯(cuò)的文件：
1.備份被寫壞的AOF文件
2.運(yùn)行redis-check-aof –fix進(jìn)行修復(fù)
3.用diff -u來(lái)看下兩個(gè)文件的差異，確認(rèn)問(wèn)題點(diǎn)
4.重啟redis，加載修復(fù)后的AOF文件
【聊聊redis持久化 – AOF重寫】
AOF重寫的內(nèi)部運(yùn)行原理，我們有必要了解一下。
在重寫即將開始之際，redis會(huì)創(chuàng)建（fork）一個(gè)“重寫子進(jìn)程”，這個(gè)子進(jìn)程會(huì)首先讀取現(xiàn)有的AOF文件，并將其包含的指令進(jìn)行分析壓縮并寫入到一個(gè)臨時(shí)文件中。
與此同時(shí)，主工作進(jìn)程會(huì)將新接收到的寫指令一邊累積到內(nèi)存緩沖區(qū)中，一邊繼續(xù)寫入到原有的AOF文件中，這樣做是保證原有的AOF文件的可用性，避免在重寫過(guò)程中出現(xiàn)意外。
當(dāng)“重寫子進(jìn)程”完成重寫工作后，它會(huì)給父進(jìn)程發(fā)一個(gè)信號(hào)，父進(jìn)程收到信號(hào)后就會(huì)將內(nèi)存中緩存的寫指令追加到新AOF文件中。
當(dāng)追加結(jié)束后，redis就會(huì)用新AOF文件來(lái)代替舊AOF文件，之后再有新的寫指令，就都會(huì)追加到新的AOF文件中了。
【聊聊redis持久化 – 如何選擇RDB和AOF】
對(duì)于我們應(yīng)該選擇RDB還是AOF，官方的建議是兩個(gè)同時(shí)使用。這樣可以提供更可靠的持久化方案。
【聊聊主從 – 用法】
像MySQL一樣，redis是支持主從同步的，而且也支持一主多從以及多級(jí)從結(jié)構(gòu)。
主從結(jié)構(gòu)，一是為了純粹的冗余備份，二是為了提升讀性能，比如很消耗性能的SORT就可以由從服務(wù)器來(lái)承擔(dān)。
redis的主從同步是異步進(jìn)行的，這意味著主從同步不會(huì)影響主邏輯，也不會(huì)降低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)行重命名，來(lái)避免命令被外人誤執(zhí)行。
【聊聊主從 – 同步原理】
從服務(wù)器會(huì)向主服務(wù)器發(fā)出SYNC指令，當(dāng)主服務(wù)器接到此命令后，就會(huì)調(diào)用BGSAVE指令來(lái)創(chuàng)建一個(gè)子進(jìn)程專門進(jìn)行數(shù)據(jù)持久化工作，也就是將主服務(wù)器的數(shù)據(jù)寫入RDB文件中。在數(shù)據(jù)持久化期間，主服務(wù)器將執(zhí)行的寫指令都緩存在內(nèi)存中。
在BGSAVE指令執(zhí)行完成后，主服務(wù)器會(huì)將持久化好的RDB文件發(fā)送給從服務(wù)器，從服務(wù)器接到此文件后會(huì)將其存儲(chǔ)到磁盤上，然后再將其讀取到內(nèi)存中。這個(gè)動(dòng)作完成后，主服務(wù)器會(huì)將這段時(shí)間緩存的寫指令再以redis協(xié)議的格式發(fā)送給從服務(wù)器。
另外，要說(shuō)的一點(diǎn)是，即使有多個(gè)從服務(wù)器同時(shí)發(fā)來(lái)SYNC指令，主服務(wù)器也只會(huì)執(zhí)行一次BGSAVE，然后把持久化好的RDB文件發(fā)給多個(gè)下游。在redis2.8版本之前，如果從服務(wù)器與主服務(wù)器因某些原因斷開連接的話，都會(huì)進(jìn)行一次主從之間的全量的數(shù)據(jù)同步；而在2.8版本之后，redis支持了效率更高的增量同步策略，這大大降低了連接斷開的恢復(fù)成本。
主服務(wù)器會(huì)在內(nèi)存中維護(hù)一個(gè)緩沖區(qū)，緩沖區(qū)中存儲(chǔ)著將要發(fā)給從服務(wù)器的內(nèi)容。從服務(wù)器在與主服務(wù)器出現(xiàn)網(wǎng)絡(luò)瞬斷之后，從服務(wù)器會(huì)嘗試再次與主服務(wù)器連接，一旦連接成功，從服務(wù)器就會(huì)把“希望同步的主服務(wù)器ID”和“希望請(qǐng)求的數(shù)據(jù)的偏移位置（replication offset）”發(fā)送出去。主服務(wù)器接收到這樣的同步請(qǐng)求后，首先會(huì)驗(yàn)證主服務(wù)器ID是否和自己的ID匹配，其次會(huì)檢查“請(qǐng)求的偏移位置”是否存在于自己的緩沖區(qū)中，如果兩者都滿足的話，主服務(wù)器就會(huì)向從服務(wù)器發(fā)送增量?jī)?nèi)容。
增量同步功能，需要服務(wù)器端支持全新的PSYNC指令。這個(gè)指令，只有在redis-2.8之后才具有。
【聊聊redis的事務(wù)處理】
眾所周知，事務(wù)是指“一個(gè)完整的動(dòng)作，要么全部執(zhí)行，要么什么也沒(méi)有做”。
在聊redis事務(wù)處理之前，要先和大家介紹四個(gè)redis指令，即MULTI、EXEC、DISCARD、WATCH。這四個(gè)指令構(gòu)成了redis事務(wù)處理的基礎(chǔ)。
1.MULTI用來(lái)組裝一個(gè)事務(wù)；
2.EXEC用來(lái)執(zhí)行一個(gè)事務(wù)；
3.DISCARD用來(lái)取消一個(gè)事務(wù)；
4.WATCH用來(lái)監(jiān)視一些key，一旦這些key在事務(wù)執(zhí)行之前被改變，則取消事務(wù)的執(zhí)行。
紙上得來(lái)終覺(jué)淺，我們來(lái)看一個(gè)MULTI和EXEC的例子：
redis> MULTI //標(biāo)記事務(wù)開始
OK
redis> INCR user_id //多條命令按順序入隊(duì)
QUEUED
redis> INCR user_id
QUEUED
redis> INCR user_id
QUEUED
redis> PING
QUEUED
redis> EXEC //執(zhí)行
1) (integer) 1
2) (integer) 2
3) (integer) 3
4) PONG
在上面的例子中，我們看到了QUEUED的字樣，這表示我們?cè)谟肕ULTI組裝事務(wù)時(shí)，每一個(gè)命令都會(huì)進(jìn)入到內(nèi)存隊(duì)列中緩存起來(lái)，如果出現(xiàn)QUEUED則表示我們這個(gè)命令成功插入了緩存隊(duì)列，在將來(lái)執(zhí)行EXEC時(shí)，這些被QUEUED的命令都會(huì)被組裝成一個(gè)事務(wù)來(lái)執(zhí)行。
對(duì)于事務(wù)的執(zhí)行來(lái)說(shuō)，如果redis開啟了AOF持久化的話，那么一旦事務(wù)被成功執(zhí)行，事務(wù)中的命令就會(huì)通過(guò)write命令一次性寫到磁盤中去，如果在向磁盤中寫的過(guò)程中恰好出現(xiàn)斷電、硬件故障等問(wèn)題，那么就可能出現(xiàn)只有部分命令進(jìn)行了AOF持久化，這時(shí)AOF文件就會(huì)出現(xiàn)不完整的情況，這時(shí)，我們可以使用redis-check-aof工具來(lái)修復(fù)這一問(wèn)題，這個(gè)工具會(huì)將AOF文件中不完整的信息移除，確保AOF文件完整可用。
有關(guān)事務(wù)，大家經(jīng)常會(huì)遇到的是兩類錯(cuò)誤：
1.調(diào)用EXEC之前的錯(cuò)誤
2.調(diào)用EXEC之后的錯(cuò)誤
“調(diào)用EXEC之前的錯(cuò)誤”，有可能是由于語(yǔ)法有誤導(dǎo)致的，也可能時(shí)由于內(nèi)存不足導(dǎo)致的。只要出現(xiàn)某個(gè)命令無(wú)法成功寫入緩沖隊(duì)列的情況，redis都會(huì)進(jìn)行記錄，在客戶端調(diào)用EXEC時(shí)，redis會(huì)拒絕執(zhí)行這一事務(wù)。（這時(shí)2.6.5版本之后的策略。在2.6.5之前的版本中，redis會(huì)忽略那些入隊(duì)失敗的命令，只執(zhí)行那些入隊(duì)成功的命令）。我們來(lái)看一個(gè)這樣的例子：
127.0.0.1:6379> multi
OK
127.0.0.1:6379> haha //一個(gè)明顯錯(cuò)誤的指令
(error) ERR unknown command 'haha'
127.0.0.1:6379> ping
QUEUED
127.0.0.1:6379> exec
//redis無(wú)情的拒絕了事務(wù)的執(zhí)行，原因是“之前出現(xiàn)了錯(cuò)誤”
(error) EXECABORT Transaction discarded because of previous errors.
而對(duì)于“調(diào)用EXEC之后的錯(cuò)誤”，redis則采取了完全不同的策略，即redis不會(huì)理睬這些錯(cuò)誤，而是繼續(xù)向下執(zhí)行事務(wù)中的其他命令。這是因?yàn)?，?duì)于應(yīng)用層面的錯(cuò)誤，并不是redis自身需要考慮和處理的問(wèn)題，所以一個(gè)事務(wù)中如果某一條命令執(zhí)行失敗，并不會(huì)影響接下來(lái)的其他命令的執(zhí)行。我們也來(lái)看一個(gè)例子：
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 23
QUEUED
//age不是集合，所以如下是一條明顯錯(cuò)誤的指令
127.0.0.1:6379> sadd age 15
QUEUED
127.0.0.1:6379> set age 29
QUEUED
127.0.0.1:6379> exec //執(zhí)行事務(wù)時(shí)，redis不會(huì)理睬第2條指令執(zhí)行錯(cuò)誤
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> get age
"29" //可以看出第3條指令被成功執(zhí)行了
好了，我們來(lái)說(shuō)說(shuō)最后一個(gè)指令“WATCH”，這是一個(gè)很好用的指令，它可以幫我們實(shí)現(xiàn)類似于“樂(lè)觀鎖”的效果，即CAS（check and set）。
WATCH本身的作用是“監(jiān)視key是否被改動(dòng)過(guò)”，而且支持同時(shí)監(jiān)視多個(gè)key，只要還沒(méi)真正觸發(fā)事務(wù)，WATCH都會(huì)盡職盡責(zé)的監(jiān)視，一旦發(fā)現(xiàn)某個(gè)key被修改了，在執(zhí)行EXEC時(shí)就會(huì)返回nil，表示事務(wù)無(wú)法觸發(fā)。
127.0.0.1:6379> set age 23
OK
127.0.0.1:6379> watch age //開始監(jiān)視age
OK
127.0.0.1:6379> set age 24 //在EXEC之前，age的值被修改了
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 25
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec //觸發(fā)EXEC
(nil) //事務(wù)無(wú)法被執(zhí)行
【教你看懂redis配置 – 簡(jiǎn)介】
我們可以在啟動(dòng)redis-server時(shí)指定應(yīng)該加載的配置文件，方法如下：
$ ./redis-server /path/to/redis.conf
接下來(lái)，我們就來(lái)講解下redis配置文件的各個(gè)配置項(xiàng)的含義，注意，本文是基于redis-2.8.4版本進(jìn)行講解的。
redis官方提供的redis.conf文件，足有700+行，其中100多行為有效配置行，另外的600多行為注釋說(shuō)明。
在配置文件的開頭部分，首先明確了一些度量單位：
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
可以看出，redis配置中對(duì)單位的大小寫不敏感，1GB、1Gb和1gB都是相同的。由此也說(shuō)明，redis只支持bytes，不支持bit單位。
redis支持“主配置文件中引入外部配置文件”，很像C/C++中的include指令，比如：
include /path/to/other.conf
如果你看過(guò)redis的配置文件，會(huì)發(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）
下面我們就來(lái)逐一講解。
【教你看懂redis配置 -通用】
默認(rèn)情況下，redis并不是以daemon形式來(lái)運(yùn)行的。通過(guò)daemonize配置項(xiàng)可以控制redis的運(yùn)行形式，如果改為yes，那么redis就會(huì)以daemon形式運(yùn)行：
daemonize no
當(dāng)以daemon形式運(yùn)行時(shí)，redis會(huì)生成一個(gè)pid文件，默認(rèn)會(huì)生成在/var/run/redis.pid。當(dāng)然，你可以通過(guò)pidfile來(lái)指定pid文件生成的位置，比如：
pidfile /path/to/redis.pid
默認(rèn)情況下，redis會(huì)響應(yīng)本機(jī)所有可用網(wǎng)卡的連接請(qǐng)求。當(dāng)然，redis允許你通過(guò)bind配置項(xiàng)來(lái)指定要綁定的IP，比如：
bind 192.168.1.2 10.8.4.2
redis的默認(rèn)服務(wù)端口是6379，你可以通過(guò)port配置項(xiàng)來(lái)修改。如果端口設(shè)置為0的話，redis便不會(huì)監(jiān)聽(tīng)端口了。
port 6379
有些同學(xué)會(huì)問(wèn)“如果redis不監(jiān)聽(tīng)端口，還怎么與外界通信呢”，其實(shí)redis還支持通過(guò)unix socket方式來(lái)接收請(qǐng)求。可以通過(guò)unixsocket配置項(xiàng)來(lái)指定unix socket文件的路徑，并通過(guò)unixsocketperm來(lái)指定文件的權(quán)限。
unixsocket /tmp/redis.sock
unixsocketperm 755
當(dāng)一個(gè)redis-client一直沒(méi)有請(qǐng)求發(fā)向server端，那么server端有權(quán)主動(dòng)關(guān)閉這個(gè)連接，可以通過(guò)timeout來(lái)設(shè)置“空閑超時(shí)時(shí)限”，0表示永不關(guān)閉。
timeout 0
TCP連接?；畈呗?，可以通過(guò)tcp-keepalive配置項(xiàng)來(lái)進(jìn)行設(shè)置，單位為秒，假如設(shè)置為60秒，則server端會(huì)每60秒向連接空閑的客戶端發(fā)起一次ACK請(qǐng)求，以檢查客戶端是否已經(jīng)掛掉，對(duì)于無(wú)響應(yīng)的客戶端則會(huì)關(guān)閉其連接。所以關(guān)閉一個(gè)連接最長(zhǎng)需要120秒的時(shí)間。如果設(shè)置為0，則不會(huì)進(jìn)行?；顧z測(cè)。
tcp-keepalive 0
redis支持通過(guò)loglevel配置項(xiàng)設(shè)置日志等級(jí)，共分四級(jí)，即debug、verbose、notice、warning。
loglevel notice
redis也支持通過(guò)logfile配置項(xiàng)來(lái)設(shè)置日志文件的生成位置。如果設(shè)置為空字符串，則redis會(huì)將日志輸出到標(biāo)準(zhǔn)輸出。假如你在daemon情況下將日志設(shè)置為輸出到標(biāo)準(zhǔn)輸出，則日志會(huì)被寫到/dev/null中。
logfile ""
如果希望日志打印到syslog中，也很容易，通過(guò)syslog-enabled來(lái)控制。另外，syslog-ident還可以讓你指定syslog里的日志標(biāo)志，比如：
syslog-ident redis
而且還支持指定syslog設(shè)備，值可以是USER或LOCAL0-LOCAL7。具體可以參考syslog服務(wù)本身的用法。
syslog-facility local0
對(duì)于redis來(lái)說(shuō)，可以設(shè)置其數(shù)據(jù)庫(kù)的總數(shù)量，假如你希望一個(gè)redis包含16個(gè)數(shù)據(jù)庫(kù)，那么設(shè)置如下：
databases 16
這16個(gè)數(shù)據(jù)庫(kù)的編號(hào)將是0到15。默認(rèn)的數(shù)據(jù)庫(kù)是編號(hào)為0的數(shù)據(jù)庫(kù)。用戶可以使用select <DBid>來(lái)選擇相應(yīng)的數(shù)據(jù)庫(kù)。
【教你看懂redis配置 – 快照】
快照，主要涉及的是redis的RDB持久化相關(guān)的配置，我們來(lái)一起看一看。
我們可以用如下的指令來(lái)讓數(shù)據(jù)保存到磁盤上，即控制RDB快照功能：
save <seconds> <changes>
舉例來(lái)說(shuō)：
save 900 1 //表示每15分鐘且至少有1個(gè)key改變，就觸發(fā)一次持久化
save 300 10 //表示每5分鐘且至少有10個(gè)key改變，就觸發(fā)一次持久化
save 60 10000 //表示每60秒至少有10000個(gè)key改變，就觸發(fā)一次持久化
如果你想禁用RDB持久化的策略，只要不設(shè)置任何save指令就可以，或者給save傳入一個(gè)空字符串參數(shù)也可以達(dá)到相同效果，就像這樣：
save ""
如果用戶開啟了RDB快照功能，那么在redis持久化數(shù)據(jù)到磁盤時(shí)如果出現(xiàn)失敗，默認(rèn)情況下，redis會(huì)停止接受所有的寫請(qǐng)求。這樣做的好處在于可以讓用戶很明確的知道內(nèi)存中的數(shù)據(jù)和磁盤上的數(shù)據(jù)已經(jīng)存在不一致了。如果redis不顧這種不一致，一意孤行的繼續(xù)接收寫請(qǐng)求，就可能會(huì)引起一些災(zāi)難性的后果。
如果下一次RDB持久化成功，redis會(huì)自動(dòng)恢復(fù)接受寫請(qǐng)求。
當(dāng)然，如果你不在乎這種數(shù)據(jù)不一致或者有其他的手段發(fā)現(xiàn)和控制這種不一致的話，你完全可以關(guān)閉這個(gè)功能，以便在快照寫入失敗時(shí)，也能確保redis繼續(xù)接受新的寫請(qǐng)求。配置項(xiàng)如下：
stop-writes-on-bgsave-error yes
對(duì)于存儲(chǔ)到磁盤中的快照，可以設(shè)置是否進(jìn)行壓縮存儲(chǔ)。如果是的話，redis會(huì)采用LZF算法進(jìn)行壓縮。如果你不想消耗CPU來(lái)進(jìn)行壓縮的話，可以設(shè)置為關(guān)閉此功能，但是存儲(chǔ)在磁盤上的快照會(huì)比較大。
rdbcompression yes
在存儲(chǔ)快照后，我們還可以讓redis使用CRC64算法來(lái)進(jìn)行數(shù)據(jù)校驗(yàn)，但是這樣做會(huì)增加大約10%的性能消耗，如果你希望獲取到最大的性能提升，可以關(guān)閉此功能。
rdbchecksum yes
我們還可以設(shè)置快照文件的名稱，默認(rèn)是這樣配置的：
dbfilename dump.rdb
最后，你還可以設(shè)置這個(gè)快照文件存放的路徑。比如默認(rèn)設(shè)置就是當(dāng)前文件夾：
dir ./
【教你看懂redis配置 – 復(fù)制】
redis提供了主從同步功能。
通過(guò)slaveof配置項(xiàng)可以控制某一個(gè)redis作為另一個(gè)redis的從服務(wù)器，通過(guò)指定IP和端口來(lái)定位到主redis的位置。一般情況下，我們會(huì)建議用戶為從redis設(shè)置一個(gè)不同頻率的快照持久化的周期，或者為從redis配置一個(gè)不同的服務(wù)端口等等。
slaveof <masterip> <masterport>
如果主redis設(shè)置了驗(yàn)證密碼的話（使用requirepass來(lái)設(shè)置），則在從redis的配置中要使用masterauth來(lái)設(shè)置校驗(yàn)密碼，否則的話，主redis會(huì)拒絕從redis的訪問(wèn)請(qǐng)求。
masterauth <master-password>
當(dāng)從redis失去了與主redis的連接，或者主從同步正在進(jìn)行中時(shí)，redis該如何處理外部發(fā)來(lái)的訪問(wèn)請(qǐng)求呢？這里，從redis可以有兩種選擇：
第一種選擇：如果slave-serve-stale-data設(shè)置為yes（默認(rèn)），則從redis仍會(huì)繼續(xù)響應(yīng)客戶端的讀寫請(qǐng)求。
第二種選擇：如果slave-serve-stale-data設(shè)置為no，則從redis會(huì)對(duì)客戶端的請(qǐng)求返回“SYNC with master in progress”，當(dāng)然也有例外，當(dāng)客戶端發(fā)來(lái)INFO請(qǐng)求和SLAVEOF請(qǐng)求，從redis還是會(huì)進(jìn)行處理。
你可以控制一個(gè)從redis是否可以接受寫請(qǐng)求。將數(shù)據(jù)直接寫入從redis，一般只適用于那些生命周期非常短的數(shù)據(jù)，因?yàn)樵谥鲝耐綍r(shí)，這些臨時(shí)數(shù)據(jù)就會(huì)被清理掉。自從redis2.6版本之后，默認(rèn)從redis為只讀。
slave-read-only yes
只讀的從redis并不適合直接暴露給不可信的客戶端。為了盡量降低風(fēng)險(xiǎn)，可以使用rename-command指令來(lái)將一些可能有破壞力的命令重命名，避免外部直接調(diào)用。比如：
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
從redis會(huì)周期性的向主redis發(fā)出PING包。你可以通過(guò)repl_ping_slave_period指令來(lái)控制其周期。默認(rèn)是10秒。
repl-ping-slave-period 10
在主從同步時(shí)，可能在這些情況下會(huì)有超時(shí)發(fā)生：
1.以從redis的角度來(lái)看，當(dāng)有大規(guī)模IO傳輸時(shí)。
2.以從redis的角度來(lái)看，當(dāng)數(shù)據(jù)傳輸或PING時(shí)，主redis超時(shí)
3.以主redis的角度來(lái)看，在回復(fù)從redis的PING時(shí)，從redis超時(shí)
用戶可以設(shè)置上述超時(shí)的時(shí)限，不過(guò)要確保這個(gè)時(shí)限比repl-ping-slave-period的值要大，否則每次主redis都會(huì)認(rèn)為從redis超時(shí)。
repl-timeout 60
我們可以控制在主從同步時(shí)是否禁用TCP_NODELAY。如果開啟TCP_NODELAY，那么主redis會(huì)使用更少的TCP包和更少的帶寬來(lái)向從redis傳輸數(shù)據(jù)。但是這可能會(huì)增加一些同步的延遲，大概會(huì)達(dá)到40毫秒左右。如果你關(guān)閉了TCP_NODELAY，那么數(shù)據(jù)同步的延遲時(shí)間會(huì)降低，但是會(huì)消耗更多的帶寬。（如果你不了解TCP_NODELAY，可以到這里來(lái)科普一下）。
repl-disable-tcp-nodelay no
我們還可以設(shè)置同步隊(duì)列長(zhǎng)度。隊(duì)列長(zhǎng)度（backlog)是主redis中的一個(gè)緩沖區(qū)，在與從redis斷開連接期間，主redis會(huì)用這個(gè)緩沖區(qū)來(lái)緩存應(yīng)該發(fā)給從redis的數(shù)據(jù)。這樣的話，當(dāng)從redis重新連接上之后，就不必重新全量同步數(shù)據(jù)，只需要同步這部分增量數(shù)據(jù)即可。
repl-backlog-size 1mb
如果主redis等了一段時(shí)間之后，還是無(wú)法連接到從redis，那么緩沖隊(duì)列中的數(shù)據(jù)將被清理掉。我們可以設(shè)置主redis要等待的時(shí)間長(zhǎng)度。如果設(shè)置為0，則表示永遠(yuǎn)不清理。默認(rèn)是1個(gè)小時(shí)。
repl-backlog-ttl 3600
我們可以給眾多的從redis設(shè)置優(yōu)先級(jí)，在主redis持續(xù)工作不正常的情況，優(yōu)先級(jí)高的從redis將會(huì)升級(jí)為主redis。而編號(hào)越小，優(yōu)先級(jí)越高。比如一個(gè)主redis有三個(gè)從redis，優(yōu)先級(jí)編號(hào)分別為10、100、25，那么編號(hào)為10的從redis將會(huì)被首先選中升級(jí)為主redis。當(dāng)優(yōu)先級(jí)被設(shè)置為0時(shí)，這個(gè)從redis將永遠(yuǎn)也不會(huì)被選中。默認(rèn)的優(yōu)先級(jí)為100。
slave-priority 100
假如主redis發(fā)現(xiàn)有超過(guò)M個(gè)從redis的連接延時(shí)大于N秒，那么主redis就停止接受外來(lái)的寫請(qǐng)求。這是因?yàn)閺膔edis一般會(huì)每秒鐘都向主redis發(fā)出PING，而主redis會(huì)記錄每一個(gè)從redis最近一次發(fā)來(lái)PING的時(shí)間點(diǎn)，所以主redis能夠了解每一個(gè)從redis的運(yùn)行情況。
min-slaves-to-write 3
min-slaves-max-lag 10
上面這個(gè)例子表示，假如有大于等于3個(gè)從redis的連接延遲大于10秒，那么主redis就不再接受外部的寫請(qǐng)求。上述兩個(gè)配置中有一個(gè)被置為0，則這個(gè)特性將被關(guān)閉。默認(rèn)情況下min-slaves-to-write為0，而min-slaves-max-lag為10。
【教你看懂redis配置 – 安全】
我們可以要求redis客戶端在向redis-server發(fā)送請(qǐng)求之前，先進(jìn)行密碼驗(yàn)證。當(dāng)你的redis-server處于一個(gè)不太可信的網(wǎng)絡(luò)環(huán)境中時(shí)，相信你會(huì)用上這個(gè)功能。由于redis性能非常高，所以每秒鐘可以完成多達(dá)15萬(wàn)次的密碼嘗試，所以你最好設(shè)置一個(gè)足夠復(fù)雜的密碼，否則很容易被黑客破解。
requirepass zhimakaimen
這里我們通過(guò)requirepass將密碼設(shè)置成“芝麻開門”。
redis允許我們對(duì)redis指令進(jìn)行更名，比如將一些比較危險(xiǎn)的命令改個(gè)名字，避免被誤執(zhí)行。比如可以把CONFIG命令改成一個(gè)很復(fù)雜的名字，這樣可以避免外部的調(diào)用，同時(shí)還可以滿足內(nèi)部調(diào)用的需要：
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c89
我們甚至可以禁用掉CONFIG命令，那就是把CONFIG的名字改成一個(gè)空字符串：
rename-command CONFIG ""
但需要注意的是，如果你使用AOF方式進(jìn)行數(shù)據(jù)持久化，或者需要與從redis進(jìn)行通信，那么更改指令的名字可能會(huì)引起一些問(wèn)題。
【教你看懂redis配置 -限制】
我們可以設(shè)置redis同時(shí)可以與多少個(gè)客戶端進(jìn)行連接。默認(rèn)情況下為10000個(gè)客戶端。當(dāng)你無(wú)法設(shè)置進(jìn)程文件句柄限制時(shí)，redis會(huì)設(shè)置為當(dāng)前的文件句柄限制值減去32，因?yàn)閞edis會(huì)為自身內(nèi)部處理邏輯留一些句柄出來(lái)。
如果達(dá)到了此限制，redis則會(huì)拒絕新的連接請(qǐng)求，并且向這些連接請(qǐng)求方發(fā)出“max number of clients reached”以作回應(yīng)。
maxclients 10000
我們甚至可以設(shè)置redis可以使用的內(nèi)存量。一旦到達(dá)內(nèi)存使用上限，redis將會(huì)試圖移除內(nèi)部數(shù)據(jù)，移除規(guī)則可以通過(guò)maxmemory-policy來(lái)指定。
如果redis無(wú)法根據(jù)移除規(guī)則來(lái)移除內(nèi)存中的數(shù)據(jù)，或者我們?cè)O(shè)置了“不允許移除”，那么redis則會(huì)針對(duì)那些需要申請(qǐng)內(nèi)存的指令返回錯(cuò)誤信息，比如SET、LPUSH等。但是對(duì)于無(wú)內(nèi)存申請(qǐng)的指令，仍然會(huì)正常響應(yīng)，比如GET等。
maxmemory <bytes>
需要注意的一點(diǎn)是，如果你的redis是主redis（說(shuō)明你的redis有從redis），那么在設(shè)置內(nèi)存使用上限時(shí)，需要在系統(tǒng)中留出一些內(nèi)存空間給同步隊(duì)列緩存，只有在你設(shè)置的是“不移除”的情況下，才不用考慮這個(gè)因素。
對(duì)于內(nèi)存移除規(guī)則來(lái)說(shuō)，redis提供了多達(dá)6種的移除規(guī)則。他們是：
1.volatile-lru：使用LRU算法移除過(guò)期集合中的key
2.allkeys-lru：使用LRU算法移除key
3.volatile-random：在過(guò)期集合中移除隨機(jī)的key
4.allkeys-random：移除隨機(jī)的key
5.volatile-ttl：移除那些TTL值最小的key，即那些最近才過(guò)期的key。
6.noeviction：不進(jìn)行移除。針對(duì)寫操作，只是返回錯(cuò)誤信息。
無(wú)論使用上述哪一種移除規(guī)則，如果沒(méi)有合適的key可以移除的話，redis都會(huì)針對(duì)寫請(qǐng)求返回錯(cuò)誤信息。
maxmemory-policy volatile-lru
LRU算法和最小TTL算法都并非是精確的算法，而是估算值。所以你可以設(shè)置樣本的大小。假如redis默認(rèn)會(huì)檢查三個(gè)key并選擇其中LRU的那個(gè)，那么你可以改變這個(gè)key樣本的數(shù)量。
maxmemory-samples 3
最后，我們補(bǔ)充一個(gè)信息，那就是到目前版本（2.8.4）為止，redis支持的寫指令包括了如下這些：
set setnx setex append
incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
getset mset msetnx exec sort
【教你看懂redis配置 – 追加模式】
默認(rèn)情況下，redis會(huì)異步的將數(shù)據(jù)持久化到磁盤。這種模式在大部分應(yīng)用程序中已被驗(yàn)證是很有效的，但是在一些問(wèn)題發(fā)生時(shí)，比如斷電，則這種機(jī)制可能會(huì)導(dǎo)致數(shù)分鐘的寫請(qǐng)求丟失。
如博文上半部分中介紹的，追加文件（Append Only File）是一種更好的保持?jǐn)?shù)據(jù)一致性的方式。即使當(dāng)服務(wù)器斷電時(shí)，也僅會(huì)有1秒鐘的寫請(qǐng)求丟失，當(dāng)redis進(jìn)程出現(xiàn)問(wèn)題且操作系統(tǒng)運(yùn)行正常時(shí)，甚至只會(huì)丟失一條寫請(qǐng)求。
我們建議大家，AOF機(jī)制和RDB機(jī)制可以同時(shí)使用，不會(huì)有任何沖突。對(duì)于如何保持?jǐn)?shù)據(jù)一致性的討論，請(qǐng)參見(jiàn)本文。
appendonly no
我們還可以設(shè)置aof文件的名稱：
appendfilename "appendonly.aof"
fsync()調(diào)用，用來(lái)告訴操作系統(tǒng)立即將緩存的指令寫入磁盤。一些操作系統(tǒng)會(huì)“立即”進(jìn)行，而另外一些操作系統(tǒng)則會(huì)“盡快”進(jìn)行。
redis支持三種不同的模式：
1.no：不調(diào)用fsync()。而是讓操作系統(tǒng)自行決定sync的時(shí)間。這種模式下，redis的性能會(huì)最快。
2.always：在每次寫請(qǐng)求后都調(diào)用fsync()。這種模式下，redis會(huì)相對(duì)較慢，但數(shù)據(jù)最安全。
3.everysec：每秒鐘調(diào)用一次fsync()。這是性能和安全的折衷。
默認(rèn)情況下為everysec。有關(guān)數(shù)據(jù)一致性的揭秘，可以參考本文。
appendfsync everysec
當(dāng)fsync方式設(shè)置為always或everysec時(shí)，如果后臺(tái)持久化進(jìn)程需要執(zhí)行一個(gè)很大的磁盤IO操作，那么redis可能會(huì)在fsync()調(diào)用時(shí)卡住。目前尚未修復(fù)這個(gè)問(wèn)題，這是因?yàn)榧词刮覀冊(cè)诹硪粋€(gè)新的線程中去執(zhí)行fsync()，也會(huì)阻塞住同步寫調(diào)用。
為了緩解這個(gè)問(wèn)題，我們可以使用下面的配置項(xiàng)，這樣的話，當(dāng)BGSAVE或BGWRITEAOF運(yùn)行時(shí)，fsync()在主進(jìn)程中的調(diào)用會(huì)被阻止。這意味著當(dāng)另一路進(jìn)程正在對(duì)AOF文件進(jìn)行重構(gòu)時(shí)，redis的持久化功能就失效了，就好像我們?cè)O(shè)置了“appendsync none”一樣。如果你的redis有時(shí)延問(wèn)題，那么請(qǐng)將下面的選項(xiàng)設(shè)置為yes。否則請(qǐng)保持no，因?yàn)檫@是保證數(shù)據(jù)完整性的最安全的選擇。
no-appendfsync-on-rewrite no
我們?cè)试Sredis自動(dòng)重寫aof。當(dāng)aof增長(zhǎng)到一定規(guī)模時(shí)，redis會(huì)隱式調(diào)用BGREWRITEAOF來(lái)重寫log文件，以縮減文件體積。
redis是這樣工作的：redis會(huì)記錄上次重寫時(shí)的aof大小。假如redis自啟動(dòng)至今還沒(méi)有進(jìn)行過(guò)重寫，那么啟動(dòng)時(shí)aof文件的大小會(huì)被作為基準(zhǔn)值。這個(gè)基準(zhǔn)值會(huì)和當(dāng)前的aof大小進(jìn)行比較。如果當(dāng)前aof大小超出所設(shè)置的增長(zhǎng)比例，則會(huì)觸發(fā)重寫。另外，你還需要設(shè)置一個(gè)最小大小，是為了防止在aof很小時(shí)就觸發(fā)重寫。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
如果設(shè)置auto-aof-rewrite-percentage為0，則會(huì)關(guān)閉此重寫功能。
【教你看懂redis配置 – LUA腳本】
lua腳本的最大運(yùn)行時(shí)間是需要被嚴(yán)格限制的，要注意單位是毫秒：
lua-time-limit 5000
如果此值設(shè)置為0或負(fù)數(shù)，則既不會(huì)有報(bào)錯(cuò)也不會(huì)有時(shí)間限制。
【教你看懂redis配置 – 慢日志】
redis慢日志是指一個(gè)系統(tǒng)進(jìn)行日志查詢超過(guò)了指定的時(shí)長(zhǎng)。這個(gè)時(shí)長(zhǎng)不包括IO操作，比如與客戶端的交互、發(fā)送響應(yīng)內(nèi)容等，而僅包括實(shí)際執(zhí)行查詢命令的時(shí)間。
針對(duì)慢日志，你可以設(shè)置兩個(gè)參數(shù)，一個(gè)是執(zhí)行時(shí)長(zhǎng)，單位是微秒，另一個(gè)是慢日志的長(zhǎng)度。當(dāng)一個(gè)新的命令被寫入日志時(shí)，最老的一條會(huì)從命令日志隊(duì)列中被移除。
單位是微秒，即1000000表示一秒。負(fù)數(shù)則會(huì)禁用慢日志功能，而0則表示強(qiáng)制記錄每一個(gè)命令。
slowlog-log-slower-than 10000
慢日志最大長(zhǎng)度，可以隨便填寫數(shù)值，沒(méi)有上限，但要注意它會(huì)消耗內(nèi)存。你可以使用SLOWLOG RESET來(lái)重設(shè)這個(gè)值。
slowlog-max-len 128
【教你看懂redis配置 – 事件通知】
redis可以向客戶端通知某些事件的發(fā)生。這個(gè)特性的具體解釋可以參見(jiàn)本文。
【教你看懂redis配置 – 高級(jí)配置】
有關(guān)哈希數(shù)據(jù)結(jié)構(gòu)的一些配置項(xiàng)：
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
有關(guān)列表數(shù)據(jù)結(jié)構(gòu)的一些配置項(xiàng)：
list-max-ziplist-entries 512
list-max-ziplist-value 64
有關(guān)集合數(shù)據(jù)結(jié)構(gòu)的配置項(xiàng)：
set-max-intset-entries 512
有關(guān)有序集合數(shù)據(jù)結(jié)構(gòu)的配置項(xiàng)：
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
關(guān)于是否需要再哈希的配置項(xiàng)：
activerehashing yes
關(guān)于客戶端輸出緩沖的控制項(xiàng)：
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
有關(guān)頻率的配置項(xiàng)：
hz 10
有關(guān)重寫aof的配置項(xiàng)
aof-rewrite-incremental-fsync yes
至此，redis的入門內(nèi)容就結(jié)束了，內(nèi)容實(shí)在不少，但相對(duì)來(lái)說(shuō)都很基礎(chǔ)，本文沒(méi)有涉及redis集群、redis工作原理、redis源碼、redis相關(guān)LIB庫(kù)等內(nèi)容，后續(xù)會(huì)陸續(xù)奉獻(xiàn)，大家敬請(qǐng)期待：）
謝謝！
相關(guān)文章
這篇文章主要介紹了Redis緩存穿透出現(xiàn)原因及解決方案,文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-08-08
關(guān)于Redis數(shù)據(jù)持久化的概念介紹
Redis是內(nèi)存數(shù)據(jù)庫(kù)，數(shù)據(jù)都是存儲(chǔ)在內(nèi)存中，需要定期將Redis中的數(shù)據(jù)以某種形式(或命數(shù)據(jù)令)從內(nèi)存保存到硬盤，今天給大家分享Redis數(shù)據(jù)的持久化的概念介紹，需要的朋友參考下吧2021-08-08
本文主要介紹了Redis Stream類型的使用詳解，文中通過(guò)示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2021-11-11
這篇文章主要介紹了查看redis的緩存時(shí)間方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2025-03-03
這篇文章主要介紹了Redis教程(十)：持久化詳解,本文講解了Redis提供了哪些持久化機(jī)制、RDB機(jī)制的優(yōu)勢(shì)和劣勢(shì)、AOF機(jī)制的優(yōu)勢(shì)和劣勢(shì)、其它等內(nèi)容,需要的朋友可以參考下2015-04-04
Redis?鍵值對(duì)(key-value)數(shù)據(jù)庫(kù)實(shí)現(xiàn)方法
Redis 的鍵值對(duì)中的 key 就是字符串對(duì)象,而 value 可以是字符串對(duì)象,也可以是集合數(shù)據(jù)類型的對(duì)象,比如 List 對(duì)象,Hash 對(duì)象、Set 對(duì)象和 Zset 對(duì)象,這篇文章主要介紹了Redis?鍵值對(duì)數(shù)據(jù)庫(kù)是怎么實(shí)現(xiàn)的,需要的朋友可以參考下2024-05-05
在本篇文章里小編給大家分享了關(guān)于redis事務(wù)常用操作的相關(guān)知識(shí)點(diǎn)內(nèi)容，有興趣的朋友們可以跟著學(xué)習(xí)參考下。2019-07-07
今天小編就為大家分享一篇redis-cli 使用密碼登錄的實(shí)例，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。一起跟隨小編過(guò)來(lái)看看吧2018-05-05
本文主要介紹了Redis實(shí)現(xiàn)短信登錄的示例代碼，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2023-07-07
Redis 8種基本數(shù)據(jù)類型及常用命令和數(shù)據(jù)類型的應(yīng)用場(chǎng)景小結(jié)
Redis是一種基于內(nèi)存操作的數(shù)據(jù)庫(kù),其中多虧于高效的數(shù)據(jù)結(jié)構(gòu),本文主要介紹了Redis 8種基本數(shù)據(jù)類型及常用命令和數(shù)據(jù)類型的應(yīng)用場(chǎng)景小結(jié),具有一定的參考價(jià)值,感興趣的可以了解一下2024-03-03