linux 啟動 redis：cd /usr/local/redis-3.2.0
src/redis-server redis.conf //保證 redis 啟動時讀取的是配置完成的 redis.conf 文件
src/redis-cli //啟動客戶端
ps -ef|grep redis //查看 redis 進(jìn)程狀態(tài)

默認(rèn)的配置 redis.conf 文件中，首先約定了存儲單位：
1k => 1000 bytes
1kb => 1024 bytes
1m => 1000000 bytes
1mb => 10241024 bytes
1g => 1000000000 bytes
1gb => 10241024*1024 bytes
Redis 配置中對單位的大小寫不敏感，1GB、1Gb和1gB都是相同的。由此也說明，Redis 只支持 bytes，不支持 bit 單位。
Redis 支持以 “includes” 的方式引入其他配置文件，比如：
include/path/to/local.conf
include/path/to/other.conf
需要注意的是，假如多個一個配置項在不同配置文件中都有定義，則以最后一行讀入的為準(zhǔn)，就是說后面的配置項會覆蓋前面的配置項。

1.1通用配置
默認(rèn)情況下，Redis 并不是以 daemon 形式來運行的。通過 daemonize 配置項可以控制Redis的運行形式，如果改為 yes，那么 Redis 就會以 daemon 形式運行：
daemonize no
當(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
可是，如果Redis不監(jiān)聽端口，還怎么與外界通信呢？其實Redis還支持通過 unix socket 方式來接收請求?？梢酝ㄟ^ unix socket 配置項來指定 unix socket 文件的路徑，并通過 unix socket perm 來指定文件的權(quán)限。
unixsocket /tmp/Redis.sock
unixsocketperm 700

在高 QPS 的環(huán)境下需要提高 backlog 的值來避免 TCP 的慢連接問題。想要提高 backlog 的值，除了需要設(shè)置 Redis 的 tcp-backlog ，還要同時提高更改 Linux 的配置，否則，Linux內(nèi)核會默認(rèn)將其截取為 /proc/sys/net/core/somaxconn 的大小。
tcp-backlog 511
當(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)行?；顧z測。
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 <DBid> 來選擇相應(yīng)的數(shù)據(jù)庫。

1.2快照配置
快照，主要涉及的是 Redis 的 RDB 持久化相關(guān)的配置。
可以用如下的指令來讓數(shù)據(jù)保存到磁盤上，即控制 RDB 快照功能：
save <seconds> <changes>
舉例來說：
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è)置就是：
dir ./db/

1.3主從配置
Redis 提供了主從同步功能。
通過 slaveof 配置項可以控制某一個 Redis 作為另一個 Redis 的從服務(wù)器，通過指定 IP 和端口來定位到主Redis 的位置。一般情況下建議用戶為從 Redis 設(shè)置一個不同頻率的快照持久化的周期，或者為從 Redis 配置一個不同的服務(wù)端口等等。
slaveof <masterip> <masterport>
如果主 Redis 設(shè)置了驗證密碼的話（使用 requirepass 來設(shè)置），則在從 Redis 的配置中要使用masterauth 來設(shè)置校驗密碼，否則的話，主 Redis 會拒絕從 Redis 的訪問請求。
masterauth <master-password>
當(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 inprogress” ，當(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 b8c02d524045429941cc15f59e41cb7be6c52
從 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ù)同步的延遲時間會降低，但是會消耗更多的帶寬。
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。

1.4 安全配置
我們可以要求 Redis 客戶端在向 Redis-server 發(fā)送請求之前，先進(jìn)行密碼驗證。由于 Redis 性能非常高，每秒鐘可以完成多達(dá)15萬次的密碼嘗試，所以最好設(shè)置一個足夠復(fù)雜的密碼，否則很容易被黑客破解。
requirepass chenlongfei
這里通過 requirepass 將密碼設(shè)置成我的名字。
Redis 允許我們對 Redis 指令進(jìn)行更名，比如將一些比較危險的命令改個名字，避免被誤執(zhí)行。比如可以把 CONFIG 命令改成一個很復(fù)雜的名字，這樣可以避免外部的調(diào)用，同時還可以滿足內(nèi)部調(diào)用的需要：
rename-command CONFIG b840fc02d5240454299c15f59e41cb7be6c89
我們甚至可以禁用掉 CONFIG 命令，那就是把 CONFIG 的名字改成一個空字符串：
rename-command CONFIG ""
但需要注意的是，如果使用 AOF 方式進(jìn)行數(shù)據(jù)持久化，或者需要與從 Redis 進(jìn)行通信，那么更改指令的名字可能會引起一些問題。

1.5 限制配置
我們可以設(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 <bytes>
需要注意的一點是，如果 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

1.6 AOF配置
默認(rèn)情況下， Redis 會異步的將數(shù)據(jù)持久化到磁盤。這種模式在大部分應(yīng)用程序中已被驗證是很有效的，但是在一些問題發(fā)生時，比如斷電，則這種機(jī)制可能會導(dǎo)致數(shù)分鐘的寫請求丟失。
如上半部分中介紹的， AOF 是一種更好的保持?jǐn)?shù)據(jù)一致性的方式。即使當(dāng)服務(wù)器斷電時，也僅會有1秒鐘的寫請求丟失，當(dāng) Redis 進(jìn)程出現(xiàn)問題且操作系統(tǒng)運行正常時，甚至只會丟失一條寫請求。
官方建議， AOF 機(jī)制和 RDB 機(jī)制可以同時使用，不會有任何沖突。
appendonly yes
我們還可以設(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 。
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在恢復(fù)時，會忽略最后一條可能存在問題的指令，默認(rèn)值yes。即在 aof 寫入時，可能存在指令寫錯的問題(突然斷電，寫了一半)，這種情況下，yes會log并繼續(xù)，而no會直接恢復(fù)失敗。
aof-load-truncated yes

1.7 LUA腳本配置
lua 腳本的最大運行時間是需要被嚴(yán)格限制的，單位是毫秒：
lua-time-limit 5000
如果此值設(shè)置為0或負(fù)數(shù)，則既不會有報錯也不會有時間限制。

1.8 集群設(shè)置
平常的 Redis 實例不能作為集群的節(jié)點，只有作為集群節(jié)點啟動的實例才可以。下面的配置可以是 Redis 實例作為集群節(jié)點啟動：
cluster-enabled yes
每個集群節(jié)點都有一個集群配置文件，該文件是由集群節(jié)點來創(chuàng)建和維護(hù)的，不能人工參與。每個集群節(jié)點需要不同的配置文件，所以需要保證同一個系統(tǒng)下的集群節(jié)點沒有重名的配置文件，建議以端口號標(biāo)記配置文件。
cluster-config-file nodes-6379.conf
當(dāng)節(jié)點超時大于 cluster-node-timeout 的時候后，就會被認(rèn)為宕機(jī)了，單位為毫秒。
cluster-node-timeout 15000
Redis 集群有一種 failover （故障轉(zhuǎn)移）機(jī)制，即當(dāng)主 Redis 宕機(jī)之后，會有一個最合適的從 Redis 充當(dāng)主 Redis 。但是，當(dāng)從 Redis 的數(shù)據(jù)“太老”了，與住 Redis 的標(biāo)準(zhǔn)數(shù)據(jù)偏差很大，為了保證數(shù)據(jù)一致性， Redis 會放棄 failover 。判別從 Redis 的的數(shù)據(jù)是不是“太老”有兩種方法：
（1）如果有多個從 Redis 可以接替主 Redis 的工作，則它們會交換信息，選取“最佳復(fù)制偏移”（接受了原主 Redis 最多的數(shù)據(jù)同步）的從 Redis 作為下一任主 Redis 。
（2）每個從Redis計算與原主Redis最后一次數(shù)據(jù)同步的時間，當(dāng)最短的時間間隔大于某個臨界點的時候，集群則放棄failover。
方法（2）當(dāng)中的臨界點可以通過配置調(diào)節(jié)，臨界點的計算規(guī)則為：
(node-timeout * slave-validity-factor)+ repl-ping-slave-period
如node-timeout為30秒，slave-validity-factor為10秒，repl-ping-slave-period為10秒，當(dāng)與原主Redis最后一次對話的時間間隔超過310秒的時候，集群就會放棄failover。
當(dāng)slave-validity-factor太大會使一臺數(shù)據(jù)“太老”的從Redis充當(dāng)主Redis；而slave-validity-factor太小可能會造成找不到合適的從Redis繼任。
默認(rèn)的slave-validity-factor為10。
cluster-slave-validity-factor 10
考慮一種極端情況，集群有一臺主Redis和四臺從Redis，從Redis全部掛掉，failover機(jī)制有可能造成集群只有主Redis而無從Redis的尷尬境況。為了保證集群的名副其實，可以規(guī)定，當(dāng)從Redis少于某個數(shù)量時，拒絕執(zhí)行failover。
cluster-migration-barrier 1
默認(rèn)情況下，當(dāng)集群檢測到某個哈希槽（hash slot）沒有被覆蓋（沒有任何節(jié)點為此服務(wù)）會停止接受查詢服務(wù)，如果集群部分宕機(jī)最終會導(dǎo)致整個集群不可用，當(dāng)哈希槽重新被全覆蓋的時候會自動變?yōu)榭捎?。如果希望那些哈希槽被覆蓋的集群節(jié)點繼續(xù)接受查詢服務(wù)，需要將cluster-require-full-coverage設(shè)置為no。
cluster-require-full-coverage yes

1.9 慢日志配置
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)存?？梢允褂肧LOWLOG RESET來重設(shè)這個值。
slowlog-max-len 128

1.10 延遲監(jiān)控配置
Redis的延遲監(jiān)控子系統(tǒng)會在運行時對不同操作取樣，以此來收集與延遲相關(guān)的數(shù)據(jù)，這些信息可以通過LATENCY命令以報表的形式呈現(xiàn)給用戶。
系統(tǒng)只會記錄那些執(zhí)行時間等于或大于atency-monitor-threshold的操作，該值默認(rèn)為0，代表關(guān)閉監(jiān)控，因為收集延遲數(shù)據(jù)多少會影響Redis的性能。
latency-monitor-threshold 0

1.11事件通知配置
Redis可以向客戶端通知某些事件的發(fā)生。
例如，鍵空間（keyspace）時間通知如果開啟，一個客戶端對Database 0中的“foo”鍵執(zhí)行了DEL操作，兩條信息會通過Pub/Sub發(fā)布出去：
PUBLISH__keyspace@0__:foo del
PUBLISH__keyevent@0__:del foo
可以選擇需要發(fā)送哪種類型的通知，每種類型用一個字母代表：
K 鍵空間事件,發(fā)布到“keyspace@<db> prefix”頻道
E 鍵事件, 發(fā)布到“ keyevent@<db> prefix”頻道
g 通用事件，比如 DEL,EXPIRE, RENAME, ...等操作都屬于
$ String操作
l List操作
s Set操作
h Hash操作
z Sorted set操作
x 過期操作
e 驅(qū)逐操作（因為內(nèi)存不足數(shù)據(jù)被刪除）
A 代表“g$lshzxe”的組合, 所以“AKE”可以代表所有事件

notify-keyspace-events配置以上述的字母組合為參數(shù)，舉例說明：
（1）notify-keyspace-events Elg
當(dāng)有List操作或通用操作，發(fā)布通知到“ keyevent@<db> prefix”頻道
（2）notify-keyspace-events Ex
當(dāng)有鍵的過期操作時，發(fā)布通知到“keyevent@0:expired”頻道
默認(rèn)情況下，notify-keyspace-events的參數(shù)為空字符串，代表關(guān)閉通知。
notify-keyspace-events ""

1.12 高級配置
Hash 在條目數(shù)量較小的時候會使用一種高效的內(nèi)存數(shù)據(jù)結(jié)構(gòu)編碼，當(dāng)超過某個臨界點就會采用另一種存儲方式，該臨界點由下面的兩個配置決定：
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
與Hash類似，較小的List會以一種特殊的編碼方式來節(jié)省空間，只要List不超過下面的上限：
list-max-ziplist-entries 512
list-max-ziplist-value 64
Set只有在滿足下面的條件時才會采用特殊編碼方式：Set中存儲的恰好都是十進(jìn)制的整數(shù)，而且長度不超過64位（有符號）。數(shù)量上限為：
set-max-intset-entries 512
同樣，有序集合也會采用特殊編碼來節(jié)省空間，只要不超過上限：
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
RedisHyperLogLog 是用來做基數(shù)統(tǒng)計的算法，HyperLogLog 的優(yōu)點是，在輸入元素的數(shù)量或者體積非常非常大時，計算基數(shù)所需的空間總是固定并且很小的。當(dāng)HyperLogLog用稀疏式表示法時所用內(nèi)存超過下面的限制，就會轉(zhuǎn)換成稠密式表示，為了更高的內(nèi)存利用率，官方建議值為3000。
hll-sparse-max-bytes 3000
Redis 在每 100 毫秒時使用 1 毫秒的 CPU時間來對 Redis 的 hash 表進(jìn)行重新 hash 。當(dāng)使用場景中有非常嚴(yán)格的實時性需要，不能夠接受 Redis 時不時的對請求有 2 毫秒的延遲的話，把這項配置為 no 。
如果沒有這么嚴(yán)格的實時性要求，可以設(shè)置為 yes ，以便能夠盡可能快的釋放內(nèi)存。
activerehashing yes
客戶端的輸出緩沖區(qū)的限制，因為某種原因客戶端從服務(wù)器讀取數(shù)據(jù)的速度不夠快，可用于強(qiáng)制斷開連接（一個常見的原因是一個發(fā)布 / 訂閱客戶端消費消息的速度無法趕上生產(chǎn)它們的速度）。
可以三種不同客戶端的方式進(jìn)行設(shè)置：
（1）normal -> 正?？蛻舳?br> （2）slave -> slave 和 MONITOR 客戶端
（3）pubsub -> 至少訂閱了一個 pubsub channel 或 pattern 的客戶端
每個client-output-buffer-limit 語法 :
client-output-buffer-limit<class> <hard limit> <soft limit> <soft seconds> 一旦達(dá)到硬限制客戶端會立即斷開，或者達(dá)到軟限制并保持達(dá)成的指定秒數(shù)（連續(xù)）。
例如，如果硬限制為 32 兆字節(jié)和軟限制為 16 兆字節(jié) /10 秒，如果輸出緩沖區(qū)的大小達(dá)到 32 兆字節(jié)，客戶端將會立即斷開，客戶端達(dá)到 16 兆字節(jié)和連續(xù)超過了限制 10 秒，也將斷開連接。
默認(rèn) normal 客戶端不做限制，因為他們在一個請求后未要求時（以推的方式）不接收數(shù)據(jù)，只有異步客戶端可能會出現(xiàn)請求數(shù)據(jù)的速度比它可以讀取的速度快的場景。
把硬限制和軟限制都設(shè)置為 0 來禁用該特性
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
Redis 會按照一定的頻率來執(zhí)行后臺任務(wù)，比如關(guān)閉超時的客戶端，清除過期鍵等。不是所有的任務(wù)都會按照相同的頻率來執(zhí)行，但 Redis 依照指定的“ Hz ”值來執(zhí)行檢查任務(wù)。
hz 10
aof rewrite 過程中，是否采取增量文件同步策略，默認(rèn)為“yes”。 rewrite 過程中,每32M數(shù)據(jù)進(jìn)行一次文件同步，這樣可以減少 aof 大文件寫入對磁盤的操作次數(shù)。
aof-rewrite-incremental-fsync yes