# Redis 配置文件：版本3.0.5
# 當配置中需要配置內存大小時，可以使用 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 1gB
################## INCLUDES #####################
# 引入多個配置文件。如，在已有標準模板的同時，還需要自定義配置文件。
# 注意：include進來的配置文件不會被admin或Sentinel的CONFIG REWRITE命令重寫。
# include最好放在配置文件的前端。
# include /path/to/local.conf
################## GENERAL #####################
# 默認情況下，Redis不會作爲守護進程運行。如果需要，把該項的值更改爲yes
# 由於redis以最終的配置作爲實際配置，因此我們希望你將include命令放置在配置文件的最前面以防配置被覆蓋。如果你打算使用另外的 conf文件來覆蓋當前文件的配置，那麼最好將include指令放置到該文件的末尾。即最後生效原則，最後被解析的配置將作爲最後的配置。
daemonize yes
# 當Redis作爲守護進程運行時，Redis默認會把pid文件放在/var/run/redis.pid，你可以配置到其他地址。
pidfile /var/run/redis.pid
# 當運行多個redis服務時，需要指定不同的pid文件和端口
# 指定redis運行的端口，默認是6379。當爲0時，Redis將不會通過TCP socket監聽。
# 注：只是不使用TCP socket監聽。依舊可以連接，只是無法通過網絡連接。
port 6379
# TCP 監聽積壓區backlog
# 在一個併發量高的環境中，你需要指定一個比較大的backlog值來避免慢連接（由於網絡原因握手速度慢）的情況。
# 注意，linux內核會默認 使用/proc/sys/net/core/somaxconn 的值來削減 backlog的實際值，因此你需要確保提升 somaxconn 和 tcp_max_syn_backlog 這兩個值來確保此處的backlog生效。
# 注：這裏的backlog是指目前最大連接隊列的積壓區。因爲TCP連接是三次握手，沒有
# 完成三次握手和尚未被accept的connect都會處於連接隊列中。但是backlog的實際值
# 與操作系統相關，並非設置多少就是多少，只能說調整得大一些可以在同一時間應對更
# 多的連接請求。
# 注：只有當每一個請求都重新發起一個連接的時候，backlog值的增大才能影響到併發量。在tcp穩定連接的時候，或連接複用（連接池的使用），backlog值對併發沒有任何影響。因此該值一般採用默認值。
tcp-backlog 511
# 默認情況下redis會在所有的可用網絡接口中進行監聽，如果你想讓redis在指定的網絡接口中監聽，那麼可以使用bind 命令來指定redis的監聽接口。
# 在生產環境中最好設置該項
# bind 127.0.0.1
# 指定unix sock的路徑來進行連接監聽，默認是不指定，因此redis不會在unix socket上進行監聽。
# unixsocket /tmp/redis.sock
# unixsocketperm 755
# 設置客戶端連接時的超時時間（關閉掉空閒N秒的連接），單位爲秒。當客戶端在這段時間內沒有發出任何指令，那麼關閉該連接。
# 0是關閉此設置，不處理空閒連接。
timeout 0
# TCP keepalive
#如果該值不爲0，將使用 SO_KEEPALIVE 這一默認的做法來向客戶端連接發送TCP ACKs
#這樣的好處有以下兩個原因：
# 1）檢測已經死亡的對端（注：TCP的關閉會存在無法完成4次握手的情況，如斷電，斷網，數據丟失等等）
# 2）保持連接在網絡環境中的存活
# 注：最好設置爲60
tcp-keepalive 60
# 指定日誌記錄級別
# Redis總共支持四個級別：debug、verbose、notice、warning，默認爲verbose
# debug 記錄很多信息，用於開發和測試
# varbose 有用的信息，不像debug會記錄那麼多
# notice 普通的verbose，常用於生產環境
# warning 只有非常重要或者嚴重的信息會記錄到日誌
loglevel debug
# 配置log文件地址
# 默認值爲stdout，標準輸出，若守護進程模式會輸出到/dev/null
# logfile stdout
logfile /var/log/redis/redis.log
# 當設置 'syslog-enabled'爲 yes時， 允許記錄日誌到系統日誌中。
# 以及你可以使用更多的syslog參數來滿足你的要求。
# syslog-enabled no
# 指定在系統日誌中的身份
# syslog-ident redis
# 執行系統日誌的設備名。 Must be USER or between LOCAL0-LOCAL7.
# syslog-facility local0
# 設置數據庫編號
# 默認值爲16，默認數據庫爲0，數據庫範圍在0-（database-1）之間
databases 16
#################### SNAPSHOTTING #####################
# 保存數據到磁盤，格式如下:
# save <seconds> <changes>
# 指出在多長時間內，有多少次更新操作，就將數據同步到數據文件rdb。
# 相當於條件觸發抓取快照，這個可以多個條件配合
# 比如默認配置文件中的設置，就設置了三個條件：
# save 900 1 900秒內至少有1個key被改變
# save 300 10 300秒內至少有300個key被改變
# save 60 10000 60秒內至少有10000個key被改變
# 注：生產環境中需要關掉所有此項以減少磁盤IO壓力。而使用主動的BGSAVE操作進行持久化操作。
save 900 1
save 300 10
save 60 10000
# 作爲默認，redis會在RDB快照開啓和最近後臺保存失敗的時候停止接受寫入(最少一個# 保存點)，這會使得用戶察覺（通常比較困難）到數據不會保持在硬盤上的正確性，
# 否則很難發現這些災難會發生，
# 如果後臺保存程序再次開始工作，reidis會再次自動允許寫入，
# 然而如果對redis服務器設置了合理持續的監控，那麼你可以關閉掉這個選項。
# 這會導致redis將繼續進行工作，無論硬盤，權限或者其他的是否有問題
stop-writes-on-bgsave-error yes
# 存儲至本地數據庫時（持久化到rdb文件）是否壓縮數據，默認爲yes
# 注：如果機器性能不佳，cpu使用率過高的情況，可以關閉該功能。缺點是RDB文件會# 比較大。
rdbcompression yes
# 從RDB的版本5開始，CRC64校驗值會寫入到文件的末尾
# 這會使得格式化過程中，使得文件的完整性更有保障，但是這會在保存和加載的時候損 失不少的性能(大概在10%)
# 你可以關閉這個功能來獲得最高的性能
# RDB文件會在校驗功能關閉的時候，使用0來作爲校驗值，這將告訴加載代碼來跳過校 驗步驟
rdbchecksum yes
# 本地持久化數據庫文件名，默認值爲dump.rdb
dbfilename dump.rdb
# 工作目錄
# 數據庫鏡像備份的文件放置的路徑。
# 這裏的路徑跟文件名要分開配置是因爲redis在進行備份時，先會將當前數據庫的狀態寫# 入到一個臨時文件中，等備份完成時，
# 再把該該臨時文件替換爲上面所指定的文件，而這裏的臨時文件和上面所配置的備份文件都會放在這個指定的路徑當中。
# AOF文件也會存放在這個目錄下面
# 注意這裏必須制定一個目錄而不是文件
dir ./
##################### REPLICATION ########################
# 主從複製. 設置該數據庫爲其他數據庫的從數據庫.
# 設置當本機爲slave服務時，設置master服務的IP地址及端口，在Redis啓動時，它會# 自動從master進行數據同步
# 關於主從複製需要注意以下幾點：
# 1）Redis的主從複製是異步的。但是你可以配置master在沒有至少一個slave連接時，# 停止接受寫入
# 2）當複製連接斷掉不是很長時間時，Redis的slave可以執行局部再複製。需要配置backlog （積壓區）size參數。
# 3）複製是自動的，無需用戶干預。在統一網絡分區中的Master和Slaves會自動重連並重啓複製。
# slaveof <masterip> <masterport>
# 當master服務設置了密碼保護時(用requirepass制定的密碼)
# slave服務連接master的密碼
# masterauth <master-password>
# 當從庫同主機失去連接或者複製正在進行，從機庫有兩種運行方式：
# 1) 如果slave-serve-stale-data設置爲yes(默認設置)，從庫會繼續相應客戶端的請求
# 2) 如果slave-serve-stale-data是指爲no，出去INFO和SLAVOF命令之外的任何請求都會返回一個
# 錯誤”SYNC with master in progress”
slave-serve-stale-data yes
# 配置一個Slave的實例是否接受寫請求，
# Slave在存儲一些短暫的數據的的時候，接收寫請求是一件非常正確的事情
# （因爲數據在向Master同步之後非常容易擦除）但是會因爲配置不正確而導致一些問 題，從redis 2.6開始默認Slave是隻讀服務器
# 提示：只讀的Slave並不是設計用來公開給不受信任的互聯網客戶端的，它
# 僅僅是一個用來防止對實例進行誤操作的保護層。只讀Slave默認用來輸出管理命令
# 例如 CONFIG, DEBUG 和其他。如果你想限制它的規模，你可以使用'rename-command' # 來提高它的安全性，使它作爲一個影子來執行管理或者危險的命令
slave-read-only yes
# Slave在預設的間隔中發送送一個ping到目標服務器。默認是10秒鐘
# repl-ping-slave-period 10
# repl-timeout設置了以下的複製超時值：
# 1) 在Slave中，使用同步IO進行大規模傳輸
# 2) 在Slave中，Master的超時(ping，數據)
# 3) 在Master中. Slave的超時(對pings的響應)
# 注：應確保這個值大於指定的repl-ping-slave-period值，否則當主從之間流量較少時，會檢測到超時的情況
# repl-timeout 60
# 在Slave同步之後是否關閉TCP_NODELAY？
# 如果你選擇 "yes"，redis將會使用一個很小的TCP包和很小的帶寬來向Slave發送數據。
# 如果使用默認的設置這會增加數據複製到Slave之間的延遲。如果使用默認配置的linux內核這個延遲會高達到40毫秒
# 如果你選擇 "no"，數據複製到Slave將會減少延遲，但是會使用更多的帶寬。
#作爲默認我們爲低延遲進行優化，但是在一個高流量的情況下或者當Master和Slave
#有很多hops的時候，將該值設置爲yes會更好
# 注：這就是一個網絡調優的問題，默認的TCP內核會使用Nagle，即將小的數據包合併 # 成大的數據包(及yes的情況)。在等待合併的過程種，肯定會存在等待後續數據的步驟，因此這會導致數據的延遲。yes，就是使用TCP的默認情況開啓Nagle算法，no就是關閉Nagle算法
repl-disable-tcp-nodelay no
# 設置複製的backlog值。(注：這個backlog和tcp中的backlog不一樣)
# 這個backlog值是一個積壓緩衝區，當Slave斷開連接之後，Master將更新的數據放置在這個緩衝區中，因爲當從服務重新連接上來時候不是所有的數據都需要同步，因此從這個緩衝區中取數據就可以同步到和Master一樣的狀態
# 這個值設置得越大，Slave的掉線時間就可以越長，上線後就可以進行局部更新
# 注：當掉線時間過長而無法進行局部更新，那麼Slave就會再一次進行同步所有的數據，耗時和當時的數據量成正比
# 當且僅當第一個Slave連接到服務器之後這個緩存纔會被分配
# 注：該參數在master上有效。該值的大小應當經過測算。
# repl-backlog-size 1mb
# 當Slave在長時間內沒有連接到Master時，backlog的緩存將會被釋放。
# 以下選項就是自Slave最後一次斷掉和Master之間的連接開始N秒後清空backlog的緩存。設置爲0意味着永遠不會清空backlog
# repl-backlog-ttl 3600
# 在redis的信息輸出中我們使用一個整型值來表示Slave的優先值
# 這個優先級的作用是，在主從結構中，當Master不能正常工作的時候時候，
# 將一個Slave提升爲Master，提升的依據就是這個值。
# 假設有三個優先級分別爲 25 10 100 的服務器，將優先將數值最少的提升爲Master
# 即最小值優先
# 如果優先級設置爲0，意味着該從機將不會有機會成爲Master
# 默認優先級是100
slave-priority 100
# 在下面的情況下Master停止接受寫入事件：
# 當Master連接的Slave個數小於N，或Slave的數據落後（lag）小於等於M秒
# 注：N個Slave必須是在線的狀態
# lag的單位是秒，它必須<=指定的值，它從最後一次收到ping包的時間開始計算。
# 通常ping包都是每秒發送一次。
# 注：這個選項並不擔保N個副本都會接受寫入，但是會確保在指定的時間沒有足夠的從服務可用的時，在會話返回上顯示丟失寫入。
# 例如要求最少三個Slave在lag<=10秒
# min-slaves-to-write 3
# min-slaves-max-lag 10
#
# 設置任意一個爲0都會導致關閉這項特性
#
# 默認min-slaves-to-write 設置爲0(關閉這個特性)
# min-slaves-max-lag 設置爲10
# 注：這兩個選項不是特別安全的選項。可能會影響應用使用。只有在確定應用場景後可 # 選擇開啓。
###################### SECURITY ######################
# 要求客戶端在處理其他指令之前先發起AUTH <PASSWORD>，
# 這在你不信任其他的接入主機上的redis-server是比較有用的。
# 這個選項應當註釋掉來保證向後的兼容性，畢竟大部分的人都不需要鑑權驗證(因爲他們# 都運行自己的sever)
# 注：由於redis太快，所以每秒鐘可以嘗試150K次密碼，因此你應該設置一個
# 非常強壯的密碼來防止別人的破解。（密碼要儘可能的複雜）
# requirepass foobared
# 命令重命名。
# 它用來改變共享環境中危險命令的名字，在這個例子中
# CONFIG 命令被重命名爲一個難以猜解的名字。
# 這會對內部用戶的工具有效，但是對一般的客戶端無效。
# Example:
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
# 可以使用一個空字符串來禁用這個命令
# rename-command CONFIG ""
# 注：改變記錄在AOF文件中的命令名稱或者傳輸到從服務會導致問題
# AOF file or transmitted to slaves may cause problems.
# 注：我們通常會將KEYS（客戶端使用KEY *進行查詢會卡死Redis進程）、SHUTDOWN（關閉實例）、FLUSHALL（清除所有數據及文件信息，類似初始化）、FLUSHDB（清除當前數據庫中所有數據）
####################### LIMITS ########################
# 設置同一時間的客戶端最大連接數，默認限制是10000個客戶端。
# 然而如果redis服務不設置這個限制值那麼最大的用戶數就是最大文件描述符數-32.
# 一旦連接的用戶數超出了限制值，redis將會關閉新的連接並且發送
# 'max number of client reached'
# maxclients 10000
# 不使用超出指定大小的內存，
# 當redis使用到的內存達到限定值的時候，將會根據淘汰策略移除一部分key
# 如果根據相關策略無法移除key，或者策略被設置爲 'noeviction'，redis將會對
# 使用到內存的命令返回錯誤，比如 SET LPUSH等，並且進入只讀模式，僅僅響應只讀的命令，如GET。
# 這個選項在你將redis當做一個LRU緩存和設置一個內存大小限制的時候十分有用。
# 注：如果你的Slave關聯到一個開啓最大內存限制的redis實例上，
# Master向Slave輸出緩衝區屬於被該服務器使用的內存的一部分。
# 因此網絡問題和重新同步引發的複製，不會觸發淘汰key的循環，
# 反過來，Slave的輸出緩衝區將觸發淘汰 key的DELs操作，直到數據庫清空
# 簡單來說，如果你擁有一個Slave，我們建議你將這個值
# 設置爲少於系統可用的最大內存，以便系統可以騰出空間來安放Slave的輸出緩存（但是如果策略是noeviction 那就沒這個必要）
#
# maxmemory <bytes>
# 最大內存（MAXMEMORY）策略: 當redis使用的內存達到指定的最大值時，你可以使用如下的5種策略來應對：
#
# volatile-lru -> 使用LRU算法依據過期時間來移除key
# allkeys-lru -> 使用LRU算法來移除任何key
# volatile-random -> 根據過期時間設置隨機移除key
# allkeys-random -> 隨機移除任何一個key
# volatile-ttl -> 移除一個最近過期時間的key
# noeviction -> 所有key不過期(即不移除任何key)，對於任何寫操作都返回一個錯誤信息
# 注: 在以上所有策略中，當不存在一個key滿足以上的淘汰策略時(即無法空出內存時)，
# 任何寫操作都會返回錯誤信息
#
# 目前爲止具有寫入操作的指令是: 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，你可以使用如下參數修改示例的數量大小
# maxmemory-samples 3
################# APPEND ONLY MODE ##################
# Redis默認使用異步存儲數據到硬盤上.
#
# 這個模式非常合適一些應用，但是當redis的進程出現問題
# 或者停電的時候，會丟失一些寫入的數據(丟失的多少根據保存點的設置)
#
# Append Only 文件(Append Only file)，是一個備選的持久化模型，
# 它提供了更好的續航能力，對於一個使用默認數據同步文件策略的實例，
# redis可能會因爲一個戲劇性的災難比如停電等丟失一秒鐘的數據。
#
# 或者由於redis進程本身的錯誤僅僅寫入一個數據，但操作系統一直運行。
#
# AOF和RDB可以毫無問題地共存，因此你可以同時開啓他們，
#
# 但如果你開啓了AOF，redis會在啓動時加載AOF（默認是加載RDB），因爲AOF有更好的魯棒性。
# 可以從http://redis.io/topics/persistence 獲取更多的信息
appendonly no
# append file 的名稱 (默認是: "appendonly.aof")
appendfilename "appendonly.aof"
# fsync() 函數調用告訴操作系統立即將數據寫入到硬盤中，而不是寫入到輸出緩衝區
# 等待足夠的數據再寫入。一些操作系統會立即將數據寫入到硬盤中，一些其他的
# 操作系統則只是儘可能快地將數據寫入硬盤中。
# Redis支持三種不同寫AOF文件的模式:
# no：不進行強制同步，僅僅讓操作系統根據自身的決策寫入到硬盤中。這種速度更快。
# always：在每一次追加寫入操作都採用強制同步，特點是慢，安全。
# everysec：每間隔一秒鐘強制同步數據。折中的方案。
#
# 默認採用"everysec"作爲速度和安全性之間的平衡方案。
# 可以根據自己的需求決定採用更快的方案或者更安全的方案。
# 選擇no，何時寫入數據將由操作系統決定，你可以由此獲取最快的速度。
# 選擇always，數據將立即寫入到硬盤中，你可以獲得更高的數據安全性。
#
# 更多的信息可以從以下地址中獲取:
# http://antirez.com/post/redis-persistence-demystified.html
#
# 如果不開啓該選項默認使用"everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
# 當AOF的強制寫入策略設置爲always 或者 everysec，並且一個後臺保存進程
#（一個後臺保存進程或者 AOF 日誌後臺重寫）會佔用硬盤的大量I/O資源，在一些linux
# 的配置中redis會因爲 fsync() 調用而長期鎖定。目前我們沒法解決這個問題。
# 即使採用另外的線程來運行強制同步，也會鎖定住我們的同步write(2)調用。
#
# 爲了減輕這個問題，下面的選項將會在BGSAVE 或者BGREWRITEAOF運行時
# 預防主進程調用fsync()。
#
# 這意味着當另一個子進程在保存的時候，Redis的保存策略將處於"appendfsync none"這樣的類似狀態。
# 在實際應用中，這意味着在最壞的情況下將會失去30秒的日誌(使用linux默認的設置)。
#
# 如果你採用yes，那麼將會存在一個潛在的隱患，不然請設置它爲 "no"，
# 這是一個爲了穩定的安全性選擇。
no-appendfsync-on-rewrite no
# 自動改寫append only 文件.
#
# redis會在AOF日誌文件增長到指定百分比的時候通過調用BGREWRITEAOF來自動重寫日誌文件。
#
# 它是這樣工作的：redis會記住最後一次改寫後AOF文件的大小(如果重寫自重啓以來
# 尚未發生，那麼AOF文件的大小就是啓動以來使用的大小)。
# 這個基準值將會和當前值進行比較，如果當前值比設定的百分比還要大，重寫事件就會發生。
# 並且你需要指定一個AOF重寫的最小值，用來避免當重寫文件的百分比增長符合目標
# 但是整個文件依然很小的場景。
#
# 將 auto-aof-rewrite-percentage 設置爲0則可以關閉掉AOF自動重寫的功能
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# Redis在啓動時會將AOF文件中的數據載入到內存中，載入時可能會出現載入的AOF 文件的最後被truncate的場景。
# 通常該情況會發生在運行Redis的操作系統crash，尤其是沒有使用data=ordered選項的ext4文件系統中（注：不會在Redis crash或abort但操作系統正常工作的場景中發生）。
# 當出現這種情況時，Redis可能會報錯退出，或儘可能多的載入數據（默認情況）。
# 同時，開始在aof文件上執行truncate操作。下面的參數將控制這種行爲：
# 如該參數被設置爲yes，那麼該被truncate的AOF文件會繼續被加載，且Redis會啓動服務後將該事件以日誌的形式告知用戶。
# 否則，如果該選項被設置爲no，那麼Redis將報錯中斷並拒絕啓動服務。該參數被設置爲no時，需要用戶在重啓動Redis服務前，使用redis-check-aof工具修復AOF文件。
# 注：如果AOF前後完整但是中間被截斷，那麼Redis還是會報錯並退出。該參數主要用# 於Redis嘗試從AOF文件中讀取更多數據，但沒有更多數據存在的場景。
aof-load-truncated yes
################## LUA SCRIPTING #####################
# 以毫秒爲單位限定lua腳本的最大執行時間.
#
# 當lua腳本在超出最大允許執行時間之後，redis會記錄下這個腳本到日誌中，
#並且會向這個請求返回error的錯誤。
# 僅當 SCRIPT KILL 和 SHUTDOWN NOSAVE 命令可用時，
# 一個運行時間超過最大限定時間的腳本纔會繼續執行。
# SCRIPT KILL用來停止一個沒有調用寫入命令的腳本，
# 當用戶不想等待腳本的自然中止但腳本又在進行寫操作時，
# 採用 SHUTDOWN NOSAVE 是解決這個問題的唯一辦法，可以立即停掉整個腳本。
#
# 設置爲0 或者一個負數來取消時間限定.
lua-time-limit 5000
################### SLOW LOG #######################
# slow log（慢日誌）用來記錄執行時間超過指定值的查詢。
# 執行時間不包含 I/O操作，比如和客戶端交互，發送應答等等，
# 僅是執行命令的真實時間（僅是線程因爲執行這個命令而鎖定且無法處理其他請求的階段）。
# 你可以使用兩個參數來配置 slow log，一個是以微秒爲單位的命令執行時間值，
# 另一個是slow log 的長度（即記錄的最大數量）。
# 當一個新的命令被記錄到slow log的時候，最舊的一條記錄將會被移除。
#
# 下面的值將會被解釋爲微秒爲單位，所以 1,000,000 微秒爲 1秒
#
# 將這個值設置爲一個負數，將關閉掉slow log ，如果設置爲0，則記錄所有的命令
# (默認是10毫秒)。
slowlog-log-slower-than 10000
# 因爲這會消耗內存，因此實際上並不是限制到這個長度.
# 可以使用 SLOWLOG RESET來回收佔用的內存
slowlog-max-len 128
############### LATENCY MONITOR ####################
# redis延遲監控子系統的示例與操作系統收集的redis實例相關的數據不同
#
# 通過LATENCY命令，可以爲用戶打印出相關信息的圖形和報告
#
# 這個系統只會記錄運行時間超出指定時間值的命令，如果設置爲0，這個監控將會被關閉
#
# 默認的情況下，延遲監控是關閉，因爲如果你沒有延遲的問題大部分情況下不需要，
# 並且收集數據的行爲會對性能造成影響，雖然這個影響很小可以在大負荷下工作。
#
# 延遲監控可以使用如下命令來打開：
# "CONFIG SET latency-monitor-threshold <milliseconds>".
latency-monitor-threshold 0
################## EVENT NOTIFICATION ####################
# redis可以在key 空間中採用發佈/訂閱模式來通知事件的發生。
#
# 這個功能的文檔可以查看 http://redis.io/topics/keyspace-events
#
# 對於一個實例，如果鍵空間事件通知是啓用狀態，當一個客戶端執行在一個
# 存儲在Database 0名爲"foo"的key的DEL(刪除)操作時，
# 有如下兩條信息將會通過發佈訂閱系統產生
#
# 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 : 要想訂閱通道名爲__keyevent@0__:expired 上expired keys的事件:
# notify-keyspace-events Ex
#
# 默認不啓用所有通知，因爲大部分的用戶無需這些功能，而且這些功能會帶來一些開銷
#
# 如果你沒有指定K 或者E，沒有事件會被傳遞。
notify-keyspace-events ""
################### ADVANCED CONFIG ###################
# 創建空白哈希表時,程序默認使用REDIS_ENCODING_ZIPLIST 編碼,當以下任何一個條件被滿足時,程序將編碼從切換爲REDIS_ENCODING_HT。
# 哈希表中某個鍵或某個值的長度大於 server.hash_max_ziplist_value (默認值爲 64)。
# 壓縮列表中的節點數量大於server.hash_max_ziplist_entries (默認值爲 512 )。
#
# ziplist是一個解決空間的緊湊的數據存儲結構，但是當數據超過閾值時，將採用原生的數據存儲結構
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
# 與哈希表類似。
list-max-ziplist-entries 512
list-max-ziplist-value 64
# 設置特殊編碼的唯一情況：
# 當一個set僅僅由一個基數爲10最大位數爲64位的有符號×××的字符串構成的時候。
#
# 以下配置設置了set的限制大小，當小於這個值時將會使用一個更緊湊的數據結構來
# 保存以期減少內存佔用
set-max-intset-entries 512
# 與hash和list類似。zsort也採用如下的配置來選擇是否進行特殊編碼來節省空間。
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
# HyperLogLog 稀疏表示字節限制
# 這個限制包含了16個字節的頭部，當一個HyperLogLog使用sparse representation
# 超過了這個顯示，它就會轉換到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設計與實現》的字典部分)
activerehashing yes
# 客戶端輸出緩衝區顯示可以用來解決由於某些原因導致的強制斷線，
# 而造成的不能讀到需要的數據。
# 一個比較常見的原因是發佈訂閱模式中，客戶端不能足夠快速地消費發佈者生產的信息。
#
# 這個限制可以設置爲如下的三種類型:
#
# normal -> 正常普通的客戶端，包含監控客戶端
# slave -> 主從結構中的從客戶端
# pubsub -> 訂閱了最少一個頻道的客戶端
#
# 每一個 client-output-buffer-limit 格式如下:
#
# client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
#
# 在兩種情況下服務器認爲客戶端不是意外臨時掉線
#
# 1.緩衝區的數據達到硬限制
# 2.緩衝區的數據達到軟限制，同時時間超過了指定值
#
# 因爲一個客戶端離線，有可能是臨時性的網絡故障，或者傳輸問題
# 也有可能是永久性離線 或者強制性離線，此時服務器將不會保留他的緩存數據
# 以下的設置就是爲了判斷這一情況的
#
# 硬限制和軟限制都可以通過將其設置爲0來關閉掉
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會按照一定的頻率來處理諸如關閉超時連接，清理沒有被使用的過期key等此類
# 後臺任務
#
# 並不是所有的任務都以相同的頻率來執行的，redis通過一個hz的值來決定處理這些(如上所述的後臺任務)任務的頻率
#
# 提高這個值會使用更多的cpu時間來在redis閒置的時候處理以上的，但是同時，
# 超時的連接的處理和過期key的清理也會更精確
#
# hz的取值範圍在1到500，不建議設置爲超過100的值，默認是10
hz 10
# 當子進程重寫AOF文件的時候，以下選項將會允許等到存在32MB數據的時候才調用強制同步，這樣可以降低IO上的延遲。
aof-rewrite-incremental-fsync yes
Creator: Perry.Zhang
Date: 12.15.2015