Redis 5.0.4配置文件redis.conf全文解讀

   Redis解壓完畢可見目錄下的redis.conf,在安裝之後生成自啓動腳本就有步驟是複製該配置文件到/etc/redis/目錄下,話不多說,看看去:

1.頭部說明

  頭部內容說明:注意單位問題,當需要設置內存大小的時候,可使用類似1k、5GB、4M這樣的常見格式,單位不區分大小寫,1GB 1Gb 1gB的寫法是完全一樣的。

2.INCLUDES

  一般情況下只有一個配置文件,但若對所有的Redis服務器有通用版配置文件的基礎上,又對每個服務器有個性化配置需求,就可以通過include /path/to/local.conf參數配置多個配置文件。

  注意:“inclue”選項不能被admin或Redis哨兵的“CONFIG REWRITE”命令重寫,因爲Redis總是使用最後解析的配置行作爲配置指令的值,最好在redis.conf 開頭配置includes來避免它在運行時被覆寫;相反,若要以include的配置爲主,那麼需要將 include 配置寫在 redis.conf 文件的末尾。

3.MODULES

  Redis 4.0起引入Module自定義模塊開發功能,loadmodule參數引入自定義模塊。

4.NETWORK

  Network涉及的參數:

  • bind:配置一個或多個 ip地址來實現監聽一個或多個網絡接口;默認值127.0.0.1,即只允許本地客戶端連接,不可遠程連接;如果bind值爲空,則Redis監聽服務器上所有可用網絡接口的連接。
  • protected-mode:redis3.2版本後新增的配置項,默認爲yes,需配置bind ip或者設置訪問密碼來實現連接redis服務,值爲no時,外部網絡可以直接訪問。
  • port:Redis運行端口,默認值6379,如果端口設置爲0,Redis就不會監聽TCP套接字,單機開啓多個Redis服務進程時該值就需有差異。
  • tcp-backlog:在高併發環境下需要一個高backlog值來避免客戶端慢連接問題,默認值511,注意Linux內核默默地將這個值減小到/proc/sys/net/core/somaxconn的值,所以需要確認增大somaxconn和tcp_max_syn_backlog兩個值來達到想要的效果。
  • unixsocket、unixsocketperm:指定用來監聽Unix socket的路徑,沒有默認值, 所以在沒有指定的情況下Redis不會監聽Unix socket。
  • timeout:設置客戶端空閒多少秒後關閉連接,單位爲秒,默認0,(0代表禁用,永不關閉)。
  • tcp-keepalive:定時通過SO_KEEPALIVE向客戶端發送ACK檢測客戶端是否存活,該值是發送ACK的時間間隔,單位爲秒,Redis 3.2.1.起官方建議值300s,如果爲0,則不會定期檢測,timeout和tcp-keepalive都可用來清理失效的連接。

5.GENERAL

  GENERAL涉及的參數:

  • daemonize:Redis默認不作爲守護進程來運行的,可以把這個設置爲"yes"讓它作爲守護進程來運行,注意,當作爲守護進程的時候,Redis會把進程ID寫到 /var/run/redis.pid。
  • supervised:通過upstart和systemd管理Redis守護進程,這些supervision方法僅表示“process is ready”。
  • pidfile:配置PID文件路徑,當redis作爲守護進程運行的時候,會把pid寫進指定路徑文件中。
  • loglevel:設置日誌級別,默認notice,可選值如下:

debug(很多信息,對開發/測試有用)
verbose(很多精簡的有用信息,但是不像debug等級那麼多)
notice(適量的信息,基本上是生產環境中需要的程度
warning(只有很重要/嚴重的信息會記錄下來)

  • logfile:定義日誌名稱,空值表示強制輸出到命令行終端窗口上,注意:如果Redis以守護進程方式運行,而設置日誌爲標準輸出的話,那麼日誌會發送到 /dev/null。
  • syslog-enabled: 要使用系統日誌記錄器很簡單,只要設置 “syslog-enabled” 爲 “yes” 就可以了, 然後根據需要設置其他一些syslog參數就可以了。
  • syslog-ident:指定syslog身份,默認爲redis。
  • syslog-facility:指定syslog的設備,必須是一個用戶或者是 LOCAL0 ~ LOCAL7 之一。
  • databases:設置數據庫個數,默認數據庫是 DB 0,可以通過SELECT WHERE dbid(0~## ‘databases’ - 1)來爲每個連接使用不同的數據庫。
  • always-show-logo:yes
今天的不高興
和昨天的不高興
大有區別
如果昨天你問我
爲什麼不高興
我會滔滔不絕跟你說上半天
而今天
你最好別問我

6.SNAPSHOTTING

  SNAPSHOTTING涉及的參數:

  • save: 指定觸發 Redis的持久化條件,即指定秒數和數據變化次數之後把數據庫寫到磁盤上。

   下面的例子將會進行把數據寫入磁盤的操作:save 900 1 #900秒內如果超過1個key被修改,則發起數據快照保存。
  注意:不需要持久化數據時把所有"save"配置註釋即可,也可通過添加一條帶空字符串參數的save指令來移除之前所有配置的save指令。

  • stop-writes-on-bgsave-error:默認爲yes,如果開啓RDB快照(至少一條save指令)並且最新的後臺保存失敗,Redis將會停止接受寫操作,這將提醒用戶數據沒有正確的持久化到硬盤,否則可能沒人注意到故障發生。如果後臺保存進程重啓,Redis將自動允許寫操作。且如果已經部署了適當的Redis服務器和持久化的監控,可關掉這個功能以便於即使是硬盤,權限等出問題了Redis也能夠像平時一樣正常工作,
  • rdbcompression:當導出到 .rdb 數據庫時是否用LZF壓縮字符串對象,默認設置爲 “yes”,所以幾乎總是生效的,如果想節省CPU的話可以把這個設置爲 “no”,但是如果有可壓縮的key的話,那數據文件就會更大了。
  • rdbchecksum:因爲版本5的RDB有一個CRC64算法的校驗在文末,這使文件格式更可靠,但在生產和加載RDB文件時,有性能消耗的代價(大約10%),所以可以關掉它來獲取性能最優化;另外,在禁用校驗和的情況下創建的RDB文件的校驗和爲零,它將跳過檢查加載代碼。
  • dbfilename:定義持久化數據庫的文件名。
  • dir: 定義數據持久化路徑。

7.REPLICATION

  REPLICATION涉及的參數:

  • replicaof :主從同步參數,通過 slaveof 配置來實現Redis實例的備份,用於本機Redis作爲slave去連接主Redis
  • masterauth :如果master設置了密碼(通過下面的 “requirepass” 選項來配置),那麼slave在開始同步之前必須進行身份驗證,否則它的同步請求會被拒絕。
  • replica-serve-stale-data:當一個slave與master的連接斷開,或者同步正在進行中,slave的行爲有兩種可能:

   如果 slave-serve-stale-data 設置爲 “yes” (默認值),slave會繼續響應客戶端請求,可能是正常數據,也可能是還沒獲得值的空數據。
   如果 slave-serve-stale-data 設置爲 “no”,slave會回覆"正在從master同步(SYNC with master in progress)"來處理各種請求,除了 INFO 和 SLAVEOF 命令。

  • replica-read-only:一般slave爲只讀庫,該參數配置salve實例是否接受寫操作,可寫的slave實例可能對存儲臨時數據比較有用 (因爲寫入salve的數據在同master同步之後將很容被刪除),但是如果客戶端由於配置錯誤在寫入時也可能產生一些問題。
  • repl-diskless-sync:DISKLESS REPLICATION目前是實驗性功能,該參數定義主從數據複製是否使用無硬盤複製功能,默認值爲no。

   sk-backed:Redis master 節點創建一個新的進程將 RDB 文件寫入磁盤,然後文件通過父進程傳輸給replicas 節點。
    Diskless:Redis master 節點創建一個新的進程直接將 RDB 文件寫入到 replica 的 socket 中,不寫入磁盤。

  • repl-diskless-sync-delay:啓用無硬盤複製時,一旦傳輸開始,後續新的replicas就得排隊等待,所以master節點會在這個delay時間之後再傳輸以期望會有多個replicas連接進來,再同時同步到多個replicas節點,這個時間以秒爲單位,默認爲5秒,要關掉這一功能,只需將它設置爲0秒,傳送會立即啓動。
  • repl-ping-replica-period:slave根據指定的時間間隔向服務器發送ping請求,默認10秒。
  • repl-timeout: 以下選項爲設置同步的超時時間:
    1)從replicas角度來看,在與master SYNC期間有大容量數據傳輸造成超時;
    2)從replicas角度來看,master超時,如data、ping等;
    3)在master角度來看,replicas超時,如REPLCONF ACK pings。

  確保這個值大於指定的repl-ping-slave-period,否則在主從間低業務量時每次都會檢測到超時.

  • repl-disable-tcp-nodelay:是否在replicas套接字發送SYNC之後禁用 TCP_NODELAY ,如果選擇“yes”,Redis將使用更少的TCP包和帶寬來向replicas發送數據,但是這將使數據傳輸到replicas上有延遲,Linux內核的默認配置會達到40毫秒;如果選擇了 “no”, 數據傳輸到replicas的延遲將會減少但要使用更多的帶寬,默認會爲低延遲做優化,但高負載情況或主從之間的跳數過多時,“yes”是個不錯的選擇,默認值no。
  • repl-backlog-size:設置數據複製backlog緩衝大小,backlog記錄replicas斷開連接期間產生的數據,當replicas重新連接時,無需做全量同步,增量同步斷開期間replicas丟失的數據即可;同步的backlog越大,replicas 能夠進行增量同步並且允許斷開連接的時間就越長,backlog在至少有一個replicas連接的情況下master纔會創建。
  • repl-backlog-ttl:當master在一段時間內不再與任何replicas連接,backlog將會釋放;該參數配置了從最後一個replicas斷開多少秒後,backlog緩衝將會釋放,0表示永不釋放backlog。

注意:replicas節點永遠都不會釋放這個backlog緩衝區,因爲它有可能升級到master節點, 要力保能夠與新從節點實現 “增量同步”。

  • replica-priority:通過Redis的Info輸出的replicas節點信息(整數值),當master運行故障時,Redis Sentinel根據該配置值來選擇一個replicas提升爲master。優先級數字小的replicas會優先考慮提升爲master,如有3個 replicas節點priority 值分別爲 10,100,25,Sentinel 會選擇 priority爲10的節點提升爲master,0作爲一個特殊的優先級,標識這個replicas不能作爲master,默認優先級爲100。
  • min-replicas-to-write 3、min-replicas-max-lag 10:該配置表示可用的replicas少於3個、延遲超過10秒就禁止寫操作,當至少有 N個replicas節點延遲少於M秒時,master才接受寫操作,N個replicas需要是“oneline”狀態,延時是以秒爲單位,並且必須小於等於指定值,是從最後一個從replicas接收到的ping(通常每秒發送)開始計數;將上面參數的任意一個設置爲 0 表示不啓用此功能,min-replicas-to-write的默認值爲0,min-replicas-max-lag的默認值爲10。
  • replica-announce-ip 5.5.5.5、replica-announce-port 1234:Redis master可以通過不同方式列出連接過來的replicas節點的地址和端口。 如: Redis Sentinel 等會使用 “INFO replication” 命令來獲取 replica 實例信息,master 的 “ROLE”命令也會提供此信息。

  replica節點IP/Port信息:
  IP:通過自動識別replica連接master的Socket 的信息中自動獲取;
  Port:與master連接的端口,也是 replicas節點用來監聽其他客戶端的連接。
  注意:若啓用了端口轉發或者 NAT,可能需要其他IP和Port才能連接到replicas節點。 這種情況下,需要設置這兩個選項,這樣 replicas 就會用這兩個選項設置的值覆蓋默認行爲獲取的值,然後報告給 master節點。 根據實際情況,可以只設置其中某個選項,而不用兩個選項都設置。

8.SECURITY

  SECURITY涉及的參數:

  • requirepass:該參數要求客戶端在處理任何命令時都要通過AUTH 驗證身份,這個功能在限制不被信任的其它客戶端連接時很實用,爲了向後兼容的話,這段應該註釋掉,而且大多數時候不需要身份驗證(例如:它們運行在自己的服務器上。)

  警告:由於Redis太快了,所以居心不良的人可以嘗試超過每秒150k個密碼來試圖破解連接。這意味着需要一個設置高強度的密碼,否則破解太容易了。

  • rename-command:在共享環境下,可以爲危險命令進行重命名規避風險,比如,爲 CONFIG 改個其他不太容易猜到的名字,例如:rename-command ONFIG b840fc02d524045429941cc15f59e41cb7be6c52,甚至也可以通過給命令賦值一個空字符串來完全禁用這條命令。

9.CLIENTS

  CLIENTS涉及的參數:

  • maxclients:設置客戶端最大併發連接數,默認10000,由於redis不區分連接是客戶端連接還是內部打開文件或者和replicas連接等,那麼最大的客戶端連接數就被設置成當前文件限制數減32(因爲Redis服務器保留了一些文件描述符作爲內部使用),所以該參數最低值32,一旦併發數達到設定值,Redis會關閉所有新連接併發送錯誤’max number of clients reached’。

10.MEMORY MANAGEMENT

  MEMORY MANAGEMENT涉及的參數:

  • maxmemory:Redis配置的最大內存,當內存滿了,會根據maxmemory-policy策略進行數據處理,如果因爲刪除策略Redis無法刪除key,或者策略設置爲 “noeviction”,Redis會回覆需要更多內存的錯誤信息給命令。例如,SET,LPUSH等等,但是會繼續響應像Get這樣的只讀命令。

  警告:master爲同步replicas的輸出緩衝區所需內存不計算在使用內存中,如果需要附加多個replicas,建議設置一個稍小的maxmemory,這樣系統就會有空閒的內存作爲replicas的輸出緩存區(但是如果最大內存策略設置爲"noeviction"的話就沒必要了)。

  • maxmemory-policy:最大內存策略:如果達到內存限制了,Redis如何刪除key,可以在下面五個策略裏面選:

volatile-lru -> 根據LRU算法生成的過期時間來刪除。
allkeys-lru -> 根據LRU算法刪除任何key。
volatile-random -> 根據過期設置來隨機刪除key。
allkeys->random -> 無差別隨機刪。
volatile-ttl -> 根據最近過期時間來刪除(輔以TTL)
noeviction -> 誰也不刪,直接在寫操作時返回錯誤。
  注意:對所有策略來說,如果Redis找不到合適的可以刪除的key都會在寫操作時返回一個錯誤。
  目前涉及的命令:set setnx setex append incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd sinter sinterstore union sunionstore sdiff sdiffstore zadd zincrby zunionstore interstore hset hsetnx hmset hincrby incrby decrby getset mset msetnx exec sort

  • maxmemory-samples:LRU, LFU and minimal TTL算法都不是很精確,二是近似算法(爲了節省內存),因此可以調整它的速度或精度;例如:默認Redis會檢查5個key然後取最近最少使用的那個。

  可以通過maxmemory-samples進行設置樣本數,默認值5是比較合適的值,10非常接近真實的LRU,但消耗更多的CPU,3更快,但不太準確。

  • replica-ignore-maxmemory:是否開啓replica的最大內存

不愛那麼多,只愛一點點,別人眉來又眼去,我只偷看你一眼。 ——李敖

11.LAZY FREEING

  Redis 有兩種原語刪除keys:一種是用DEL命令對object的阻塞(同步)刪除, 同步刪除意味着刪除過程中服務端會停止處理新命令,以便以同步方式回收與object關聯的所有內存; 如果刪除的 key 與一個小的 object 相關聯,則執行DEL命令所需的時間非常短,與Redis中的大多數其他O(1)或O(log_N)命令相當; 若要刪除的 key 管理了一個很大的 object,但是,如果key與包含數百萬個元素的聚合值關聯,則服務器可以阻塞很長時間(甚至幾秒鐘)以完成操作。

  基於上述原因,Redis還提供了UNLINK(非阻塞DEL)等非阻塞刪除原語以及FLUSHALL和FLUSHDB命令的異步選項,以便在後臺回收內存;這些命令在固定時間內執行,另一個線程將儘可能快的從後臺儘快回收內存。

  DEL,UNLINK 以及用於FLUSHALL和FLUSHDB的 ASYNC 選項由用戶控制。 這取決於應用程序的設計,用戶可以按需選擇使用阻塞或者非阻塞的方式;然而因爲其他操作的副作用,Redis服務器有時不得不刪除keys或flush整個數據庫,具體來說,Redis在以下場景中獨立於用戶調用刪除對象:

  1)在逐出時:由於maxmemory和maxmemory策略配置,爲了在不超過指定內存限制的情況下爲新數據騰出空間;
  2)因爲數據過期配置:必須從內存中刪除具有相關生存時間的key(參閱expire命令);
  3)因爲命令的副作用,該命令將數據存儲在ma已經存在的key上,例如,RENAME命令會刪除舊的key內容當它被另一個key內容替換時,類似地,SUNIONSTORE或SORT with STORE選項會刪除現有key,SET命令本身刪除指定鍵的任何舊內容,以便用指定字符串替換它;
  4)在複製過程中,當replica與其主服務器執行全量同步時,將刪除整個數據庫的內容以便加載剛剛傳輸過來的RDB文件。

  在上述所有情況下,默認情況是以阻塞的方式刪除對象,就像調用DEL一樣;但是,可以使用以下配置指令,具體配置每種情況,以非阻塞方式釋放內存,如調用UNLINK:

  • lazyfree-lazy-eviction:內存滿時逐出,默認值no;
  • lazyfree-lazy-expire:刪除過期key,默認值no;
  • lazyfree-lazy-server-del:內部刪除,比如rename oldkey newkey時,如果newkey存在需要刪除newkey,默認值no;
  • replica-lazy-flush:接收完RDB文件後清空數據選項,默認值no。

12.APPEND ONLY MODE

  默認情況下,Redis在磁盤上異步轉儲數據集,這種模式在許多應用程序中已經足夠好了,但是Redis進程的問題或斷電可能會導致幾分鐘的寫操作丟失(取決於配置的保存點)。

  Append Only File是一種更好的持久化方式,例如,使用默認的數據fsync策略(請參閱配置文件的後面部分),Redis在斷電等意外情況只會丟失最多一秒的寫入數據,在系統正常運行而 Redis 進程出錯(如崩潰)的情況下只會丟掉最近一次寫操作。

  可以同時啓用AOF和RDB持久化方案,而不會出現問題。如果啓用了AOF,Redis將在啓動階段自動加載AOF文件,該方式提供更好的持久化保證,更多詳情可參閱http://redis.io/topics/persistence。

  APPEND ONLY MODE涉及的參數如下:

  • appendonly:是否開啓AOF,默認no;
  • appendfilename:定義AOF文件名,默認爲"appendonly.aof";
  • appendfsync:數據同步模式,默認值是“everysec”,是在速度和數據安全的兩者尋求平衡的折中模式。

  fsync()調用告訴操作系統將數據寫入磁盤而不是等更多的數據進入輸出緩衝區,某些操作系統會真的馬上flush數據到磁盤上,而某些操作系統將嘗試儘快這樣做,Redis支持三種不同的模式:

no:不調用fsync,讓操作系統決定什麼時候寫數據到磁盤,比較快;
always:每次對append only log寫入後進行fsync,速度慢,但是最安全。
everysec:每秒鐘只同步一次,比較折中的模式,如果不確定,使用“everysec”。

  • no-appendfsync-on-rewrite:如果對延遲要求很高的應用,這個字段可以設置爲yes,否則還是設置爲no,從持久化的角度來看,這是最安全的選擇;設置爲yes表示rewrite期間對新寫操作不fsync,暫時存在內存中,等rewrite完成後再寫入,默認爲no,建議yes。

  當AOF fsync策略設置爲always或everysec,並且後臺保存進程(後臺保存或AOF日誌後臺重寫)正在對磁盤執行大量I/O時,在某些Linux配置中,Redis可能會在fsync()調用上阻塞太長時間。請注意,目前還沒有對此進行修復,因爲即使在不同的線程中執行fsync,也會阻止同步寫入調用。爲了緩解這個問題,可以使用該選項,防止在BGSAVE或bgrowriteaof正在進行時在主進程中調用fsync()。這意味着當另一個子進程在保存時,Redis的持久性是與“appendfsync none”相同。實際上,這意味着在最壞的情況下(使用默認的Linux設置),可能會丟失長達30秒的日誌。

  • auto-aof-rewrite-percentage 100、auto-aof-rewrite-min-size 64mb:AOF自動重寫配置,默認值爲100;設置允許重寫的最小AOF文件大小,避免了達到約定百分比但尺寸仍然很小的情況還要重寫。

  自動重寫AOF文件,如果AOF日誌文件增大到指定百分比,Redis能夠通過BGREWRITEAOF自動重寫AOF日誌文件。

  工作原理:Redis記住上次重寫時AOF文件的大小(如果重啓後還沒有重寫操作,就直接用啓動時的AOF大小)比較基礎大小與當前大小,如果當前大小超過基礎大小的比例達到指定百分比,就會觸發重寫操作,指定百分比爲0會禁用AOF自動重寫特性。

  • aof-load-truncated:Redis在以AOF方式恢復數據時,對最後一條可能出問題的指令的處理方式,默認值yes。

  在Redis啓動過程中,當AOF數據被加載回內存時,可能會發現AOF文件在末尾被截斷,這可能是因爲Redis運行的系統宕機了,特別是當ext4文件系統沒有在data=ordered選項的情況下掛載時(但是,當Redis本身崩潰或中止但操作系統仍然正常工作時,這種情況不會發生)。
  Redis可以在發生這種情況時終止進程,或者加載AOF文件中儘可能多的數據(目前的默認值),如果發現AOF文件在結尾處被截斷,則可以啓動。以下選項控制此行爲。

yes:則加載截斷的AOF文件,Redis服務器開始發出日誌來通知用戶事件;否則,如果將該選項設置爲“no”,服務器將因錯誤而中止並拒絕啓動。
no:用戶需要在重新啓動服務器之前使用“redis check AOF”實用程序修復AOF文件。請注意,如果在中間發現AOF文件已損壞,則服務端因錯誤終止進程並拒絕啓動,此選項僅適用於Redis試圖從AOF文件讀取更多數據但找不到足夠字節的情況。

  • aof-use-rdb-preamble:當重寫AOF文件時,Redis能夠在AOF文件中使用RDB前導碼,以便更快地重寫和恢復,啓用此選項時,重寫的AOF文件由兩個不同的節組成:[RDB file][AOF tail],當加載AOF文件時,Redis通過以 “REDIS” 字符串開頭的 AOF 文件識別出此文件是由RDB和AOF組合而成的,Redis會先加載 RDB 部分,然後再加載AOF部分,默認值yes。

13.LUA SCRIPTING

  lua-time-limit:Lua腳本的最長執行時間(毫秒),默認5000ms,如果達到最大執行時間,Redis將記錄腳本在允許的最大時間之後仍在執行中,並返回錯誤信息。當長時間運行的腳本超過最大執行時間時,只有腳本KILL和SHUTDOWN NOSAVE命令可用,KILL用於停止尚未調用write命令的腳本;SHUTDOWN NOSAVE在腳本已經發出寫命令但用戶不希望等待腳本自然終止的情況下關閉服務器的唯一方法。該參數爲0或負值,以便在沒有警告的情況下無限執行。

14.REDIS CLUSTER

  REDIS CLUSTER涉及的參數:

  • cluster-enabled:開啓redis集羣,默認no。
  • cluster-config-file:指定Redis集羣配置文件名,每個羣集節點都有一個羣集配置文件,持久化保存集羣的信息,它由Redis節點自動創建和更新,確保同一系統中運行的各Redis實例該配置文件不要重名,默認文件名nodes-6379.conf。
  • cluster-node-timeout:集羣節點連接超時設置(單位:毫秒),默認15000。
  • cluster-replica-validity-factor: 集羣replica有效因子,默認配置值爲10,如果該項設置爲0,不管replica節點和Master節點間失聯多久都會一直嘗試failover。

  在進行故障轉移的時候,所有的replica節點都會請求申請爲master,但是有些replica節點可能與master斷開連接一段時間了, 導致數據過於陳舊,這樣的replica節點不應該被提升爲master,該參數就是用來判斷replica節點與master斷開連接的時間是否過長。

判斷方法是:比較replica節點斷開連接的時間與(node-timeout * slave-validity-factor) + repl-ping-slave-period ,如果replica節點超時時間爲30秒,並且slave-validity-factor爲10,假設默認的repl-ping-slave-period是10秒,即如果超過310秒replica節點將不會嘗試進行故障轉移。
較大的slave-validity-factor值可能允許包含過舊數據的replica節點成爲master,同時較小的值可能會阻止集羣選舉出新master。爲了達到最大限度的高可用性,可以設置爲0,即replica節點不管和master失聯多久都可以提升爲master。

  • cluster-migration-barrier:通常反映集羣中每個master節點所需的replicas節點數量,master的replica數量大於該給定值,replica才能提升爲master,如這個參數若被設爲2,那麼只有當一個master節點擁有2個可工作的從節點時,它的一個從節點纔會嘗試提升,默認爲1(即該集羣至少有3個節點,1 master+2 replicas,master宕機,仍有另外1個replica的情況下其中1個replica可以提升),測試環境可設置爲0,生成環境中至少設置爲1。
  • cluster-require-full-coverage:默認情況下,如果Redis集羣節點檢測到至少有一個hash slot不可用(沒有可用的節點爲其提供服務),集羣將停止查詢數據。這樣,如果集羣部分關閉(例如不再覆蓋一系列散列槽),那麼所有集羣最終都將不可用,如果所有slot恢復則集羣自動恢復。如果需要集羣部分可用情況下仍可提供查詢服務,設置爲no。

注意:不建議打開該配置,這樣會造成分區的時候,小分區的master一直在接受寫請求,會造成很長時間數據不一致。

  • cluster-replica-no-failover:選項設置爲yes時,會阻止replicas嘗試對其master在主故障期間進行failover,但是強制情況下,master仍然可以執行手動故障轉移。這在類似多個數據中心操作的情況下適用,比如在整個DC故障的情況下不希望其中一方被提升。

15.CLUSTER DOCKER/NAT support

  在某些部署中,Redis集羣節點地址發現失敗,因爲地址是NAT-ted或端口是轉發的(典型的情況是Docker和其他容器),爲了使Redis集羣在這樣的環境中工作,需要一個靜態配置,其中每個節點都知道其公共地址。

  默認情況下,Redis會自動檢測自己的IP和從配置中獲取綁定的PORT,告訴客戶端或者是其他節點。而在Docker環境中,如果使用的不是host網絡模式,在容器內部的IP和PORT都是隔離的,那麼客戶端和其他節點無法通過節點公佈的IP和PORT建立連接。如果開啓以下配置,Redis節點會將配置中的這些IP和PORT告知客戶端或其他節點,而這些IP和PORT是通過Docker轉發到容器內的臨時IP和PORT的。

例如:

  • cluster-announce-ip 10.1.1.5
  • cluster-announce-port 6379
  • cluster-announce-bus-port 6380

16.SLOW LOG

  Redis Slow Log存於內存中,記錄超過指定執行時間的命令,執行時間不包括與client連接、發送應答等I/O操作,而只是實際執行命令所需的時間(這是命令執行的唯一階段,線程被阻塞,不能同時服務於其他請求)。

  • slowlog-log-slower-than 10000:執行時間超過該值時記錄到慢日誌中,單位是微妙,注意,負數將禁用慢日誌,而值爲0將強制記錄每個命令;
  • slowlog-max-len 128:慢查詢日誌長度,當一個新的命令被寫進日誌的時候,最舊的那個記錄會被刪掉,這個長度沒有限制,只是要注意它會消耗內存,可以使用slow log RESET回收慢日誌使用的內存。

17.LATENCY MONITOR

  latency-monitor-threshold 0:延遲監控功能是用來監控Redis中執行比較緩慢的一些操作,用LATENCY打印Redis實例在跑命令時的耗時圖表,只記錄大於等於延遲監視器閾值設置的值的操作,Redis延遲監視子系統在運行時對不同的操作進行採樣,以便收集與Redis實例的可能延遲源相關的數據。

  默認情況下,延遲監視是禁用的,可以通過“CONFIG SET Latency monitor threshold”輕鬆啓用延遲監視,因爲如果沒有延遲問題,則通常不需要它,而且收集數據會對性能產生影響,雖然影響很小,但可以在大負載下測量。

18.EVENT NOTIFICATION

  notify-keyspace-events “”:鍵空間通知使得客戶端可以通過訂閱頻道或模式,來接收那些以某種方式改動了 Redis 數據集的事件。因爲開啓鍵空間通知功能需要消耗一些 CPU ,所以在默認配置下,該功能處於關閉狀態。

  例如,如果啓用了keyspace事件通知,並且客戶端對存儲在數據庫0中的鍵“foo”執行DEL操作,則將通過Pub/Sub發佈兩條消息:
PUBLISH keyspace@0:foo del
PUBLISH keyevent@0:del foo
可以在一組類中選擇Redis將通知的事件,每個類都由一個字符標識:
K:鍵空間事件,以“Keyspace@”前綴發佈。
E: Keyevent事件,以“Keyevent@”前綴發佈。
g:通用命令(非特定類型),如DEL、EXPIRE、RENAME…
$:String命令
l:列出命令
S:集合命令
h:哈希命令
z:排序集合命令
x:過期事件(每次密鑰過期時生成的事件)
e:退出事件(爲maxmemory退出密鑰時生成的事件)
A:g$lshzxe的別名,因此“AKE”字符串表示所有事件。

“notify keyspace events”將零個或多個字符組成的字符串作爲參數,空字符串表示通知被禁用。
示例:要啓用列表和泛型事件,請從事件名稱的角度使用:
notify-keyspace-events Elg

19.ADVANCED CONFIG

  當哈希有少量的條目,並且最大的條目不超過給定的閾值時,使用內存高效的數據結構對其進行編碼,可以使用以下指令配置這些閾值:

  • hash-max-ziplist-entries 512、hash-max-ziplist-value 64:當哈希類型元素個數小於hash-max-ziplist-entries配置(默認512個)同時所有值都小於hash-max-ziplist-value配置(默認64個字節)時,Redis會使用ziplist作爲哈希的內部實現。即表示當hash項(field,value)數>512即ziplist項>1024的時候轉爲dict,表示當hash中的value長度超過64的時候轉爲dict。
  • list-max-ziplist-size -2:列表也以一種特殊的方式進行編碼,以保存空間每個內部列表節點允許的條目數可以指定爲固定的最大大小或最大元素數。

  當取正值的時候,表示按照數據項個數來限定每個quicklist節點上的ziplist長度,比如,當這個參數配置成5的時候,表示每個quicklist節點的ziplist最多包含5個數據項。

  當取負值的時候,表示按照佔用字節數來限定每個quicklist節點上的ziplist長度,這時,它只能取-1到-5這五個值,每個值含義如下:
*-5: 每個quicklist節點上的ziplist大小不能超過64 Kb;(注:1kb => 1024 bytes)
-4: 每個quicklist節點上的ziplist大小不能超過32 Kb;
-3: 每個quicklist節點上的ziplist大小不能超過16 Kb;
-2: 每個quicklist節點上的ziplist大小不能超過8 Kb;(-2是Redis給出的默認值)
-1: 每個quicklist節點上的ziplist大小不能超過4 Kb。
正數意味着每一個列表節點存儲的元素數量要精確到這個數量,最高性能的選項通常是-2(8kb大小)或-1(4kb大小)。

  • list-compress-depth 0:這個參數表示一個quicklist兩端不被壓縮的節點個數,這裏的節點個數是指quicklist雙向鏈表的節點個數,而不是指ziplist裏面的數據項個數。實際上,一個quicklist節點上的ziplist,如果被壓縮,就是整體被壓縮的。
    參數list-compress-depth的取值含義如下:
    0: 是個特殊值,表示都不壓縮,這是Redis的默認值。
    1: 表示quicklist兩端各有1個節點不壓縮,中間的節點壓縮。
    2: 表示quicklist兩端各有2個節點不壓縮,中間的節點壓縮。
    3: 表示quicklist兩端各有3個節點不壓縮,中間的節點壓縮。
    依此類推…由於0是個特殊值,很容易看出quicklist的頭節點和尾節點總是不被壓縮的,以便於在表的兩端進行快速存取。
  • set-max-intset-entries 512:集合只有一種特殊的編碼方式:當集合被組合時剛好是十進制64位有符號整形數字的字符串,以下配置設置set集大小的限制,以便使用此特殊的內存保存編碼。
  • zset-max-ziplist-entries 128、zset-max-ziplist-value 64:與hash和list類似,經過排序的集也經過特殊編碼,有序集合也可以用一種特別的編碼方式來節省大量空間,這種編碼只適合長度和元素都小於改參數限制的有序集合。
  • hll-sparse-max-bytes 3000:HyperLogLog稀疏數據結構表示字節數限制,限制包括16字節的頭,小於等於hll-sparse-max-bytes使用稀疏數據結構(sparse),大於hll-sparse-max-bytes使用稠密的數據結構(dense);大於16000的值是完全無用的,因爲在這一點上,密集表示更節省內存,建議值爲~3000,以便具有的內存好處, 減少內存的消耗。如果不考慮CPU,但空間要求較高,並且數據集由許多基數在0-15000範圍內的HyperLogLog組成,則該值可以提高到~10000。
  • stream-node-max-bytes 4096、stream-node-max-entries 100:Streams宏節點最大大小/項,流數據結構是對內部多個項進行編碼的大節點的基樹。使用此配置,可以配置單個節點的大小(字節),以及在附加新流條目時切換到新節點之前可能包含的最大項目數。如果將以下任何設置設置爲0,則會忽略該限制,因此,例如,可以通過將max bytes設置爲0,將max entries設置爲所需值,從而僅設置max entires限制。
  • activerehashing yes:Redis將在每100毫秒時使用1毫秒的CPU時間來對redis的hash表進行重新hash,可以降低內存的使用。當實際使用場景中,有非常嚴格的實時性需要,不能夠接受Redis時不時的對請求有2毫秒的延遲的話,把這項配置爲no;如果沒有這麼嚴格的實時性要求,可以設置爲yes,以便能夠儘可能快的釋放內存。
  • client-output-buffer-limit normal 0 0 0:對客戶端輸出緩衝進行限制可以強迫那些不從服務器讀取數據的客戶端斷開連接,用來強制關閉傳輸緩慢的客戶端。對於normal client,第一個0表示取消hard limit,第二個0和第三個0表示取消soft limit,normal client默認取消限制,因爲如果沒有尋問,是不會接收數據的。
  • client-output-buffer-limit replica 256mb 64mb 60:對於slave client和MONITER client,如果client-output-buffer一旦超過256mb,又或者超過64mb持續60秒,那麼服務器就會立即斷開客戶端連接。
  • client-output-buffer-limit pubsub 32mb 8mb 60:對於pubsub client,如果client-output-buffer一旦超過32mb,又或者超過8mb持續60秒,那麼服務器就會立即斷開客戶端連接。
  • client-query-buffer-limit 1gb:客戶端查詢緩衝區累積新命令,默認情況下,它們被限制在一個固定的數量,以避免協議不同步導致客戶端查詢緩衝區中未綁定的內存使用量的錯誤。但是,如果有非常特殊的需求,比如巨大的multi/exec請求或類似的請求,可以在這裏配置它。
  • proto-max-bulk-len 512mb:在Redis協議中,批量請求(即表示單個字符串的元素)通常被限制爲512 MB。
  • hz 10:Redis調用一個內部函數來執行許多後臺任務,比如在超時時關閉客戶端的連接,清除從未請求過的過期key,等等。並非所有任務都以相同的頻率執行,但Redis會根據指定的“hz”值檢查要執行的任務。

  默認情況下,“hz”設置爲10;當Redis空閒時,提高這個值將使用更多的CPU,但同時當有許多key同時過期時,Redis將更具響應性,並且可以更精確地處理超時。範圍在1到500之間,但是值超過100通常不是一個好主意,大多數用戶應該使用默認值10,並且僅在需要非常低延遲的環境中才將此值提高到100。

  • dynamic-hz yes:開啓動態HZ,同時到期會使Redis的反應更靈敏,以及超時可以更精確地處理當啓用動態HZ時,當啓用動態HZ時,實際配置的HZ將用作作爲基線,但是一旦連接了更多的客戶機,實際上將根據需要使用配置的HZ值的倍數,這樣一個閒置的實例將佔用的CPU時間很少,而繁忙的實例響應更爲迅速。
  • aof-rewrite-incremental-fsync yes:當一個子對象重寫AOF文件時,如果啓用了該參數,則每生成32MB的數據就會對該文件進行fsync,這有利於把文件寫入磁盤,可以避免過大的延遲峯值。
  • rdb-save-incremental-fsync yes:當Redis保存RDB文件時,如果啓用該參數,每生成32MB數據,文件將被fsync-ed,以便以增量方式將文件提交到磁盤並避免大延遲峯值。
  • lfu-log-factor 10:概率因子,可以調整計數器counter的增長速度,lfu-log-factor越大,counter增長的越慢。
  • lfu-decay-time 1:衰減因子,是一個以分鐘爲單位的數值,可以調整counter的減少速度,lfu衰減時間的默認值爲1,特殊值爲0意味着每次掃描計數器時都會使其衰減。

20.ACTIVE DEFRAGMENTATION

  該部分功能還是試驗性的,但也是基於一定的stress測試和人工手動測試。

  活動碎片整理:活動(聯機)碎片整理允許Redis服務器壓縮內存中少量數據分配和釋放之間的剩餘空間,從而允許回收內存。碎片化是一個自然的過程,它發生在每個分配器和某些工作負載上,通常需要重新啓動服務器以降低碎片,或者至少刷新掉所有數據並重新創建它。但是,由於Oran Agra for Redis 4.0實現了這個特性,這個過程可以在服務器運行時以“hot”方式實施。
   基本上,當碎片超過某個級別(見下面的配置選項)時,Redis將開始通過利用某些特定的Jemalloc特性(爲了瞭解分配是否導致碎片並將其分配到更好的位置)在相鄰的內存區域中創建值的新副本,同時,將發佈舊的數據副本。對所有鍵遞增地重複此過程將導致碎片回落到正常值。
   需要了解的重要事項:此功能在默認情況下是禁用的,並且僅當編譯Redis使用Jemalloc的副本時才起作用,Jemalloc的源代碼是Redis這個是Linux版本的默認設置;如果沒有碎片問題,則不需要啓用此功能;一旦遇到碎片,可以在需要時使用命令“CONFIG SET activedefrag yes”啓用此功能。

  涉及的參數:

  • activedefrag yes:啓用主動碎片整理;
  • active-defrag-ignore-bytes 100mb:啓動活動碎片整理的最小碎片;
  • active-defrag-threshold-lower 10:啓動碎片整理的最小碎片百分比;
  • active-defrag-threshold-upper 100:使用最大消耗時的最大碎片百分比;
  • active-defrag-cycle-min 5:在CPU百分比中進行碎片整理的最小消耗;
  • active-defrag-cycle-max 75:磁盤碎片整理的最大消耗;
  • active-defrag-max-scan-fields 1000:將從主字典掃描處理的set/hash/zset/list字段的最大數目。

這配置文件……終於翻完了!!!太難了!!!轉載請標來處!!!眼睛都要碼瞎了,o(╥﹏╥)o

“你瞧,世界上就是有一千個我,這一千個我終還是抱着你!”—金庸

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章