redis.conf(版本3.2.6) 翻譯

redis :3.2.6版本

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   都是 相同含義。

################################## 文件包含 ###################################

在這個位置 包含 一個或多個 另外的配置 文件 ： 這樣做 很有用！ 特別是你 有 一個 對大多數redis服務都適用的標準的模版，

並且 只是有一小部分 配置選項需要自定義設置。 包含的文件 又可以再包含其他文件。所以 這樣來使用的情況很多。

注意 “include” 包含的選項  不會被 (由 admin 或 Redis Sentinel  產生的 ） “CONFIG REWRITE” 這樣的命令 覆蓋。 

由於 redis  總是  使用 最後一次處理的那一行 作爲 配置指令 的值， 所以你最好 將 這些“include” 放在這個文件的開頭，這樣就能避免 在 運行的時候 覆蓋 此文件中的配置 。

相反的，你想 使用 “include”s 去 覆蓋 此文件中 配置選項，你最好在此文件的 末尾 使用 “include”s

# include /path/to/local.conf

# include /path/to/other.conf

################################## 網絡 #####################################

默認的， 如果 沒有指定  “bind” 配置指令， Redis 就會 監聽  來自此服務器上 所有網卡接口 的連接。

可以使用  “bind” 配置指令（後邊 跟着 1個或多個ip 地址）  去 監聽 一個 或多個 網卡接口

例如：

# bind 192.168.1.100 10.0.0.1

#bind 127.0.0.1 ::1

~~~ 警告！ ~~~ 如果 運行着 Redis 的這臺計算機 直接 暴露在 internet 網絡中， 那麼 對所有網卡接口都 bind監聽 就是

很危險的！ 將 暴露給internet網絡中的 每個人。 所以 默認的，不要註釋 下面的 bind指令，這樣就會 強制 Redis 去

監聽IPv4 loolback 接口地址（這位意味着 Reids 將 只能 接受 來自 客戶端發到 此（正在運行的redis的）計算機上 綁定了接口的 連接）

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

bind 127.0.0.1 192.168.8.129

保護模式 是一層安全保護，是爲了避免  在internet上保持打開的 Redis實例 被訪問 和被利用。

何時 保護模式應該開啓 ，條件是什麼：

1. 服務 沒有顯式地 用 “bind” 指令 綁定 一些 ip地址。
2.   沒有配置密碼

服務器 僅僅支持 來自 IPv4 和IPv6 loopback 地址 127.0.0.1 和 ::1  和 unix域 套接字 的 客戶端的 連接

默認的 保護模式  是 被禁用的。 如果你想讓來自其他主機 的客戶端 去連接 Redis, 即便是沒有配置密碼驗證，也

沒有 顯式地 使用 bind 指令  列出一些網卡接口 。 

protected-mode yes

在指定的端口 接受連接， 默認是 6379。如果 port指定的 是0, Redis 將不會監聽 TCP 套接字

port 6379

# TCP listen()  積壓日誌(backlog)

#在每秒請求數很高的環境，你需要 高的 backlog, 是爲了避免 慢的 客戶端連接 問題。

#注意 Linux 內核(kernel) 將 默默的 截斷它的值 和  /proc/sys/net/core/somaxconn 的值一樣。

所以，確保同時提高 somaxconn  和  和 tcp_max_syn_backlog 的值 以達到 預期的效果。

tcp-backlog 511

# Unix 域套接字（Unix socket）

#  指定 Unix socket 的路徑 ，這通常用於去監聽新來的連接。 Unix socket 沒有默認值， 所以如果沒有指定

unix socket ,那麼Redis 也不會監聽。

 

# unixsocket /tmp/redis.sock

# unixsocketperm 700

如果 一個客戶端是閒置 N秒，就關閉這個連接。

# TCP 心跳包（keepalive）.

# 如果 非零， 使用 SO_KEEPALIVE 發送 TCP ACKs  給缺乏交流的客戶端。 這樣做很有用！，基於如下兩個原因：

# 1.  檢測 死亡對

# 2.  接受 活着的（從中間的網絡設備角度來看）連接 ；

 

# 在Linux , 用秒爲單位指定的值， 通常作爲 發送ACKs  的間隔時間。 注意， 爲了關閉連接需要雙倍的時間。

# 在其他的內核系統上， 間隔時間取決於 內核的配置。

# 這個選項 合理的，推薦的值是 300秒， 從Redis 3.2.1 開始就開始使用這個新的值了。

tcp-keepalive 300

################################# 常規(GENERAL) #####################################

#  默認 Redis 不會以守護進程方式來運行。 如果你需要守護進程方式來啓動 ，使用 yes  。

# 注意 當守護進程方式的方式運行時， Redis 將會在 /var/run/redis.pid 下創建一個 pid 文件。

daemonize yes

# 如果你從 upstart  或者 systemd 來運行Redis, Redis 可以和 supervison tree 交互。 選項：

#  supervised no    -  無監督交互

#  supervised upstart  -  放 Redis  到 SIGSTOP mode  就會 signal upstart

#  supervised systemd  - 寫 READY=1 到 $NOTIFY_SOCKET 

# supervised auto  -  基於 UPSTART_JOB 或 NOTIFY_SOCKET 環境變量 偵測  upstart 或者method方法。

# 注意：   這些監督方法 僅是  進程只讀的信號

#               他們不啓用  持續不斷的活力 pings 回到 你的 supervisor.

#  supervised no

#  如果 指定了 pid 文件， Redis 在startup 時寫入， 在退出時 刪除 pid 文件

#  當server  非守護進程方式 運行， 且 配置文件也沒有指定，則 不會有pid 文件被創建， 

#  當server  是守護方式運行， 則即便是 沒指定 pid 文件也會被創建，默認是 /var/run/redis.pid

# 創建 一個 pid 文件 是最好的嘗試： 如果redis 不能夠創建 它，也不會有壞的結果產生，服務還是會 正常的開始運行

pidfile /var/run/redis_6379.pid

#  指定服務的 冗餘級別

#  可取的值如下：

#  debug   （對  開發/測試 有用 的 大量的 信息）

#  verbose  （ 許多 罕見 的有用信息， 不像 debug 級別 那樣雜亂）

#  notice  (     適用於 生產環境的， 適量的冗餘信息）

#  warning  ( 只記錄  重要的 或 關鍵的 ）

loglevel notice

 

# 指定日誌文件名， 也可以是空字符，這被通常強制 redis  輸出日誌到標準輸出上， 注意如果你在守護方式運行方式下，使用了

# 標準輸出，那麼日誌 將會被 發送到 /dev/null

logfile ""

# 如果要 記錄 系統日誌，只需要 設置 ‘syslog-enabled’ 爲 yes,  你可以根據你的需要 選擇性的 改變其他的syslog參數

 

# syslog-enabled no

#  指定 syslog 身份

# syslog-ident redis

# 指定 syslog 設置 ， 必須是 USER   或者 在 LOCAL0-LOCAL7.

#  設置數據庫 的數量， 默認的database 是 DB 0,  你可以 使用 select <dbid> where dbid  來爲具體的連接選擇不同的databse

# dbid  是一個數字 取值 在 0 and  ‘databases’-1 之間。

################################ 快照（SNAPSHOTTING）  ################################

保存 DB 到 硬盤上：

save  <seconds> <changes>

如果 指定了 秒數，和指定了寫操作的次數， 那麼就會保存到DB;

下面的例子中，相應的行爲將被保存。

過了 900s ,且 至少有一個 key發生了改變。

過了 300s, 且 至少有10個key 發生了改變。

過了 60s, 且至少有 10000個 key 發生了改變。

注意： 你可以通過 註釋掉所以的”save”行 來 完全禁用 saving 

可以通過  save  指令 攜帶一個 空字符串參數 來移除所有 先前配置的save 點。就想下面這樣：

# save “”

save 900 1

save 300 10

save 60  10000

 

#默認的  如果 RDB 快照 被啓用（至少有一個save 點）並且 最近一次 後臺save 失敗，那麼Redis 將停止接受 寫操作。

這個使用戶意識到數據沒有被很好的持久化到硬盤上， 因此出現的情況是： 沒有人注意到 一些災難將要發生。

# 如果後臺saving進程 再次開始工作，Redis 會自動再次地允許寫。

#  然而 你已經 創建 Redis server 和 持久化 的監控， 你可能想禁用此功能，以讓Redis 繼續正常的工作，即便是發生了一些問題：比如：

硬盤的，權限的等等。

stop-writes-on-bgsave-error yes

 

#  當導出 .rdb 數據庫時，使用LZF 來對 string 對象進行壓縮？

#  默認地， 他將被設置爲 “yes”, 因爲 這幾乎總是最好的選擇。

#  If you want to save some CPU in the saving child set it to 'no' but

#  the dataset will likely be bigger if you have compressible values or keys.

rdbcompression yes

# 由於RDB 5版本 的一個CRC64 校驗和 被放置在文件末尾。 

#  這樣做使這種格式 對 錯誤更加有抵抗能力，但是 當保存或加載RDB文件時，有性能損耗（大約10%） ，所以爲了最高的性能考慮

# 你可以 禁止它。

#  沒有 校驗和的 RDB 文件  有 zero 校驗，這個是爲了告訴 加載的代碼 跳過 檢測。

# rdbchecksum yes

# 將DB 導出 後的文件名

dbfilename dump.rdb

工作目錄

DB將被寫到此目錄，並使用上面 “dbfilename” 配置指令指定的名字。

僅僅是追加的文件 也會被創建到此目錄。

注意：你必須在這裏指定一個目錄，而不是文件。

dir ./

################################# 主從複製(REPLICATION) #################################

主從複製， 使用 slaveof   去  創建 另一個Redis 服務的 一個複製實例。 關於Redis 複製，需要理解下ASAP的一些方面。

1）Redis 複製 是異步進行的。在沒有達到最少指定數量的從的連接 時， 你可以配置master 來停止接受寫。

2）如果 複製連接 是 在相當短暫的時間內斷掉時，Redis 能夠執行 一個部分的重新同步（同master 的）；你可能想要配置 複製 的backlog size(看這個文件的下個部分）；backlog size的大小取決於你的需求

3）複製 時自動的，不需要用戶的交互，像網絡如果出現問題， 複製會自動 重新嘗試連接master 和重新和master同步

# slaveof <masterip>  <masterport>

# 當 slave 失去和 master的連接， 或者 複製 仍在處理中， 那麼 slave 可以有兩種不同的行爲：

1） 如果 slave-server-stale-data  被設置爲 ‘yes’ (默認地），slave 仍然會響應 客戶端的請求， 可能響應的是過期數據，或者數據是空的

2） 如果 slave-serve-stale-data 被設置爲 ‘no’,  slave 將響應一個錯誤“ SYNC with master in progress” 給 除了INFO 和 SLAVEOF的 所有的命令

slave-serve-stale-data yes

#你可以 配置 slave 實例 去接受或不接受 寫。 slave支持寫 可能  對   存儲一些   短暫臨時的數據  是很有用的，（因爲 寫在slave 的數據 可以很容易的在和master同步後被刪除）， 但 如果客戶端的錯誤配置，也會引起問題

從 Redis 2.6 之後 默認的 slave 是隻讀的。

注意： 從服務 只讀 設置 不是  專爲  暴露給  在internet網絡上不信任的客戶端 設計的。它僅僅是 防止 錯誤使用 實例的 一個保護層。只讀  的從服務 默認地仍然會暴露所有的 管理性質的命令 如： “CONFIG”, “DEBUG”, 等等。 在一定程度上，你可以通過 使用“rename-command” 來掩蓋所有的管理的/危險的 命令。

slave-read-only yes

#複製   同步策略 ： 硬盤 或者  socket

警告： 無硬盤複製  當前是 實驗性質。

#新的 slaves  和 重新建立連接的slave 是不能夠繼續 複製處理。 需要做的是叫做“全部同步“。

# 一個 RDB 文件 從 master 被傳播到 slaves.

#  有兩種不同的 傳播方式：

# 1） 硬盤back  :  master  創建一個新的 進程來在硬盤上寫 RDB 文件， 之後file 增量方式  從父進程 傳輸到 slave 。

#2） 無硬盤：  master  創建一個新的進程  ，他 直接將 RDB文件 寫到 slave  sockets, 完全不需要落地到硬盤

#使用硬盤的複製方式， RDB 文件生成時， 多個slave 排隊等待着處理， 當前RDB 文件被處理完成後，他就可以使用RDB文件來提供服務了。

無硬盤的複製 是 ，當前 一個 結束後，後邊排隊的傳輸就開始了。

#當使用 無硬盤複製時，master 可以等待一定時間（幾秒） 再開始傳輸，爲的就是 多個 slave 都能到達，然後並行傳輸。

#像 慢的硬盤速度， 和 快的，有大帶寬的網絡環境， 無硬盤複製 就更適合了。

repl-diskless-sync no

# 當啓用 無硬盤複製， 就很有必要 配置 延遲時間了， 這是爲了並行的開啓多個子進程  來通過 socket  將 RDB 傳輸 給 slaves

# 這很重要，因爲 一旦開始 傳輸了，他就不能去 服務 新來的slave  了， 新來的，只能排隊 等待下一次的 RDB 傳輸， 所以master

等待 一個 delay 時間 就是爲了 讓更多的slave  能及時到達。

# delay  以秒 爲單位， 且 默認 爲 5 秒， 爲了完全禁用它，你可以將它設置爲0， 這樣傳輸 使用 ASAP 方式

repl-diskless-sync-delay 5

# slaves  會 以事先定義好的間隔時間來發送PING 包。可以通過下面的選項 來改變 這個間隔時間的 值， 默認的值 是 10秒

# repl-ping-slave-period 10

#下面的 選項 設置 複製的超時時間 是爲了：

#1） 同步期間 大體量的傳輸 IO， 從slave角度看

#2）master超時時間， 從slaves 角度看 （data, pings)

# 3） slave 超時時間， 從 master角度看 ( Replconf ACK pings).

# 

#  很重要的一點是 一定要 確保 下面選項的值 比 “repl-ping-slave-period “ 指定的 值大； 否則每次 master 和slave 的傳輸都會被

#認爲是 發生超時了，這是很很低效的傳輸。

#

# repl-timeout 60

#  在同步完成後 在 slave socket 上 禁用 TCP_NODELAY？

#  如果你設置爲 “yes”  , Redis 將 使用 少量的TCP包 和少帶寬 來發送數據給 slaves.   

#  但是這會使 數據到達 slave 上 增加延遲， 根據Linux 內核的默認配置 是 40毫秒。

# 如果 你 設置爲“no”,  數據到達slave 側 的延遲將會降低，但是會使用更多的帶寬。

# 默認的 我們優化的目標 是 低延遲， 但是在非常高的 傳輸負載 下、或者 master 和 slave 有許多跳 時，使用“yes” 可能是個好辦法。

repl-disable-tcp-nodelay no

#  設置複製 的“積壓大小” 。 這個 “backlog”   就是 緩衝，   有時slaves 失去連接時，積累從的數據 就放在這個緩衝區中， 所以當

# slave 再次連接進來，通常沒必要進行一個 完全的 同步，只需要部分的再 同步 就足夠了，只需要傳遞 slave 失去連接的這段時間的數據即可。

#  

#  將 backlog 設置爲更大的值，就能支持 slave 失去連接的 時間更長。

#   backlog 內存 只會被分配一次， 必要條件是 “至少有一個 slave ”，

#

# repl-backlog-size 1mb

#

#  在  master 和 slave 的連接 斷開一定時間後，backlog 對應緩衝區 將被釋放， 下面的配置選項 單位是秒。

#

#  0 的值 意味着 從來不要釋放 backlog.

#

#  # repl-backlog-ttl 3600

#  有 小數字權重的 slave 是更有可能被 晉升， 所以 如果 現在 有 三個 slave  權重 分別是 10， 100， 25， 哨兵將會選擇 值爲10的slave,

# 因爲 他的值最小

#  

# 然而 0 值的slave， 不能夠擔任master,  所以 0 值的slave, 不會被哨兵選擇來晉升。

#

# 默認的 權重的值 是 100

# slave-priority 100

#

 

#   “如果 在 M秒的時間內，少於 N 個 slave 連接， master 就停止接受 寫” 這是可以做到的，

#

#  N 個Slave  需要是 在線的狀態。

#

#  遲滯 的單位是秒， 它必須 小於等於 指定的值M， 遲滯的計算是從 收到上一個slave 發來的ping 開始計算。ping 通常每秒發送一個。

#

#  這個選項 不保證 N 個 slave 能接受 write,  但它可以限制  。。。。

#

#   例如： 至少 需要3 個 slave,  遲滯 小於等於 10秒 如下設置：

#

# min-slaves-to-write 3

# min-slaves-max-lag 10

 

#  可以 設置 上面的 爲 0   來禁用 此功能

#

#  默認的  “min-slaves-to-write” 被設置爲 0 （禁用此功能），min-slaves-max-lag  被設置爲 10

#

#  master 能夠 以各種方式 列出 slave 的 地址 和端口 。如：  “ INFO replication” , 它通常由  哨兵使用， 爲了去發現 slave.

#   另外一個地方 就是 master  的 “ROLE” 命令 的 輸出信息也包含它， 

#  slave 的 IP 地址 可以由 下面兩種方式獲取：

#  

#  IP： 可以通過 slave  到 master 連接 的 sockets 對 來自動的獲取 到

#   Port :   在 slave 複製 的 握手階段，就可以得知 端口，

#  然而 當 端口轉發 或者 使用NAT  ， slave 可能被  通過 不同的IP 和 端口 到達。  下面的 兩個選項，slave 用來去 報告 給  master 它的 IP和port,

#  爲了 INFO  和 ROLE  能報告 這些值。

#

# slave-announce-ip 5.5.5.5

# slave-announce-port 1234

################################## 安全（SECURITY） ###################################

#要求 客戶端 在處理任何命令前 發出 AUTH <PASSWORD> 。 這可能 在某種環境下很有用，這樣環境是：你不信任其他的客戶端去訪問正在 運行着的 Redis服務器

#

# 爲了先後兼容，你可以註釋掉它，因爲大多數人不需要 auth （例如： 他們 運行他們自己的  服務器）

#

#  注意：  由於redis  是相當快， 外部的用戶  可以 以每秒 15萬次 去嘗試。 這意味着 使用 一個非常健壯的密碼， 否則很容易被破解。

#

# requirepass foobared

#

#  重命名 命令

#

# 在 一個共享的環境中 去對 危險的命令去重命名，是被允許的。例如 ： CONFIG 命令， 它可以被重命名爲 更難猜的名字，這樣一般的客戶端

# 就不能再使用，對於內部使用的 工具 還是仍然可以使用此命令的。

#

# 例如:

#

# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

#

#  去完全禁用 一個命令 也是可以的，方法就是 重命名爲空字符串：

#

# rename-command CONFIG ""

#

#注意： 命令的名字，這種行爲也會被記錄在AOF 文件中 ，也會傳輸到slave 中，可能會引起問題。

################################### 限制（LIMITS） ####################################

#設置 在同一時間 的 最大 客戶端鏈接數量。 默認的，這個 limit 被設置爲 10000 客戶端。。。。

#

# 一旦 限制達到了， Redis將關閉所有新的連接，併發送給連接的另一端 一個錯誤“ max number of clients reached’.

#

# maxclients 10000

 

# 不要 使用內存超過 指定數量的字節

# 當 到達了內存限制，Redis 將 根據 相應的驅逐策略( maxmemory-policy ) 來嘗試移除 keys.

#

#  如果 不能夠根據 策略 來移除 keys 或者 policy 被設置爲 ‘不驅逐’， Redis 將 對一些命令響應  錯誤信息， 這些命令像

#  SET,  LPUSH,等等， 但它會繼續正常的響應 只讀的命令，如 GET.

#

#  如果Redis 被當作 LRU 緩存 時，這個選項很有用， 或者 被用來做一個嚴格內存限制（配合着，使用‘noeviction’ 策略).

#

#  警告： 如果 你的 slaves 開啓了 maxmemory,  ………..【不能理解！】

#

#  簡而言之， 如果 你使用了 slave, 建議你 設置 一個更小的 maxmemory, 爲了在 slave上 系統還能爲 輸出緩衝，留有一些內存空間（

#  但是 如果 是‘noeviction’ 策略，就沒必要這樣做了）。

#

# maxmemory <bytes>

 

# MAXMEMORY 策略： 就是 當內存使用 達到 maxmemory 的值時， Redis 如何去移除keys

#

#  volatile-lru,   ->  使用LRU 算法 移除掉那些帶有 過期時間的key

#  allkeys-lru  ->   使用 LRU算法，移除掉 任意一個 key

# volatile-random  -> 隨機地 刪除 一個帶過期時間的key

# allkeys-random  ->  隨基地刪除 一個 任意的key

#  volatile-ttl   ->  移除那些馬上要過期的key ( 

# noeviction  ->  不過期任何的key， 只是 對寫操作返回一個 錯誤

#

# 注意：  當沒有合適的key 來被刪除時， 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  和  最小值 TTL 算法 不是  那種 罕見的算法， 而是   接近的算法 （都是爲了 節省內存），所以你可以  爲了速度 或者 精確性 來調整它。

#    默認地 Redis 將 檢測 5個keys  然後挑選一個 最近最少使用的， 你可以使用下面的配置 指令改變 這個 採樣大小

#

#    默認的5 是 能產生 足夠好的結果。 10左右 非常接近 真正的LRU,但是花費更多的CPU.  3 是 非常快，但不是非常精確

#

# maxmemory-samples 5

############################## 追加模式（APPEND ONLY MODE） ###############################

 

#   默認地 Reids  同步地到處數據到硬盤上。 這種模式 在大多數模式下 是足夠好了， 但是 Redis進程的問題 或者 突然的 停電 都可能

#  引起幾分鐘的數據丟失 （取決於配置的保存點）

#

#  AOF 模式( Append Only File )是 一個 另類的持久化模式 它提供了更好的 持久性。 像使用了 fsync 策略 保存的數據，Redis 即便是在發生 如：

# 突然斷電的事件 或者 Redis 進程發生問題（但操作系統是仍然正確運行） 的 情況下 也只會丟失 一秒的寫數據。

#

#  AOF  和 RDB 持久化方式 可以被同時使用，沒有任何問題。

#  如果AOF 被啓用了， 在Redis 啓動時 將會加載 AOF文件， 這個文件 會有更好的持久性的保證。

#

#  請 查看 http://redis.io/topics/persistence  來獲取更好的信息。

 

appendonly no

# 只 追加 文件 名字： （默認是 “appendonly.aof”)

appendfilename "appendonly.aof"

 

#  fsync() 調用 告訴 操作系統 去 真實地 寫數據到硬盤上，而不是 等着 爲了有更多的數據到輸出緩衝。

#  一些OS 將真正地刷新數據到硬盤上， 一些其他的OS 將僅僅只是 試着去做 採用 ASAP方式。

#

# Redis  支持三種不同的模式：

#

#  no :  不進行 fsync, 僅讓 OS 想刷新數據的時候再刷新。 這種快。

# always :  每次 寫append only 日誌 就去 fsync。  慢， 但是最安全。

# everysec :  每秒鐘 進行一次 fsync。  折中的方案。

#

#  默認是 “everysec”,   它通常是  速度快 和 數據安全 之間正確的折中，妥協的方案

#

#  更多詳情 可以檢查下面的標題：

#  http://antirez.com/post/redis-persistence-demystified.html

#

#  如果不知道怎麼使用， 就用 ”everysec".

# 

#  appendfsync always

appendfsync everysec

# appendfsync no

# 當AOF fsync 策略被設置爲 always 或 everysec。 則後臺進程就會執行大量的I/O 操作， 在一些Linux配置， Redis 會在

# fsync上 阻塞很長時間。 注意當前 沒有修復這個問題。因爲即便  在不同的線程上執行，也將會阻塞我們的同步寫 調用。

#

#   爲了緩和這個問題， 使用下面的選項 將可以在 主進程正在調用BGSAVE 或 BGREWRITEAOF 時，阻止主進程調用fsync()。

#

#  這意味着 當另一個子進程 正在保存，Redis 的 持久性和 “appendfsync none” 一樣。 在特殊的時期，在特殊情況，Redis可能

# 丟失 達到 30秒（ 這是 Linux  系統的默認設置）的數據。

#

#  如果你有潛在的問題 ，你可以改爲“yes” 。 否則，就讓它爲 “no”, 這是 從 持久性的角度看 是 最安全的選擇。

#

no-appendfsync-on-rewrite no

 

#  自動 重寫 AOF 文件

#  當 AOF 日誌文件 增長超過指定的百分比時， Redis 能夠自動地 重寫 log 文件，含蓄的叫 BGREWRITEAOF， 

#

#  他的運行機制 是： Redis 會記錄最新的AOF 文件的大小（如果 從一啓動就沒有 rewrite 過，那麼就使用一開始的AOF)

#  和 當前的 大小 比較。 如果 當前大小 比 指定的百分比更大，  就會觸發 rewrite。 

#   要給AOF文件 指定一個需要重寫的最小 大小，這個很有用，當AOF文件百分比增加達到了，但大小沒有達到，就可以避免rewrite 了

#

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

 

#  當AOF 數據被加載到內存時，Redis 的啓動進程 會找到 AOF文件，可能會在進程的最後階段將 AOF文件進行重置。

#  這會發生在 當 Redis 是 宕機， 特別是 ext4 文件系統 掛載時，沒有按照數據順序（ 然而 當Redis 自己宕機，或者終止，而操作系統仍然工作正確）

#

#  當這種情況發生時，Redis 既可以推出並返回錯誤，也可以  （如果AOF文件被找到並在最後被重置） 加載更多地加載 數據。下面的選項可以控制此行爲。

#

#  如果 aof-load-truncated 被設置爲 yes,  則 AOF文件被加載並且Redis 服務 會 觸發一個日誌 來通知 用戶這個事情。

#  因此 如果 選項 被 設置爲 ‘no’, 服務器就會以發出錯誤信息終止，並且拒絕去開始啓動。 當 選項被設置爲 no, 用戶需要 在開始服務器前使用 “redis-check-aof”工具去修復AOF文件。

#

#  如果  AOF 文件 在中間部分 被發現 出錯誤了，那麼 Redis 服務 仍然會推出並返回錯誤。 這個選項 僅適用於  當Redis 試着去從AOF文件中 讀取更多的數據，而沒有足夠的

# 數據被發現時。

################################ LUA腳本  （LUA SCRIPTING）  ###############################

#

# lua  腳本的 最大執行時間，單位 “毫秒”

#

#  如果達到了最大執行時間， Redis 將記錄日誌，腳本仍然會執行，並且對 給查詢要查詢的 命令 返回一個錯誤。

#  當 一個正在運行的腳本，超過了最大執行時間，這時只有SCRIPT  KILL 和 SHUTDOWN NOSAVE 命令可以用。 第一個命令可以用來去停止一個腳本，

#  這個命令不認爲是 “寫命令”， 第二個命令用來去關閉服務器， 爲了防止腳本中的寫命令出現問題，並且用戶不想等待腳本的自然終止的這種情況。

#  

#   設置爲 0  或者 負數 值 含義 是 不限制 執行時間，也不會產生警告！

#

 

################################ Redis 集羣 （REDIS CLUSTER ） ###############################

#

# ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

#  警告：實驗性的 ： Redis 集羣被認爲是 標準的代碼， 爲了能夠去給它 一個“成熟”的標籤，我們需要去等待  非凡的比例的用戶去部署在生成環境中。

# ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

#

#   正常情況下 Redis 實例 不是Redis 集羣的一部分； 只有當它被當作集羣節點被啓動時，它才能成爲 集羣節點。 爲了將其作爲一個集羣節點來啓動，集羣需要

#  去掉下面選項的註釋

#

#   cluster-enabled yes

 

#  集羣上的每一個節點 都有一個集羣配置文件。 redis 不被打算手動來編輯， 它被Redis 節點創建和更新。每個Redis 集羣節點都需要個一個不同的 集羣配置文件。

# 要確保 運行在同一個系統上的 實例 不要使用相同的集羣配置文件

#

#  cluster-config-file nodes-6379.conf

#

#  集羣節點超時時間，是毫秒爲單位的， 一個節點 在這個時間內沒有到達，就被認爲處於 一個失敗的狀態。

#

# cluster-node-timeout 15000

#   一個 slave 如果它的數據 看起來很老，他會避免 開始故障轉移。

#

#  對於 slave  當前沒有 一個簡單方式 去 真實的測量他的 數據 有效期， 所以會 有下面的兩種檢查行爲。

#

# 1） 如果這裏有 多個 slave 可以來進行 故障轉移， 他們之間會交換信息，目的就是 選出 優勢最大的那個 slave  (更多的數據來自master 進程）

# slave 將 獲取它自己的排名， 來應用到 故障轉移

#

# 2） 每個slave節點 會 計算他和master 上次交互時的時間。 這可以通過ping 或者 收到的命令， 或者 和master 斷開連接後的時間。

#       如果上次交互是太老， slave 將不會嘗試 去故障轉移。

#

#    第二點 可以被用戶調試到。 具體來說  一個slave 不會執行故障轉移，是由於，和master 的上次交互 的時間 大於：

#

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

#

# 例如： 如果 node-timeout  是 30秒， 並且 slave-validity-factor 是 10， 並且 假定 repl-ping-slave-period 是 10秒 ， 如果 slave 沒能夠 和master交互超過

# 310秒， 那麼slave 將不會嘗試着去故障轉移。

#

#   slave-validity-factor 有一個大的值 可以允許 slave  有一些太老的數據 也能進行故障轉移， 然而 較小的值 可能會阻止集羣 去快速的選擇一個slave.

#

#  爲了最大的可用性， 將slave-validity-factor 設置爲0 值也是可以的，這樣意味着： slaves 將總是 嘗試 去故障轉移 master, 而不管 它上次和master交互的時間

# （ 然而他們總是去根據他們的排名 來 按比例延遲）。

#

# cluster-slave-validity-factor 10

 

#  集羣的 slave 能夠遷移到 孤兒master , 孤兒master  是指沒有 slaves 。  這會改進 集羣   對抗失敗的 能力. 

# 孤兒master  如果在沒有slave 情況下失敗，是不能夠 故障轉移，

#

#  當 對於 老的 master 仍然 至少有一個（number 個）slave時， slave就可以遷移到 孤兒master。 這個number就是 “migration barrier” 。

#  migration barrier 的值  1  意味着 master 至少有一個slave時 ，slave就可以 能遷移。  這個通常反映了 集羣中 每個master  對應的slave 數量。

#

#  默認是 1  ； 你想禁用 這個功能，只需要 設置一個很大值 即可。0 值也是可以設置的，這種設置對 debug很有用，對在生成環境上是很危險的。

#

# cluster-migration-barrier 1

 

#  如果集羣 偵測到  有至少一個 hash slot 沒有被覆蓋（沒有節點對此slot服務），那麼Redis集羣節點就會停止接受 查詢命令。

#  如果 集羣中的部分 掛掉了（例如 ： 一個範圍的 hash slots 不再被覆蓋）， 集羣 將變的 最終地， 不可用。

#   一旦所有的slots 被再次覆蓋，它會 自動變的 可用。

#

#    然而 有時 你想 你的集羣 部分是 正常工作，並能繼續接受 查詢 （這些查詢設計的slot 仍然被覆蓋的）。爲了做到這樣，你只需

#    設置 cluster-require-full-coverage 選項 爲 no。

#

# cluster-require-full-coverage yes

 

#  爲了去設置你的 集羣，首先要確保 查看了 相關文檔。

#  可用的 網址 ： available at http://redis.io web site.

 

################################## 慢查詢日誌 （ SLOW LOG） ###################################

 

#   Redis 的 慢查詢日誌 記錄了 那些超過了指定執行時間的 查詢。這個執行時間 不包括 I/O 操作 像 和客戶端的連接， 發送響應等，

#  它 僅僅是 確實要執行命令需要的時間 （在命令執行期間，線程是阻塞的，並且不能夠在同一時間服務其他的請求）

 

#  下面的時間，單位是微秒， 所以 1000000 是等於 1秒。 負數值 表示 禁用掉 滿查詢日誌， 0值 會強制記錄每個命令。

 

slowlog-log-slower-than 10000

 

#  這裏對 長度沒有限制， 只需要注意的是，它會消耗內存， 你可以 使用 SLOWLOG  重新聲明 內存。

slowlog-max-len 128

 

################################ 潛在的 監控（LATENCY MONITOR） ##############################

 

# Redis 的潛在的監控子系統  在Redis 運行時 可以採集不同的操作，爲了去 收集 Redis實例的數據。

#  通過 LATENCY  命令 用戶能夠獲取 相應的信息，並且可以打印爲 圖像 或 獲取報告。

#

#   系統  僅僅記錄     那些執行時間等於或者大於 “latency-monitor-threshold “ 的值的操作。 當它的值被設置爲0， 則，潛在的監控

#  就被關閉了。

#

#  默認地 潛在監控 被 禁用， 是由於 如果你沒有潛在的問題，它大多數是不需要的，並且收集數據會有性能上的損耗，儘管不大，但在

#  大負載的情況下還是能夠測量到的。如果有需要的話， 在運行時 可以使用“ CONFIG SET latency-monitor-threshold <milliseconds>”命令 來很容易地開啓。

latency-monitor-threshold 0

#

#############################事件通知（ EVENT NOTIFICATION ）##############################

#  Redis 可以  給 Pub/Sub 客戶端 通知一些關於 key空間 的一些事件。

#  這個功能 的 文檔 在： http://redis.io/topics/notifications

#

#  對於實例  如果開啓了 事件通知， 當 一個 客戶端  對 一個 存儲在 Database 0 上 的 “foo” Key 執行 DEL 操作, 則 有兩種消息 會通過

#  Pub/Sub 發佈出去。

#

# PUBLISH __keyspace@0__:foo del

# PUBLISH __keyevent@0__:del foo

#

#  去 選擇 Redis 定義的一個類集的事件  來通知是可能的。 每個類 都被用 一個 單獨的字符 來定義。

# 

#  K   Keyspace 事件，  使用 __keyspace@<db>__  來發布

#  E    Keyevent  事件 ， 使用 __keyevent@<db>__  來發布

#  g   Generic 命令 ， 非指定類型的命令 如： DEL, EXPIRE, RENAME, …

#  $    字符 命令，

#  l     列表命令，

#  s    集合 命令

#  h    哈希 命令

#  z     有序集合命令

#  x    過期事件  （每次 一個key 過期時，就會產生一個事件）

#  e    驅逐事件   （當一個key  被 maxmemory 機制 驅逐掉時 產生）

#  A    g$lshzxe    的別名，所以 “ AKE”  意味着 所有事件。

#

#

#   notify-keyspace-events  接收  一個由  0個或多個 字符組成的字符串 作爲參數。空的字符串 意味着 禁用 通知機制。

#

#  例如 ： 從事件名的 視角 來 啓用 list  和 generic 事件。使用：

#

#  notify-keyspace-events Elg

#

#  例子2:   爲了 獲取 過期key 訂閱的 名叫 __keyevent@0__:expired 的頻道 產生的數據流。

#

#  notify-keyspace-events Ex

#

#  默認地 所有的通知功能是被禁用的，因爲大多數人 不需要使用此功能，並且此功能有些開銷。注意，

#如果你不指定 K 或 E 中至少一個，那麼就不會有事件被投送。

notify-keyspace-events ""

############################### 高級配置 （ADVANCED CONFIG） ###############################

 

#   Hash 當有一些少量的 entry 時 被 使用 一個內存高效的數據結構 編碼， 最大的 entry 數量不要 超過一個 給定的 門檻。

#  這個 門檻 可以使用如下的指令 來配置。

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

 

#   List 也會以一種特殊的方式 來進行編碼，爲了能夠節省空間。

#   每個  list 內部 entry 的數量 可以被    用 固定的內存大小或者 固定的元素數量，來指定。

#  對於固定的內存大小 ，使用 -5  至 -1  ,含義如下：

#   -5  ： 最大大小 ：64Kb  <—   不建議！  對正常的工作負載來說

#  -4 ：最大大小: 32Kb  <— 不建議

#  -3 ：最大大小: 16Kb  <—  可能不建議

# -2  ： 最大大小: 8Kb   <—   好

# -1 ： 最大大小  <—  好

#   整數數值 意味着 每個 list 存儲的真是的 元素的數量

#

#  最高性能的選項 通常是 -2 或 -1

list-max-ziplist-size -2

 

#  List 有可能也被壓縮。

#  compress-depth 是  quicklist  ziplist   從 *each* 到 *exclude*  的節點的數量 。列表的頭和尾總是不被壓縮，

# 是 爲了更快的 push/pop 操作。 設置有：

#  0  :  禁用 所有壓縮

#  1  :   在list 中 從 第一個節點後開始壓縮 ， 不管是 從頭 或尾部 開始都是如此。

#     所以 ：[head]->node->node->...->node->[tail]

#     [head], [tail] 將總是不被壓縮， 內部的節點將被壓縮。

#  2  ：[head]->[next]->node->node->...->node->[prev]->[tail]

#         2意味着 不壓縮 head 或 head->next  或者 or  tail->prev  或者  tail。 但是壓縮他們中間的節點

# 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]

#      等等

list-compress-depth 0

 

#  在某種情況下 會使用特殊的編碼， 這個情況就是  一個 集合 由 字符串組成，碰巧 是 10 進制整型，範圍在 64位無符號整型範圍內。

#   下面的配置 可以設置 集合的限制，這個限制是爲了能夠使用 特殊的節省內存的編碼。

#

set-max-intset-entries 512

 

#  類似哈希、列表 ，有序集合 也會使用特殊的編碼 以 節省許多空間。 

#  當 長度 和 有序集合裏邊的元素 低於 下面的 限制時，纔會使用此編碼。

zset-max-ziplist-entries 128

zset-max-ziplist-value 64