一、概述

redis的配置文件中，有著許多說明和可配置項，了解它們能夠更好的使用redis去解決開發中遇到的困難。
此配置文件基于linux下的redis-6.2.4版本。

二、單位換算描述-units

在配置文件開頭就有這么一段：

這里描述了一些基本的度量單位是如何與bytes進行換算的。

并且說明了單位不區分大小寫，寫1GB、1gb、1Gb、1gB效果都是一樣的。

三、包含配置-include

意思就是說環境中使用的 redis.conf 可以包含其他的 redis.conf。

解開紅框處的注釋，被引入的配置文件會整合成一個配置文件來使用。

在使用redis主從復制，搭建集群的時候，這個配置通常都會使用到。

也就是說多個redis實例的時候是可以把公共的配置文件提取出來然后再用include來進行引入的。

四、網絡相關配置

4.1 bind

默認情況bind=127.0.0.1，代表只能接受本機的訪問請求。后面的::1是ipv6的地址。

在不寫的bind情況下，代表無限制接受任何ip地址的訪問。

生產環境肯定要配置上應用服務器的地址，服務器是需要遠程訪問的。

4.2 保護模式-protected-mode

保護模式模式默認是開啟的。

開啟了protected-mode(保護模式)，那么在沒有設定bind ip且沒有設密碼的情況下，也只接受本機的響應。

如果學習時想要方便，讓哪里都可以訪問，可以注釋掉bind配置，并且把保護模式改成no。

4.3 端口號配置-Port

redis默認端口6379就是在這里配置的。

多實例時，就是在這里修改每個實例的端口。

4.4 tcp半連接隊列長度配置 tcp-backlog

設置tcp的backlog，backlog是一個連接隊列，隊列總和=未完成三次握手隊列 + 已經完成三次握手隊列。

在高并發環境下一般需要一個高backlog值來避免慢客戶端連接問題。

因為Linux內核會將這個值減小到/proc/sys/net/core/somaxconn的值（128）。

所以需要確認增大/proc/sys/net/core/somaxconn和/proc/sys/net/ipv4/tcp_max_syn_backlog（128）

兩個值來達到想要的效果。

4.5 超時關閉-timeout

它可以決定一個空閑的客戶端維持多少秒會關閉，0表示關閉該功能。即永不關閉。

默認的配置也是0。

4.6 tcp心跳檢測 tcp-keepalive

對訪問客戶端的一種心跳檢測，每個n秒檢測一次。

單位為秒，如果設置為0，則不會進行Keepalive檢測，建議設置成60。

五、通用配置-general

5.1 是否配置為守護進程

配置是否為守護進程，默認值為no。

讓redis成為守護進程，意味著redis可以后臺運行，所以一般都會把它設置為yes。

但是，如果redis是服務腳本啟動的，那么不管該參數為什么，redis都會運行成為一個守護進程。

5.2 pid文件位置配置-pidfile

配置存放pid文件的位置，每個實例會產生一個不同的pid文件。

5.3 日志級別配置-loglevel

指定日志記錄級別，redis總共支持四個級別：

• debug：能設置的最高的日志級別，打印所有信息，包括debug信息。
• verbose：打印除了debug日志之外的所有日志。
• notice：打印除了debug和verbose級別的所有日志。
• warning：僅打印非常重要的信息。

默認的日志級別為為notice。

四個級別根據使用階段來選擇，生產環境選擇notice 或者warning。

5.4 日志文件輸出路徑配置-logfile

該路徑默認為空。可以根據自己需要把日志文件輸出到指定位置。

5.6 數據庫數量配置-databases

設定redis中庫的數量，默認數量是16，這也是大家眾所周知的數量。

5.7 是否總是顯示logo

默認是值是no。

六、密碼配置-requirepass

在命令中設置密碼，只是臨時的。重啟redis服務器，密碼就還原了。

永久設置，需要再配置文件中進行設置。

把下面注釋解開，把foobared修改成自己相要的密碼即可。

由于redis響應較高，所以被破解密碼時，響應也很快。如果密碼不夠復雜，那么可能很快就被暴力破

解了，因此盡量使用長且復雜的密碼作為redis的訪問密碼。

七、客戶端最大連接數-maxclients

設置redis同時可以與多少個客戶端進行連接。

這里雖然注釋了，但是默認maxclients就是10000。如果達到了此限制，redis則會拒絕新的連接請求。

并且向這些連接請求方發出max number of clients reached以作回應。

八、內存管理

8.1 redis最大內存配置-maxmemory

建議最好設置，否則，將內存占滿，會造成服務器宕機以及部分數據丟失。

這是因為一旦到達內存使用上限，redis將會試圖刪除已到期或即將到期的Key。

移除規則可以通過maxmemory-policy來指定。

8.2 達到最大內存時的移除策略-maxmemory-policy

這里主要有八種策略可以選擇：

• volatile-lru ：使用LRU算法移除key，只對設置了過期時間的Key進行淘汰。(最近最少使用策略)

• allkeys-lru： 在所有集合key中，使用LRU算法移除key。

• volatile-lfu ：使用LFU算法移除key，只對設置了過期時間的Key進行淘汰。。

• allkeys-lfu ：在所有集合key中，使用LFU算法移除key。

• volatile-random ：只對設置了過期時間的Key進行淘汰，淘汰算法為隨機淘汰。

• allkeys-random： 在所有集合key中，移除隨機的key。

• volatile-ttl： 移除那些TTL值最小的key，即那些最近要過期的key。

• noeviction： 永不刪除key，針對寫操作，達到最大內存再進行數據裝入時會返回錯誤。

redis使用的默認策略為noeviction。

8.3 設置樣本數量-maxmemory-samples

設置樣本數量，LRU算法和最小TTL算法都并非是精確的算法，而是估算值。

所以可以設置樣本的大小，redis默認會檢查這么多個key并選擇其中LRU的那個。

一般設置3到7的數字，數值越小樣本越不準確，但性能消耗越小。默認值5就可以獲得很好的效果。

九、AOF持久化配置

9.1 開始/關閉AOF-appendonly

配置文件中默認是關閉aof的，想要開啟把no改成yes即可。

9.2 AOF文件名稱-appendfilename

默認的文件名稱是appendonly.aof，一般也無需修改這個文件名稱。

9.3 持久化同步策略-appendfsync

主要有三種策略可供選擇：

• everysec：每秒執行，發送異常時可能會丟失最后一秒的數據。
• always：每次寫操作執行，數據最安全，但是對性能有影響。
• no：不強制刷盤，不主動同步數據，由內核決定什么時候刷盤，數據最不安全，性能最好。
  

這里三者都提供了，只需要解開想要的持久化同步策略的注釋，再把原來的持久化策略注釋掉即可

9.4 后臺有保存任務時，暫時停止appendfsync

可以理解為，有數據保存到redis是，暫時停止持久化。默認并沒有開啟。

9.5 自動重寫AOF文件

在AOF文件大小增長到了指定的百分比（相對于上次AOF文件大小的增長量）或者最小體積時。

會自動調用BGREWRITEAOF命令重寫AOF文件。

自動重寫AOF文件的最小大小是64mb。

9.6 AOF文件末尾截斷時的處理策略-aof-load-truncated

默認是true，發生文件截斷時，依舊加載文件。

9.7 開啟混合持久化-aof-use-rdb-preamble

開啟混合持久化，更快的AOF重寫和啟動時數據恢復。

十、配置LUA腳本最大執行時長-lua-time-limit

lua-time-limit配置的單位毫秒，默認是5秒。

當腳本運行時間超過限制后，redis將開始接受其他命令當不會執行，而是會返回BUSY錯誤。

十一、redis集群配置-REDIS CLUSTER

11.1 允許開啟集群模式-cluster-enabled

注意以集群模式啟動的redis實例才能作為集群的節點。

11.2 集群配置文件-cluster-config-file

這個文件redis會自行創建和維護，我們只需要解開注釋即可，文件名一般都無需更改。

11.3 集群節點超時時間-cluster-node-timeout

單位是毫秒。

在集群模式下，master節點之間會互相發送PING心跳來檢測集群master節點的存活狀態。

超過配置的時間沒有得到響應，則認沒有響應的master節點宕機。

11.4 副本有效因子-cluster-replica-validity-factor

該配置用于決定當redis集群中，一個master宕機后，如何選擇一個slave節點完成故障轉移自動恢復。

較大的值可能允許數據太舊的副本故障切換到主副本，而太小的值可能會阻止群集選擇副本。

如果設置為0 ，則不管slave與 master 之間斷開多久，都認為自己有資格成為master；

11.5 master故障轉移時保留的最少副本數-cluster-migration-barrier

默認值為1（僅當副本的主副本至少保留一個副本時，副本才會遷移）。

要禁用遷移，只需將其設置為非常大的值。可以設置值0，但僅對調試有用，并且在生產中很危險。

11.6 哈希槽全覆蓋檢查-cluster-require-full-coverage

默認值是true，如果希望正在工作的集群的子集繼續接受對仍然覆蓋的密鑰空間部分的查詢可以把它設置為no

11.7 自動故障轉移-cluster-replica-no-failover

默認值為no，當設置為yes時，此選項可防止副本在主機故障期間嘗試故障切換master。

但是，如果被迫這樣做，主機仍然可以執行手動故障切換。

11.8 集群宕機時允許節點處理讀請求-cluster-allow-reads-when-down

默認值為no。

11.9 對NAT網絡或者Docker的支持

這里還給了個使用示例：

十二、慢日志

慢查詢日志功能用于記錄執行時間超過給定時長的命令請求。

用戶可以通過這個功能產生的日志來監視和優化查詢速度。

12.1 慢日志記錄閾值-slowlog-log-slower-than

命令執行時間超過這個值就會被記錄到慢日志中，默認值是10000微秒。

12.2 慢日志文件大小-slowlog-max-len

慢日志文件超過這個長度后最舊的記錄會被刪除，默認值是128條。

十三、延遲監控-latency-monitor-threshold

單位是毫秒，默認情況下，延遲監控是禁用的。

因為如果沒有延遲問題，通常不需要延遲監控，而且收集數據會對性能產生影響，

十四、事件通知-notify-keyspace-events

默認情況下所有事件通知都是關閉的，因為大多數用戶不需要這些特性。

十五、是否開啟gopher協議

默認這個配置是被注釋了的，而且默認值也是不開啟。

十六、高級設置

16.1 設置Hash底層數據結構由ziplist轉為hashtable的閾值

由于hash類型的數據結構主要有兩種：ziplist（壓縮列表），hashtable（哈希表）。

當field-value長度較短且個數較少時，使用ziplist，否則使用hashtable。

意思就是當一個Hash類型的key包含的實體數量超過了hash-max-ziplist-entries的值或者某個實體的大小超

過了hash-max-ziplist-value的值（單位字節），那么底層編碼就會升級成hashtable。

16.2 設置List底層數據結構quicklist中單個ziplist的大小

redis將鏈表和ziplist結合起來組成了quicklist。也就是將多個ziplist使用雙向指針串起來使用。

在配置文件中它可以有五個選項：

• -5：最大大小為64Kb，不推薦作為正常情況下的負載
• -4：最大大小為32Kb，不推薦
• -3：最大大小為16Kb，大概可能估計好像不是很推薦（原話：probably not recommended）
• -2：最大大小為8Kb，推薦（原話：good）
• -1：最大大小為4Kb，推薦（原話：good）

默認值是-2。

16.3 設置如何繼續壓縮List中ziplist

ziplist還可以繼續進行壓縮。

可以如下設置它的值：

• 0：代表不壓縮，默認值
• 1：兩端各一個節點不壓縮
• 2：兩端各兩個節點不壓縮
• ...：依次類推。。。
  

16.4 設置set底層intset升級為hashtable的閾值

單位是字節。

16.5 ZSet底層數據結構由ziplist轉為skiplist的閾值

單位是字節。

16.6 設置HyperLogLog底層稀疏矩陣轉為稠密矩陣的閾值

HyperLogLog當在計數比較小時會使用稀疏矩陣來存儲，只有當計數達到閾值時，才會轉為稠密矩陣。

超過16000的值是完全無用的，因為這種情況下使用稠密矩陣更加節省內存。

注釋中給出的建議值是3000。

這樣以便在不降低太多PFADD速度的情況下獲取空間有效編碼的好處。稀疏編碼的PFADD的時間復雜度為O(N)。

當更少考慮CPU占用時更多考慮內存占用時，這個值可以升到10000左右。

16.7 自定義Stream宏節點大小

stream-node-max-bytes選項修改Stream中每個宏節點能夠占用的最大內存。

stream-node-max-entries參數指定每個宏節點中可存儲條目的最大數量。

16.8 是否開啟Rehash

redis在每100毫秒時使用1毫秒的CPU時間來對redis的hash表進行重新hash，可以降低內存的使用。

當有非常嚴格的實時性需要時，不能夠接受redis時不時的對請求有2毫秒的延遲的話，把這項配置為no。

如果沒有這么嚴格的實時性要求，可以設置為yes，以便能夠盡可能快的釋放內存。

16.9 客戶端輸出緩存控制

下面的三種客戶端說明：

• normal：一般客戶端包含監控客戶端
• replica：副本客戶端（slave）
• pubsub：客戶端至少訂閱了一個pubsub通道或模式

客戶端輸出緩沖區限制指令語法：

client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>

一旦達到hard limit限制或者達到soft limit之后又過了soft seconds秒，那么客戶端會立即被斷開連接。

16.10 配置客戶端query buffer大小

每個Client都有一個query buffer(查詢緩存區或輸入緩存區), 它用于保存客戶端的發送命令。

客戶端query buffer大小不能超過該項配置的值。

16.11 Redis協議批量請求單個字符串限制

proto-max-bulk-len默認值是512mb。

16.2 執行任務頻率

redis會調用一個內部函數來執行許多后臺任務，比如在超時時關閉客戶端連接，清楚從未被請求過的過期key等。

redis會根據指定的hz值檢查要執行的任務。它范圍在1到500之間，但是不超過100。

大部分情況下應該使用缺省值10，只有在需要非常低延遲的環境中才應該將值提高到100。

16.3 動態任務執行頻率

根據客戶端連接的數量動態的調整hz的值。

當有更多的客戶端連接時，會臨時以hz設置基準提高該hz的值。默認開啟。

16.4 AOF重寫時執行fsync策略

當redis重寫AOF文件時，如果啟用了以下選項，則該文件將每生成32MB的數據進行fsync同步。

這對于以更增量的方式將文件提交到磁盤并避免較大的延遲峰值非常有用。

16.5 保存RDB文件時執行fsync策略

當redis保存RDB文件時，如果啟用以下選項，則每生成32 MB的數據，文件就會同步一次。

這對于以更增量的方式將文件提交到磁盤并避免較大的延遲峰值非常有用。

16.6 LFU設置

這兩個值的配置需要結合LUF算法，這里就不贅述了。

一般就使用默認值即可。

十七、碎片整理

• 默認情況下，此功能被禁用，并且僅當編譯redis以使用隨redis源代碼提供的emalloc副本時。

  此功能才有效。這是Linux版本的默認設置。

• 如果沒有碎片問題，則無需啟用此功能。

• 一旦遇到內存碎片，可以在需要時使用命令CONFIG SET activedefrag yes啟用此功能。

• 配置參數能夠微調碎片整理過程的行為。如果你不確定它們是什么意思，最好不要改變默認值

17.1 開啟活動碎片整理

activedefrag no

17.2 啟動活動碎片整理的最小內存碎片閾值

active-defrag-ignore-bytes 100mb

17.3 啟動活動碎片整理的最小內存碎片百分比

active-defrag-threshold-lower 10

17.4 嘗試釋放的最大百分比

active-defrag-threshold-upper 100

17.5 最少CPU使用率

active-defrag-cycle-min 1

17.6 最大CPU使用率

active-defrag-cycle-max 25

17.7 最大掃描量

# Maximum number of set/hash/zset/list fields that will be processed from
# the main dictionary scan
active-defrag-max-scan-fields 1000

17.8 是否使用后臺線程

jemalloc-bg-thread yes

activedefrag yes`啟用此功能。

• 配置參數能夠微調碎片整理過程的行為。如果你不確定它們是什么意思，最好不要改變默認值

17.1 開啟活動碎片整理

activedefrag no

17.2 啟動活動碎片整理的最小內存碎片閾值

active-defrag-ignore-bytes 100mb

17.3 啟動活動碎片整理的最小內存碎片百分比

active-defrag-threshold-lower 10

17.4 嘗試釋放的最大百分比

active-defrag-threshold-upper 100

17.5 最少CPU使用率

active-defrag-cycle-min 1

17.6 最大CPU使用率

active-defrag-cycle-max 25

17.7 最大掃描量

# Maximum number of set/hash/zset/list fields that will be processed from
# the main dictionary scan
active-defrag-max-scan-fields 1000

17.8 是否使用后臺線程

jemalloc-bg-thread yes