編譯完 redis，它的配置文件在源碼目錄下 redis.conf ，將其拷貝到工作目錄下即可使用，下面具體解釋redis.conf 中的各個參數：

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

設置客戶端連接時的超時時間，單位為秒。當客戶端在這段時間內沒有發出任何指令，那么關閉該連接

6 tcp-keepalive 0

指定 TCP 連接是否為長連接,"偵探"信號有 server 端維護。默認為 0.表示禁用

7 loglevel notice

log等級分為 4 級，debug,verbose, notice, 和 warning。生產環境下一般開啟 notice

8 logfile stdout

配置 log 文件地址，默認使用標準輸出，即打印在命令行終端的窗口上，修改為日志文件目錄

9 databases 16

設置數據庫的個數，可以使用 SELECT 命令來切換數據庫。默認使用的數據庫是 0 號庫。默認 16 個庫

10

save 900 1

save 300 10

save 60 10000

保存數據快照的頻率，即將數據持久化到 dump.rdb 文件中的頻度。用來描述"在多少秒期間至少多少個變更操作"觸發 snapshot 數據保存動作，默認設置，意思是：

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%性能，是否進行校驗和，是否對 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,直到"內存足夠"為止. 如果如果"過期集合"中全部移除全部移除仍不能滿足,將 OOMallkeys-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 aof 同步頻率

# 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 get10,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"包括"過期集合"檢測、關閉"空閑超時"的連接等,此值必

Redis 配置文件詳解

須大于 0 且小于 500。此值過小就意味著更多的 cpu 周期消耗,后臺 task 被輪詢的次數更頻繁。此值過大意味著"內存敏感"性較差。建議采用默認值。

45 include 載入文件

# include /path/to/local.conf

# include /path/to/other.conf

額外載入配置文件。

總結

以上是生活随笔為你收集整理的Redis配置详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。