來源：腳本之家

這篇文章主要介紹了超強(qiáng)、超詳細(xì)Redis入門教程,本文詳細(xì)介紹了Redis數(shù)據(jù)庫各個方面的知識,需要的朋友可以參考下

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項目的開發(fā)和維護(hù)弟孟。

redis的作者何許人也

開門見山，先看照片：

誰在使用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等等：

$ find . -type f -executable
./redis-benchmark //用于進(jìn)行redis性能測試的工具
./redis-check-dump //用于修復(fù)出問題的dump.rdb文件
./redis-cli //redis的客戶端
./redis-server //redis的服務(wù)端
./redis-check-aof //用于修復(fù)出問題的AOF文件
./redis-sentinel //用于集群管理

學(xué)會啟動redis

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

./redis-server ../redis.conf

默認(rèn)情況下尊沸，redis-server會以非daemon的方式來運行，且默認(rèn)服務(wù)端口為6379贤惯。

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

使用redis客戶端

我們直接看一個例子：

//這樣來啟動redis客戶端了
$ ./redis-cli
//用set指令來設(shè)置key屁商、value
127.0.0.1:6379> set name "roc"
OK
//來獲取name的值
127.0.0.1:6379> get name
"roc"
//通過客戶端來關(guān)閉redis服務(wù)端
127.0.0.1:6379> shutdown
127.0.0.1:6379>

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颈墅，有幾個點要提醒大家：

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類型是一個很基礎(chǔ)的數(shù)據(jù)類型饵撑，也是任何存儲系統(tǒng)都必備的數(shù)據(jù)類型。

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

set mystr "hello world!" //設(shè)置字符串類型
get mystr //讀取字符串類型

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

另外锨咙，我們還可以通過字符串類型進(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ù)值操作時，redis會將字符串類型轉(zhuǎn)換成數(shù)值酪刀。

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

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

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

首先要明確一點，redis中的lists在底層實現(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中指定一個范圍來提取元素影斑。我們來看幾個例子：

//新建一個list叫做mylist，并在列表頭部插入元素"1"
127.0.0.1:6379> lpush mylist "1"
//返回當(dāng)前mylist中的元素個數(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中從編號0到編號1的元素
127.0.0.1:6379> lrange mylist 0 1
1) "0"
2) "1"
//列出mylist中從編號0到倒數(shù)第一個元素
127.0.0.1:6379> lrange mylist 0 -1
1) "0"
2) "1"
3) "2"

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

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

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

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

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

//向集合myset中加入一個新元素"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
//新建一個新的集合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"

//對兩個集合求并集
127.0.0.1:6379> sunion myset yourset
1) "1"
2) "one"
3) "2"
4) "two"

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

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：
127.0.0.1:6379> zadd myzset 1 baidu.com
(integer) 1

//向myzset中新增一個元素360.com捺檬，賦予它的序號是3
127.0.0.1:6379> zadd myzset 3 360.com
(integer) 1

//向myzset中新增一個元素google.com再层，賦予它的序號是2
127.0.0.1:6379> zadd myzset 2 google.com
(integer) 1

//列出myzset的所有元素，同時列出其序號堡纬，可以看出myzset已經(jīng)是有序的了聂受。
127.0.0.1:6379> zrange myzset 0 -1 withscores
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存的是字符串和字符串值之間的映射，比如一個用戶要存儲其全名炮叶、姓氏、年齡等等，就很適合使用哈希容劳。

我們來看一個例子：

//建立哈希禽绪，并賦值
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"

//更改哈希中的某一個值
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的操作，同樣很豐富侣肄，需要時旧困，大家可以從這里查詢。

聊聊redis持久化 – 兩種方式

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

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

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

其實RDB和AOF兩種方式也可以同時使用，在這種情況下悼嫉，如果redis重啟的話艇潭，則會優(yōu)先采用AOF方式來進(jìn)行數(shù)據(jù)恢復(fù)，這是因為AOF方式的數(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)行備份，因為快照文件總是完整可用的笼裳。

對于RDB方式唯卖，redis會單獨創(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)點，但它的缺點也是不容忽視的。如果你對數(shù)據(jù)的完整性非常敏感法牲，那么RDB方式就不太適合你史汗，因為即使你每5分鐘都持久化一次，當(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是指把緩存中的寫指令記錄到磁盤中）葬项，因為在這種情況下省咨，redis仍然可以保持很好的處理性能，即使redis故障玷室，也只會丟失最近1秒鐘的數(shù)據(jù)。

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

因為采用了追加方式汗贫，如果不做任何處理的話身坐，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文件的可用性，這點大家可以放心搭幻。

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)點多多拳魁，但AOF方式也同樣存在缺陷惶桐，比如在同樣數(shù)據(jù)規(guī)模的情況下，AOF文件要比RDB文件的體積大潘懊。而且姚糊，AOF方式的恢復(fù)速度也要慢于RDB方式。

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

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

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

聊聊redis持久化 – AOF重寫

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

在重寫即將開始之際，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ù)器便瑟。

另外缆毁，要說的一點是，即使有多個從服務(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ù)器接收到這樣的同步請求后履澳，首先會驗證主服務(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的例子：

redis> MULTI //標(biāo)記事務(wù)開始
OK
redis> INCR user_id //多條命令按順序入隊
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的字樣斗锭，這表示我們在用MULTI組裝事務(wù)時地淀，每一個命令都會進(jìn)入到內(nèi)存隊列中緩存起來，如果出現(xiàn)QUEUED則表示我們這個命令成功插入了緩存隊列岖是，在將來執(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)某個命令無法成功寫入緩沖隊列的情況磨确，redis都會進(jìn)行記錄，在客戶端調(diào)用EXEC時声邦，redis會拒絕執(zhí)行這一事務(wù)乏奥。（這時2.6.5版本之后的策略亥曹。在2.6.5之前的版本中邓了，redis會忽略那些入隊失敗的命令，只執(zhí)行那些入隊成功的命令）媳瞪。我們來看一個這樣的例子：

127.0.0.1:6379> multi
OK
127.0.0.1:6379> haha //一個明顯錯誤的指令
(error) ERR unknown command 'haha'
127.0.0.1:6379> ping
QUEUED
127.0.0.1:6379> exec
//redis無情的拒絕了事務(wù)的執(zhí)行骗炉，原因是“之前出現(xiàn)了錯誤”
(error) EXECABORT Transaction discarded because of previous errors.

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

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 23
QUEUED
//age不是集合，所以如下是一條明顯錯誤的指令
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ù)時秸弛，redis不會理睬第2條指令執(zhí)行錯誤
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í)行了

好了铭若，我們來說說最后一個指令“WATCH”，這是一個很好用的指令递览，它可以幫我們實現(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ā)。

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ù)無法被執(zhí)行

教你看懂redis配置 – 簡介

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

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

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

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

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

# 1k => 1000 bytes

# 1kb => 1024 bytes

# 1m => 1000000 bytes

# 1mb => 1024*1024 bytes

# 1g => 1000000000 bytes

# 1gb => 1024*1024*1024 bytes

可以看出，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. 復(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形式來運行的氏豌。通過daemonize配置項可以控制redis的運行形式，如果改為yes热凹，那么redis就會以daemon(守護(hù)進(jìn)程)形式運行：

daemonize no
#修改daemonize為yes泵喘，即默認(rèn)以后臺程序方式運行(效果等價./redis-server &)。

當(dāng)以daemon形式運行時般妙，redis會生成一個pid文件纪铺，默認(rèn)會生成在/var/run/redis.pid。當(dāng)然碟渺，你可以通過pidfile來指定pid文件生成的位置鲜锚，比如：

pidfile /path/to/redis.pid

默認(rèn)情況下，redis會響應(yīng)本機(jī)所有可用網(wǎng)卡的連接請求。當(dāng)然芜繁，redis允許你通過bind配置項來指定要綁定的IP攒霹，比如：

bind 192.168.1.2 10.8.4.2

redis的默認(rèn)服務(wù)端口是6379，你可以通過port配置項來修改浆洗。如果端口設(shè)置為0的話，redis便不會監(jiān)聽端口了集峦。

port 6379

有些同學(xué)會問“如果redis不監(jiān)聽端口伏社，還怎么與外界通信呢”，其實redis還支持通過unix socket方式來接收請求塔淤≌可以通過unixsocket配置項來指定unix socket文件的路徑，并通過unixsocketperm來指定文件的權(quán)限高蜂。

unixsocket /tmp/redis.sock
unixsocketperm 755

當(dāng)一個redis-client一直沒有請求發(fā)向server端聪黎，那么server端有權(quán)主動關(guān)閉這個連接，可以通過timeout來設(shè)置“空閑超時時限”备恤，0表示永不關(guān)閉稿饰。

timeout 0

TCP連接保活策略露泊，可以通過tcp-keepalive配置項來進(jìn)行設(shè)置喉镰，單位為秒，假如設(shè)置為60秒惭笑，則server端會每60秒向連接空閑的客戶端發(fā)起一次ACK請求侣姆，以檢查客戶端是否已經(jīng)掛掉，對于無響應(yīng)的客戶端則會關(guān)閉其連接沉噩。所以關(guān)閉一個連接最長需要120秒的時間捺宗。如果設(shè)置為0，則不會進(jìn)行贝桑活檢測蚜厉。

tcp-keepalive 0

redis支持通過loglevel配置項設(shè)置日志等級，共分四級派歌，即debug弯囊、verbose、notice胶果、warning匾嘱。

loglevel notice

redis也支持通過logfile配置項來設(shè)置日志文件的生成位置。如果設(shè)置為空字符串早抠，則redis會將日志輸出到標(biāo)準(zhǔn)輸出霎烙。假如你在daemon情況下將日志設(shè)置為輸出到標(biāo)準(zhǔn)輸出，則日志會被寫到/dev/null中。

logfile ""

如果希望日志打印到syslog中悬垃，也很容易游昼，通過syslog-enabled來控制。另外尝蠕，syslog-ident還可以讓你指定syslog里的日志標(biāo)志烘豌，比如：

syslog-ident redis

而且還支持指定syslog設(shè)備，值可以是USER或LOCAL0-LOCAL7看彼。具體可以參考syslog服務(wù)本身的用法廊佩。

syslog-facility local0

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

databases 16

這16個數(shù)據(jù)庫的編號將是0到15。默認(rèn)的數(shù)據(jù)庫是編號為0的數(shù)據(jù)庫茁计。用戶可以使用select 來選擇相應(yīng)的數(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持久化的策略劲绪，只要不設(shè)置任何save指令就可以男窟，或者給save傳入一個空字符串參數(shù)也可以達(dá)到相同效果，就像這樣：

save ""

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

如果下一次RDB持久化成功裤纹，redis會自動恢復(fù)接受寫請求搜变。

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

stop-writes-on-bgsave-error yes

對于存儲到磁盤中的快照，可以設(shè)置是否進(jìn)行壓縮存儲浸策。如果是的話冯键，redis會采用LZF算法進(jìn)行壓縮。如果你不想消耗CPU來進(jìn)行壓縮的話庸汗，可以設(shè)置為關(guān)閉此功能惫确，但是存儲在磁盤上的快照會比較大。

rdbcompression yes

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

rdbchecksum yes

我們還可以設(shè)置快照文件的名稱盏档，默認(rèn)是這樣配置的：

dbfilename dump.rdb

最后凶掰，你還可以設(shè)置這個快照文件存放的路徑。比如默認(rèn)設(shè)置就是當(dāng)前文件夾：

dir ./

教你看懂redis配置 – 復(fù)制

redis提供了主從同步功能蜈亩。
通過slaveof配置項可以控制某一個redis作為另一個redis的從服務(wù)器懦窘，通過指定IP和端口來定位到主redis的位置。一般情況下稚配，我們會建議用戶為從redis設(shè)置一個不同頻率的快照持久化的周期畅涂，或者為從redis配置一個不同的服務(wù)端口等等。
slaveof
如果主redis設(shè)置了驗證密碼的話（使用requirepass來設(shè)置）道川，則在從redis的配置中要使用masterauth來設(shè)置校驗密碼午衰，否則的話，主redis會拒絕從redis的訪問請求冒萄。
masterauth
當(dāng)從redis失去了與主redis的連接臊岸，或者主從同步正在進(jìn)行中時，redis該如何處理外部發(fā)來的訪問請求呢尊流？這里帅戒，從redis可以有兩種選擇：

第一種選擇：如果slave-serve-stale-data設(shè)置為yes（默認(rèn)），則從redis仍會繼續(xù)響應(yīng)客戶端的讀寫請求崖技。

第二種選擇：如果slave-serve-stale-data設(shè)置為no逻住，則從redis會對客戶端的請求返回“SYNC with master in progress”，當(dāng)然也有例外迎献，當(dāng)客戶端發(fā)來INFO請求和SLAVEOF請求瞎访，從redis還是會進(jìn)行處理。

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

slave-read-only yes

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

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

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

repl-ping-slave-period 10

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

1. 以從redis的角度來看，當(dāng)有大規(guī)模IO傳輸時读恃。
2. 以從redis的角度來看隧膘，當(dāng)數(shù)據(jù)傳輸或PING時，主redis超時
3. 以主redis的角度來看寺惫，在回復(fù)從redis的PING時疹吃，從redis超時

用戶可以設(shè)置上述超時的時限，不過要確保這個時限比repl-ping-slave-period的值要大西雀，否則每次主redis都會認(rèn)為從redis超時萨驶。

repl-timeout 60

我們可以控制在主從同步時是否禁用TCP_NODELAY。如果開啟TCP_NODELAY艇肴，那么主redis會使用更少的TCP包和更少的帶寬來向從redis傳輸數(shù)據(jù)腔呜。但是這可能會增加一些同步的延遲，大概會達(dá)到40毫秒左右再悼。如果你關(guān)閉了TCP_NODELAY育谬，那么數(shù)據(jù)同步的延遲時間會降低，但是會消耗更多的帶寬帮哈。（如果你不了解TCP_NODELAY膛檀，可以到這里來科普一下）。

repl-disable-tcp-nodelay no

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

repl-backlog-size 1mb

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

repl-backlog-ttl 3600

我們可以給眾多的從redis設(shè)置優(yōu)先級，在主redis持續(xù)工作不正常的情況是嗜，優(yōu)先級高的從redis將會升級為主redis愈案。而編號越小，優(yōu)先級越高鹅搪。比如一個主redis有三個從redis站绪，優(yōu)先級編號分別為10、100丽柿、25崇众，那么編號為10的從redis將會被首先選中升級為主redis。當(dāng)優(yōu)先級被設(shè)置為0時航厚，這個從redis將永遠(yuǎn)也不會被選中。默認(rèn)的優(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-slaves-to-write 3
min-slaves-max-lag 10

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

教你看懂redis配置 – 安全

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

requirepass zhimakaimen

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

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

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c89

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

rename-command CONFIG ""

但需要注意的是田篇，如果你使用AOF方式進(jìn)行數(shù)據(jù)持久化替废，或者需要與從redis進(jìn)行通信，那么更改指令的名字可能會引起一些問題泊柬。

教你看懂redis配置 -限制

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

如果達(dá)到了此限制刀崖，redis則會拒絕新的連接請求惊科，并且向這些連接請求方發(fā)出“max number of clients reached”以作回應(yīng)。

maxclients 10000

我們甚至可以設(shè)置redis可以使用的內(nèi)存量亮钦。一旦到達(dá)內(nèi)存使用上限馆截，redis將會試圖移除內(nèi)部數(shù)據(jù)，移除規(guī)則可以通過maxmemory-policy來指定蜂莉。

如果redis無法根據(jù)移除規(guī)則來移除內(nèi)存中的數(shù)據(jù)蜡娶，或者我們設(shè)置了“不允許移除”，那么redis則會針對那些需要申請內(nèi)存的指令返回錯誤信息映穗，比如SET窖张、LPUSH等。但是對于無內(nèi)存申請的指令蚁滋，仍然會正常響應(yīng)宿接，比如GET等。
maxmemory
需要注意的一點是辕录，如果你的redis是主redis（說明你的redis有從redis）澄阳，那么在設(shè)置內(nèi)存使用上限時，需要在系統(tǒng)中留出一些內(nèi)存空間給同步隊列緩存踏拜，只有在你設(shè)置的是“不移除”的情況下碎赢，才不用考慮這個因素。
對于內(nèi)存移除規(guī)則來說速梗，redis提供了多達(dá)6種的移除規(guī)則肮塞。他們是：

1. volatile-lru：使用LRU算法移除過期集合中的key
2. allkeys-lru：使用LRU算法移除key
3. volatile-random：在過期集合中移除隨機(jī)的key
4. allkeys-random：移除隨機(jī)的key
5. volatile-ttl：移除那些TTL值最小的key襟齿，即那些最近才過期的key。
6. noeviction：不進(jìn)行移除枕赵。針對寫操作猜欺，只是返回錯誤信息。

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

maxmemory-policy volatile-lru

LRU算法和最小TTL算法都并非是精確的算法篮昧，而是估算值赋荆。所以你可以設(shè)置樣本的大小。假如redis默認(rèn)會檢查三個key并選擇其中LRU的那個懊昨，那么你可以改變這個key樣本的數(shù)量窄潭。

maxmemory-samples 3

最后，我們補(bǔ)充一個信息酵颁，那就是到目前版本（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會異步的將數(shù)據(jù)持久化到磁盤躏惋。這種模式在大部分應(yīng)用程序中已被驗證是很有效的幽污，但是在一些問題發(fā)生時，比如斷電簿姨，則這種機(jī)制可能會導(dǎo)致數(shù)分鐘的寫請求丟失距误。
如博文上半部分中介紹的，追加文件（Append Only File）是一種更好的保持?jǐn)?shù)據(jù)一致性的方式款熬。即使當(dāng)服務(wù)器斷電時，也僅會有1秒鐘的寫請求丟失攘乒，當(dāng)redis進(jìn)程出現(xiàn)問題且操作系統(tǒng)運行正常時贤牛，甚至只會丟失一條寫請求。
我們建議大家则酝，AOF機(jī)制和RDB機(jī)制可以同時使用殉簸，不會有任何沖突。對于如何保持?jǐn)?shù)據(jù)一致性的討論沽讹，請參見本文般卑。

appendonly no

我們還可以設(shè)置aof文件的名稱：

appendfilename "appendonly.aof"

fsync()調(diào)用，用來告訴操作系統(tǒng)立即將緩存的指令寫入磁盤爽雄。一些操作系統(tǒng)會“立即”進(jìn)行蝠检，而另外一些操作系統(tǒng)則會“盡快”進(jìn)行。
redis支持三種不同的模式：

1. no：不調(diào)用fsync()挚瘟。而是讓操作系統(tǒng)自行決定sync的時間叹谁。這種模式下饲梭，redis的性能會最快。
2. always：在每次寫請求后都調(diào)用fsync()焰檩。這種模式下憔涉，redis會相對較慢，但數(shù)據(jù)最安全析苫。
3. everysec：每秒鐘調(diào)用一次fsync()兜叨。這是性能和安全的折衷。

默認(rèn)情況下為everysec衩侥。有關(guān)數(shù)據(jù)一致性的揭秘国旷，可以參考本文。

appendfsync everysec

當(dāng)fsync方式設(shè)置為always或everysec時顿乒，如果后臺持久化進(jìn)程需要執(zhí)行一個很大的磁盤IO操作议街，那么redis可能會在fsync()調(diào)用時卡住。目前尚未修復(fù)這個問題璧榄，這是因為即使我們在另一個新的線程中去執(zhí)行fsync()特漩，也會阻塞住同步寫調(diào)用。

為了緩解這個問題骨杂，我們可以使用下面的配置項涂身，這樣的話，當(dāng)BGSAVE或BGWRITEAOF運行時搓蚪，fsync()在主進(jìn)程中的調(diào)用會被阻止蛤售。這意味著當(dāng)另一路進(jìn)程正在對AOF文件進(jìn)行重構(gòu)時，redis的持久化功能就失效了妒潭，就好像我們設(shè)置了“appendsync none”一樣悴能。如果你的redis有時延問題，那么請將下面的選項設(shè)置為yes雳灾。否則請保持no漠酿，因為這是保證數(shù)據(jù)完整性的最安全的選擇。

no-appendfsync-on-rewrite no

我們允許redis自動重寫aof谎亩。當(dāng)aof增長到一定規(guī)模時炒嘲，redis會隱式調(diào)用BGREWRITEAOF來重寫log文件，以縮減文件體積匈庭。

redis是這樣工作的：redis會記錄上次重寫時的aof大小夫凸。假如redis自啟動至今還沒有進(jìn)行過重寫，那么啟動時aof文件的大小會被作為基準(zhǔn)值阱持。這個基準(zhǔn)值會和當(dāng)前的aof大小進(jìn)行比較夭拌。如果當(dāng)前aof大小超出所設(shè)置的增長比例，則會觸發(fā)重寫。另外啼止，你還需要設(shè)置一個最小大小道逗，是為了防止在aof很小時就觸發(fā)重寫。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

如果設(shè)置auto-aof-rewrite-percentage為0献烦，則會關(guān)閉此重寫功能滓窍。

教你看懂redis配置 – LUA腳本

lua腳本的最大運行時間是需要被嚴(yán)格限制的，要注意單位是毫秒：

lua-time-limit 5000

如果此值設(shè)置為0或負(fù)數(shù)巩那，則既不會有報錯也不會有時間限制吏夯。

教你看懂redis配置 – 慢日志

redis慢日志是指一個系統(tǒng)進(jìn)行日志查詢超過了指定的時長。這個時長不包括IO操作即横，比如與客戶端的交互噪生、發(fā)送響應(yīng)內(nèi)容等，而僅包括實際執(zhí)行查詢命令的時間东囚。

針對慢日志跺嗽，你可以設(shè)置兩個參數(shù)，一個是執(zhí)行時長页藻，單位是微秒桨嫁，另一個是慢日志的長度。當(dāng)一個新的命令被寫入日志時份帐，最老的一條會從命令日志隊列中被移除璃吧。

單位是微秒，即1000000表示一秒废境。負(fù)數(shù)則會禁用慢日志功能畜挨，而0則表示強(qiáng)制記錄每一個命令。

slowlog-log-slower-than 10000

慢日志最大長度噩凹，可以隨便填寫數(shù)值巴元，沒有上限，但要注意它會消耗內(nèi)存驮宴。你可以使用SLOWLOG RESET來重設(shè)這個值逮刨。

slowlog-max-len 128

教你看懂redis配置 – 事件通知

redis可以向客戶端通知某些事件的發(fā)生。這個特性的具體解釋可以參見本文幻赚。

教你看懂redis配置 – 高級配置

有關(guān)哈希數(shù)據(jù)結(jié)構(gòu)的一些配置項：

hash-max-ziplist-entries 512
hash-max-ziplist-value 64

有關(guān)列表數(shù)據(jù)結(jié)構(gòu)的一些配置項：

list-max-ziplist-entries 512
list-max-ziplist-value 64

有關(guān)集合數(shù)據(jù)結(jié)構(gòu)的配置項：

set-max-intset-entries 512

有關(guān)有序集合數(shù)據(jù)結(jié)構(gòu)的配置項：

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

關(guān)于是否需要再哈希的配置項：

activerehashing yes

關(guān)于客戶端輸出緩沖的控制項：

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)頻率的配置項：

hz 10

有關(guān)重寫aof的配置項

aof-rewrite-incremental-fsync yes

至此禀忆，redis的入門內(nèi)容就結(jié)束了臊旭，內(nèi)容實在不少落恼，但相對來說都很基礎(chǔ)，本文沒有涉及redis集群离熏、redis工作原理佳谦、redis源碼、redis相關(guān)LIB庫等內(nèi)容滋戳，后續(xù)會陸續(xù)奉獻(xiàn)钻蔑，大家敬請期待：）
謝謝啥刻！