250
Redis配置文件功能說明詳解
1 daemonize no
是否後台運行，默認redis 不是在後台運行的，一般啟動會改為yes。
2 pidfile /var/run/redis.pid
進程文件及路徑設置。當Redis 在後台運行的時候，Redis 默認會把pid 文件放在/var/run/redis.pid，你可以配置到其他地址。當運行多個redis 服務時，需要指定不同的pid文件和端口。
3 port
端口設置，默認6379。
4 #bind 127.0.0.1
指定Redis隻接收來自於該IP地址的請求，如果不進行設置，那麼將處理所有請求，在生產環境中為了安全最好設置該項。一般啟用。
5 timeout 0
設置客戶端連接時的超時時間，單位為秒。當客戶端在這段時間內沒有發出任何指令，那麼關閉該連接。默認為0表示禁用。
6 tcp-keepalive 0
指定TCP連接是否為長連接。“偵探”信號由server端維護。默認為0表示禁用。
7 loglevel notice
log等級。等級分為debug, verbose, notice和warning。默認一般開啟notice。
8 logfile “var/lib/redis/6379/redis.log”
配置log文件地址，默認使用標準輸出，即打印在命令行終端的窗口上，修改為日誌文件目錄。
9 databases 16
設置數據庫的個數，可以使用select命令來切換db（cluster模式下此項設置無效，select命令無效，集群默認db0）。默認使用的數據庫是0號庫。默認16個庫
10
save 900 1
save 300 10
save 60 10000
保存數據快照的頻率，即將數據持久化到dump.rdb文件中的頻度。根據時間維度及操作數維度來觸發快照持久化。
默認設置，意思是：
if(在60 秒之內有10000 個keys 發生變化時){
進行鏡像備份
}else if(在300 秒之內有10 個keys 發生了變化){
進行鏡像備份
}else if(在900 秒之內有1 個keys 發生了變化){
進行鏡像備份
}
11 stop-writes-on-bgsave-error yes
當持久化出現錯誤時，是否依然繼續進行工作，是否終止所有的客戶端write請求。默認設置"yes"表示終止，一旦snapshot數據保存故障，那麼此server為隻讀服務。如果為"no"，那麼此次snapshot將失敗，但下一次snapshot不會受到影響，不過如果出現故障,數據隻能恢複到"最近一個成功點"
12 rdbcompression yes
在進行數據鏡像備份時，是否啟用rdb文件壓縮手段，默認為yes。壓縮可能需要額外的cpu開支，不過這能夠有效的減小rdb文件的大，有利於存儲/備份/傳輸/數據恢複
13 rdbchecksum yes
讀取和寫入時候，會損失10%性能
14 rdbchecksum yes
是否進行校驗和，是否對rdb文件使用CRC64校驗和,默認為"yes"，那麼每個rdb文件內容的末尾都會追加CRC校驗和，利於第三方校驗工具檢測文件完整性
14 dbfilename dump.rdb
鏡像備份文件的文件名，默認為 dump.rdb
15 dir ./
數據庫鏡像備份的文件rdb/AOF文件放置的路徑。這裏的路徑跟文件名要分開配置是因為Redis 在進行備份時，先會將當前數據庫的狀態寫入到一個臨時文件中，等備份完成時，再把該臨時文件替換為上麵所指定的文件，而這裏的臨時文件和上麵所配置的備份文件都會放在這個指定的路徑當中
16 # slaveof <masterip> <masterport>
設置該數據庫為其他數據庫的從數據庫，並為其指定master信息。
17 masterauth
當主數據庫連接需要密碼驗證時，在這裏指定
18 slave-serve-stale-data yes
當主master服務器掛機或主從複製在進行時，是否依然可以允許客戶訪問可能過期的數據。在"yes"情況下,slave繼續向客戶端提供隻讀服務,有可能此時的數據已經過期；在"no"情況下，任何向此server發送的數據請求服務(包括客戶端和此server的slave)都將被告知"error"
19 slave-read-only yes
slave是否為"隻讀"，強烈建議為"yes"
20 # repl-ping-slave-period 10
slave向指定的master發送ping消息的時間間隔(秒)，默認為10
21 # repl-timeout 60
slave與master通訊中,最大空閑時間,默認60秒.超時將導致連接關閉
22 repl-disable-tcp-nodelay no
slave與master的連接,是否禁用TCP nodelay選項。"yes"表示禁用,那麼socket通訊中數據將會以packet方式發送(packet大小受到socket
buffer限製)。
可以提高socket通訊的效率(tcp交互次數),但是小數據將會被buffer,不會被立即發送,對於接受者可能存在延遲。"no"表示開啟tcp
nodelay選項,任何數據都會被立即發送,及時性較好,但是效率較低，建議設為no
23 slave-priority 100
適用Sentinel模塊(unstable,M-S集群管理和監控),需要額外的配置文件支持。slave的權重值,默認100.當master失效後,Sentinel將會從slave列表中找到權重值最低(>0)的slave,並提升為master。如果權重值為0,表示此slave為"觀察者",不參與master選舉
24 # requirepass foobared
設置客戶端連接後進行任何其他指定前需要使用的密碼。警告：因為redis
速度相當快，所以在一台比較好的服務器下，一個外部的用戶可以在一秒鍾進行150K 次的密碼嚐試，這意味著你需要指定非常非常強大的密碼來防止暴力破解。
25 # rename-command CONFIG 3ed984507a5dcd722aeade310065ce5d (方式:MD5('CONFIG^!'))
重命名指令,對於一些與"server"控製有關的指令,可能不希望遠程客戶端(非管理員用戶)鏈接隨意使用,那麼就可以把這些指令重命名為"難以閱讀"的其他字符串
26 # maxclients 10000
限製同時連接的客戶數量。當連接數超過這個值時，redis 將不再接收其他連接請求，客戶端嚐試連接時將收到error 信息。默認為10000，要考慮係統文件描述符限製，不宜過大，浪費文件描述符，具體多少根據具體情況而定
27 # maxmemory <bytes>
redis-cache所能使用的最大內存(bytes),默認為0,表示"無限製",最終由OS物理內存大小決定(如果物理內存不足,有可能會使用swap)。此值盡量不要超過機器的物理內存尺寸,從性能和實施的角度考慮,可以為物理內存3/4。此配置需要和"maxmemory-policy"配合使用,當redis中內存數據達到maxmemory時,觸發"清除策略"。在"內存不足"時,任何write操作(比如set,lpush等)都會觸發"清除策略"的執行。在實際環境中,建議redis的所有物理機器的硬件配置保持一致(內存一致),同時確保master/slave中"maxmemory""policy"配置一致。
當內存滿了的時候，如果還接收到set 命令，redis 將先嚐試剔除設置過expire 信息的key，而不管該key 的過期時間還沒有到達。在刪除時，
將按照過期時間進行刪除，最早將要被過期的key 將最先被刪除。如果帶有expire 信息的key 都刪光了，內存還不夠用，那麼將返回錯誤。這樣，redis 將不再接收寫請求，隻接收get 請求。maxmemory 的設置比較適合於把redis 當作於類似memcached的緩存來使用。
28 # maxmemory-policy volatile-lru
內存不足"時,數據清除策略,默認為"volatile-lru"。
volatile-lru ->對"過期集合"中的數據采取LRU(近期最少使用)算法.如果對key使用"expire"指令指定了過期時間,那麼此key將會被添加到"過期集合"中。將已經過期/LRU的數據優先移除.如果"過期集合"中全部移除仍不能滿足內存需求,將OOM.
allkeys-lru ->對所有的數據,采用LRU算法
volatile-random ->對"過期集合"中的數據采取"隨即選取"算法,並移除選中的K-V,直到"內存足夠"為止. 如果如果"過期集合"中全部移除全部移除仍不能滿足,將OOM
allkeys-random ->對所有的數據,采取"隨機選取"算法,並移除選中的K-V,直到"內存足夠"為止
volatile-ttl ->對"過期集合"中的數據采取TTL算法(最小存活時間),移除即將過期的數據.
noeviction ->不做任何幹擾操作,直接返回OOM異常
另外，如果數據的過期不會對"應用係統"帶來異常,且係統中write操作比較密集,建議采取"allkeys-lru"
29 # maxmemory-samples 3
默認值3，上麵LRU和最小TTL策略並非嚴謹的策略，而是大約估算的方式，因此可以選擇取樣值以便檢查
29 appendonly no
默認情況下，redis 會在後台異步的把數據庫鏡像備份到磁盤，但是該備份是非常耗時的，而且備份也不能很頻繁。所以redis 提供了另外一種更加高效的數據庫備份及災難恢複方式。開啟append only 模式之後，redis 會把所接收到的每一次寫操作請求都追加到appendonly.aof 文件中，當redis 重新啟動時，會從該文件恢複出之前的狀態。但是這樣會造成appendonly.aof 文件過大，所以redis 還支持了BGREWRITEAOF 指令，對appendonly.aof 進行重新整理。如果不經常進行數據遷移操作，推薦生產環境下的做法為關閉鏡像，開啟appendonly.aof，同時可以選擇在訪問較少的時間每天對appendonly.aof 進行重寫一次。
另外，對master機器,主要負責寫，建議使用AOF,對於slave,主要負責讀，挑選出1-2台開啟AOF，其餘的建議關閉
30 # appendfilename appendonly.aof
aof文件名字，默認為appendonly.aof
31
# appendfsync always
appendfsync everysec
# appendfsync no
設置對appendonly.aof 文件進行同步的頻率。always 表示每次有寫操作都進行同步，everysec 表示對寫操作進行累積，每秒同步一次。no不主動fsync，由OS自己來完成。這個需要根據實際業務場景進行配置
32 no-appendfsync-on-rewrite no
在aof rewrite期間,是否對aof新記錄的append暫緩使用文件同步策略,主要考慮磁盤IO開支和請求阻塞時間。默認為no,表示"不暫緩",新的aof記錄仍然會被立即同步
33 auto-aof-rewrite-percentage 100
當Aof
log增長超過指定比例時，重寫log file， 設置為0表示不自動重寫Aof 日誌，重寫是為了使aof體積保持最小，而確保保存最完整的數據。
34 auto-aof-rewrite-min-size 64mb
觸發aof
rewrite的最小文件尺寸
35 lua-time-limit 5000
lua腳本運行的最大時間
36 slowlog-log-slower-than 10000
"慢操作日誌"記錄,單位:微秒(百萬分之一秒,1000 * 1000),如果操作時間超過此值,將會把command信息"記錄"起來.(內存,非文件)。其中"操作時間"不包括網絡IO開支,隻包括請求達到server後進行"內存實施"的時間."0"表示記錄全部操作
37 slowlog-max-len 128
"慢操作日誌"保留的最大條數,"記錄"將會被隊列化,如果超過了此長度,舊記錄將會被移除。可以通過"SLOWLOG
<subcommand> args"查看慢記錄的信息(SLOWLOG get 10,SLOWLOG reset)
38
hash-max-ziplist-entries 512
hash類型的數據結構在編碼上可以使用ziplist和hashtable。ziplist的特點就是文件存儲(以及內存存儲)所需的空間較小,在內容較小時,性能和hashtable幾乎一樣.因此redis對hash類型默認采取ziplist。如果hash中條目的條目個數或者value長度達到閥值,將會被重構為hashtable。
這個參數指的是ziplist中允許存儲的最大條目個數，，默認為512，建議為128
hash-max-ziplist-value 64
ziplist中允許條目value值最大字節數，默認為64，建議為1024
39
list-max-ziplist-entries 512
list-max-ziplist-value 64
對於list類型,將會采取ziplist,linkedlist兩種編碼類型。解釋同上。
40 set-max-intset-entries 512
intset中允許保存的最大條目個數,如果達到閥值,intset將會被重構為hashtable
41
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
zset為有序集合,有2中編碼類型:ziplist,skiplist。因為"排序"將會消耗額外的性能,當zset中數據較多時,將會被重構為skiplist。
42 activerehashing yes
是否開啟頂層數據結構的rehash功能,如果內存允許,請開啟。rehash能夠很大程度上提高K-V存取的效率
43
client-output-buffer-limit
normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
客戶端buffer控製。在客戶端與server進行的交互中,每個連接都會與一個buffer關聯,此buffer用來隊列化等待被client接受的響應信息。如果client不能及時的消費響應信息,那麼buffer將會被不斷積壓而給server帶來內存壓力.如果buffer中積壓的數據達到閥值,將會導致連接被關閉,buffer被移除。
buffer控製類型包括:normal ->
普通連接；slave ->與slave之間的連接；pubsub ->pub/sub類型連接，此類型的連接，往往會產生此種問題;因為pub端會密集的發布消息,但是sub端可能消費不足.
指令格式:client-output-buffer-limit <class> <hard> <soft> <seconds>",其中hard表示buffer最大值,一旦達到閥值將立即關閉連接;
soft表示"容忍值",它和seconds配合,如果buffer值超過soft且持續時間達到了seconds,也將立即關閉連接,如果超過了soft但是在seconds之後，buffer數據小於了soft,連接將會被保留.
其中hard和soft都設置為0,則表示禁用buffer控製.通常hard值大於soft.
44 hz 10
Redis
server執行後台任務的頻率,默認為10,此值越大表示redis對"間歇性task"的執行次數越頻繁(次數/秒)。"間歇性task"包括"過期集合"檢測、關閉"空閑超時"的連接等,此值必須大於0且小於500。此值過小就意味著更多的cpu周期消耗,後台task被輪詢的次數更頻繁。此值過大意味著"內存敏感"性較差。建議采用默認值。
45
#
include /path/to/local.conf
# include /path/to/other.conf
額外載入配置文件。
最後更新：2017-06-19 19:32:48