redis2.8配置文件中文翻譯版

# Redis 配置案例
#關(guān)于單位，當你需要指定內(nèi)存的大小時，可以使用如下的單位來指定
#（譯者注，為什么會存在1000為單位，我認為是考慮到硬盤的容量單位是以1000來進行計算而非程序中的1024）
#（因此 使用 1000為單位可以進一步地精確估算出所需的實際硬盤容量）
#
# 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 ###################################

#
#如果你擁有一個標準的配置模板，并且希望在該模板之上坐一些個性化的修改，你可以
#使用include 指令來引入其他的配置文件。
#
#注意："include" 不會被 admin 或者 Redis Sentinel "CONFIG REWRITE" 命令覆蓋。
#（譯者注："CONFIG REWRITE" 是redis 2.8 引入的新命令，用來重寫配置）
#由于redis以最終的配置作為實際配置，因此我們希望你將include命令放置在配置文件的最前面
#以防配置被覆蓋
#如果你打算使用另外的 conf文件來覆蓋當前文件的配置，那么最好將include指令放置到該文件的末尾
#
# 即最后生效原則，最后被解析的配置將作為最后的配置
#
# include /path/to/local.conf
# include /path/to/other.conf

################################ GENERAL #####################################

# redis 默認不是以一個守護進程來運行的，使用 yes，可以讓redis作為守護進程來運行
# 注意：當redis作為守護進程的時候 /var/run/redis.pid 作為 pid 文件
#
daemonize no

# 當redis以守護進程運行時，將會使用/var/run/redis.pid作為 pid文件的位置，也就是
#上一個指令所說的默認，你可以根據(jù)自己的需要修改它
#
pidfile /var/run/redis.pid

# 在指定的端口上進行監(jiān)聽，默認是 6379
# 如果端口設(shè)置為0，那么redis就不會在TCP socket上進行監(jiān)聽
# (譯者注：不在tcp socket上進行監(jiān)聽，不代表沒法連接，只是無法使用網(wǎng)絡(luò)連接而已)
port 6379

# TCP listen() backlog值
#（譯者注：backlog值是指目前最大的連接隊列，因為TCP連接是三次握手）
#（沒有完成三次握手和尚未被accept的connect都會處于連接隊列中，但是backlog的實際值與操作系統(tǒng)相關(guān)）
#（并非設(shè)置多少就是多少，只能說調(diào)整得大一些可以在同一時間應(yīng)對更多的連接請求）
#
#在一個并發(fā)量高的環(huán)境中，你需要指定一個比較大的backlog值來避免慢連接（由于網(wǎng)絡(luò)原因握手速度慢）的情況
#注意，linux內(nèi)核會默認 使用/proc/sys/net/core/somaxconn 的值來削減 backlog的實際值，
#因此你需要確保提升 somaxconn 和 tcp_max_syn_backlog 這兩個值來確保此處的backlog生效
#（譯者注：只有 當每一個請求都重新發(fā)起一個連接的時候，backlog值的增大才能影響到并發(fā)量）
#（在tcp穩(wěn)定連接的時候，或連接復用(連接池的使用)，backlog值對并發(fā)沒有任何影響）
#
tcp-backlog 511

#
#默認情況下redis會在所有的可用網(wǎng)絡(luò)接口中進行監(jiān)聽，如果你想讓redis在指定的網(wǎng)絡(luò)接口中
#監(jiān)聽，那么可以使用bind 命令來指定redis的監(jiān)聽接口
#（譯者科普：網(wǎng)絡(luò)的中的服務(wù)是通過 ip+進程 來進行區(qū)分的，當一個服務(wù)器擁有兩個ip時 ）
#（自然就在網(wǎng)絡(luò)中擁有兩個人身份，如 內(nèi)網(wǎng)，外網(wǎng)，當你只想讓redis在一個網(wǎng)絡(luò)上監(jiān)聽時，就可以使用如下的配置）
# (127.0.0.1 就是指定只能本機進行網(wǎng)絡(luò)訪問)
# 例如:
#
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1

#
#指定unix sock的路徑來進行連接監(jiān)聽，默認是不指定，因此redis不會在unix socket上進行監(jiān)聽
#（譯者注：這個是用來進行進程間通信的時候指定的）
# unixsocket /tmp/redis.sock
# unixsocketperm 755

# 關(guān)閉掉空閑N秒的連接（0則是不處理空閑連接）
timeout 0

# TCP keepalive.
#
#
#如果該值不為0，將使用 SO_KEEPALIVE 這一默認的做法來向客戶端連接發(fā)送TCP ACKs 
#
#這樣的好處有以下兩個原因
# 1）檢測已經(jīng)死亡的對端（譯者注：TCP的關(guān)閉會存在無法完成4次握手的情況，如斷電，斷網(wǎng)，數(shù)據(jù)丟失等等）
# 2）保持連接在網(wǎng)絡(luò)環(huán)境中的存活
#
#
tcp-keepalive 0

# 指定日志的記錄級別的
# 可以是如下的幾個值之一
# debug (盡可能多的日志信息，用于開發(fā)和測試之中)
# verbose (少但是有用的信息, 沒有debug級別那么混亂)
# notice (適量的信息，用于生產(chǎn)環(huán)境)
# warning (只有非常重要和關(guān)鍵的信息會被記錄)
loglevel notice

# 指定日志文件的位置. 為空時將輸出到標準輸出設(shè)備
# 如果你在demo模式下使用標準輸出的日志，日志將會輸出到 /dev/null
logfile ""

# 當設(shè)置 'syslog-enabled'為 yes時， 允許記錄日志到系統(tǒng)日志中。
# 以及你可以使用更多的日志參數(shù)來滿足你的要求

# syslog-enabled no

# 指定在系統(tǒng)日志中的身份
# syslog-ident redis

# 指定系統(tǒng)日志的能力. 必須是 LOCAL0 到 LOCAL7 之間（閉區(qū)間）.
# syslog-facility local0

#設(shè)置數(shù)據(jù)庫的編號. 默認的數(shù)據(jù)庫是DB 0
#使得你可以在每一個連接的基礎(chǔ)之上使用 SELECT dbid> 來指定另外的數(shù)據(jù)庫，但是這個值必須在 0到 'database'-1之間

databases 16

################################ SNAPSHOTTING ################################
#
# 保存 DB 到硬盤:
#
#  save seconds> changes>
#
#  將會在seconds> 和 changes>兩個值同時滿足時，將DB數(shù)據(jù)保存到硬盤中
#  其中seconds> 每多少秒，changes>是改變的key的數(shù)量
#
#  在以下的例子中，將會存在如下的行為
#  當存在最少一個key 變更時，900秒(15分鐘)后保存到硬盤
#  當存在最少10個key變更時，300秒后保存到硬盤
#  當存在最少1000個key變更時，60秒后保存到硬盤
#
#  提示: 你可以禁用如下的所有 save 行
#
#  你可以刪除所有的save然后設(shè)置成如下這樣的情況
#
#
#
#  save ""

save 900 1
save 300 10
save 60 10000

#
# 作為默認，redis會在RDB快照開啟和最近后臺保存失敗的時候停止接受寫入(最少一個保存點)
#這會使得用戶察覺（通常比較困難）到數(shù)據(jù)不會保持在硬盤上的正確性，否則很難發(fā)現(xiàn)
#這些災(zāi)難會發(fā)生
#
# 如果后臺保存程序再次開始工作，reidis會再次自動允許寫入
#
#然而如果對redis服務(wù)器設(shè)置了合理持續(xù)的監(jiān)控，那么你可以關(guān)閉掉這個選項。
#這會導致redis將繼續(xù)進行工作，無論硬盤，權(quán)限或者其他的是否有問題
#
#


stop-writes-on-bgsave-error yes

# 是否在dump到 rdb 數(shù)據(jù)庫的時候使用LZF來壓縮字符串
# 默認是 yes，因為這是一個優(yōu)良的做法
#
# 如果你不想耗費你的CPU處理能力，你可以設(shè)置為 no，但是這會導致你的數(shù)據(jù)會很大


rdbcompression yes

# 從RDB的版本5開始，CRC64校驗值會寫入到文件的末尾
#這會使得格式化過程中，使得文件的完整性更有保障，但是這會在保存和加載的時候損失不少的性能(大概在10%)
#你可以關(guān)閉這個功能來獲得最高的性能
#
#RDB文件會在校驗功能關(guān)閉的時候，使用0來作為校驗值，這將告訴加載代碼來跳過校驗步驟

rdbchecksum yes

# DB的文件名稱

dbfilename dump.rdb

# 工作目錄.
#
# DB將會使用上述 'dbfilename'指定的文件名寫入到該目錄中
# 
# 追加的文件也會在該目錄中創(chuàng)建
# 
# 注意，你應(yīng)該在這里輸入的是一個目錄而不是一個文件名
dir ./

################################# REPLICATION #################################

# 主從復制。使用 slaveof 命令來 指導redis從另一個redis服務(wù)的拷貝中來創(chuàng)建一個實例
#
#注意：這個配置是主從結(jié)構(gòu)的從（主從結(jié)構(gòu)的從，怎么那么拗口呢）redis的本地配置
#
#如下例子，這個配置指導 slave (從redis) 通過另一個redis的實例的ip和端口號來獲取DB數(shù)據(jù)
#
#
#
# slaveof masterip> masterport>


#
# 如果主服務(wù)器開啟了密碼保護(使用下面的"requirepass"配置)
# 這個配置就是告訴從服務(wù)在發(fā)起向主服務(wù)器的異步復制的請求之前使用如下的密碼進行認證，
#否則主服務(wù)器會拒絕這個請求
#
#
#
# masterauth master-password>


#
# 如果從服務(wù)器失去了和主服務(wù)器之間的連接，或者當復制仍然處于處理狀態(tài)的時候
# 從服務(wù)器做出如下的兩個行為
#
# 1）如果 slave-serve-stale-data 被設(shè)置為 yes(默認值)，從服務(wù)器將會持續(xù)
# 回復來自客戶端的請求，可能會回復已經(jīng)過期的數(shù)據(jù)，或者返回空的數(shù)據(jù)，當從服務(wù)器第一次異步請求數(shù)據(jù)時。
#
# 2）如果 slave-serve-stale-data 被設(shè)置為 no ，從服務(wù)器就會返回"SYNC with master in progress"
# 這個錯誤，來應(yīng)答所有命令除了 INFO 和 SLAVEOF
#

slave-serve-stale-data yes


#
#
# 你可以配置一個從服務(wù)器的實例是否接受寫請求，
# 從服務(wù)器在存儲一些短暫的數(shù)據(jù)的的時候，接收寫請求是一件非常正確的事情
# （因為數(shù)據(jù)在向主服務(wù)器同步之后非常容易擦除）但是會因為配置不正確而導致一些問題
#
# 從redis 2.6開始默認從服務(wù)器是只讀的服務(wù)器
#
#
#
#提示：只讀的從服務(wù)器并不是設(shè)計用來公開給不受信任的互聯(lián)網(wǎng)客戶端的，它
#僅僅是一個用來防止對實例進行誤操作的保護層。只讀從服務(wù)器默認用來輸出管理命令
#例如 CONFIG, DEBUG 和其他。如果你想限制它的規(guī)模，你可以使用'rename-command'來
#提高它的安全性，使得她作為一個影子來執(zhí)行管理或者危險的命令
#
#

slave-read-only yes

# 從服務(wù)器在預(yù)設(shè)的間隔中發(fā)送送一個ping到目標服務(wù)器。你可以通過修改repl-ping-slave-period
#的值來修改它，默認是10秒鐘
#
#
# repl-ping-slave-period 10

# repl-timeout設(shè)置了以下的復制超時值:
#
# 1) 在從服務(wù)器中，使用同步IO進行大規(guī)模傳輸.
# 2) 在從服務(wù)器中，主服務(wù)器的超時(ping，數(shù)據(jù))
# 3) 在主服務(wù)器中. 從服務(wù)器的超時(對pings的響應(yīng))
#
#
# 確保這個值大于 指定的repl-ping-slave-period 值，否則當主從之間是低流量時
# 會檢測到超時的情況
#
# repl-timeout 60

# 在從服務(wù)器同步之后是否關(guān)閉TCP_NODELAY?
#
#
# 如果你選擇 "yes"，redis將會使用一個很小的TCP包和很小的帶寬來向從服務(wù)器發(fā)送數(shù)據(jù)。
# 如果使用默認的設(shè)置這會增加數(shù)據(jù)復制到從服務(wù)器之間的延遲。如果使用默認配置的linux內(nèi)核
# 這個延遲會高達到40毫秒
#
#
#如果你選擇 "no"，數(shù)據(jù)復制到從服務(wù)器將會減少延遲，但是會使用更多的帶寬。
#
#作為默認我們?yōu)榈脱舆t進行優(yōu)化，但是在一個高流量的情況下或者當主服務(wù)器和從服務(wù)器
#有很多hops的時候，將該值設(shè)置為yes會更好
# (譯者注：這就是一個網(wǎng)絡(luò)調(diào)優(yōu)的問題，默認的TCP內(nèi)核會使用Nagle，即將小的數(shù)據(jù)包合并成大的數(shù)據(jù)包(及yes的情況))
# (在等待合并的過程種，肯定會存在等待后續(xù)數(shù)據(jù)的步驟，因此這會導致數(shù)據(jù)的延遲)
# (yes，就是使用TCP的默認情況開啟Nagle算法，no就是關(guān)閉Nagle算法)

repl-disable-tcp-nodelay no

#
#
#設(shè)置復制的backlog值。(這個backlog和tcp中的backlog不一樣)
#
#這個backlog值是一個緩沖區(qū)，當從服務(wù)器斷開連接之后，主服務(wù)器將更新的數(shù)據(jù)放置
#在這個緩沖區(qū)中，因為當從服務(wù)重新連接上來時候不是所有的數(shù)據(jù)都需要同步，因此從這個
#緩沖區(qū)中取數(shù)據(jù)就可以同步到和主服務(wù)器一樣的狀態(tài)
#
#
#這個值設(shè)置得越大，從服務(wù)器的掉線時間就可以越長，上線后就可以進行局部更新
#（譯者注：當?shù)艟€時間過長而無法進行局部更新，那么從服務(wù)器就會再一次進行同步所有的數(shù)據(jù)，耗時和當時的數(shù)據(jù)量成正比）
#當且僅當?shù)谝粋€從服務(wù)器連接到服務(wù)器之后這個緩存才會被分配
#
# repl-backlog-size 1mb

#
# 
# 當從服務(wù)器在長時間內(nèi)沒有連接到主服務(wù)器時，backlog的緩存將會被釋放。
# 以下的選項就是自 從服務(wù)器最后一次斷掉和主服務(wù)器之間的
# 連接開始N秒后清空backlog的緩存
#
# 設(shè)置為0意味著永遠不會清空backlog
#
# repl-backlog-ttl 3600

#
#
# 在redis的信息輸出中我們使用一個整型值來表示從服務(wù)器的優(yōu)先值
#
#這個優(yōu)先級的作用是，在主從結(jié)構(gòu)種，當主服務(wù)器不能正常工作的時候時候，
#將一個從服務(wù)器提升為主服務(wù)器，提升的依據(jù)就是這個值。
#
# 假設(shè)又三個 優(yōu)先級分別為 25 10 100 的服務(wù)器，將優(yōu)先將數(shù)值最少的提升為主服務(wù)器
# 即最小值優(yōu)先
# 如果優(yōu)先級設(shè)置為0，意味著將不會又機會成為主服務(wù)器
# 默認優(yōu)先級是100
slave-priority 100


#
# 下面的值用來設(shè)置主服務(wù)器停止接受寫入事件的情況。
# 如果從服務(wù)器的連接小于N 
# 從服務(wù)器的數(shù)據(jù)落后 小于等于M秒
# 
# N個從服務(wù)器必須是在線的狀態(tài)
#
# lag的單位是秒，它必須 =指定的值，它從最后一次收到ping包的時間開始計算。 
# 通常ping包都是每秒發(fā)送一次
#
#
# 這個選項并不擔保N個副本都會接受寫入，但是會確保在指定的時間沒有足夠的從服務(wù)可用的時候
# 窗口上顯示丟失寫入
#
#
# 例如要求最少三個從服務(wù)器在lag=10秒
#
# min-slaves-to-write 3
# min-slaves-max-lag 10
#
# 設(shè)置任意一個為0都會導致關(guān)閉這項特性
#
# 默認min-slaves-to-write 設(shè)置為0(關(guān)閉這個特性)
# min-slaves-max-lag 設(shè)置為10

################################## SECURITY ###################################


#
# 要求客戶端在處理其他指令之前先發(fā)起AUTH PASSWORD>
#
# 這在你不信任其他的接入主機上的redis-server是比較有用
#
# 這個選項應(yīng)當注釋掉來保證向后的兼容性，畢竟大部分的人都不需要鑒權(quán)驗證(因為他們都運行自己的sever)
#
# 
#注意，由于redis太快，所以每秒鐘可以嘗試150K次密碼，因此你應(yīng)該設(shè)置一個
#非常強壯的密碼來防止別人的破解
#
# requirepass foobared

# 命令重命名.
#
#
# 它用來改變共享環(huán)境中危險命令的名字，在這個例子中
# CONFIG 命令被重命名為一個難以猜解的名字。
# 這會對內(nèi)部用戶的工具有效，但是對一般的客戶端無效。
#
# Example:
#
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
#
#
# 可以使用一個空字符串來抹殺這個命令
#
# rename-command CONFIG ""
#
# 請注意，改變記錄在AOF文件中的命令名稱或者傳輸?shù)綇姆?wù)會導致問題
# AOF file or transmitted to slaves may cause problems.

################################### LIMITS ####################################


#
# 設(shè)置同一時間的客戶端最大連接數(shù)，默認的限制是10000個客戶端。
#然而如果redis服務(wù)不設(shè)置這個限制值那么最大的用戶數(shù)就是最大文件描述符數(shù)-32.
#
#
#一旦連接的用戶數(shù)超出了限制值，redis將會關(guān)閉新的連接并且發(fā)送 'max number of client reached'
#
# maxclients 10000

# 不使用超出指定大小的內(nèi)存，
#當redis使用到的內(nèi)存達到限定值的時候，將會根據(jù)淘汰策略試圖移除一部分key
#
#
# 如果根據(jù)相關(guān)策略無法移除key，或者策略被設(shè)置為 'noeviction'，redis將會對
#使用到內(nèi)存的命令返回錯誤，比如 SET LPUSH等，并且進入只讀模式僅僅響應(yīng)只讀的命令如GET
#
# 這個選項在你將redis當做一個LRU緩存和設(shè)置一個內(nèi)存大小限制的時候十分有用。
#
#

#
# 警告：如果你的從服務(wù)器關(guān)聯(lián)到一個有最大內(nèi)存限制的redis實例上，
# 
# 主服務(wù)器向從服務(wù)器輸出的緩存屬于被該服務(wù)器使用的內(nèi)存的一部分。
#因此 網(wǎng)絡(luò)問題和重新同步引發(fā)的復制，不會觸發(fā)淘汰key的循環(huán)，
#
#反過來，從服務(wù)器的輸出緩存將會被觸發(fā)淘汰的DEL key，直到數(shù)據(jù)庫清空
#
#
#
#簡單來說，如果你擁有一個從服務(wù)器，我們建議你將這個值
#設(shè)置為少于系統(tǒng)可用的最大內(nèi)存，以便系統(tǒng)可以騰出空間來安放
#從服務(wù)器的輸出緩存（但是如果策略是noeviction 那就沒這個必要）
#
# maxmemory bytes>

# 最大內(nèi)存策略: 當redis使用的內(nèi)存達到指定的最大值時，你可以使用如下的5種
# 策略來應(yīng)對這種情況
#
# volatile-lru -> 使用LRU算法依據(jù)過期時間來移除key
# allkeys-lru -> 使用LRU算法來移除任何key
# volatile-random -> 根據(jù)過期時間設(shè)置隨即移除key
# allkeys-random -> 隨即移除任何一個key
# volatile-ttl -> 移除一個最近過期時間的key
# noeviction -> 所有key用不過期(即不移除任何key)，對于任何寫操作都返回一個錯誤信息
# 
# 提示: 在以上的所有策略中，當不存在一個key滿足以上的淘汰策略時(即無法空出內(nèi)存時)
# 任何寫操作都會返回錯誤信息
#
#    目前為止具有寫入操作的指令是: 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 volatile-lru

#
# LRU和最小TTL算法都不是精確的算法，但是是近似的算法，
#因此你可以選擇一些樣本大小來進行測試，對于一個默認的redis實例
#將會選選擇3個key，并且挑選其中之一作為最近最少的Key，你可以使用如下參數(shù)修改例子的數(shù)量大小
#
#
# maxmemory-samples 3

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

# Redis默認使用異步存儲數(shù)據(jù)到硬盤上.
#
# 這個模式非常合適一些應(yīng)用，但是當redis的進程出現(xiàn)問題
# 或者停電的時候，會丟失一些寫入的數(shù)據(jù)(丟失的多少根據(jù)保存點的設(shè)置)
#
# 
# Append Only 文件(Append Only file)，是一個備選的持久化模型，
# 它提供了更好的續(xù)航能力，對于一個使用默認數(shù)據(jù)同步文件策略的實例
#redis可能會因為一個戲劇性的災(zāi)難比如停電等丟失一秒鐘的數(shù)據(jù)
#
#或者由于redis進程本身的錯誤僅僅寫入一個數(shù)據(jù)，但操作系統(tǒng)一直運行
#
#
#
# AOF和RDB可以毫無問題地共存，因此你可以同時開啟他們，
# 
# 如果你開啟了AOF,redis會在啟動時加載AOF，因為AOF有更好的魯棒性
#
# 你可以從 http://redis.io/topics/persistence 獲取更多的信息

appendonly no

# append only file 的名稱 (默認是: "appendonly.aof")

appendfilename "appendonly.aof"

# fsync() 調(diào)用告訴操作系統(tǒng)立即將數(shù)據(jù)寫入到硬盤中，而不是寫入到輸出緩沖區(qū)
# 等待足夠的數(shù)據(jù)再寫入。一些操作系統(tǒng)會立即將數(shù)據(jù)寫入到硬盤中，一些其他的
#操作系統(tǒng)則只是盡可能快地將數(shù)據(jù)寫入硬盤中
#
# 
# Redis支持三種不同的模式:
#
# no:不進行強制同步，僅僅讓操作系統(tǒng)根據(jù)自身的決策寫入到硬盤中。這種速度更快 
# always:在每一次追加寫入操作都采用強制同步，特點是慢，安全。
# everysec：每間隔一秒鐘強制同步數(shù)據(jù)。折中的方案
#
#
# 默認采用 "everysec"作為速度和安全性之間的平衡方案
# 你將根據(jù)自己的需求決定采用更快的方案或者更安全的方案。
# 選擇no，何時寫入數(shù)據(jù)將由操作系統(tǒng)決定，你可以由此獲取最快的速度
# 選擇always，數(shù)據(jù)將立即寫入到硬盤中，你可以獲得更高的數(shù)據(jù)安全性
#
# 更多的信息可以從以下地址中獲取:
# http://antirez.com/post/redis-persistence-demystified.html
#
# 如果不開啟該選項默認使用"everysec".

# appendfsync always
appendfsync everysec
# appendfsync no




#
#
# 當AOF的強制寫入策略設(shè)置為 always 或者 everysec，并且一個后臺保存進程
#（一個后臺保存進程或者 AOF 日志后臺重寫）會占用硬盤的大量I/O資源，在一些linux
# 的配置中redis會因為 fsync() 調(diào)用而長期鎖定。特別的是在目前我們沒法解決這個問題
# 即使采用另外的線程來運行強制同步也會鎖定住我們的 同步 write(2)調(diào)用
#
# 為了減輕這個問題，下面的選項將會在GBSAVE 或者BGREWRITEAOF運行時
# 預(yù)防主進程調(diào)用fsync()
#
# 這意味著當另一個 子進程在保存的時候，Redis的保存策略將處于"appendfsync none"這樣的類似狀態(tài)
# 在實際應(yīng)用當中，這意味著在最壞的情況下將會失去30秒的日志(使用linux默認的設(shè)置)
#
# 
# 如果你采用yes，那么將會存在一個潛在的隱患，不然請設(shè)置它為 "no"，
# 這是一個為了穩(wěn)定的安全性選擇
#

no-appendfsync-on-rewrite no

# 自動改寫append only 文件.
#
# redis會在AOF日志文件增長到指定百分比的時候通過調(diào)用BGREWRITEAOF來自動重寫日志文件
# 
# 他是這樣工作的：redis會記住最后一次改寫后AOF文件的大小(如果重寫自重啟以來
#尚未發(fā)生，那么AOF文件的大小就是啟動以來使用的大小)
#
#
# 這個基準值將會和當前值進行比較，如果當前值比設(shè)定的百分比還要大，重寫事件就會發(fā)生。
#
# 并且你需要指定一個AOF重寫的最小值，這用來避免當重寫文件的百分比增長符合目標
# 但是整個文件依然很小的時候
#
#
# 將 auto-aof-rewrite-percentage 設(shè)置為0則可以關(guān)閉掉AOF自動重寫的功能
#

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

################################ LUA SCRIPTING ###############################

# 以毫秒為單位限定lua腳本的最大執(zhí)行時間.
#
#
# 當lua腳本在超出最大允許執(zhí)行時間之后，redis會記錄下這個腳本到日志中，
#并且會向這個請求返回error的錯誤
#
#
#
# 僅當 SCRIPT KILL 和 SHUTDOWN NOSAVE 命令可用的時候
# 一個運行時間超過最大限定時間的腳本才會繼續(xù)執(zhí)行
# SCRIPT KILL用來停止一個沒有調(diào)用寫入命令的腳本
# 當用戶不想等待腳本的自然中止但腳本又在進行寫操作的時候
# 采用 SHUTDOWN NOSAVE 是解決這個問題的唯一辦法，他可以立即停掉整個腳本
#
#
# 設(shè)置為0 或者一個負數(shù)來取消時間限定.
lua-time-limit 5000

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

# 
# slow log（慢日志）用來記錄執(zhí)行時間超過指定值的查詢。
# 執(zhí)行時間不包含 I/O操作，比如和客戶端交互，發(fā)送應(yīng)答等等
# 僅僅是執(zhí)行命令的真實時間，（僅僅是線程因為執(zhí)行這個命令而鎖定且無法處理其他請求的階段）
#
#
# 你可以使用兩個參數(shù)來配置 slow log，一個是以微秒為單位的命令執(zhí)行時間值，
# 另一個是slow log 的長度（即記錄的最大數(shù)量）
# 當一個新的命令被記錄到slow log的時候，最舊的一條記錄將會被移除。
#
#
# 下面的值將會被解釋為 微秒 為單位，所以 1000000 微秒為 1秒
# 
# 將這個值設(shè)置為一個負數(shù)，將關(guān)閉掉slow log ，如果設(shè)置為0，則記錄所有的命令
#(默認是10毫秒)
slowlog-log-slower-than 10000

# 因為這會消耗內(nèi)存，因此實際上并不是限制到這個長度.
# 你可以使用 SLOWLOG RESET來回收占用的內(nèi)存
slowlog-max-len 128

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

#
# redis延遲監(jiān)控子系統(tǒng)例子與操作系統(tǒng)收集的redis實例相關(guān)的數(shù)據(jù)不同
#
# 通過LATENCY命令，可以為用戶打印出相關(guān)信息的圖形和報告
#
#這個系統(tǒng)只會記錄運行時間超出指定時間值的命令，如果設(shè)置為0，這個監(jiān)控將會被關(guān)閉
#
#
# 默認的情況下，延遲監(jiān)控是關(guān)閉，因為如果你沒有延遲的問題大部分情況下不需要
#，并且收集數(shù)據(jù)的行為會對性能造成影響，雖然這個影響很小可以在大負荷下工作
# 
#延遲監(jiān)控可以使用如下命令來打開
#
# "CONFIG SET latency-monitor-threshold milliseconds>".
latency-monitor-threshold 0

############################# Event notification ##############################

#redis 可以在key 空間中采用發(fā)布訂閱模式來通知事件的發(fā)生
#
#這個功能的文檔可以查看 http://redis.io/topics/keyspace-events
# 
#
#對于一個實例，如果鍵空間事件通知是啟用狀態(tài)，當一個客戶端執(zhí)行在一個
#存儲在Database 0名為"foo"的key的DEL(刪除)操作時，
#有如下兩條信息將會通過發(fā)布訂閱系統(tǒng)產(chǎn)生
#
#
# PUBLISH __keyspace@0__:foo del
# PUBLISH __keyevent@0__:del foo
#
#
# 以下是可選的redis事件通知，每個類別的事件可以由一個字符進行描述
#
# 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
# by zero or multiple characters. The empty string means that notifications
# are disabled at all.
#
# 例子1: 啟用 list 和 generic 事件, 
#
# notify-keyspace-events Elg
#
# 例子2 2: 要想訂閱通道名為__keyevent@0__:expired 上expired keys的事件:
#
# notify-keyspace-events Ex
#
#
# 默認不啟用所有的通知，因為大部分的用戶不需要這些功能，而且這些功能會帶來一些開銷
#
# 如果你沒有指定 K 或者 E，沒有事件會被傳遞
#
notify-keyspace-events ""

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

#
#創(chuàng)建空白哈希表時,程序默認使用 REDIS_ENCODING_ZIPLIST 編碼,當以下任何一個條件被滿
#足時,程序?qū)⒕幋a從切換為 REDIS_ENCODING_HT
#哈希表中某個鍵或某個值的長度大于 server.hash_max_ziplist_value (默認值為 64)。
#壓縮列表中的節(jié)點數(shù)量大于 server.hash_max_ziplist_entries (默認值為 512 )。
#
# ziplist是一個解決空間的緊湊的數(shù)據(jù)存儲結(jié)構(gòu)，但是當數(shù)據(jù)超過閾值時，將采用原生的數(shù)據(jù)存儲結(jié)構(gòu)
#
#
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

#
# 與hash表類似，
#
list-max-ziplist-entries 512
list-max-ziplist-value 64

#
# 設(shè)置特殊編碼的唯一情況：
# 當一個set僅僅由一個基數(shù)為10最大位數(shù)為64位的有符號整形的字符串構(gòu)成的時候
#
#以下配置設(shè)置了set的限制大小，當小于這個值的時候?qū)褂靡粋€更緊湊的數(shù)據(jù)結(jié)構(gòu)來保存
#以期減少內(nèi)存占用
#
set-max-intset-entries 512


#
# 與hash和list類似 zsort也采用如下的配置來選擇是否進行特殊編碼來節(jié)省空間
#
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

#
# HyperLogLog 稀疏表示字節(jié)限制
# 這個限制包含了16個字節(jié)的頭部，當一個HyperLogLog使用sparse representation
# 超過了這個顯示，它就會轉(zhuǎn)換到dense representation上
# 
#

hll-sparse-max-bytes 3000


#
# active rehashing使用CPU時間的每100毫秒中的1毫秒來進行rehashing工作
# 來rehash redis的主hash表(rehash的時候在代碼種引入記時來保證)
#
# lazy rehashing ：逐步hash，每一次添加查找刪除進行一次rehash的步驟
# 又稱惰性hash
# 
# 因為hash的再散列會導致整個進程的stop，為了避免長時間的stop，以上的策略都是在分散整個
# rehash的過程(參照《redis設(shè)計與實現(xiàn)》的字典部分)
#

activerehashing yes

#
# 客戶端輸出緩沖區(qū)顯示可以用來解決由于某些原因?qū)е碌膹娭茢嗑€
# 而造成的不能讀到足夠的數(shù)據(jù)
# 一個比較常見的原因是發(fā)布訂閱模式種，客戶端不能足夠快速地消費發(fā)布者生產(chǎn)的信息
#
# 這個限制可以設(shè)置為如下的三種類型:
#
# normal -> 正常普通的客戶端，包含監(jiān)控客戶端
# slave -> 主從服務(wù)器的從客戶端
# pubsub -> 訂閱了最少一個頻道的客戶端
#
# 每一個 client-output-buffer-limit 格式如下:
#
# client-output-buffer-limit class> hard limit> soft limit> soft seconds>
#
#
#
# 在兩種情況下服務(wù)器認為客戶端不是意外臨時掉線
# 
# 1.緩沖區(qū)的數(shù)據(jù)達到硬限制
# 2.緩沖區(qū)的數(shù)據(jù)達到軟限制，同時時間超過了指定值
#
# 因為一個客戶離線，有可能是臨時性的網(wǎng)絡(luò)故障，或者傳輸問題
# 也有可能是永久性離線 或者強制性離線，此時服務(wù)器將不會保留他的緩存數(shù)據(jù)
# 以下的設(shè)置就是為了判斷這一情況的
#
#
#
# 硬限制和軟限制都可以通過將其設(shè)置為0來關(guān)閉掉
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會按照一定的頻率來處理諸如 關(guān)閉超時連接，清理沒有被使用的過期key等等此類后臺任務(wù)
#
# 并不是所有的任務(wù)都以相同的頻率來執(zhí)行的，redis通過一個hz的值來決定處理這些(如上所述的后臺任務(wù))任務(wù)的頻率
#
#
# 提高這個值會使用更多的cpu時間來在redis閑置的時候處理以上的，但是以此同時
# 超時的連接的處理和過期key的清理則會更精確
#
# hz的取值范圍在1到500，不建議設(shè)置為超過100的值，默認是10
hz 10
#
# 當子進程重寫AOF文件的時候，以下選項將會允許等到存在32MB數(shù)據(jù)的時候才調(diào)用強制同步
# 這樣可以降低IO上的延遲
#
aof-rewrite-incremental-fsync yes