作者：黃湘龍

花了三天時間，把REDIS 3.0.6英文版大部分都翻譯過來了，還有部分沒翻譯完，等我慢慢更新本文章。

原創首發，歡迎同學們糾正錯誤，也歡迎轉載，但請標明出處。

?# Redis在沒有配置文件的情況下也能啟動，但一般不建議無配置啟動

# 帶配置啟動Redis命令如下：

# ./redis-server /path/to/redis.conf

################################ 普通配置 ?#####################################

# Redis默認不以守護進程運行，如何配置為“yes”，那么以守護進程運行

# 如果以守護進程運行，Redis會生成一個進程文件在/var/run/redis.pid

daemonize no

# 如果以守護進程運行，守護進程的進程文件配置

pidfile /var/run/redis.pid

# 監聽端口

port 6379

# TCP listen() backlog.

# 高并發環境下，為了避免出現TCP-IP的accept-quene滿了導致的服務器端丟棄客戶端發上來的SYN包的而引起的慢連接問題，

# 需要把本配置和linux內核的somaxconn配置都設置到一個合理值。

tcp-backlog 511

# 很多地方翻譯如下：

# 指定redis只接收來自于該IP地址的請求，如果不進行設置，那么將處理所有請求，在生產環境中最好設置該項

# 但是，實際上，應該bind的是redis所在服務器網卡的ip。也就是說，如果你的redis服務器有兩張網卡，一張是ip-1,另一張是ip-2，如果你bind ip-1.那么只有請求ip-1的請求會被受理。

# 這塊其實和mysql的bind的意義是一樣的

# Examples:

#

# bind 192.168.1.100 10.0.0.1

# bind 127.0.0.1

# unix上的配置，指定unix的socket文件路勁。Redis沒有預設這個值，如果需要在unix上運行redis，需要設置這兩個值。

# unixsocket /tmp/redis.sock

# unixsocketperm 700

# 關閉N秒內無請求的客戶端連接，如果設置為0，不啟動該功能

timeout 0

# TCP 的keepalive間隔時間

# 如果設置為0，在客戶端沒有請求上來時，使用系統的 SO_KEEPALIVE 值來發送TCP ACKs 給客戶端。

# 發送這個請求給客戶端主要有兩個原因：

# 1.確認此客戶端是否還活著

# 2.更新客戶端和Redis中間的網絡設備上的連接的活躍時間。一些中間網絡設備會定期刪除一些不活躍的連接。

#

# 這個值建議設置為60（秒）

tcp-keepalive 0

# 日志級別：

# debug (產生大量日志，給開發和測試時用)

# verbose (一些正常的日志，比debug少很多)

# notice (適度的日志，一般記錄一些產品問題)

# warning (非常重要和嚴重問題的日志)

loglevel notice

# 日志文件路徑

# 如果設置為空字符串，日志從控制臺輸出

# 如果以守護進程運行，并且本配置為空字符串，那么所有日志輸出到/dev/null

logfile ""

# 是否將redis日志寫入系統日志

# syslog-enabled no

# 系統日志中Redis日志標識

# syslog-ident redis

# 指定syslog 設備（facility), 必須是USER或者LOCAL0到LOCAL7

# syslog-facility local0

# 數據庫個數，默認使用的數據庫是0，可以使用select語句切換數據庫

databases 16

################################ 內存快照 ?################################

# Redis自動快照保存到磁盤或者調用bgsave，是后臺進程完成的，其他客戶端仍然和可以讀寫redis服務器，后臺保存快照到磁盤會占用大量內存。

# 調用save保存內存中的數據到磁盤，將阻塞客戶端請求，直到保存完畢。

# 調用shutdown命令，Redis服務器會先調用save，所有數據持久化到磁盤之后才會真正退出。

# 內存數據持久化配置

# save <時間> <變更次數>

# 兩個條件同時滿足，發生一次落地本地磁盤動作，下面三個配置是或的關系

# 如果不想落地內存中的數據，直接注釋掉下面三個配置即可

# 如果配置成save ""，之前落地的數據都可能被刪除

save 900 1

save 300 10

save 60 10000

# 如果最后一次落地磁盤操作失敗，停止接受客戶端的寫請求，避免出現落地磁盤的數據和內存中的數據不一致

# 一旦持久化動作恢復工作，Redis可以繼續接受客戶端的寫操作

# 如果你有良好的監控系統能監控redis和其持久化的操作，那么你可以屏蔽這個功能。

# 這個功能的副作用是可能會因為持久化的問題影響生產環境。

stop-writes-on-bgsave-error yes

# 指定存儲至本地數據庫時是否壓縮數據，默認為yes，Redis采用LZF壓縮，如果為了節省CPU時間，可以關閉該選項，但會導致數據庫文件變的巨大

rdbcompression yes

# 保存rdb和加載rdb文件的時候CRC64檢驗，可以防止錯誤，但是要付出約10%的性能，可以關閉他，提高性能。

rdbchecksum yes

# 持久化文件名

dbfilename dump.rdb

# 設置工作目錄, rdb文件會寫到該目錄, append only file也會存儲在該目錄下.

dir ./

################################# 數據同步 #################################

# 主從同步。用slaveof的配置來設置本機的Redis作為從實例，實時從主實例讀取數據，成為起鏡像。主要是高可用場景需要本功能。

# 1). 同一個Master可以同步多個Slaves。

# 2). Slave同樣可以接受其它Slaves的連接和同步請求，這樣可以有效的分載Master的同步壓力。因此我們可以將Redis的Replication架構視為圖結構

# 3). Master Server是以非阻塞的方式為Slaves提供服務。所以在Master-Slave同步期間，客戶端仍然可以提交查詢或修改請求。

# 4). Slave Server同樣是以非阻塞的方式完成數據同步。在同步期間，如果有客戶端提交查詢請求，Redis則返回同步之前的數據。

# 5). 為了分載Master的讀操作壓力，Slave服務器可以為客戶端提供只讀操作的服務，寫服務仍然必須由Master來完成。即便如此，系統的伸縮性還是得到了很大的提高。

# 6). Master可以將數據保存操作交給Slaves完成，從而避免了在Master中要有獨立的進程來完成此操作。

# 7). Redis的數據同步是異步進行的，你可以配置主實例在和從實例斷掉連接的時候停止接受客戶端發過來的寫請求。

# 8). 同步是自動完成的，不需要人工干預。主從之間的網絡短暫的斷開后，從再次連上主之后，會自動從上次斷開的時候同步數據。

#

# slaveof <masterip> <masterport>

# 同步密碼

# masterauth <master-password>

# 本配置決定slave實例在和master斷掉連接或者同步過程中是否繼續相應客戶端的請求，默認是響應。

# 如果設置成no，那么slave實例在不同步狀態只會正確響應INFO and SLAVEOF兩個命令，對于其他命令一律返回"SYNC with master in progress"

slave-serve-stale-data yes

# 從實例是否只讀

# 對從實例的寫操作是非常不靠譜的行為，因為這些寫操作可能下一秒就被同步過來的主實例的寫操作給覆蓋了，這個配置默認為yes

# 但對從實例設置為只讀之后，也不以為著你可以把從實例放開給互聯網上的不信任客戶端，因為一些管理命令仍然可以在上面執行

slave-read-only yes

# 同步策略：先寫文件，再通過文件同步；直接寫socket同步.

#

# -------------------------------------------------------

# 注意：直接通過socket進行無文件全量同步，目前還是實驗階段

# -------------------------------------------------------

#

# 當新的從實例連入主實例，或者從實例斷開連接時間比較長，再連入主實例的時候，為了保證數據一致，主實例會將

# 全量數據同步給從實例。稱之為全量同步。這個同步有兩種方式：

#

# 1).Disk-backed:主實例創建一個任務去寫DB文件到磁盤，文件創建完畢后，主實例增量方式讀取文件中的數據傳輸給從實例。

#

# 2).Diskless:主實例創建一個任務把全量數據直接寫入從實例的socket連接上，數據不落地。

#?

# 使用Disk-backed模式同步數據有個好處就是，這個文件一旦生成，多個slave實例過來全量同步，都可以重用這一個文件；

# 使用Diskless模式同步全量數據，一旦一個全量同步行為開始了，其他slave實例的同步請求過來時，只能先排到隊列里面去等下一次全量同步開始。

#

# 使用diskless的數據同步時，master實例會等一會（時間可配），看看這段時間內是否有多個slave實例同時請求全量同步，好湊齊了一塊給所有實例傳輸數據。

#

# 在網絡帶寬充裕的情況下，diskless的同步避免了磁盤io，性能會好很多。

repl-diskless-sync no

# 就是上面說的主實例在開始給slave做全量同步前等待的時間

repl-diskless-sync-delay 5

# 從實例會定期去ping主實例，下面是時間間隔，不設置的話，默認是10秒

# repl-ping-slave-period 10

# 這個選項被以下三個邏輯共用:

#

# 1) 主從間數據同步的超時時間.

# 2) 從實例看到主實例的數據同步或者ping超時時間.

# 3) 主實例發送REPLCONF ACK pings時，從實例超時時間.

#

# 這個配置務必比repl-ping-slave-period這個配置要大，不然在業務量少的時候，每次主實例都會檢測到從實例超時

# repl-timeout 60

# 在從實例發送SYNC后，禁用TCP_NODELAY

#?

# 如果禁用，Redis會發送更少的TCP包，占用更少的帶寬，但會造成從實例上稍微的數據延遲，一般情況，按照linux內核默認配置，這個時間會在40ms

# 如果不禁用，延時會減少，但會使用多一點帶寬。

#

# 一般情況下，我們為了主從的一致性，我們會設置成不禁用。但是在流量非常大的情況，或者帶寬不夠的情況，設置成經用說不定能達到一個理想的效果

repl-disable-tcp-nodelay no

# 同步數據緩存大小

# 有時候從實例會因為網絡或其他原因斷開與主實例的連接，短時間內，從實例又連上主。

# 如果從斷開時間點到連上的時間點之間的所有變化數據都在這個緩存中，那么就不需要全量同步，主實例只需要將這些數據同步到從即可。

# 如果斷開的時間太長，這塊緩存cover不住所有的變動數據，那么就會發生一次主從之間的全量同步。

# 緩存越大，能容忍的斷開時間越長。

# 一旦第一個從實例連上了主實例，主實例就會分配這塊緩存并維護之。

# repl-backlog-size 1mb

# 主實例會在沒有任何從實例連接的情況下清除同步數據緩存。

# 最后一個從實例斷開連接repl-backlog-ttl秒后，主實例開始清理同步緩存數據。

# repl-backlog-ttl設置為零表示永不清理同步緩存

#

# repl-backlog-ttl 3600

# 本配置是一個可以用INFO命令從Redis內查出來的值，語義是在主實例掛了的情況下，根據從實例的優先級推舉那個從實例作為主。

# Redis提供一個叫Redis Sentinel的監控程序做主從監控和主從切換工作。他主要有以下功能：

# 監控（Monitoring）： Redis Sentinel實時監控主服務器和從服務器運行狀態。

#

# 提醒（Notification）：當被監控的某個 Redis 服務器出現問題時， Redis Sentinel 可以向系統管理員發送通知， 也可以通過 API 向其他程序發送通知。

#

# 自動故障轉移（Automatic failover）： 當一個主服務器不能正常工作時，Redis Sentinel 可以將一個從服務器升級為主服務器，?

# 并對其他從服務器進行配置，讓它們使用新的主服務器。當應用程序連接到 Redis 服務器時， Redis Sentinel會告之新的主服務器地址和端口。

# Redis Sentinel 是一個分布式系統， 你可以在架構中運行多個 Sentinel 進程，這些進程通過相互通訊來判斷一個主服務器是否斷線，以及是否應該執行故障轉移。

# 在配置Redis Sentinel時，至少需要有1個Master和1個Slave。當Master失效后,Redis Sentinel會報出失效警告，并通過自動故障轉移將Slave提升為Master，并提供讀寫服務;當失效的Master恢復后，Redis?

# Sentinel會自動識別，將Master自動轉換為Slave并完成數據同步。

#?

# 下面問題來了，他這個切換過程怎么告知所有應用程序呢？他可以通過API向其他應用程序發通知，但我個人認為這個機制沒有KeepAliveD切換網絡虛擬IP可靠。

slave-priority 100

# Redis提供一個功能，用來限制主實例接受寫請求：如果主實例沒有min-slaves-to-write個從實例有效連接，那么主實例拒絕所有客戶端發起的寫請求。

# 有效連接是指從實例最后一次PING主實例的時間到檢查時間的間隔小于min-slaves-max-lag秒。從實例一般每秒發送一次PING。

#

# 本配置主要為了避免從實例失去連接后大量丟失數據，導致必須全量同步的情況發生。

#

# 比如要求主實例必須連接三臺從實例，并且，所有從實例的延遲時間在10秒以內可以這么設置：

#

# min-slaves-to-write 3

# min-slaves-max-lag 10

################################## 安全 ###################################

# Redis的密碼，如果設置，那么在運行任何命令前，必須先輸入密碼。

# 如果你的內網環境有不信任的主機在運行，那么你需要設置這個密碼。如果你的內網是安全的，那么不建議設置本密碼。

#

# Redis允許客戶端每秒嘗試15萬次密碼匹配，如果你密碼不夠強，很容易被破解

#

# requirepass foobared

# 修改命令名

# Redis允許你修改一些危險的命令的指令名。比如你可以把CONFIG修改成一個很難猜測的名字，只有內部人員知道這個名字，以防外人使用次命令：

# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

#

# 你也可以完全禁用一些命令，把一個命令的指令名變為空字符串即可：

# rename-command CONFIG ""

#

# 請注意這些對命令名的修改也會同步到AOF文件中，或者傳輸給從實例中，引起其他問題。

################################### 內存限制 ####################################

# 客戶端連接總數限制，默認值為10000

# 然而如果Redis服務器不能配置處理文件的句柄數來滿足指定的值，那么最大的客戶端連接數就被設置成當前文件限制數減32（因

# 為Redis服務器保留了一些文件描述符作為內部使用）

#

# maxclients 10000

# 內存限制

# 如果Redis使用的內存達到了內存限制，那么Redis會就會動用淘汰策略來處理expaire字典中的鍵，這種場景適合LRU模式

# 如果Redis不能刪除數據，那么Redis停止接受寫請求，開啟只讀模式

#

# 關于maxmemory的設置，如果redis的應用場景是作為db使用，那不要設置這個選項，因為db是不能容忍丟失數據的。

# 如果作為cache使用，則可以啟用這個選項（其實既然有淘汰策略，那就是cache了）

#

# 在集群環境下（尤其是有多個slavers的情形），maxmeomory的值并不是實際redis使用的內存，這個選項值并沒有包括slaver的output buffer。

# redis早期版本出過一個bug，在多個slaver的情形下，設置了maxmemory值，同時設定了淘汰策略，會造成master上的數據被漸漸擦除。

# 需要注意留點內存給同步緩存

# maxmemory <bytes>

# 內存淘汰策略，當內存使用達到限制時，Redis根據此策略刪除數據

#?

# volatile-lru -> 根據LRU算法刪除過期Key

# allkeys-lru -> 根據LRU算法刪除所有Key

# volatile-random -> 隨機算出過期數據

# allkeys-random -> 隨機刪除任意數據

# volatile-ttl -> 根據最近過期時間來刪除（輔以TTL）

# noeviction -> 不刪除任何數據，拒絕客戶端寫請求

#

# 注意：如果Reids在當前策略下找不到可以刪除的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個樣本，然后選出最舊的那個。

#

# maxmemory-samples 5

############################## APPEND ONLY MODE ###############################

# 默認情況下Redis會異步落地內存中的數據到磁盤，這種模式對于很多場景是夠用的。

# 但這種模式有個缺點就是對于突發情況，比如突然停電，落地的文件數據會丟失幾分鐘數據，具體的丟失時間視配置情況而定。

#

# AOF是一種可選的持久化模式，能很好地解決上面說的數據丟失的問題。默認配置下，AOF模式在意外故障發生時最多丟失一秒鐘的數據。

# AOF和RDB兩種持久化模式能同時啟動，不會互相影響。如果AOF模式生效了，那么Redis啟動的時候會首先載入AOF文件來保證數據的可靠性。

#

# AOF文件是可識別的純文本，它的內容就是一個個的Redis標準命令,

# AOF日志也不是完全按客戶端的請求來生成日志的，比如命令 INCRBYFLOAT 在記AOF日志時就被記成一條SET記錄，

# 因為浮點數操作可能在不同的系統上會不同，所以為了避免同一份日志在不同的系統上生成不同的數據集，所以這里只將操作后的結果通過SET來記錄。

# 每一條寫命令都生成一條日志,AOF文件會很大。

#

# 請查看?http://redis.io/topics/persistence?來獲取更多信息.

appendonly no

# AOF模式文件名，默認為 "appendonly.aof"

appendfilename "appendonly.aof"

# 函數fsync()的調用告訴操作系統將同步緩存中的數據真實落地到磁盤，一些操作系統會立即落地，一些會盡量快地落地。

# Redis在落地緩存數據的時候，有三種模式

#

# appendfsync always : 每次有客戶端發送寫操作，都需要落地到磁盤，性能最差，但最安全。

# appendfsync everysec : 顧名思義，每秒寫一次，均衡模式。

# appendfsync no : 操作系統在需要的時候才落地數據到磁盤，性能最好，但可能有數據丟失風險。對大多數Linux操作系統，是每30秒進行一次fsync，將緩沖區中的數據寫到磁盤上。

#

# Redis實用的默認模式是everysec，這是一種均衡的模式。

#

# 請查看下面的文章來獲取更多的細節

#?http://antirez.com/post/redis- ... .html?

appendfsync everysec

# 在AOF同步文件同步模式設置為always或者everysec的時候，會有一個后臺線程去做這個事，同時產生大量磁盤IO。

# 這些IO操作經常會阻塞后臺RDB落地線程和AOF日志重寫線程，甚至導致整個Redis被阻塞，目前沒有很好的解決方案。

#?

# 為了緩解這個問題，Redis增加了本配置，fsync()在BGSAVE或者BGREWRITEAOF時被阻止

# 這就意味這在BGSAVE或者BGREWRITEAOF時，Redis不會去寫AOF，可能會因此丟掉30秒以內的數據。

#?

# 如果你因為AOF寫入產生延遲問題，可以將本配置設置為yes。本配置設置為no為最安全，最不可能丟失數據的方式。

no-appendfsync-on-rewrite no

# AOF重寫

# 在AOF文件增長到足夠大超過配置的百分比的時候，Redis提供AOF重寫功能

#

# Redis的實現方式是這樣的：

# Redis會在啟動的時候或者重寫之后記住此時AOF文件的尺寸，然后定時對比當前AOF文件尺寸和記住的尺寸，如果尺寸達到設定的百分比，觸發AOF重寫

# 將auto-aof-rewrite-percentage設置為0，屏蔽自動重寫能力

#?

# AOF重寫是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。

# 其生成過程和RDB類似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。

# 在寫入新文件的過程中，所有的寫操作日志還是會寫到原來老的 AOF文件中，同時還會記錄在內存緩沖區中。

# 當重完操作完成后，會將所有緩沖區中的日志一次性寫入到臨時文件中。

# 然后調用原子性的rename命令用新的 AOF文件取代老的AOF文件。

#

# 重寫后，AOF文件變成一個非常小的全量文件

# 命令：BGREWRITEAOF， 我們應該經常調用這個命令來來重寫

#?

# 為了避免AOF非常小也發生重寫這樣的操作，我們增加auto-aof-rewrite-min-size配置，在AOF文件尺寸比這個配置小的時候，不發生重寫動作。

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

# 有時候AOF因為突然斷電等（mount ext4文件系統時沒有加上data=ordered選項）特殊原因不完整

# 本配置設置為yes時自動加載，忽略錯誤，然后自動發布一個log給客戶端（默認）

# 本設置設置為no時需要手動使用redis-check-aof工具修改AOF文件后才能啟動Redis

aof-load-truncated yes

################################ LUA SCRIPTING ?###############################

# Lua script腳本最長運行時間限制，單位是毫秒

#

# 如果腳本出現這種情況，Redis會記錄一條日志然后給執行者返回一條錯誤

# 當一條腳本執行時間超過最大限制，只有SCRIPT KILL 和 SHUTDOWN NOSAVE兩條命令能關閉只

# SCRIPT KILL用來關閉沒有寫操作的腳本，SHUTDOWN NOSAVE可以關閉有寫命令的腳本

# 設置成0或者負數，腳本運行時間就無限制了

lua-time-limit 5000

################################ REDIS 集群 ?###############################

#

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

# WARNING EXPERIMENTAL: 開發者認為Redis 集群代碼是穩定的的代碼，但需要一定數量的用戶

# 在生產環境中驗證其成熟程度。

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

# 普通的Redis實例不能加入Redis集群，只有啟動時，本參數設置為yes的Redis實例才能成為集群的一部分

# cluster-enabled yes

# Redis集群中的每個借點都需要一個單獨的配置文件，這個配置文件不建議手動編輯，

# 它是由Redis節點來維護的。注意這個配置文件不能被集群中多個節點復用。

# cluster-config-file nodes-6379.conf

# 集群節點的超時時間

# 超過cluster-node-timeout毫秒連不上的節點會被認為是失效節點

# 一些內部時間限制都是節點超時時間的倍數

# cluster-node-timeout 15000

# A slave of a failing master will avoid to start a failover if its data

# looks too old.

# 集群的策略：Slave發現自己的數據太老了，那么它就不再去取代主。

#

# 沒有一個好的辦法讓slaver去發現自己的數據太老了，目前Redis執行的檢查主要有一下兩點：

# 1)如果有多個可用的從（可以隨時failover主的從），這些從會進行通信交換信息，

# 來確認數據最新的從的數據按照從新到舊的排行，一旦需要failover主的時候，排行中最靠前的從沖上去。

# 2)每個從都會計算自己和主在交互過程中失聯間隔時間，這個時間是這樣計算的：

# 如果是正常的同步聯機狀態，那么這個間隔時間是從最后一次和主的ping或者收到主的同步命令開始到目前的時間；

# 如果從和主斷開連接，那么這個時間從斷開連接的時間開始算。

# 如果這個間隔時間太長，那么這個從就不會再嘗試去failure主。

#

# The point "2" can be tuned by user. Specifically a slave will not perform

# the failover if, since the last interaction with the master, the time

# elapsed is greater than:

#

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

#

# So for example if node-timeout is 30 seconds, and the slave-validity-factor

# is 10, and assuming a default repl-ping-slave-period of 10 seconds, the

# slave will not try to failover if it was not able to talk with the master

# for longer than 310 seconds.

#

# A large slave-validity-factor may allow slaves with too old data to failover

# a master, while a too small value may prevent the cluster from being able to

# elect a slave at all.

#

# For maximum availability, it is possible to set the slave-validity-factor

# to a value of 0, which means, that slaves will always try to failover the

# master regardless of the last time they interacted with the master.

# (However they'll always try to apply a delay proportional to their

# offset rank).

#

# Zero is the only value able to guarantee that when all the partitions heal

# the cluster will always be able to continue.

#

# cluster-slave-validity-factor 10

# Cluster slaves are able to migrate to orphaned masters, that are masters

# that are left without working slaves. This improves the cluster ability

# to resist to failures as otherwise an orphaned master can't be failed over

# in case of failure if it has no working slaves.

#

# Slaves migrate to orphaned masters only if there are still at least a

# given number of other working slaves for their old master. This number

# is the "migration barrier". A migration barrier of 1 means that a slave

# will migrate only if there is at least 1 other working slave for its master

# and so forth. It usually reflects the number of slaves you want for every

# master in your cluster.

#

# Default is 1 (slaves migrate only if their masters remain with at least

# one slave). To disable migration just set it to a very large value.

# A value of 0 can be set but is useful only for debugging and dangerous

# in production.

#

# cluster-migration-barrier 1

# 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.

#

# However sometimes you want the subset of the cluster which is working,

# to continue to accept queries for the part of the key space that is still

# covered. In order to do so, just set the cluster-require-full-coverage

# option to no.

#

# cluster-require-full-coverage yes

# In order to setup your cluster make sure to read the documentation

# available at?http://redis.io?web site.

################################## SLOW LOG ###################################

# The Redis Slow Log is a system to log queries that exceeded a specified

# execution time. The execution time does not include the I/O operations

# like talking with the client, sending the reply and so forth,

# but just the time needed to actually execute the command (this is the only

# stage of command execution where the thread is blocked and can not serve

# other requests in the meantime).

#

# You can configure the slow log with two parameters: one tells Redis

# what is the execution time, in microseconds, to exceed in order for the

# command to get logged, and the other parameter is the length of the

# slow log. When a new command is logged the oldest one is removed from the

# queue of logged commands.

# The following time is expressed in microseconds, so 1000000 is equivalent

# to one second. Note that a negative number disables the slow log, while

# a value of zero forces the logging of every command.

slowlog-log-slower-than 10000

# There is no limit to this length. Just be aware that it will consume memory.

# You can reclaim memory used by the slow log with SLOWLOG RESET.

slowlog-max-len 128

################################ LATENCY MONITOR ##############################

# The Redis latency monitoring subsystem samples different operations

# at runtime in order to collect data related to possible sources of

# latency of a Redis instance.

#

# Via the LATENCY command this information is available to the user that can

# print graphs and obtain reports.

#

# The system only logs operations that were performed in a time equal or

# greater than the amount of milliseconds specified via the

# latency-monitor-threshold configuration directive. When its value is set

# to zero, the latency monitor is turned off.

#

# By default latency monitoring is disabled since it is mostly not needed

# if you don't have latency issues, and collecting data has a performance

# impact, that while very small, can be measured under big load. Latency

# monitoring can easily be enabled at runtime using the command

# "CONFIG SET latency-monitor-threshold <milliseconds>" if needed.

latency-monitor-threshold 0

############################# EVENT NOTIFICATION ##############################

# Redis can notify Pub/Sub clients about events happening in the key space.

# This feature is documented at?http://redis.io/topics/notifications

#

# For instance if keyspace events notification is enabled, and a client

# performs a DEL operation on key "foo" stored in the Database 0, two

# messages will be published via Pub/Sub:

#

# PUBLISH __keyspace@0__:foo del

# PUBLISH __keyevent@0__:del foo

#

# It is possible to select the events that Redis will notify among a set

# of classes. Every class is identified by a single character:

#

# ?K ? ? Keyspace events, published with __keyspace@<db>__ prefix.

# ?E ? ? Keyevent events, published with __keyevent@<db>__ prefix.

# ?g ? ? Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...

# ?$ ? ? String commands

# ?l ? ? List commands

# ?s ? ? Set commands

# ?h ? ? Hash commands

# ?z ? ? Sorted set commands

# ?x ? ? Expired events (events generated every time a key expires)

# ?e ? ? Evicted events (events generated when a key is evicted for maxmemory)

# ?A ? ? Alias for g$lshzxe, so that the "AKE" string means all the events.

#

# ?The "notify-keyspace-events" takes as argument a string that is composed

# ?of zero or multiple characters. The empty string means that notifications

# ?are disabled.

#

# ?Example: to enable list and generic events, from the point of view of the

# ? ? ? ? ? event name, use:

#

# ?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

#

# ?By default all notifications are disabled because most users don't need

# ?this feature and the feature has some overhead. Note that if you don't

# ?specify at least one of K or E, no events will be delivered.

notify-keyspace-events ""

############################### ADVANCED CONFIG ###############################

# Hashes are encoded using a memory efficient data structure when they have a

# small number of entries, and the biggest entry does not exceed a given

# threshold. These thresholds can be configured using the following directives.

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

# Similarly to hashes, small lists are also encoded in a special way in order

# to save a lot of space. The special representation is only used when

# you are under the following limits:

list-max-ziplist-entries 512

list-max-ziplist-value 64

# Sets have a special encoding in just one case: when a set is composed

# of just strings that happen to be integers in radix 10 in the range

# of 64 bit signed integers.

# The following configuration setting sets the limit in the size of the

# set in order to use this special memory saving encoding.

set-max-intset-entries 512

# Similarly to hashes and lists, sorted sets are also specially encoded in

# order to save a lot of space. This encoding is only used when the length and

# elements of a sorted set are below the following limits:

zset-max-ziplist-entries 128

zset-max-ziplist-value 64

# HyperLogLog sparse representation bytes limit. The limit includes the

# 16 bytes header. When an HyperLogLog using the sparse representation crosses

# this limit, it is converted into the dense representation.

#

# A value greater than 16000 is totally useless, since at that point the

# dense representation is more memory efficient.

#

# The suggested value is ~ 3000 in order to have the benefits of

# the space efficient encoding without slowing down too much PFADD,

# which is O(N) with the sparse encoding. The value can be raised to

# ~ 10000 when CPU is not a concern, but space is, and the data set is

# composed of many HyperLogLogs with cardinality in the 0 - 15000 range.

hll-sparse-max-bytes 3000

# 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.

#

# The default is to use this millisecond 10 times every second in order to

# actively rehash the main dictionaries, freeing memory when possible.

#

# If unsure:

# use "activerehashing no" if you have hard latency requirements and it is

# not a good thing in your environment that Redis can reply from time to time

# to queries with 2 milliseconds delay.

#

# use "activerehashing yes" if you don't have such hard requirements but

# want to free memory asap when possible.

activerehashing yes

# The client output buffer limits can be used to force disconnection of clients

# that are not reading data from the server fast enough for some reason (a

# common reason is that a Pub/Sub client can't consume messages as fast as the

# publisher can produce them).

#

# The limit can be set differently for the three different classes of clients:

#

# normal -> normal clients including MONITOR clients

# slave ?-> slave clients

# pubsub -> clients subscribed to at least one pubsub channel or pattern

#

# The syntax of every client-output-buffer-limit directive is the following:

#

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

#

# A client is immediately disconnected once the hard limit is reached, or if

# the soft limit is reached and remains reached for the specified number of

# seconds (continuously).

# So for instance if the hard limit is 32 megabytes and the soft limit is

# 16 megabytes / 10 seconds, the client will get disconnected immediately

# if the size of the output buffers reach 32 megabytes, but will also get

# disconnected if the client reaches 16 megabytes and continuously overcomes

# the limit for 10 seconds.

#

# By default normal clients are not limited because they don't receive data

# without asking (in a push way), but just after a request, so only

# asynchronous clients may create a scenario where data is requested faster

# than it can read.

#

# Instead there is a default limit for pubsub and slave clients, since

# subscribers and slaves receive data in a push fashion.

#

# Both the hard or the soft limit can be disabled by setting them to zero.

client-output-buffer-limit normal 0 0 0

client-output-buffer-limit slave 256mb 64mb 60

client-output-buffer-limit pubsub 32mb 8mb 60

# Redis calls an internal function to perform many background tasks, like

# closing connections of clients in timeout, purging expired keys that are

# never requested, and so forth.

#

# Not all tasks are performed with the same frequency, but Redis checks for

# tasks to perform according to the specified "hz" value.

#

# By default "hz" is set to 10. Raising the value will use more CPU when

# Redis is idle, but at the same time will make Redis more responsive when

# there are many keys expiring at the same time, and timeouts may be

# handled with more precision.

#

# The range is between 1 and 500, however a value over 100 is usually not

# a good idea. Most users should use the default of 10 and raise this up to

# 100 only in environments where very low latency is required.

hz 10

# When a child rewrites the AOF file, if the following option is enabled

# the file will be fsync-ed every 32 MB of data generated. This is useful

# in order to commit the file to the disk more incrementally and avoid

# big latency spikes.

aof-rewrite-incremental-fsync yes