Redis6.0配置文件翻譯(Google手動翻譯)

原文鏈接(一般情況下你打不開這個網頁)：https://raw.githubusercontent.com/redis/redis/6.0/redis.conf

Redis配置文件

請注意，爲了讀取配置文件，必須以文件路徑作爲第一個參數來啓動Redis：./redis-server /path/to/redis.conf

關於單位的注意事項：當需要內存大小時，可以指定 ＃以通常的1k 5GB 4M格式，依此類推：

1k => 1000 bytes
1kb => 1024 bytes
1m => 1000000 bytes
1mb => 1024*1024 bytes
1g => 1000000000 bytes
1gb => 1024*1024*1024 bytes
單位不區分大小寫，因此1GB 1Gb 1gB都相同。

---

--- INCLUDES

在此處包括一個或多個其他配置文件。如果您具有可用於所有Redis服務器的標準模板，但還需要自定義一些每臺服務器設置，則此功能很有用。包含文件可以包含其他文件，因此請明智地使用此文件。

注意，選項“ include”不會被admin或Redis Sentinel中的命令“ CONFIG REWRITE”重寫。由於Redis始終使用最後處理的行作爲配置指令的值，最好將包含在此文件的開頭，以避免在運行時覆蓋配置更改。

如果您有興趣使用include覆蓋配置選項，則最好使用include作爲最後一行。例如

include /path/to/local.conf
include /path/to/other.conf

 

--- MODULES

在啓動時加載模塊。 如果服務器無法加載模塊，它將中止。 可以使用多個loadmodule指令。

loadmodule /path/to/my_module.so
loadmodule /path/to/other_module.so

 

--- NETWORK

默認情況下，如果未指定“ bind”配置指令，則Redis偵聽來自服務器上所有可用網絡接口的連接。 可以使用“ bind”配置指令僅偵聽一個或多個所選接口，然後偵聽一個或多個IP地址。

# Examples:
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1 ::1

警告~~~如果運行Redis的計算機直接暴露在Internet上，則綁定到所有接口都是危險的，並且會將實例暴露給Internet上的每個人。因此，默認情況下，我們將取消註釋以下的bind指令，這將強制Redis僅偵聽IPv4環回接口地址（這意味着Redis將只能接受來自正在運行的同一臺計算機上運行的客戶端的連接）。

如果您確定要立即收聽所有界面，請註釋一下以下幾行。

bind 127.0.0.1

保護模式是安全保護的一層，以避免訪問和利用Internet上打開的Redis實例。

啓用保護模式時，如果：

• 服務器沒有使用“ bind”指令顯式綁定到一組地址。
• 未配置密碼。

服務器僅接受來自IPv4和IPv6回送地址127.0.0.1和::1以及來自Unix域套接字的客戶端的連接。

默認情況下啓用保護模式。僅當您確定您希望其他主機的客戶端連接到Redis時，即使未配置身份驗證，也不會使用“ bind”指令顯式列出一組特定的接口，才應禁用它。

protected-mode yes

接受指定端口上的連接，默認爲6379（IANA #815344）。 如果指定了端口0，則Redis將不會在TCP套接字上偵聽。

port 6379

 

TCP listen() backlog(積壓).

在每秒請求數很高的環境中，爲了避免客戶機連接速度慢的問題，您需要大量積壓訂單。請注意，Linux內核＃將以無提示的方式將其截斷爲 /proc/sys/net/core/somaxconn 的值，因此確保同時提高 somaxconn 和 tcp_max_syn_backlog 的值，以獲得所需的效果。

tcp-backlog 511

 

Unix socket(套接字).

指定用於偵聽傳入連接的Unix套接字的路徑。 沒有默認值，因此在未指定Redis時，Redis將不會在Unix套接字上偵聽。

 unixsocket /tmp/redis.sock
 unixsocketperm 700

客戶端空閒N秒後關閉連接（0禁用） 超時0

 

TCP keepalive.

如果不爲零，請在沒有通信的情況下使用SO_KEEPALIVE向客戶端發送TCP ACK。 這很有用，有兩個原因：

• 檢測死亡的同伴。
• 從中間的網絡設備的角度來看，使連接活着。

在Linux上，指定的值（以秒爲單位）是用於發送ACK的時間段。 注意，關閉連接需要兩倍的時間。 在其他內核上，期限取決於內核配置。

此選項的合理值爲300秒，這是從Redis 3.2.1開始的新Redis默認值。

tcp-keepalive 300

 

TLS/SSL

默認情況下，禁用TLS / SSL。 要啓用它，可以使用“ tls-port”配置指令來定義TLS偵聽端口。 要在默認端口上啓用TLS，請使用：

port 0
tls-port 6379

配置X.509證書和私鑰，以用於對連接的客戶端，主服務器或羣集對等服務器進行身份驗證。 這些文件應爲PEM格式。

tls-cert-file redis.crt 
 tls-key-file redis.key

配置DH參數文件以啓用Diffie-Hellman（DH:）密鑰交換：

 tls-dh-params-file redis.dh

配置CA證書捆綁包或目錄以對TLS / SSL客戶端和對等方進行身份驗證。 Redis需要其中至少一項的顯式配置，並且不會隱式使用系統範圍的配置。

tls-ca-cert-file ca.crt
tls-ca-cert-dir /etc/ssl/certs

默認情況下，TLS端口上的客戶端（包括副本服務器）是必需的 使用有效的客戶端證書進行身份驗證。

使用此僞指令可以禁用認證。

tls-auth-clients no

默認情況下，Redis副本不嘗試建立TLS連接 與它的master。

使用以下指令在複製鏈接上啓用TLS。

tls-replication yes

默認情況下，Redis Cluster總線使用純TCP連接。 要爲總線協議啓用TLS，請使用以下指令：

 tls-cluster yes

明確指定要支持的TLS版本。 允許的值不區分大小寫，包括“ TLSv1”，“ TLSv1.1”，“ TLSv1.2”，“ TLSv1.3”（OpenSSL> = 1.1.1）或任意組合。 要僅啓用TLSv1.2和TLSv1.3，請使用：

 tls-protocols "TLSv1.2 TLSv1.3"

配置允許的密碼。有關更多信息，請參見 ciphers(1ssl) 聯機幫助頁。 關於此字符串的語法。

注意：此配置僅適用於<= TLSv1.2。

tls-ciphers DEFAULT:!MEDIUM

配置允許的TLSv1.3密碼套件。 有關此字符串的語法（尤其是TLSv1.3密碼套件）的語法的更多信息，請參見ciphers（1ssl）聯機幫助頁。

tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256

選擇密碼時，請使用服務器的首選項而不是客戶端的首選項。 默認情況下，服務器遵循客戶端的首選項。

tls-prefer-server-ciphers yes

默認情況下，TLS會話緩存已啓用，以允許支持它的客戶端進行更快，更便宜的重新連接。 使用以下指令禁用緩存。

tls-session-caching no

更改默認的TLS會話緩存數。 零值會將緩存設置爲無限大小。 默認大小爲20480。

 tls-session-cache-size 5000

更改緩存的TLS會話的默認超時。默認超時爲300 秒。

tls-session-cache-timeout 60

 

GENERAL(一般)

默認情況下，Redis不會作爲守護程序運行。 如果需要，請使用“是”。 請注意，Redis守護進程將在/var/run/redis.pid中寫入一個pid文件。

daemonize no

如果從upstart或systemd運行Redis，Redis可以與您的supervision(管理者) tree進行交互。 選項：

• supervised no - no supervision interaction
• supervised upstart - 通過將Redis置於SIGSTOP模式發出信號upstart
• supervised systemd - 通過將 READY=1 寫入 $NOTIFY_SOCKET 來產生信號
• supervised auto - 根據UPSTART_JOB或NOTIFY_SOCKET環境變量檢測upstart 或systemd方法

注意：這些管理方式僅表示“過程已準備就緒”。 它們無法使您的管理者連續不斷地進行ping操作。

supervised no

如果指定了pid文件，則Redis會在啓動時將其寫入指定位置並在退出時將其刪除。

當服務器以非守護進程運行時，如果在配置中未指定任何pid文件，則不會創建。 守護服務器時，即使未指定，也會使用pid文件，默認爲“ /var/run/redis.pid”。

創建pid文件是最大的努力：如果Redis無法創建它，則不會發生任何不好的情況，服務器將正常啓動並運行。

pidfile /var/run/redis_6379.pid

 

指定服務器詳細級別。

這可以是以下之一：

• debug 很多信息，對於開發/測試很有用
• verbose 許多很少有用的信息，但不會像調試級別那樣混亂
• notice 中等冗長，您可能想在生產中使用
• warning 僅記錄非常重要/重要的消息

loglevel notice

指定日誌文件名。 空字符串也可以用於強制Redis登錄標準輸出。 請注意，如果您使用標準輸出進行日誌記錄但進行守護進程，則日誌將發送到 /dev/null

logfile ""

要啓用到系統記錄器的日誌記錄，只需將“ syslog-enabled”設置爲yes， 並根據需要更新其他syslog參數

syslog-enabled no

指定系統日誌標識。

syslog-ident redis

指定系統日誌工具。必須是USER或LOCAL0-LOCAL7之間。

syslog-facility local0

設置數據庫數。 默認數據庫爲DB 0，您可以使用SELECT <dbid>在每個連接的基礎上選擇一個不同的數據庫，其中dbid是介於0和'databases'-1之間的數字

databases 16

默認情況下，僅當開始登錄到標準輸出並且標準輸出爲TTY時，Redis纔會顯示ASCII藝術logo 。 基本上，這意味着通常僅在交互式會話中顯示Logo 。

但是，可以通過將以下選項設置爲yes，來強制執行4.0之前的行爲並始終在啓動日誌中顯示ASCII藝術Logo。

always-show-logo yes

 

SNAPSHOTTING (快照)

將數據庫保存在磁盤上：

save <seconds> <changes>

如果同時發生了給定的秒數和對數據庫的寫操作數，則將保存數據庫。

在下面的示例中，行爲將是保存：

• 如果至少更改了1個按鍵，則在900秒（15分鐘）後
• 300秒（5分鐘）後，如果至少更改了10個按鍵
• 60秒後，如果至少更改了10000個鍵

注意：您可以通過註釋掉所有“保存”行來完全禁用保存。

也可以通過添加帶有單個空字符串參數的save指令來刪除所有先前配置的保存點，如以下示例所示：

save ""   # 將是刪除之前保存的值

# 默認值
save 900 1
save 300 10
save 60 10000

默認情況下，如果啓用RDB快照（至少一個保存點）並且最新的後臺保存失敗，則Redis將停止接受寫入。 這將使用戶（以一種困難的方式）意識到數據無法正確地持久存儲在磁盤上，否則，可能沒人會注意到並且會發生一些災難。

如果後臺保存過程將再次開始工作，則Redis將自動允許再次寫入。

但是，如果您設置了對Redis服務器和持久性的適當監視，則可能要禁用此功能，以便即使磁盤，權限等出現問題，Redis也將繼續照常工作。

stop-writes-on-bgsave-error yes

轉儲.rdb數據庫時使用LZF壓縮字符串對象？ 默認情況下將其設置爲“yes”，因爲它幾乎總是勝利。 如果要在保存子項中保存一些CPU，請將其設置爲“ no”，但是如果您具有可壓縮的值或鍵，則數據集可能會更大。

rdbcompression yes

從RDB版本5開始，CRC64校驗和位於文件的末尾。 這使該格式更能抵抗損壞，但是在保存和加載RDB文件時會降低性能（約10％），因此可以禁用它以實現最佳性能。

在禁用校驗的情況下創建的RDB文件的校驗爲零，這將指示加載代碼跳過該校驗。

rdbchecksum yes

轉儲數據庫的文件名

dbfilename dump.rdb

在未啓用持久性的實例中刪除複製使用的RDB文件。 默認情況下，此選項是禁用的，但是在某些環境中，出於法規或其他安全方面的考慮，應將RDB文件由主數據庫持久存儲在磁盤上以提供副本，或將RDB文件由副本存儲在磁盤上以加載它們以進行初始同步。 應該儘快刪除。 請注意，此選項僅在同時禁用AOF和RDB持久性的實例中起作用，否則將被完全忽略。

一種獲得相同效果的替代方法（有時更好）是在主實例和副本實例上使用無盤複製。 然而對於副本，無盤並非總是一種選擇。

rdb-del-sync-files no

 

工作目錄。

數據庫將被寫入該目錄內，文件名使用“ dbfilename”配置指令在上面指定。

也將在此目錄中創建僅附加文件。

請注意，您必須在此處指定目錄，而不是文件名。

dir ./

 

REPLICATION(複製)

主副本複製。 使用的副本使Redis實例成爲另一個Redis服務器的副本。 儘快瞭解有關Redis複製的幾件事。

   +------------------+      +---------------+
   |      Master      | ---> |    Replica    |
   | (receive writes) |      | (exact copy)  |
   |   接受     寫     |      |   精確   複製   |
   +------------------+      +---------------+

1. Redis複製是異步的，但是您可以將主服務器配置爲在似乎未與至少給定數量的副本連接時停止接受寫操作。
2. 如果複製鏈接在相對較短的時間內丟失，則Redis副本能夠與主副本執行部分重新同步。 您可能需要根據需要將複製 backlog(積壓) 大小（請參閱此文件的下一部分）配置爲合理的值。
3. 複製是自動的，不需要用戶干預。 網絡分區副本之後，副本會自動嘗試重新連接到母版並與它們重新同步。

replicaof <masterip> <masterport>

如果主服務器受密碼保護（使用下面的“ requirepass”配置指令），則可以在開始複製同步過程之前告知副本進行身份驗證，否則主服務器將拒絕副本請求。

masterauth <master-password>

但是，如果您使用的是Redis ACL（對於Redis版本6或更高版本），並且默認用戶無法運行PSYNC命令和/或其他複製所需的命令，這還不夠。 在這種情況下，最好配置一個特殊用戶以用於複製，並這樣指定masteruser配置：

masteruser <username>

指定masteruser時，副本將使用新的AUTH形式針對其主服務器進行身份驗證：

AUTH <username> <password>

當副本失去與主數據庫的連接時，或者仍在進行復制時，副本可以以兩種不同的方式起作用：

1. 如果複製副本服務過時的數據設置爲“是”（默認值），則複製副本仍將回復客戶端請求，可能包含過期數據，或者如果這是第一次同步，則數據集可能只是空的。
2. 如果複製副本服務過時的數據設置爲“否”，則複製副本將對所有類型的命令以錯誤“與主機進行同步”答覆，但是對於 INFO, replicaOF, AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG, SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB, COMMAND, POST, HOST: and LATENCY.

replica-serve-stale-data yes

您可以配置副本實例以接受或不接受寫入。 針對副本實例進行寫操作可能對存儲某些臨時數據很有用（因爲與主實例重新同步後，很容易刪除副本上寫入的數據），但是如果客戶端由於配置錯誤而向其寫入數據，也可能會導致問題。

由於Redis 2.6默認情況下，副本是隻讀的。

注意：只讀副本並非旨在向Internet上不受信任的客戶端公開。 它只是防止實例濫用的保護層。 默認情況下，只讀副本仍會導出所有管理命令，例如CONFIG，DEBUG等。 在一定程度上，您可以使用'rename-command'隱藏所有管理/危險命令來提高只讀副本的安全性。

replica-read-only yes

 

複製SYNC策略： disk or socket(磁盤或套接字)。

僅接收差異而無法繼續複製過程的新副本和重新連接的副本需要執行所謂的“完全同步”。 RDB文件從主數據庫傳輸到副本數據庫。

傳輸可以通過兩種不同的方式進行：

1. Disk-backed：Redis主服務器創建一個新過程，將RDB文件寫入磁盤。 後來，該文件由父進程逐步傳輸到副本。
2. Diskless：Redis主服務器創建一個新進程，該進程將RDB文件直接寫入副本套接字，而完全不接觸磁盤。

使用磁盤支持的複製，在生成RDB文件的同時，只要生成RDB文件的當前的子級完成工作，就可以將更多副本排入隊列並與RDB文件一起使用。 如果使用無盤複製，則一旦傳輸開始，新的副本將排隊，並且噹噹前副本終止時將開始新的傳輸。

使用無盤複製時，主服務器在開始傳輸之前會等待一段可配置的時間（以秒爲單位），以希望多個副本可以到達並且傳輸可以並行化。

使用慢速磁盤和快速（大帶寬）網絡，無盤複製效果更好。

repl-diskless-sync no

啓用無盤複製後，可以配置服務器等待的延遲，以便生成通過套接字將RDB傳輸到副本的子代。

這一點很重要，因爲一旦傳輸開始，就無法爲到達的新副本提供服務，新副本將排隊等待下一次RDB傳輸，因此服務器會等待一段時間才能讓更多副本到達。

延遲以秒爲單位指定，默認情況下爲5秒。 要完全禁用它，只需將其設置爲0秒，傳輸就會盡快開始。

repl-diskless-sync-delay 5

警告：RDB無盤加載是實驗性的。 因爲在此設置中，副本不會立即在磁盤上存儲RDB，所以它可能會導致故障轉移期間的數據丟失。 在與主機的初始同步階段，如果 I/O 錯誤，則RDB無盤加載+ Redis模塊不處理 I/O 讀取也可能導致Redis中止。 僅在執行自己的操作時使用。

副本可以直接從套接字加載它從複製鏈接讀取的RDB，也可以將RDB存儲到文件中，並在從主服務器完全獲取文件後讀取該文件。

在許多情況下，磁盤的速度比網絡慢，並且存儲和加載RDB文件可能會增加複製時間（甚至會增加主服務器的“寫時複製”內存和從屬緩衝區）。 但是，直接從套接字解析RDB文件可能意味着我們必須在收到完整的rdb之前刷新當前數據庫的內容。 因此，我們有以下選擇：

• "disabled" 不要使用無盤負載（首先將rdb文件存儲到磁盤）
• "on-empty-db" 僅在完全安全時才使用無盤加載。
• "swapdb" 直接從套接字解析數據時，將當前數據庫內容的副本保留在RAM中。 請注意，這需要足夠的內存，如果沒有足夠的內存，則可能會殺死OOM。

repl-diskless-load disabled

副本以預定義的間隔將PING發送到服務器。 可以使用repl_ping_replica_period選項更改此間隔。 默認值爲10秒。

repl-ping-replica-period 10

以下選項爲以下項設置複製超時：

• 從副本的角度來看，在SYNC期間進行批量傳輸I/O。
• 從副本（data, pings）的角度來看，主服務器超時。
• 從主服務器角度來看，副本超時（REPLCONF ACK pings）。

重要的是要確保該值大於爲repl-ping-replica-period指定的值，否則，每當主機和副本之間的通信量較低時，就會檢測到超時。

repl-timeout 60

在同步後禁用副本套接字上的TCP_NODELAY？

如果選擇“yes”，則Redis將使用更少的TCP數據包和更少的帶寬將數據發送到副本。 但這會增加數據出現在副本端的延遲，對於使用默認配置的Linux內核，此延遲最多可達40毫秒。

如果選擇“否”，則將減少數據在副本側出現的延遲，但是將使用更多帶寬進行復制。

默認情況下，我們會針對低延遲進行優化，但是在流量非常高的情況下，或者當主副本和副本之間的距離很遠時，將其設置爲“yes”可能是個好主意。

repl-disable-tcp-nodelay no

設置複製backlog(積壓) 大小。 待辦事項是一個緩衝區，當副本斷開連接一段時間後，該緩衝區會累積副本數據，因此當副本要重新連接時，通常不需要完全重新同步，但是部分重新同步就足夠了，僅傳遞副本斷開連接時丟失的數據部分。

複製待辦事項越大，副本可以斷開連接並稍後能夠執行部分重新同步的時間越長。

僅當至少有一個副本連接時，才分配backlog(積壓)。

repl-backlog-size 1mb

主服務器在一段時間內不再連接副本後，積壓的事務將被釋放。 以下選項配置了從斷開最後一個副本的時間開始到釋放待辦事項緩衝區所需的秒數。

請注意，副本永遠不會釋放積壓的超時，因爲它們可能稍後會升級爲主副本，並且應該能夠與副本正確“部分重新同步”：因此，它們應始終累積積壓。

值爲0表示從不釋放積壓。

repl-backlog-ttl 3600

副本優先級是Redis在INFO輸出中發佈的整數。 如果主服務器不再正常工作，Redis Sentinel會使用它來選擇要升級爲主服務器的副本。

具有較低優先級編號的副本被認爲更適合提升，因此，例如，如果存在三個具有10、100、25優先級的副本，則Sentinel將選擇具有最低優先級10的副本。

但是，特殊優先級0會將副本標記爲不能執行主角色，因此Redis Sentinel永遠不會選擇優先級爲0的副本進行升級。

缺省情況下，優先級爲100。

replica-priority 100

如果連接的副本少於N個，並且延遲小於或等於M秒，則主服務器可能會停止接受寫入。

N個副本需要處於“聯機”狀態。

延遲（以秒爲單位）必須小於等於指定值，該延遲是根據從副本接收到的最後ping（通常每秒發送一次）計算得出的。

此選項不能保證N個副本將接受寫操作，但是會將可用寫副本不足的情況下丟失的寫操作的暴露窗口限制爲指定的秒數。

例如，要要求至少3個副本的延遲<= 10秒，請使用：

min-replicas-to-write 3
min-replicas-max-lag 10

將一個或另一個設置爲0將禁用該功能。

默認情況下，將要寫入的最小副本設置爲0（禁用功能），並且將min-replicas-max-lag設置爲10。

Redis主服務器能夠以不同方式列出附加副本的地址和端口。 例如，“ INFO replication”部分提供了此信息，Redis Sentinel使用此信息以及其他工具來發現副本實例。 該信息可用的另一個位置是主服務器的“ ROLE”命令的輸出。

副本通常報告的列出的IP和地址可以通過以下方式獲得：

• IP：通過檢查副本用來與主服務器連接的套接字的對等地址來自動檢測該地址。
• Port：該端口在複製握手期間由副本進行通信，通常是副本用來偵聽連接的端口。

但是，當使用端口轉發或網絡地址轉換（NAT）時，實際上可以通過不同的 IP和Port pairs(一對) 訪問該副本。 副本可以使用以下兩個選項，以便向其主服務器報告特定的IP和端口集，以便INFO和ROLE都將報告這些值。

如果只需要覆蓋端口或IP地址，則無需使用這兩個選項。

replica-announce-ip 5.5.5.5
replica-announce-port 1234

 

KEYS TRACKING(跟蹤, 追蹤)

Redis爲客戶端的值緩存實現服務器輔助的支持。 這是使用invalidation table來實現的，該無效表使用1600萬個插槽記住哪些客戶端可能具有某些鍵子集。 依次使用它是爲了向客戶端發送無效消息。 請了解有關此功能的更多信息，請檢查以下頁面：

https://redis.io/topics/client-side-caching

爲客戶端啓用跟蹤時，所有隻讀查詢均假定爲已緩存：這將強制Redis將信息存儲在invalidation table中。修改密鑰後，此類信息將被清除，並將無效消息發送到客戶端。但是，如果工作量主要由讀取決定，Redis可以使用越來越多的內存來跟蹤許多客戶端獲取的keys 。

因此，可以爲invalidation table配置最大填充值。默認情況下，它設置爲1M keys，一旦達到此限制，即使未修改鍵，Redis也將開始撤消失效表中的鍵，只是爲了回收內存：這反過來將迫使客戶端使緩存無效價值觀。基本上，表的最大大小是要在服務器端用來跟蹤有關誰緩存內容的信息的內存與客戶端將緩存的對象保留在內存中的能力之間進行權衡的。

如果將值設置爲0，則表示沒有限制，Redis將在失效表中保留所需數量的鍵。在“stats”信息部分，您可以在invalidation table中找到有關鍵數的信息。在每個給定的時刻。

注意：在廣播模式下使用鍵跟蹤時，服務器端未使用任何內存，因此此設置無用。

tracking-table-max-keys 1000000

 

SECURITY(安全)

警告：由於Redis的速度非常快，外部用戶每秒可以在一個現代化的盒子上嘗試高達100萬個密碼。 這意味着您應該使用非常安全的密碼，否則密碼很容易破解。 請注意，由於該密碼實際上是客戶端和服務器之間的共享機密，並且不應被任何人記住，因此該密碼可以很容易地是來自 /dev/urandom 的長字符串或其他任何內容，因此可以使用長且不可猜測的密碼 沒有暴力攻擊的可能。

Redis ACL用戶的定義如下：

user <username> ... acl rules ...
# 例如：
user worker +@list +@connection ~jobs:* on >ffa9203c493aa99

特殊的用戶名“默認”用於新連接。 如果該用戶具有“ nopass”規則，則新連接將立即被認證爲“default”用戶，而不需要通過AUTH命令提供的任何密碼。 否則，如果未將“default”用戶標記爲“ nopass”，則連接將以未認證狀態啓動，並且需要AUTH（或HELLO命令的AUTH選項）才能進行認證並開始工作。

描述用戶可以執行的操作的ACL規則如下：

• on 啓用用戶：可以驗證爲該用戶。
• off 禁用用戶：不再可以與此用戶進行身份驗證，但是已經過身份驗證的連接仍然可以使用。
• +<command> 允許執行該命令
• -<command> 禁止執行該命令
• +@<category> 允許執行此類中具有有效類別的所有命令，例如@admin, @set, @sortedset, ...，請參閱server.c文件中的完整列表，其中描述和定義了Redis命令表 。 特殊類別@all表示所有命令，但是當前在服務器中存在，並且將來會通過模塊加載。
• +<command>|subcommand 允許使用本來禁用的命令中的特定子命令。 注意，這種形式不允許像-DEBUG | SEGFAULT那樣爲負數，而只能以“ +”開頭。
• allcommands +@all的別名。 請注意，這意味着可以執行將來通過模塊系統加載的所有命令。
• nocommands -@all的別名。
• ~<pattern> 添加可以在命令中提及的鍵模式。 例如~*允許所有鍵。 該模式是類似於KEYS之一的 glob-style 的模式。 可以指定多個模式。
• allkeys 〜*的別名
• resetkeys 刷新允許的鍵模式列表。
• ><password> 將此密碼添加到用戶的有效密碼列表中。 例如，>mypass會將“ mypass”添加到列表中。 該指令清除“ no pass”標誌（請參閱下文）。
• <<password> 從有效密碼列表中刪除此密碼。
• nopass 用戶的所有設置密碼都將被刪除，並且該用戶被標記爲不需要密碼：這意味着每個密碼都將對該用戶起作用。 如果此指令用於默認用戶，則每個新連接都將立即通過默認用戶進行身份驗證，而無需任何顯式的AUTH命令。 請注意，“ resetpass”指令將清除此情況。
• resetpass 刷新允許的密碼列表。 此外，刪除“ nopass”狀態。 在“resetpass”之後，用戶將沒有關聯的密碼，並且沒有添加一些密碼（或稍後將其設置爲“ nopass”）就無法進行身份驗證的方法。
• reset 執行以下操作：resetpass, resetkeys, off, -@all。 用戶返回到創建後立即具有的相同狀態。

可以按任何順序指定ACL規則：例如，您可以先輸入密碼，再輸入標誌或密鑰模式。 但是請注意，加法和減法規則將根據ordering順序進行更改。 例如，請參見以下示例：

user alice on +@all -DEBUG ~* >somepassword

這將允許“ alice”使用除DEBUG命令之外的所有命令，因爲 +@all 將所有命令添加到了alice可以使用的命令集中，並且後來刪除了DEBUG。 但是，如果我們顛倒兩個ACL規則的順序，結果將是不同的：

user alice on -DEBUG +@all ~* >somepassword

現在，當alice在允許的命令集中還沒有命令時，DEBUG被刪除，之後又添加了所有命令，因此用戶將能夠執行所有操作。

基本上，ACL規則是從左到右處理的。

有關ACL配置的更多信息，請參考Redis網站，網址https://redis.io/topics/acl。

 

ACL LOG

ACL日誌跟蹤與ACL關聯的失敗命令和身份驗證事件。 ACL日誌可用於對被ACL阻止的失敗命令進行故障排除。 ACL日誌存儲在內存中。 您可以使用ACL LOG RESET回收內存。 在下面定義ACL日誌的最大條目長度。

acllog-max-len 128

使用外部ACL文件

除了在此文件中配置用戶之外，還可以使用僅列出用戶的獨立文件。 這兩種方法不能混合使用：如果您在此處配置用戶並同時激活外部ACL文件，則服務器將拒絕啓動。

外部ACL用戶文件的格式與redis.conf內部用於描述用戶的格式完全相同。

aclfile /etc/redis/users.acl

重要說明：從Redis 6開始，“ requirepass”只是新ACL系統之上的兼容性層。 選項效果將只是爲默認用戶設置密碼。 客戶端仍然可以像往常一樣使用AUTH 進行身份驗證，或者如果它們遵循新協議，則可以使用AUTH default 進行更明確的身份驗證：兩者都可以使用。

requirepass foobared

 

Command renaming (DEPRECATED).命令重命名（不建議使用）

警告：儘可能避免使用此選項。 而是使用ACL從默認用戶中刪除命令，並將其僅放置在您出於管理目的而創建的某些admin用戶中。

可以在共享環境中更改危險命令的名稱。 例如，可以將CONFIG命令重命名爲一些難以猜測的名稱，以便它仍可用於內部使用的工具，但不適用於一般客戶。

Example:
 rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

通過將命令重命名爲空字符串也可以完全取消命令：

rename-command CONFIG ""

請注意，更改登錄到AOF文件或傳輸到副本的命令的名稱可能會導致問題。

 

CLIENTS

同時設置最大連接客戶端數。 默認情況下，此限制設置爲10000個客戶端，但是，如果Redis服務器無法將進程文件限制配置爲允許指定的限制，則允許的最大客戶端數將設置爲當前文件限制減去32（因爲Redis保留了 內部使用的文件描述符很少）。

達到限制後，Redis將關閉所有新連接，併發送錯誤消息“已達到最大客戶端數”。

重要說明：使用Redis羣集時，最大連接數也與羣集總線共享：羣集中的每個節點將使用兩個連接，一個進入，另一個離開。 對於非常大的羣集，重要的是相應地調整限制大小。

maxclients 10000

 

 

MEMORY MANAGEMENT

將內存使用限制設置爲指定的字節數。當達到內存限制時，Redis將嘗試根據所選的逐出策略（請參見maxmemory-policy）刪除密鑰。

如果Redis無法根據策略刪除密鑰，或者如果策略設置爲“ noeviction”，則Redis將開始對將使用更多內存的命令（例如SET，LPUSH等）進行錯誤回覆，並將繼續答覆諸如GET之類的只讀命令。

當將Redis用作LRU或LFU緩存，或爲實例設置硬盤限制（使用“ noeviction”策略）時，此選項通常很有用。

警告：如果您將副本連接到實例且maxmemory處於打開狀態，則從使用的內存數量中減去提供副本所需的輸出緩衝區的大小，這樣，網絡問題/重新同步將不會觸發逐出密鑰的循環，並且 反過來，副本的輸出緩衝區已滿，有被驅逐的鍵的DEL觸發了更多鍵的刪除，依此類推，直到數據庫完全清空。

簡而言之...如果您附加了副本，建議您爲maxmemory設置一個下限，以便系統上有一些可用RAM用於副本輸出緩衝區（但是如果策略爲'noeviction'，則不需要這樣做）。

maxmemory <bytes>

MAXMEMORY POLICY：達到maxmemory時，Redis將如何選擇要刪除的內容。 您可以從以下行爲中選擇一種：

• volatile-lru -> 使用近似的LRU驅逐，僅設置過期的密鑰。
• allkeys-lru -> 使用近似的LRU退出任何密鑰。
• volatile-lfu -> 使用近似的LFU退出，僅設置了過期密鑰。
• allkeys-lfu -> 使用近似的LFU退出任何密鑰。
• volatile-random -> 刪除具有過期設置的隨機密鑰。
• allkeys-random -> 刪除隨機密鑰，任何密鑰。
• volatile-ttl -> 取出最接近到期時間（較小的TTL）的密鑰
• noeviction -> 不要驅逐任何東西，只需在寫操作中返回錯誤。

LRU(Least Recently Used)表示最近最少使用

LFU(Least Frequently Used)表示最少使用

LRU，LFU和volatile-ttl均使用近似隨機算法實現。

注意：使用上述任何策略時，如果沒有合適的退出鍵，Redis將在寫入操作中返回錯誤。 在撰寫本文時，這些命令是：set setnx setex append incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby getset mset msetnx exec sort

默認值爲：

maxmemory-policy noeviction

LRU，LFU和最小TTL算法不是精確算法，而是近似算法（以節省內存），因此您可以針對速度或準確性進行調整。 對於默認情況，Redis將檢查五個鍵並選擇最近使用的鍵，您可以使用以下配置指令更改樣本大小。

默認值爲5會產生足夠好的結果。 10非常接近真實的LRU，但是會花費更多的CPU。 3更快，但不是很準確。

maxmemory-samples 5

從Redis 5開始，默認情況下，副本將忽略其maxmemory設置（除非在故障轉移後或手動提升爲主副本）。這意味着密鑰的移出將僅由主服務器處理，將DEL命令作爲副本在主計算機側逐出，將DEL命令發送到副本。

此行爲可確保主副本和副本始終保持一致，這通常是您想要的，但是，如果副本是可寫的，或者您希望副本具有不同的內存設置，並且您確定對副本執行的所有寫操作都是冪等的，那麼您可以更改此默認設置（但請務必瞭解您的操作）。

請注意，由於默認情況下該副本不會退出，因此它可能會使用比通過maxmemory設置的內存更多的內存（某些緩衝區在副本上可能會更大，或者數據結構有時會佔用更多的內存，依此類推）。因此，請確保您監視副本並確保副本具有足夠的內存，以確保在主副本達到配置的最大內存設置之前，永不達到實際的內存不足狀態。

replica-ignore-maxmemory yes

Redis通過兩種方式回收過期的密鑰：訪問時發現這些密鑰已過期，以及在後臺，稱爲“活動的過期密鑰”。 緩慢地，交互地掃描密鑰空間，以查找要回收的過期密鑰，以便可以釋放已過期且不久之後將不再訪問的密鑰的內存。

到期週期的默認工作將嘗試避免在內存中保留超過百分之十的過期密鑰，並且將嘗試避免消耗超過總內存的25％並增加系統延遲。 但是，可以將通常設置爲“ 1”的過期“effort”增加到更大的值，直到值“ 10”。 系統將以其最大值使用更多的CPU，更長的週期（並且從技術上講可能會引入更多的延遲），並且將減少仍存在於系統中的已過期密鑰的數量。 在內存，CPU和延遲之間進行權衡。

active-expire-effort 1

 

LAZY FREEING

Redis有兩個刪除鍵的原語。 一種稱爲DEL，它是對象的阻塞刪除。 這意味着服務器停止處理新命令，以便以同步方式回收與對象關聯的所有內存。 如果刪除的鍵與一個小對象相關聯，則執行DEL命令所需的時間非常短，可與Redis中的其他大多數O（1）或O（log_N）命令相提並論。 但是，如果鍵與包含數百萬個元素的聚合值相關聯，則服務器可能會阻塞很長時間（甚至幾秒鐘）以完成操作。

由於上述原因，Redis還提供了非阻塞刪除原語，例如UNLINK（非阻塞DEL）以及FLUSHALL和FLUSHDB命令的ASYNC選項，以便在後臺回收內存。 這些命令在固定時間內執行。 另一個線程將盡可能快地在後臺逐漸釋放對象。

用戶可以控制FLUSHALL和FLUSHDB的DEL，UNLINK和ASYNC選項。 由應用程序的設計決定何時使用一個或另一個是一個好主意。 但是，Redis服務器有時必須刪除鍵或刷新整個數據庫，這是其他操作的副作用。 特別是在以下情況下，Redis獨立於用戶調用刪除對象：

1. 逐出時，由於maxmemory和maxmemory策略配置，以便在不超過指定的內存限制的情況下爲新數據騰出空間。
2. 因爲到期：必須從內存中刪除具有相關生存時間的密鑰（請參閱EXPIRE命令）。
3. 由於將數據存儲在可能已經存在的鍵上的命令的副作用。 例如，當RENAME命令替換爲舊密鑰內容時，RENAME命令可能會刪除它。類似地，SUNIONSTORE或SORT 與 STORE選項可能會刪除現有密鑰。 SET命令本身會刪除指定鍵的所有舊內容，以便將其替換爲指定的字符串。
4. 複製期間，當副本與其主副本執行完全重新同步時，將刪除整個數據庫的內容，以便加載剛傳輸的RDB文件。

在上述所有情況下，默認設置都是以阻塞方式刪除對象，就像調用DEL一樣。 但是，您可以專門配置每種情況，以便使用以下配置指令以非阻塞方式釋放內存，例如調用UNLINK的情況。

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no

對於用UNLINK調用替換用戶代碼DEL調用不容易的情況，也可以使用以下配置指令將DEL命令的默認行爲修改爲與UNLINK完全一樣：

lazyfree-lazy-user-del no

 

THREADED I/O

Redis大多是單線程的，但是有一些線程操作，例如UNLINK，緩慢的 I/O 訪問和其他在側線程上執行的操作。

現在，還可以在不同的 I/O 線程中處理Redis客戶端套接字的讀寫。 由於特別慢的寫入速度，因此Redis用戶通常使用流水線以加快每個內核的Redis性能，並生成多個實例以擴展規模。 使用 I/O 線程，可以輕鬆地將Redis加速兩次，而無需求助於實例的流水線處理或分片。

默認情況下，禁用線程處理，我們建議僅在具有至少4個或更多內核的計算機上啓用它，並至少保留一個備用內核。 使用8個以上的線程不太會有幫助。 我們還建議僅在確實存在性能問題時才使用線程 I/O，Redis實例可以使用很大一部分CPU時間，否則就沒有必要使用此功能。

因此，例如，如果您有四個核的盒子，請嘗試使用2或3個 I/O 線程，如果您有8個核，請嘗試使用6個線程。 爲了啓用 I/O 線程，請使用以下配置指令：

io-threads 4

通常，將io-threads設置爲1只會使用主線程。 啓用 I/O 線程後，我們僅使用線程進行寫操作，即對 write(2) 系統調用進行線程化，並將客戶端緩衝區傳輸到套接字。 但是，也可以通過將以下配置指令設置爲yes來啓用讀取線程和協議解析：

io-threads-do-reads no

通常，線程讀取沒有太大幫助。

注意1：無法在運行時通過CONFIG SET更改此配置指令。 啓用SSL後，該功能目前也無法使用。

注意2：如果您想使用redis-benchmark測試Redis加速，請確保您還以--threads選項匹配Redis thead的數量，以線程模式運行基準測試本身，否則您將無法注意到這些改進。

 

APPEND ONLY MODE(追加模式)

默認情況下，Redis異步將數據集轉儲到磁盤上。 此模式在許多應用程序中已經足夠好，但是Redis進程問題或停電可能會導致幾分鐘的寫入丟失（取決於配置的保存點）。

僅附加文件(Append Only File;AOF)是一種替代的持久性模式，可提供更好的持久性。 例如，使用默認的數據fsync策略（請參閱配置文件中的稍後內容），Redis在嚴重的事件（例如服務器斷電）中僅會丟失一秒鐘的寫入，如果Redis進程本身發生問題，則可能會丟失一次寫入，但是 操作系統仍在正常運行。

可以同時啓用AOF和RDB持久性，而不會出現問題。如果在啓動時啓用AOF，則Redis將加載AOF，即具有更好持久性保證的文件。

請檢查http://redis.io/topics/persistence瞭解更多信息。

appendonly no

僅附加文件的名稱（默認值：“ appendonly.aof”）

appendfilename "appendonly.aof"

fsync() 調用告訴操作系統將數據實際寫在磁盤上，而不是等待輸出緩衝區中的更多數據。 有些操作系統確實會刷新磁盤上的數據，而另一些操作系統只會嘗試儘快進行處理。

Redis支持三種不同的模式：

• no：不要fsync，只要讓OS在需要時刷新數據即可。 Faster(快點)。
• always：每次寫入僅附加日誌後的fsync。 Slow(慢), Safest(最安全)。
• everysec：fsync每秒僅一次。Compromise(妥協)。

默認值爲“ everysec”，因爲這通常是速度和數據安全性之間的正確折衷。 您可以瞭解是否可以將其放鬆爲“ no”，這將使操作系統在需要時刷新輸出緩衝區，以獲得更好的性能（但是，如果您可以忍受某些數據丟失的想法，請考慮使用默認的持久性模式 （即快照），或者相反，請使用“always”，該速度非常慢，但比秒安全。

更多詳細信息，請查看以下文章：http://antirez.com/post/redis-persistence-demystified.html

如果不確定，請使用“ everysec”

appendfsync always
appendfsync everysec
appendfsync no

當AOF fsync策略設置爲always或everysec，並且後臺保存進程（後臺保存或AOF日誌後臺重寫）對磁盤執行大量 I/O 時，在某些Linux配置中，Redis可能會在磁盤上阻塞太長時間。 fsync() 調用。 請注意，目前尚無此修復程序，因爲即使在其他線程中執行fsync也將阻止我們的同步 write(2) 調用。

爲了減輕此問題，可以使用以下選項來防止在BGSAVE或BGREWRITEAOF進行時在主進程中調用fsync() 。

這意味着當另一個孩子正在保存時，Redis的持久性與“ appendfsync none”相同。 實際上，這意味着在最壞的情況下（使用默認的Linux設置）可能會丟失多達30秒的日誌。

如果您有延遲問題，請將其設置爲“yes”。 否則，從耐用性的角度出發，將其保留爲“no”是最安全的選擇。

no-appendfsync-on-rewrite no

自動重寫僅附加文件。 當AOF日誌大小增加指定的百分比時，Redis可以自動重寫日誌文件，隱式調用BGREWRITEAOF。

它是這樣工作的：Redis會在最近一次重寫後記住AOF文件的大小（如果自重新啓動以來未發生任何重寫，則使用啓動時AOF的大小）。

將此基本大小與當前大小進行比較。 如果當前大小大於指定的百分比，則觸發重寫。 另外，您需要指定要重寫的AOF文件的最小大小，這對於避免重寫AOF文件非常有用，即使達到百分比增加，但它仍然很小。

指定零百分比以禁用自動AOF重寫功能。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

percentage=百分比

當AOF數據重新加載到內存中時，在Redis啓動過程中可能會發現AOF文件在末尾被截斷。當運行Redis的系統崩潰時，尤其是在沒有 data=ordered 選項的情況下掛載ext4文件系統時，可能會發生這種情況（但是，當Redis本身崩潰或中止，但操作系統仍然可以正常工作時，就不會發生這種情況）。

發生這種情況時，Redis可能會退出並顯示錯誤，也可以加載儘可能多的數據（當前爲默認值），如果發現AOF文件最後被截斷，則Redis會開始加載。以下選項控制此行爲。

如果aof-load-truncated設置爲yes，則將加載截短的AOF文件，並且Redis服務器將開始發出日誌以將事件通知用戶。否則，如果該選項設置爲no，則服務器將中止並顯示錯誤並拒絕啓動。當該選項設置爲no時，用戶需要在重新啓動服務器之前使用“ redis-check-aof”實用程序修復AOF文件。

請注意，如果在中間發現AOF文件已損壞，則服務器仍將退出並出現錯誤。僅當Redis嘗試從AOF文件讀取更多數據但找不到足夠的字節時，此選項才適用。

aof-load-truncated yes

重寫AOF文件時，Redis可以使用AOF文件中的RDB前同步碼來更快地進行重寫和恢復。 啓用此選項後，重寫的AOF文件由兩個不同的節組成：

[RDB file][AOF tail]

加載時，Redis會識別AOF文件以“ REDIS”字符串開頭並加載帶前綴的RDB文件，然後繼續加載AOF尾部。

aof-use-rdb-preamble yes

 

LUA腳本

Lua腳本的最大執行時間（以毫秒爲單位）。

如果達到了最大執行時間，Redis將記錄在允許的最大時間後腳本仍在執行中，並將開始以錯誤答覆查詢。

如果長時間運行的腳本超過了最大執行時間，則只有“ SCRIPT KILL”和“ SHUTDOWN NOSAVE”命令可用。 第一個可用於停止尚未調用寫命令的腳本。 第二種是在腳本已發出寫命令但用戶不想等待腳本自然終止的情況下關閉服務器的唯一方法。

將其設置爲0或負值可無警告地無限執行。

lua-time-limit 5000

 

REDIS集羣

普通Redis實例不能屬於Redis羣集； 只有作爲羣集節點啓動的節點可以。 爲了將Redis實例作爲羣集節點啓動，請啓用羣集支持，取消註釋以下內容：

cluster-enabled yes

每個羣集節點都有一個羣集配置文件。 該文件不適合手工編輯。 它由Redis節點創建和更新。 每個Redis羣集節點都需要一個不同的羣集配置文件。 確保在同一系統上運行的實例沒有重疊的集羣配置文件名。

cluster-config-file nodes-6379.conf

羣集節點超時是一個節點必須不可達的毫秒數，才能將其視爲故障狀態。 其他大多數內部時間限制是節點超時的倍數。

cluster-node-timeout 15000

如果發生故障的主副本的數據看起來太舊，它將避免啓動故障轉移。

沒有一種簡單的方法可以使副本實際上具有對其“data age”的精確度量，因此執行以下兩項檢查：

1. 如果存在多個能夠進行故障轉移的副本，則它們會交換消息，以嘗試利用具有最佳複製偏移量的副本（已處理來自主數據庫的更多數據）來發揮優勢。 副本將嘗試按偏移量獲取其等級，並將與它們的等級成比例的延遲應用於故障轉移。
2. 每個單個副本都會計算與其主副本之間最後一次交互的時間。 這可以是最後收到的ping或命令（如果主服務器仍處於“connected(已連接)”狀態），也可以是自從與主服務器斷開連接以來經過的時間（如果複製鏈接當前已關閉）。 如果最後一次交互太舊，則副本將完全不會嘗試故障轉移。

用戶可以調整點 “ 2”。 具體而言，如果自從上次與主服務器進行交互以來，經過的時間大於以下時間，則副本將不執行故障轉移：

(node-timeout * replica-validity-factor) + repl-ping-replica-period

因此，例如，如果節點超時爲30秒，並且 replica-validity-factor 爲10，並且假設默認的repl-ping-replica-period值爲10秒，則該副本將無法嘗試進行故障轉移（如果無法進行通話） 與主機的時間超過310秒。

較大的 replica-validity-factor 可能會使數據太舊的副本無法對主副本進行故障轉移，而值太小可能會使羣集根本無法選擇副本。

爲了獲得最大的可用性，可以將 replica-validity-factor 設置爲0，這意味着，無論副本上次與主機交互的時間，副本將始終嘗試對主機進行故障轉移。 （但是，他們將始終嘗試應用與其偏移等級成正比的延遲）。

Zero 是唯一能夠確保當所有分區恢復正常後羣集將始終能夠繼續運行的值。

cluster-replica-validity-factor 10

羣集副本能夠遷移到孤立的主數據庫，即那些沒有工作副本的主數據庫。 這樣可以提高羣集抵禦故障的能力，因爲如果沒有工作副本，孤立的主節點在發生故障的情況下將無法進行故障轉移。

僅當其舊主副本仍至少存在給定數量的其他工作副本時，副本副本纔會遷移到孤立的主副本。 這個數字是“移民壁壘”。 遷移障礙爲1表示僅當副本數據庫的主副本上至少有1個其他工作副本時，副本副本纔會遷移。 它通常反映出集羣中每個主數據庫所需的副本數。下方是原文：

Replicas migrate to orphaned masters only if there are still at least a given number of other working replicas for their old master. This number is the "migration barrier". A migration barrier of 1 means that a replica will migrate only if there is at least 1 other working replica for its master and so forth. It usually reflects the number of replicas you want for every master in your cluster.

缺省值爲1（副本僅在其主數據庫保留至少一個副本的情況下遷移）。 要禁用遷移，只需將其設置爲非常大的值即可。 可以將值設置爲0，但僅用於調試和生產危險。

cluster-migration-barrier 1

默認情況下，如果Redis Cluster節點檢測到至少發現一個哈希槽（沒有可用的節點正在爲其提供服務），它們將停止接受查詢。 這樣，如果集羣部分關閉（例如，不再覆蓋哈希槽的範圍），則所有集羣最終將變得不可用。一旦再次覆蓋所有插槽，它將自動返回可用狀態。下方是原文

By default Redis Cluster nodes stop accepting queries if they detect there is at least an hash slot uncovered (no available node is serving it). This way if the cluster is partially down (for example a range of hash slots are no longer covered) all the cluster becomes, eventually, unavailable. It automatically returns available as soon as all the slots are covered again.

但是，有時您希望正在運行的集羣子集繼續接受對仍覆蓋的部分鍵空間的查詢。 爲此，只需將cluster-require-full-coverage選項設置爲no。

cluster-require-full-coverage yes

設置爲yes時，此選項可防止副本在主服務器發生故障時嘗試對其主服務器進行故障轉移。 但是，主服務器仍然可以執行手動故障轉移（如果被迫執行）。

這在不同的情況下很有用，尤其是在多個數據中心操作的情況下，如果在DC完全故障的情況下不希望一側不升級，則尤其如此。

cluster-replica-no-failover no

如果將此選項設置爲yes，則允許節點在羣集處於關閉狀態時爲讀取流量提供服務，只要它認爲自己擁有slots即可。

這對於兩種情況很有用。 第一種情況是在節點故障或網絡分區期間應用程序不需要數據一致性時。 一個示例是高速緩存，只要節點具有數據，它就應該能夠爲其提供服務。

第二個用例用於不符合建議的三個分片但要啓用集羣模式並在以後擴展的配置。 如果沒有設置此選項，則在1或2分片配置中的主服務器中斷會導致整個集羣的讀/寫中斷，只有在設置了該選項的情況下，纔會發生寫中斷。 沒有法定人數的主持人，插槽所有權將不會自動更改。下方原文

The second use case is for configurations that don't meet the recommended three shards but want to enable cluster mode and scale later. A master outage in a 1 or 2 shard configuration causes a read/write outage to the entire cluster without this option set, with it set there is only a write outage. Without a quorum of masters, slot ownership will not change automatically.

cluster-allow-reads-when-down no

爲了設置羣集，請確保閱讀http://redis.io網站上的可用文檔。

 

CLUSTER DOCKER/NAT support

在某些部署中，Redis Cluster節點的地址發現失敗，這是因爲地址經過NAT限制或端口被轉發（典型情況是Docker和其他容器(containers)）。

爲了使Redis Cluster在這樣的環境中工作，需要一個靜態配置，其中每個節點都知道其公共地址。 以下兩個選項用於此範圍，分別是：

• cluster-announce-ip
• cluster-announce-port
• cluster-announce-bus-port

每個命令都向節點指示其地址，客戶端端口和羣集消息總線端口。 然後將信息發佈在總線數據包的報頭中，以便其他節點將能夠正確映射發佈信息的節點的地址。

如果未使用上述選項，則將使用常規的Redis羣集自動檢測。

請注意，重新映射時，總線端口(bus port)可能不在客戶端端口+ 10000的固定偏移處，因此您可以根據重新映射的方式指定任何port和bus-port。 如果未設置bus-port，通常將使用10000的固定偏移量。

Example:
 cluster-announce-ip 10.1.1.5
 cluster-announce-port 6379
 cluster-announce-bus-port 6380

 

SLOW LOG

Redis Slow Log是一個用於記錄超過指定執行時間的查詢的系統。 執行時間不包括與客戶端交談，發送回覆等 I/O 操作，而是實際執行命令所需的時間（這是命令執行的唯一階段，在該階段線程被阻塞並且無法同時處理其他請求）。

您可以使用以下兩個參數配置慢速日誌：一個告訴Redis爲了使命令被記錄而超過執行時間（以微秒爲單位），另一個參數是慢速日誌的長度。 記錄新命令時，最舊的命令將從記錄的命令隊列中刪除。

以下時間以微秒錶示，因此1000000等於一秒。 請注意，負數將禁用慢速日誌記錄，而零值將強制記錄每個命令。

slowlog-log-slower-than 10000

該長度沒有限制。 請注意，它將消耗內存。 您可以使用SLOWLOG RESET回收慢速日誌使用的內存。

slowlog-max-len 128

 

LATENCY MONITOR

Redis延遲監視子系統會在運行時對不同的操作進行採樣，以收集與Redis實例的潛在延遲源相關的數據。

通過LATENCY命令，該信息可供打印圖形並獲取報告的用戶使用。

系統僅記錄在等於或大於通過delay-monitor-threshold配置指令指定的毫秒數內執行的操作。 當其值設置爲零時，等待時間監視器( latency monitor)將關閉。

默認情況下，延遲監視是禁用的，因爲如果您沒有延遲問題，則通常不需要監視，並且收集數據會對性能產生影響，儘管影響很小，但是可以在大負載下進行測量。 如果需要，可以在運行時使用命令“ CONFIG SET delay-monitor-threshold <milliseconds>”輕鬆啓用延遲監視。

latency-monitor-threshold 0

 

EVENT NOTIFICATION

Redis可以將關鍵空間中發生的事件通知給發佈/訂閱客戶端。 此功能記錄在http://redis.io/topics/notifications

例如，如果啓用了鍵空間事件通知，並且客戶端對存儲在數據庫0中的鍵“ foo”執行了DEL操作，則將通過Pub / Sub發佈兩條消息：

PUBLISH __keyspace@0__:foo del
PUBLISH __keyevent@0__:del foo

可以在一組類中選擇Redis將通知的事件。 每個類都由一個字符標識：

• K Keyspace事件，以 __keyspace@<db>__ 前綴發佈。
• E Keyevent事件，以 __keyevent@<db>__ 前綴發佈。
• g 通用命令（非類型專用），例如DEL，EXPIRE，RENAME，...
• $ String commands
• l List commands
• s Set commands
• h Hash commands
• z Sorted set commands
• x Expired 事件（每次key過期時生成的事件）
• e Evicted 事件（將key驅逐到最大內存時生成的事件）
• t Stream commands
• m Key-miss事件（注意：它不包含在“ A”類中）
• A g$lshzxet的別名，因此“ AKE”字符串表示所有事件（由於key-miss事件的獨特性質，這些鍵事件被排除在“A”之外）。

“notify-keyspace-events”將由零個或多個字符組成的字符串作爲參數。 空字符串表示已禁用通知(notifications)。

示例：要啓用列表事件和通用事件，請從事件名稱的角度使用：

notify-keyspace-events Elg

Example 2: to get the stream of the expired keys subscribing to channel name 、__keyevent@0__:expired use:

notify-keyspace-events Ex

默認情況下，所有通知都被禁用，因爲大多數用戶不需要此功能，並且該功能會有一些開銷。 請注意，如果您未指定K或E中的至少一個，則不會傳遞任何事件。

notify-keyspace-events ""

 

GOPHER SERVER

Redis包含Gopher的實現RFC 1436（https://www.ietf.org/rfc/rfc1436.txt）中指定的協議。

Gopher協議在90年代後期非常流行。 它是Web的替代方法，服務器和客戶端的實現是如此簡單，以至於Redis服務器只有100行代碼才能實現這種支持。

您現在如何使用Gopher？ 好吧，Gopher從未真正死過，最近出現了一種運動，目的是使僅由純文本文檔組成的Gopher更高層次的內容得以復活。 有些人希望使用更簡單的互聯網，另一些人則認爲主流互聯網已變得過於可控，爲想要一點新鮮空氣的人們創造替代空間很酷。

無論如何，在Redis誕生10週年之際，我們給了它Gopher協議作爲禮物。

 

--- 這個怎麼運作？(HOW IT WORKS?) ---

Redis Gopher支持使用Redis的內聯協議，特別是兩種非法的內聯請求：空(empty)請求或任何以“/”開頭的請求（沒有以這樣的斜槓開頭的Redis命令）。 正常的RESP2/RESP3請求完全超出了Gopher協議實現的範圍，並且通常也得到滿足。

如果在啓用Gopher後打開與Redis的連接，並向其發送“/foo”之類的字符串，則如果存在名爲“/foo”的key，則會通過Gopher協議爲其提供服務。

爲了創建一個真正的Gopher“漏洞”（Gopher對話中Gopher站點的名稱），您可能需要類似以下的腳本：https://github.com/antirez/gopher2redis

 

--- 安全警告 (SECURITY WARNING) ---

如果您打算將Redis放在服務器Gopher頁面的公共訪問地址上，請確保爲實例設置密碼。 設置密碼後：

1. Gopher服務器（啓用後，默認情況下未啓用）仍將通過Gopher提供內容。
2. 但是，在客戶端進行身份驗證之前無法調用其他命令。

因此，請使用“ requirepass”選項來保護您的實例。

要啓用Gopher支持，請取消註釋以下行，並將選項從no（默認）設置爲yes。

gopher-enabled no

 

ADVANCED CONFIG(高級配置)

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

hash-max-ziplist-entries 512
hash-max-ziplist-value 64

列表也以特殊的方式編碼以節省大量空間。每個內部列表節點允許的條目數可以指定爲固定的最大大小或最大元素數。

對於固定的最大大小，請使用-5到-1，表示：

• -5: max size: 64 Kb <-- 不建議用於正常工作負載
• -4: max size: 32 Kb <-- 不建議
• -3: max size: 16 Kb <-- 可能不推薦
• -2: max size: 8 Kb <-- Good(好)
• -1: max size: 4 Kb <-- good

正數表示每個列表節點最多可以存儲該數量的元素。

性能最高的選項通常是-2（8 Kb大小）或-1（4 Kb大小），但是如果您的用例是唯一的，請根據需要調整設置。

list-max-ziplist-size -2

列表也可以被壓縮。 壓縮深度是指從列表的每個一側到從壓縮中排除的快速列表ziplist 節點的數量。 爲了快速執行push/pop操作，列表的首尾始終未壓縮。 設置爲：

• 0：禁用所有列表壓縮
• 1：深度1表示“直到1個節點進入列表之後，從頭到尾：So: [head]->node->node->...->node->[tail]；[head]，[tail]將始終未壓縮； 內部節點將壓縮。
• 2：[head]->[next]->node->node->...->node->[prev]->[tail]；這裏的2表示：不要壓縮head或head-> next或tail-> prev或tail，而是壓縮它們之間的所有節點。
• 3：[head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail] 等等

list-compress-depth 0

在僅一種情況下，集合具有特殊的編碼：當集合僅由字符串組成，這些字符串恰好是基數爲10的整數，其範圍爲64位有符號整數。 以下配置設置設置了大小限制，以便使用此特殊的內存節省編碼。

set-max-intset-entries 512

與hashes 和lists類似，對排序集也進行了特殊編碼，以節省大量空間。 僅當排序集的長度和元素低於以下限制時，才使用此編碼：

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

HyperLogLog 稀疏(sparse)表示形式的字節數限制。 限制包括16個字節的標頭。 當使用稀疏表示的HyperLogLog超過此限制時，它將轉換爲密集表示。

大於16000的值完全沒有用，因爲在那一點上，密集表示的存儲效率更高。

建議值約爲3000，以便在不降低過多PFADD的情況下獲得節省空間編碼的好處，而PFADD的稀疏編碼爲 O(N) 。 當不關心CPU但空間很大時，該值可以提高到10000，並且數據集由基數在0-15000範圍內的許多HyperLogLog組成。

hll-sparse-max-bytes 3000

Streams macro節點最大大小/項目(max size / items)。 流數據結構是一個大節點的基數樹，該樹對內部的多個項目進行編碼。 使用此配置，可以配置單個節點的大小（以字節爲單位），以及在添加新的流條目時切換到新節點之前它可能包含的最大項目數。 如果以下任何設置被設置爲零，則該限制將被忽略，例如，可以通過將max-bytes設置爲0並將max-entries設置爲所需值來設置maxs整體限制。

stream-node-max-bytes 4096
stream-node-max-entries 100

活動重新哈希處理每100毫秒CPU時間使用1毫秒，以幫助重新哈希主Redis哈希表（將頂級鍵映射到值的一個哈希表）。 Redis使用的哈希表實現（請參見dict.c）執行一次懶惰的重新哈希處理：您在要進行哈希處理的哈希表中運行的操作越多，執行的哈希處理“步驟”就越多，因此，如果服務器空閒，則哈希處理將永遠不會完成 散列表使用更多的內存。以下原文:

Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in order to help rehashing the main Redis hash table (the one mapping top-level keys to values). The hash table implementation Redis uses (see dict.c) performs a lazy rehashing: the more operation you run into a hash table that is rehashing, the more rehashing "steps" are performed, so if the server is idle the rehashing is never complete and some more memory is used by the hash table.

默認值是每秒使用10毫秒的毫秒數來主動刷新主要詞典，並在可能的情況下釋放內存。

如果不確定：

如果您有嚴格的延遲要求，請使用“ activehashing no”，並且在您的環境中，Redis可以不時地以2毫秒的延遲答覆查詢不是一件好事。

如果您沒有如此嚴格的要求，但希望在可能的情況下儘快釋放內存，請使用“ activerehashing yes”。

activerehashing yes

客戶端輸出緩衝區限制可用於出於某些原因強制斷開沒有足夠快地從服務器讀取數據的客戶端的斷開連接（常見原因是，Pub / Sub客戶端不能像發佈者產生消息那樣快地消耗消息。 ）。

可以爲三種不同類別的客戶端設置不同的限制：

• normal -> 普通客戶，包括MONITOR客戶
• replica -> 複製客戶端
• pubsub -> 客戶訂閱了至少一個pubsub頻道或模式

每個client-output-buffer-limit指令的語法如下：

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

一旦達到硬限制，或者達到軟限制並在指定的秒數內（連續）保持達到此限制，客戶端將立即斷開連接。

因此，例如，如果硬限制爲32兆字節，軟限制爲16兆字節/ 10秒，則如果輸出緩衝區的大小達到32兆字節，客戶端將立即斷開連接，但如果客戶端達到16兆字節，則也會斷開連接。 持續超過限制10秒鐘。

默認情況下，普通客戶端不受限制，因爲它們不會在沒有詢問的情況下（以推送方式）接收數據，而是在請求之後才接收數據，因此，只有異步客戶端纔可能創建請求數據比讀取數據更快的場景。

相反，由於訂閱者和副本以push方式接收數據，因此對pubsub和副本客戶端沒有默認限制。

硬限制或軟限制都可以通過將其設置爲零來禁用。

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

客戶端查詢緩衝區會累積新命令。 默認情況下，它們被限制爲固定數量，以避免協議不同步（例如由於客戶端錯誤）導致查詢緩衝區中的未綁定內存使用。 但是，如果您有非常特殊的需求，例如巨大的 multi/exec 請求等，則可以在此處進行配置。

client-query-buffer-limit 1gb

在Redis協議中，批量請求（即表示單個字符串的元素）通常限制爲512 mb以上。 但是，您可以在此處更改此限制。

proto-max-bulk-len 512mb

Redis調用一個內部函數來執行許多後臺任務，例如在超時時關閉客戶端連接，清除從未請求的過期Keys等。

並非所有任務都以相同的頻率執行，但是Redis會根據指定的 "hz" 值檢查要執行的任務。

默認情況下， "hz" 設置爲10。提高該值將在Redis空閒時使用更多的CPU，但是同時當有多個鍵同時到期時，它將使Redis的響應速度更快，並且可以更精確地處理超時。

範圍在1到500之間，但是通常不建議超過100。 大多數用戶應使用默認值10，僅在要求非常低延遲的環境中才將其提高到100。

hz 10

通常，具有與連接的客戶端數量成比例的HZ值很有用。 例如，這有助於避免每次後臺任務調用處理過多的客戶端，從而避免延遲高峯。

由於默認的默認HZ值保守地設置爲10，因此Redis提供並默認啓用了使用自適應HZ值的能力，當有許多連接的客戶端時，該值會暫時升高。

啓用動態HZ後，實際配置的HZ將用作基準，但是一旦連接了更多客戶端，實際將使用配置的HZ值的倍數。 這樣，空閒實例將佔用很少的CPU時間，而繁忙的實例將具有更高的響應速度。

dynamic-hz yes

當孩子(child)重寫AOF文件時，如果啓用了以下選項，則每生成32 MB的數據，文件就會進行同步處理。 這對於將文件更多地提交到磁盤並避免大的延遲峯值很有用。

aof-rewrite-incremental-fsync yes

當redis保存RDB文件時，如果啓用以下選項，則每生成32 MB數據將對文件進行fsync處理。 這對於將文件更多地提交到磁盤並避免大的延遲峯值很有用。

rdb-save-incremental-fsync yes

可以調整Redis LFU 逐出(eviction)（請參閱maxmemory設置）。 但是，最好從默認設置開始，僅在研究瞭如何提高性能以及LFU keys 隨時間變化後再進行更改，這可以通過OBJECT FREQ命令進行檢查。

Redis LFU實現中有兩個可調參數：計數器對數因子和計數器衰減時間。 在更改兩個參數之前，請務必先了解這兩個參數的含義。

LFU計數器每個密鑰只有8位，最大值是255，因此Redis使用具有對數行爲的概率增量。 給定舊計數器的值，當訪問一個鍵時，該計數器以這種方式遞增：

1. 提取介於0和1之間的隨機數R。
2. 概率P被計算爲 1/(old_value*lfu_log_factor+1) 。
3. 僅當R <P時，計數器纔會遞增。

默認的 lfu-log-factor 是10。這是一個表格，該表格顯示了頻率計數器如何隨着具有不同對數因子的不同訪問次數而變化：

 +--------+------------+------------+------------+------------+------------+
 | factor | 100 hits   | 1000 hits  | 100K hits  | 1M hits    | 10M hits   |
 +--------+------------+------------+------------+------------+------------+
 | 0      | 104        | 255        | 255        | 255        | 255        |
 +--------+------------+------------+------------+------------+------------+
 | 1      | 18         | 49         | 255        | 255        | 255        |
 +--------+------------+------------+------------+------------+------------+
 | 10     | 10         | 18         | 142        | 255        | 255        |
 +--------+------------+------------+------------+------------+------------+
 | 100    | 8          | 11         | 49         | 143        | 255        |
 +--------+------------+------------+------------+------------+------------+

注意：上表是通過運行以下命令獲得的：

redis-benchmark -n 1000000 incr foo
redis-cli object freq foo

注意2：計數器的初始值爲5，以便使新對象有機會累積命中數。

計數器衰減時間是必須經過的時間（以分鐘爲單位），以便將key 計數器除以2（如果值小於等於10，則遞減）。

lfu-decay-time的默認值爲1。特殊值0表示每次掃描計數器都會使其衰減。

lfu-log-factor 10
lfu-decay-time 1

 

ACTIVE DEFRAGMENTATION(主動碎片整理)

什麼是主動碎片整理？

主動（online）碎片整理使Redis服務器可以壓縮內存中數據的小分配和釋放之間的剩餘空間，從而可以回收內存。

碎片是每個分配器（幸運的是，使用Jemalloc的情況要少得多）和某些工作負載發生的自然過程。 通常，需要重新啓動服務器以減少碎片，或者至少清除所有數據並重新創建。 但是，由於Oran Agra爲Redis 4.0實現了此功能，因此在服務器運行時，此過程可以在運行時以“hot”方式進行。

基本上，當碎片超過一定級別時（請參閱下面的配置選項），Redis將開始通過利用某些特定的Jemalloc功能在連續的內存區域中創建值的新副本（爲了瞭解分配是否引起碎片，並將其分配到更好的位置），同時將釋放數據的舊副本。 對於所有鍵，以增量方式重複此過程將導致碎片恢復到正常值。

重要事項：

1. 默認情況下，此功能是禁用的，並且僅當您編譯Redis以使用我們隨Redis的源代碼提供的Jemalloc副本時才起作用。 這是Linux構建的默認設置。
2. 如果沒有碎片問題，則無需啓用此功能。
3. 遇到碎片之後，可以在需要時使用命令“ CONFIG SET activedefrag yes”啓用此功能。

配置參數能夠微調碎片整理過程的行爲。 如果您不確定它們的含義，則最好不要更改默認值。

• 啓用主動碎片整理

  • activedefrag no

• 啓動主動碎片整理的最小碎片廢物量

  • active-defrag-ignore-bytes 100mb

• 啓動主動碎片整理的最小碎片百分比

  • active-defrag-threshold-lower 10

• 我們在最大程度地使用碎片的最大百分比

  • active-defrag-threshold-upper 100

• 達到下限閾值時使用的最小的CPU碎片整理工作

  • active-defrag-cycle-min 1

• 達到上限時使用的最大的CPU碎片整理工作

  • active-defrag-cycle-max 25

• 主字典掃描將處理的 set/hash/zset/list 字段的最大數量

  • active-defrag-max-scan-fields 1000

• 默認情況下，將啓用用於清除的Jemalloc後臺線程

  • jemalloc-bg-thread yes

可以將不同的Redis線程和進程固定到系統中的特定CPU，以最大化服務器的性能。這對於將不同的Redis線程固定在不同的CPU中很有用，而且還可以確保 在同一主機上運行的多個Redis實例將被固定到不同的CPU。

通常，您可以使用“ taskset”命令執行此操作，但是在Linux和FreeBSD中，也可以直接通過Redis配置進行此操作。

您可以固定 server/IO 線程，bio線程，aof重寫子進程和bgsave子進程。 指定cpu列表的語法與taskset命令相同：

將Redis服務器/ IO線程設置爲CPU關聯0、2、4、6：

server_cpulist 0-7:2

將bio線程設置爲cpu近似1,3：

bio_cpulist 1,3

將aof重寫子進程設置爲cpu近似8,9,10,11：

aof_rewrite_cpulist 8-11

將bgsave子進程設置爲cpu 近似1,10,11

bgsave_cpulist 1,10-11