# Redis 配置案例 #關於單位，當你需要指定內存的大小時，可以使用如下的單位來指定 #（譯者注，為什麼會存在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文件的位置，也就是 #上一個指令所說的默認，你可以根據自己的需要修改它 # pidfile /var/run/redis.pid # 在指定的端口上進行監聽，默認是 6379 # 如果端口設置為0，那麼redis就不會在TCP socket上進行監聽 # (譯者注：不在tcp socket上進行監聽，不代表沒法連接，只是無法使用網絡連接而已) port 6379 # TCP listen() backlog值 #（譯者注：backlog值是指目前最大的連接隊列，因為TCP連接是三次握手） #（沒有完成三次握手和尚未被accept的connect都會處於連接隊列中，但是backlog的實際值與操作系統相關） #（並非設置多少就是多少，只能說調整得大一些可以在同一時間應對更多的連接請求） # #在一個並發量高的環境中，你需要指定一個比較大的backlog值來避免慢連接（由於網絡原因握手速度慢）的情況 #注意，linux內核會默認 使用/proc/sys/net/core/somaxconn 的值來削減 backlog的實際值， #因此你需要確保提升 somaxconn 和 tcp_max_syn_backlog 這兩個值來確保此處的backlog生效 #（譯者注：只有 當每一個請求都重新發起一個連接的時候，backlog值的增大才能影響到並發量） #（在tcp穩定連接的時候，或連接復用(連接池的使用)，backlog值對並發沒有任何影響） # tcp-backlog 511 # #默認情況下redis會在所有的可用網絡接口中進行監聽，如果你想讓redis在指定的網絡接口中 #監聽，那麼可以使用bind 命令來指定redis的監聽接口 #（譯者科普：網絡的中的服務是通過 ip+進程 來進行區分的，當一個服務器擁有兩個ip時 ） #（自然就在網絡中擁有兩個人身份，如 內網，外網，當你只想讓redis在一個網絡上監聽時，就可以使用如下的配置） # (127.0.0.1 就是指定只能本機進行網絡訪問) # 例如: # # bind 192.168.1.100 10.0.0.1 # 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）保持連接在網絡環境中的存活 # # tcp-keepalive 0 # 指定日志的記錄級別的 # 可以是如下的幾個值之一 # debug (盡可能多的日志信息，用於開發和測試之中) # verbose (少但是有用的信息, 沒有debug級別那麼混亂) # notice (適量的信息，用於生產環境) # warning (只有非常重要和關鍵的信息會被記錄) loglevel notice # 指定日志文件的位置. 為空時將輸出到標准輸出設備 # 如果你在demo模式下使用標准輸出的日志，日志將會輸出到 /dev/null logfile "" # 當設置 'syslog-enabled'為 yes時， 允許記錄日志到系統日志中。 # 以及你可以使用更多的日志參數來滿足你的要求 # syslog-enabled no # 指定在系統日志中的身份 # syslog-ident redis # 指定系統日志的能力. 必須是 LOCAL0 到 LOCAL7 之間（閉區間）. # syslog-facility local0 #設置數據庫的編號. 默認的數據庫是DB 0 #使得你可以在每一個連接的基礎之上使用 SELECT <dbid> 來指定另外的數據庫，但是這個值必須在 0到 'database'-1之間 databases 16 ################################ SNAPSHOTTING ################################ # # 保存 DB 到硬盤: # # save <seconds> <changes> # # 將會在<seconds> 和 <changes>兩個值同時滿足時，將DB數據保存到硬盤中 # 其中<seconds> 每多少秒，<changes>是改變的key的數量 # # 在以下的例子中，將會存在如下的行為 # 當存在最少一個key 變更時，900秒(15分鐘)後保存到硬盤 # 當存在最少10個key變更時，300秒後保存到硬盤 # 當存在最少1000個key變更時，60秒後保存到硬盤 # # 提示: 你可以禁用如下的所有 save 行 # # 你可以刪除所有的save然後設置成如下這樣的情況 # # # # save "" save 900 1 save 300 10 save 60 10000 # # 作為默認，redis會在RDB快照開啟和最近後台保存失敗的時候停止接受寫入(最少一個保存點) #這會使得用戶察覺（通常比較困難）到數據不會保持在硬盤上的正確性，否則很難發現 #這些災難會發生 # # 如果後台保存程序再次開始工作，reidis會再次自動允許寫入 # #然而如果對redis服務器設置了合理持續的監控，那麼你可以關閉掉這個選項。 #這會導致redis將繼續進行工作，無論硬盤，權限或者其他的是否有問題 # # stop-writes-on-bgsave-error yes # 是否在dump到 rdb 數據庫的時候使用LZF來壓縮字符串 # 默認是 yes，因為這是一個優良的做法 # # 如果你不想耗費你的CPU處理能力，你可以設置為 no，但是這會導致你的數據會很大 rdbcompression yes # 從RDB的版本5開始，CRC64校驗值會寫入到文件的末尾 #這會使得格式化過程中，使得文件的完整性更有保障，但是這會在保存和加載的時候損失不少的性能(大概在10%) #你可以關閉這個功能來獲得最高的性能 # #RDB文件會在校驗功能關閉的時候，使用0來作為校驗值，這將告訴加載代碼來跳過校驗步驟 rdbchecksum yes # DB的文件名稱 dbfilename dump.rdb # 工作目錄. # # DB將會使用上述 'dbfilename'指定的文件名寫入到該目錄中 # # 追加的文件也會在該目錄中創建 # # 注意，你應該在這裡輸入的是一個目錄而不是一個文件名 dir ./ ################################# REPLICATION ################################# # 主從復制。使用 slaveof 命令來 指導redis從另一個redis服務的拷貝中來創建一個實例 # #注意：這個配置是主從結構的從（主從結構的從，怎麼那麼拗口呢）redis的本地配置 # #如下例子，這個配置指導 slave (從redis) 通過另一個redis的實例的ip和端口號來獲取DB數據 # # # # slaveof <masterip> <masterport> # # 如果主服務器開啟了密碼保護(使用下面的"requirepass"配置) # 這個配置就是告訴從服務在發起向主服務器的異步復制的請求之前使用如下的密碼進行認證， #否則主服務器會拒絕這個請求 # # # # masterauth <master-password> # # 如果從服務器失去了和主服務器之間的連接，或者當復制仍然處於處理狀態的時候 # 從服務器做出如下的兩個行為 # # 1）如果 slave-serve-stale-data 被設置為 yes(默認值)，從服務器將會持續 # 回復來自客戶端的請求，可能會回復已經過期的數據，或者返回空的數據，當從服務器第一次異步請求數據時。 # # 2）如果 slave-serve-stale-data 被設置為 no ，從服務器就會返回"SYNC with master in progress" # 這個錯誤，來應答所有命令除了 INFO 和 SLAVEOF # slave-serve-stale-data yes # # # 你可以配置一個從服務器的實例是否接受寫請求， # 從服務器在存儲一些短暫的數據的的時候，接收寫請求是一件非常正確的事情 # （因為數據在向主服務器同步之後非常容易擦除）但是會因為配置不正確而導致一些問題 # # 從redis 2.6開始默認從服務器是只讀的服務器 # # # #提示：只讀的從服務器並不是設計用來公開給不受信任的互聯網客戶端的，它 #僅僅是一個用來防止對實例進行誤操作的保護層。只讀從服務器默認用來輸出管理命令 #例如 CONFIG, DEBUG 和其他。如果你想限制它的規模，你可以使用'rename-command'來 #提高它的安全性，使得她作為一個影子來執行管理或者危險的命令 # # slave-read-only yes # 從服務器在預設的間隔中發送送一個ping到目標服務器。你可以通過修改repl-ping-slave-period #的值來修改它，默認是10秒鐘 # # # repl-ping-slave-period 10 # repl-timeout設置了以下的復制超時值: # # 1) 在從服務器中，使用同步IO進行大規模傳輸. # 2) 在從服務器中，主服務器的超時(ping，數據) # 3) 在主服務器中. 從服務器的超時(對pings的響應) # # # 確保這個值大於 指定的repl-ping-slave-period 值，否則當主從之間是低流量時 # 會檢測到超時的情況 # # repl-timeout 60 # 在從服務器同步之後是否關閉TCP_NODELAY? # # # 如果你選擇 "yes"，redis將會使用一個很小的TCP包和很小的帶寬來向從服務器發送數據。 # 如果使用默認的設置這會增加數據復制到從服務器之間的延遲。如果使用默認配置的linux內核 # 這個延遲會高達到40毫秒 # # #如果你選擇 "no"，數據復制到從服務器將會減少延遲，但是會使用更多的帶寬。 # #作為默認我們為低延遲進行優化，但是在一個高流量的情況下或者當主服務器和從服務器 #有很多hops的時候，將該值設置為yes會更好 # (譯者注：這就是一個網絡調優的問題，默認的TCP內核會使用Nagle，即將小的數據包合並成大的數據包(及yes的情況)) # (在等待合並的過程種，肯定會存在等待後續數據的步驟，因此這會導致數據的延遲) # (yes，就是使用TCP的默認情況開啟Nagle算法，no就是關閉Nagle算法) repl-disable-tcp-nodelay no # # #設置復制的backlog值。(這個backlog和tcp中的backlog不一樣) # #這個backlog值是一個緩沖區，當從服務器斷開連接之後，主服務器將更新的數據放置 #在這個緩沖區中，因為當從服務重新連接上來時候不是所有的數據都需要同步，因此從這個 #緩沖區中取數據就可以同步到和主服務器一樣的狀態 # # #這個值設置得越大，從服務器的掉線時間就可以越長，上線後就可以進行局部更新 #（譯者注：當掉線時間過長而無法進行局部更新，那麼從服務器就會再一次進行同步所有的數據，耗時和當時的數據量成正比） #當且僅當第一個從服務器連接到服務器之後這個緩存才會被分配 # # repl-backlog-size 1mb # # # 當從服務器在長時間內沒有連接到主服務器時，backlog的緩存將會被釋放。 # 以下的選項就是自 從服務器最後一次斷掉和主服務器之間的 # 連接開始N秒後清空backlog的緩存 # # 設置為0意味著永遠不會清空backlog # # repl-backlog-ttl 3600 # # # 在redis的信息輸出中我們使用一個整型值來表示從服務器的優先值 # #這個優先級的作用是，在主從結構種，當主服務器不能正常工作的時候時候， #將一個從服務器提升為主服務器，提升的依據就是這個值。 # # 假設又三個 優先級分別為 25 10 100 的服務器，將優先將數值最少的提升為主服務器 # 即最小值優先 # 如果優先級設置為0，意味著將不會又機會成為主服務器 # 默認優先級是100 slave-priority 100 # # 下面的值用來設置主服務器停止接受寫入事件的情況。 # 如果從服務器的連接小於N # 從服務器的數據落後 小於等於M秒 # # N個從服務器必須是在線的狀態 # # lag的單位是秒，它必須 <=指定的值，它從最後一次收到ping包的時間開始計算。 # 通常ping包都是每秒發送一次 # # # 這個選項並不擔保N個副本都會接受寫入，但是會確保在指定的時間沒有足夠的從服務可用的時候 # 窗口上顯示丟失寫入 # # # 例如要求最少三個從服務器在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. ################################### LIMITS #################################### # # 設置同一時間的客戶端最大連接數，默認的限制是10000個客戶端。 #然而如果redis服務不設置這個限制值那麼最大的用戶數就是最大文件描述符數-32. # # #一旦連接的用戶數超出了限制值，redis將會關閉新的連接並且發送 'max number of client reached' # # maxclients 10000 # 不使用超出指定大小的內存， #當redis使用到的內存達到限定值的時候，將會根據淘汰策略試圖移除一部分key # # # 如果根據相關策略無法移除key，或者策略被設置為 'noeviction'，redis將會對 #使用到內存的命令返回錯誤，比如 SET LPUSH等，並且進入只讀模式僅僅響應只讀的命令如GET # # 這個選項在你將redis當做一個LRU緩存和設置一個內存大小限制的時候十分有用。 # # # # 警告：如果你的從服務器關聯到一個有最大內存限制的redis實例上， # # 主服務器向從服務器輸出的緩存屬於被該服務器使用的內存的一部分。 #因此 網絡問題和重新同步引發的復制，不會觸發淘汰key的循環， # #反過來，從服務器的輸出緩存將會被觸發淘汰的DEL key，直到數據庫清空 # # # #簡單來說，如果你擁有一個從服務器，我們建議你將這個值 #設置為少於系統可用的最大內存，以便系統可以騰出空間來安放 #從服務器的輸出緩存（但是如果策略是noeviction 那就沒這個必要） # # maxmemory <bytes> # 最大內存策略: 當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，因為AOF有更好的魯棒性 # # 你可以從 http://redis.io/topics/persistence 獲取更多的信息 appendonly no # append only file 的名稱 (默認是: "appendonly.aof") appendfilename "appendonly.aof" # fsync() 調用告訴操作系統立即將數據寫入到硬盤中，而不是寫入到輸出緩沖區 # 等待足夠的數據再寫入。一些操作系統會立即將數據寫入到硬盤中，一些其他的 #操作系統則只是盡可能快地將數據寫入硬盤中 # # # Redis支持三種不同的模式: # # 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)調用 # # 為了減輕這個問題，下面的選項將會在GBSAVE 或者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 ################################ 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的時候，最舊的一條記錄將會被移除。 # # # 下面的值將會被解釋為 微秒 為單位，所以 1000000 微秒為 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 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 # # 與hash表類似， # 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
