# Redis 配置案例html
#關於單位,當你須要指定內存的大小時,可使用以下的單位來指定node
#(譯者注,爲何會存在1000爲單位,我認爲是考慮到硬盤的容量單位是以1000來進行計算而非程序中的1024)linux
#(所以 使用 1000爲單位能夠進一步地精確估算出所需的實際硬盤容量)redis
#算法
# 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