Redis筆記8：解析配置文件redis.conf

2024-07-21 02:51:22

字體：大中小

來源：轉載

供稿：網(wǎng)友

如果是一個專業(yè)的 DBA，那么實例啟動時會加很多的參數(shù)以便使系統(tǒng)運行的非常穩(wěn)定，這樣就可能會在啟動時在 Redis 后面加一個參數(shù)，以指定配置文件的路徑，就象 MySQL 一樣的讀取啟動配置文件的方式來啟動數(shù)據(jù)庫。源碼編譯完成后，在 Redis目錄下有一個redis.conf 文件，這個文件即是 Redis 的配置文件。我們可以在啟動時使用以下命令來用配置文件啟動。

[root@localhost ~]# ./redis-server /opt/redis/redis.conf

Redis的一些度量單位，redis配置中對單位的大小寫不敏感，1GB、1Gb和1gB都是相同的。由此也說明，redis只支持bytes，不支持bit單位。

# 1k => 1000 bytes# 1kb => 1024 bytes# 1m => 1000000 bytes# 1mb => 1024*1024 bytes# 1g => 1000000000 bytes# 1gb => 1024*1024*1024 bytes

Redis可以引入外部配置文件很像C/C++中的include指令，多個配置文件，Redis總是使用最后加載的配置項，如果想引入的配置不會重寫，可以在主配置文件最后引入。

include /path/to/other.conf

==================== Redis配置 - 通用 ====================

# Redis默認不是以守護進程的方式運行，可以通過該配置項修改，使用yes啟用守護進程方式。注意配置成守護進程后Redis會將進程號寫入文件/var/run/redis.piddaemonize yes## 當Redis以守護進程方式運行時，Redis默認會把pid寫入/var/run/redis.pid文件，可以通過pidfile指定pidfile /var/run/redis.pid##指定Redis監(jiān)聽端口，默認端口為6379，為什么使用6379，因為6379在手機按鍵上MERZ對應的號碼，而MERZ取自意大利歌女Alessia Merz的名字port 6379## 在高并發(fā)環(huán)境下你需要一個高backlog值來避免慢客戶端連接問題。# 注意linux內核默默地將這個值減小到/PRoc/sys/net/core/somaxconn的值，# 所以需要確認增大somaxconn和tcp_max_syn_backlog兩個值來達到想要的效果。tcp-backlog 511## 默認Redis監(jiān)聽服務器上所有可用網(wǎng)絡接口的連接?？梢杂?bind"配置指令跟一個或多個ip地址來實現(xiàn)監(jiān)聽一個或多個網(wǎng)絡接口bind 192.168.1.100 10.0.0.1bind 127.0.0.1## 如果redis不監(jiān)聽端口，還怎么與外界通信呢”，其實redis還支持通過unix socket方式來接收請求。# 可以通過unixsocket配置項來指定unix socket文件的路徑，并通過unixsocketperm來指定文件的權限。# 指定用來監(jiān)聽Unix套套接字的路徑。沒有默認值，所以在沒有指定的情況下Redis不會監(jiān)聽Unix套接字unixsocket /tmp/redis.sockunixsocketperm 755## 當一個redis-client一直沒有請求發(fā)向server端，那么server端有權主動關閉這個連接，可以通過timeout來設置“空閑超時時限”，0表示永不關閉。# 設置客戶端連接時的超時時間，單位為秒。當客戶端在這段時間內沒有發(fā)出任何指令，那么關閉該連接# 默認值：0代表禁用，永不關閉 timeout 0## TCP keepalive.## 如果非零，則設置SO_KEEPALIVE選項來向空閑連接的客戶端發(fā)送ACK，由于以下兩個原因這是很有用的：## 1）能夠檢測無響應的對端# 2）讓該連接中間的網(wǎng)絡設備知道這個連接還存活## 在Linux上，這個指定的值(單位：秒)就是發(fā)送ACK的時間間隔。# 注意：要關閉這個連接需要兩倍的這個時間值。# 在其他內核上這個時間間隔由內核配置決定## TCP連接?；畈呗裕梢酝ㄟ^tcp-keepalive配置項來進行設置，單位為秒，# 假如設置為60秒，則server端會每60秒向連接空閑的客戶端發(fā)起一次ACK請求，以檢查客戶端是否已經(jīng)掛掉，# 對于無響應的客戶端則會關閉其連接。所以關閉一個連接最長需要120秒的時間。如果設置為0，則不會進行?；顧z測。## 這個選項的一個合理值是60秒tcp-keepalive 0## 指定日志記錄級別 # Redis總共支持四個級別：debug、verbose、notice、warning，默認為verbose # debug 記錄很多信息，用于開發(fā)和測試# varbose 很多精簡的有用信息，不像debug會記錄那么多# notice 普通的verbose，常用于生產環(huán)境# warning 只有非常重要或者嚴重的信息會記錄到日志 loglevel notice## 指明日志文件名。也可以使用"stdout"來強制讓Redis把日志信息寫到標準輸出上。# 默認為標準輸出，如果配置Redis為守護進程方式運行，而這里又配置為日志記錄方式為標準輸出，則日志將會發(fā)給/dev/nulllogfile ""## 要使用系統(tǒng)日志記錄器，只要設置 "syslog-enabled" 為 "yes" 就可以了。# 然后根據(jù)需要設置其他一些syslog參數(shù)就可以了。syslog-enabled no## 指定linux系統(tǒng)日志syslog的標示符，若是"syslog-enabled=no"，則這個選項無效syslog-ident redis## 指定linux系統(tǒng)日志syslog 設備(facility)，必須是USER或者LOCAL0到LOCAL7之間syslog-facility local0 ## 可用數(shù)據(jù)庫數(shù)，默認值為16，默認數(shù)據(jù)庫存儲在DB 0號ID庫中，無特殊需求，建議僅設置一個數(shù)據(jù)庫 databases 1# 查詢數(shù)據(jù)庫使用 SELECT <dbid># dbid介于 0 到 'databases'-1 之間databases 16

==================== Redis配置 - 快照 ====================

## 把數(shù)據(jù)庫存到磁盤上:## save <seconds> <changes># # 會在指定秒數(shù)和數(shù)據(jù)變化次數(shù)之后把數(shù)據(jù)庫寫到磁盤上。## 下面的例子將會進行把數(shù)據(jù)寫入磁盤的操作:# 900秒(15分鐘)之后，且至少有1個key(次)變更# 300秒(5分鐘)之后，且至少有10個key(次)變更# 60秒之后，且至少有10000個key(次)變更## 注意：如果不需要寫磁盤，則把所有 "save" 設置注釋掉，即實現(xiàn)全內存服務器。# 如果你想禁用RDB持久化的策略，只要不設置任何save指令就可以，或者給save傳入一個空字符串參數(shù)也可以達到相同效果save 900 1save 300 10save 60 10000 ## 如果用戶開啟了RDB快照功能，那么在redis持久化數(shù)據(jù)到磁盤時如果出現(xiàn)失敗，默認情況下，redis會停止接受所有的寫請求。# 這樣做的好處在于可以讓用戶很明確的知道內存中的數(shù)據(jù)和磁盤上的數(shù)據(jù)已經(jīng)存在不一致了。# 如果redis不顧這種不一致，一意孤行的繼續(xù)接收寫請求，就可能會引起一些災難性的后果。# 如果下一次RDB持久化成功，redis會自動恢復接受寫請求。# 當然，如果你不在乎這種數(shù)據(jù)不一致或者有其他的手段發(fā)現(xiàn)和控制這種不一致的話，你完全可以關閉這個功能，以便在快照寫入失敗時，也能確保redis繼續(xù)接受新的寫請求。stop-writes-on-bgsave-error yes#### 當導出到 .rdb 數(shù)據(jù)庫時是否用LZF壓縮字符串對象。# 默認設置為 "yes"，# 如果想節(jié)省CPU的話，可以把這個設置為 "no"，但是如果有可以壓縮的key卻沒有壓縮的話，那數(shù)據(jù)文件就會變得更大rdbcompression yes## 因為版本5的RDB有一個CRC64算法的校驗和放在了文件的最后。這將使文件格式更加可靠但在# 生產和加載RDB文件時，這有一個性能消耗(大約10%)，所以你可以關掉它來獲取最好的性能。# 生成的關閉校驗的RDB文件有一個0的校驗和，它將告訴加載代碼跳過檢查rdbcompression yes## 數(shù)據(jù)庫的文件名及存放路徑dbfilename dump.rdb## 工作目錄# 本地數(shù)據(jù)庫會寫到這個目錄下，文件名就是上面的 "dbfilename" 的值。# 累加文件也放這里。# 注意你這里指定的必須是目錄，不是文件名。dir ./

==================== Redis配置 - 同步 ====================

# 主從同步。通過 slaveof 配置來實現(xiàn)Redis實例的備份。# 注意，這里是本地從遠端復制數(shù)據(jù)。也就是說，本地可以有不同的數(shù)據(jù)庫文件、綁定不同的IP、監(jiān)聽不同的端口。# 當本機為從服務時，設置主服務的IP及端口，在Redis啟動時，它會自動從主服務進行數(shù)據(jù)同步slaveof <masterip> <masterport> ## 如果主服務master設置了密碼(通過下面的 "requirepass" 選項來配置)，slave服務連接master的密碼，那么slave在開始同步之前必須進行身份驗證，否則它的同步請求會被拒絕。# 當本機為從服務時，設置主服務的連接密碼masterauth <master-passWord> ## 當一個slave失去和master的連接，或者同步正在進行中，slave的行為有兩種可能：# 1) 如果 slave-serve-stale-data 設置為 "yes" (默認值)，slave會繼續(xù)響應客戶端請求，可能是正常數(shù)據(jù)，也可能是還沒獲得值的空數(shù)據(jù)。# 2) 如果 slave-serve-stale-data 設置為 "no"，slave會回復"正在從master同步(SYNC with master in progress)"來處理各種請求，除了 INFO 和 SLAVEOF 命令。slave-serve-stale-data yes## 你可以配置salve實例是否接受寫操作。可寫的slave實例可能對存儲臨時數(shù)據(jù)比較有用(因為寫入salve# 的數(shù)據(jù)在同master同步之后將很容被刪除)，# 但是如果客戶端由于配置錯誤在寫入時也可能產生一些問題。# 從Redis2.6默認所有的slave為只讀## 注意:只讀的slave不是為了暴露給互聯(lián)網(wǎng)上不可信的客戶端而設計的。它只是一個防止實例誤用的保護層。# 一個只讀的slave支持所有的管理命令比如config,debug等。為了限制你可以用'rename-command'來# 隱藏所有的管理和危險命令來增強只讀slave的安全性slave-read-only yes## 復制集同步策略：磁盤或者socket# 新slave連接或者老slave重新連接時候不能只接收不同，得做一個全同步。需要一個新的RDB文件dump出來，然后從master傳到slave?？梢杂袃煞N情況：# 1）基于硬盤（disk-backed）：master創(chuàng)建一個新進程dump RDB，完事兒之后由父進程（即主進程）增量傳給slaves。# 2）基于socket（diskless）：master創(chuàng)建一個新進程直接dump RDB到slave的socket，不經(jīng)過主進程，不經(jīng)過硬盤。# 基于硬盤的話，RDB文件創(chuàng)建后，一旦創(chuàng)建完畢，可以同時服務更多的slave?；趕ocket的話，新slave來了后，得排隊（如果超出了repl-diskless-sync-delay還沒來），完事兒一個再進行下一個。# 當用diskless的時候，master等待一個repl-diskless-sync-delay的秒數(shù)，如果沒slave來的話，就直接傳，后來的得排隊等了。否則就可以一起傳。# disk較慢，并且網(wǎng)絡較快的時候，可以用diskless。（默認用disk-based）repl-diskless-sync no## 設置成0的話，傳輸開始ASAPrepl-diskless-sync-delay 5## slave根據(jù)指定的時間間隔向服務器發(fā)送ping請求。# 時間間隔可以通過 repl_ping_slave_period 來設置。# 默認10秒repl-ping-slave-period 10## 以下選項設置同步的超時時間## 1）slave在與master SYNC期間有大量數(shù)據(jù)傳輸，造成超時# 2）在slave角度，master超時，包括數(shù)據(jù)、ping等# 3）在master角度，slave超時，當master發(fā)送REPLCONF ACK pings# # 確保這個值大于指定的repl-ping-slave-period，否則在主從間流量不高時每次都會檢測到超時repl-timeout 60## 是否在slave套接字發(fā)送SYNC之后禁用 TCP_NODELAY ？## 如果你選擇“yes”Redis將使用更少的TCP包和帶寬來向slaves發(fā)送數(shù)據(jù)。# 但是這將使數(shù)據(jù)傳輸?shù)絪lave上有延遲，Linux內核的默認配置會達到40毫秒，# 如果你選擇了 "no" 數(shù)據(jù)傳輸?shù)絪alve的延遲將會減少但要使用更多的帶寬默認我們會為低延遲做優(yōu)化，# 但高流量情況或主從之間的跳數(shù)過多時，把這個選項設置為“yes”是個不錯的選擇。repl-disable-tcp-nodelay no## 設置數(shù)據(jù)備份的backlog大小。# backlog是一個slave在一段時間內斷開連接時記錄salve數(shù)據(jù)的緩沖，# 所以一個slave在重新連接時，不必要全量的同步，而是一個增量同步就足夠了，將在斷開連接的這段時間內slave丟失的部分數(shù)據(jù)傳送給它。# 同步的backlog越大，slave能夠進行增量同步并且允許斷開連接的時間就越長。# backlog只分配一次并且至少需要一個slave連接repl-backlog-size 1mb## 當master在一段時間內不再與任何slave連接，backlog將會釋放。以下選項配置了從最后一個slave斷開開始計時多少秒后，backlog緩沖將會釋放。# 0表示永不釋放backlogrepl-backlog-ttl 3600## slave的優(yōu)先級是一個整數(shù)展示在Redis的Info輸出中。如果master不再正常工作了，# Sentinel將用它來選擇一個slave提升=升為master。優(yōu)先級數(shù)字小的salve會優(yōu)先考慮提升為master，# 所以例如有三個slave優(yōu)先級分別為10，100，25，# Sentinel將挑選優(yōu)先級最小數(shù)字為10的slave。# 0作為一個特殊的優(yōu)先級，標識這個slave不能作為master，所以一個優(yōu)先級為0的slave永遠不會被Sentinel挑選提升為master# 默認優(yōu)先級為100slave-priority 100## 如果master少于N個延時小于等于M秒的已連接slave，就可以停止接收寫操作。# N個slave需要是“oneline”狀態(tài)# 延時是以秒為單位，并且必須小于等于指定值，是從最后一個從slave接收到的ping（通常每秒發(fā)送）開始計數(shù)。# 例如至少需要3個延時小于等于10秒的slave用下面的指令：# 兩者之一設置為0將禁用這個功能。# 默認 min-slaves-to-write 值是0（該功能禁用）并且 min-slaves-max-lag 值是10。min-slaves-to-write 3min-slaves-max-lag 10

==================== redis配置 - 安全 ====================

# 要求客戶端在處理任何命令時都要驗證身份和密碼。# 這個功能在有你不信任的其它客戶端能夠訪問redis服務器的環(huán)境里非常有用。# 為了向后兼容的話這段應該注釋掉。而且大多數(shù)人不需要身份驗證(例如:它們運行在自己的服務器上)# 警告：因為Redis太快了，所以外面的人可以嘗試每秒150k的密碼來試圖破解密碼。這意味著你需要# 一個高強度的密碼，否則破解太容易了。requirepass foobared## 命令重命名# 在共享環(huán)境下，可以為危險命令改變名字。比如，你可以為 CONFIG 改個其他不太容易猜到的名字，# 這樣內部的工具仍然可以使用，而普通的客戶端將不行。# 例如：# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52# 請注意：改變命令名字被記錄到AOF文件或被傳送到從服務器可能產生問題。# 也可以通過改名為空字符串來完全禁用一個命令rename-command CONFIG ""

==================== Redis配置 - 限制 ====================

# 設置最多同時連接的客戶端數(shù)量。默認這個限制是10000個客戶端，然而如果Redis服務器不能配置# 處理文件的限制數(shù)來滿足指定的值，那么最大的客戶端連接數(shù)就被設置成當前文件限制數(shù)減32（因# 為Redis服務器保留了一些文件描述符作為內部使用）# 一旦達到這個限制，Redis會關閉所有新連接并發(fā)送錯誤'max number of clients reached'maxclients 10000## 不要用比設置的上限更多的內存。一旦內存使用達到上限，Redis會根據(jù)選定的回收策略（參見：maxmemmory-policy）刪除key# 如果因為刪除策略Redis無法刪除key，或者策略設置為 "noeviction"，Redis會回復需要更# 多內存的錯誤信息給命令。例如，SET,LPUSH等等，但是會繼續(xù)響應像Get這樣的只讀命令。# 在使用Redis作為LRU緩存，或者為實例設置了硬性內存限制的時候（使用 "noeviction" 策略）的時候，這個選項通常事很有用的。# 警告：當有多個slave連上達到內存上限的實例時，master為同步slave的輸出緩沖區(qū)所需# 內存不計算在使用內存中。這樣當驅逐key時，就不會因網(wǎng)絡問題 / 重新同步事件觸發(fā)驅逐key# 的循環(huán)，反過來slaves的輸出緩沖區(qū)充滿了key被驅逐的DEL命令，這將觸發(fā)刪除更多的key，# 直到這個數(shù)據(jù)庫完全被清空為止# # 總之...如果你需要附加多個slave，建議你設置一個稍小maxmemory限制，這樣系統(tǒng)就會有空閑# 的內存作為slave的輸出緩存區(qū)(但是如果最大內存策略設置為"noeviction"的話就沒必要了)maxmemory <bytes>## 最大內存策略：如果達到內存限制了，Redis如何選擇刪除key。你可以在下面五個行為里選：# # volatile-lru -> 根據(jù)LRU算法生成的過期時間來刪除。# allkeys-lru -> 根據(jù)LRU算法刪除任何key。# volatile-random -> 根據(jù)過期設置來隨機刪除key。 # allkeys->random -> 無差別隨機刪。 # volatile-ttl -> 根據(jù)最近過期時間來刪除（輔以TTL） # noeviction -> 誰也不刪，直接在寫操作時返回錯誤。# # 注意：對所有策略來說，如果Redis找不到合適的可以刪除的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算法的實現(xiàn)都不是很精確，但是很接近（為了省內存），所以你可以用樣本量做檢測。# 例如：默認Redis會檢查3個key然后取最舊的那個，你可以通過下面的配置指令來設置樣本的個數(shù)。maxmemory-samples 3

==================== Redis配置 - 追加模式 ====================

# 默認情況下，Redis是異步的把數(shù)據(jù)導出到磁盤上。這種模式在很多應用里已經(jīng)足夠好，但Redis進程# 出問題或斷電時可能造成一段時間的寫操作丟失(這取決于配置的save指令)。## AOF是一種提供了更可靠的替代持久化模式，例如使用默認的數(shù)據(jù)寫入文件策略（參見后面的配置）# 在遇到像服務器斷電或單寫情況下Redis自身進程出問題但操作系統(tǒng)仍正常運行等突發(fā)事件時，Redis能只丟失1秒的寫操作。## AOF和RDB持久化能同時啟動并且不會有問題。# 如果AOF開啟，那么在啟動時Redis將加載AOF文件，它更能保證數(shù)據(jù)的可靠性。# 請查看 http://redis.io/topics/persistence 來獲取更多信息.appendonly no## 追加加文件名字（默認："appendonly.aof"）appendfilename "appendonly.aof"## fsync() 系統(tǒng)調用告訴操作系統(tǒng)把數(shù)據(jù)寫到磁盤上，而不是等更多的數(shù)據(jù)進入輸出緩沖區(qū)。# 有些操作系統(tǒng)會真的把數(shù)據(jù)馬上刷到磁盤上；有些則會盡快去嘗試這么做。## Redis支持三種不同的模式：## no：不要立刻刷，只有在操作系統(tǒng)需要刷的時候再刷。比較快。# always：每次寫操作都立刻寫入到aof文件。慢，但是最安全。# everysec：每秒寫一次。折中方案。 ## 默認的 "everysec" 通常來說能在速度和數(shù)據(jù)安全性之間取得比較好的平衡。根據(jù)你的理解來# 決定，如果你能放寬該配置為"no" 來獲取更好的性能(但如果你能忍受一些數(shù)據(jù)丟失，可以考慮使用# 默認的快照持久化模式)，或者相反，用“always”會比較慢但比everysec要更安全。## 請查看下面的文章來獲取更多的細節(jié)# http://antirez.com/post/redis-persistence-demystified.html # # 如果不能確定，就用 "everysec"appendfsync everysec## 如果AOF的同步策略設置成 "always" 或者 "everysec"，并且后臺的存儲進程（后臺存儲或寫入AOF# 日志）會產生很多磁盤I/O開銷。某些Linux的配置下會使Redis因為 fsync()系統(tǒng)調用而阻塞很久。# 注意，目前對這個情況還沒有完美修正，甚至不同線程的 fsync() 會阻塞我們同步的write(2)調用。## 為了緩解這個問題，可以用下面這個選項。它可以在 BGSAVE 或 BGREWRITEAOF 處理時阻止fsync()。# # 這就意味著如果有子進程在進行保存操作，那么Redis就處于"不可同步"的狀態(tài)。# 這實際上是說，在最差的情況下可能會丟掉30秒鐘的日志數(shù)據(jù)。（默認Linux設定）# # 如果把這個設置成"yes"帶來了延遲問題，就保持"no"，這是保存持久數(shù)據(jù)的最安全的方式。no-appendfsync-on-rewrite no## 自動重寫AOF文件# 如果AOF日志文件增大到指定百分比，Redis能夠通過 BGREWRITEAOF 自動重寫AOF日志文件。# # 工作原理：Redis記住上次重寫時AOF文件的大?。ㄈ绻貑⒑筮€沒有寫操作，就直接用啟動時的AOF大?。? # 這個基準大小和當前大小做比較。如果當前大小超過指定比例，就會觸發(fā)重寫操作。你還需要指定被重寫# 日志的最小尺寸，這樣避免了達到指定百分比但尺寸仍然很小的情況還要重寫。## 指定百分比為0會禁用AOF自動重寫特性。auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb## AOF文件可能在尾部是不完整的（上次system關閉有問題，尤其是mount ext4文件系統(tǒng)時沒有加上data=ordered選項。只會發(fā)生在os死時，redis自己死不會不完整）。# 那redis重啟時load進內存的時候就有問題了。發(fā)生的時候，可以選擇redis啟動報錯，或者load盡量多正常的數(shù)據(jù)。# 如果aof-load-truncated是yes，會自動發(fā)布一個log給客戶端然后load（默認）。如果是no，用戶必須手動redis-check-aof修復AOF文件才可以。aof-load-truncated yes

==================== Redis配置 - LUA腳本 ====================

# 如果達到最大時間限制（毫秒），redis會記個log，然后返回error。# 當一個腳本超過了最大時限。只有SCRIPT KILL和SHUTDOWN NOSAVE可以用。第一個可以殺沒有調write命令的東西。要是已經(jīng)調用了write，只能用第二個命令殺。# 設置成0或者負值，時限就無限。lua-time-limit 5000

==================== Redis配置 - 集群 ====================

WARNING Redis Cluster在3.0.X版本還不是一個穩(wěn)定版本

# 開啟集群cluster-enabled yes## 每一個集群節(jié)點都有一個集群配置文件cluster-config-file nodes-6379.conf## 集群節(jié)點的超時時間，單位為毫秒cluster-node-timeout 15000## 控制從節(jié)點FailOver相關的設置# 設為0，從節(jié)點會一直嘗試啟動FailOver.# 設為正數(shù)，失聯(lián)大于一定時間（factor*節(jié)點TimeOut），不再進行FailOvercluster-slave-validity-factor 10## 最小從節(jié)點連接數(shù)cluster-migration-barrier 1## 默認為Yes,丟失一定比例Key后（可能Node無法連接或者掛掉），集群停止接受寫操作# 設置為No，集群丟失Key的情況下仍提供查詢服務cluster-require-full-coverage yes

==================== Redis配置 - 慢日志 ====================

# Redis慢查詢日志可以記錄超過指定時間的查詢。運行時間不包括各種I/O時間，例如：連接客戶端，# 發(fā)送響應數(shù)據(jù)等，而只計算命令執(zhí)行的實際時間（這只是線程阻塞而無法同時為其他請求服務的命令執(zhí)行階段）# # 你可以為慢查詢日志配置兩個參數(shù):一個指明Redis的超時時間(單位為微秒)來記錄超過這個時間的命令# 另一個是慢查詢日志長度。當一個新的命令被寫進日志的時候，最老的那個記錄從隊列中移除。## 下面的時間單位是微秒，所以1000000就是1秒。注意，負數(shù)時間會禁用慢查詢日志，而0則會強制記錄# 所有命令。slowlog-log-slower-than 10000## 這個長度沒有限制。只是要主要會消耗內存。你可以通過 SLOWLOG RESET 來回收內存。slowlog-max-len 128

==================== Redis配置 - 延遲監(jiān)控 ====================

# 默認情況下禁用延遲監(jiān)控,因為它基本上是不需要的，單位為毫秒latency-monitor-threshold 0

==================== Redis配置 - 事件通知 ====================

# Redis 能通知 Pub/Sub 客戶端關于鍵空間發(fā)生的事件# 這個功能文檔位于http://redis.io/topics/keyspace-events## 例如：如果鍵空間事件通知被開啟，并且客戶端對 0 號數(shù)據(jù)庫的鍵 foo 執(zhí)行 DEL 命令時，將通過# Pub/Sub發(fā)布兩條消息：# PUBLISH __keyspace@0__:foo del# PUBLISH __keyevent@0__:del foo## 可以在下表中選擇Redis要通知的事件類型。事件類型由單個字符來標識：## K 鍵空間通知，以__keyspace@<db>__為前綴# E 鍵事件通知，以__keysevent@<db>__為前綴# g DEL , EXPIRE , RENAME 等類型無關的通用命令的通知, ...# $ String命令# l List命令# s Set命令# h Hash命令# z 有序集合命令# x 過期事件（每次key過期時生成）# e 驅逐事件（當key在內存滿了被清除時生成）# A g$lshzxe的別名，因此”AKE”意味著所有的事件## notify-keyspace-events 帶一個由0到多個字符組成的字符串參數(shù)?？兆址馑际峭ㄖ唤谩?# 例子：啟用List和通用事件通知：# notify-keyspace-events Elg## 例子2：為了獲取過期key的通知訂閱名字為 __keyevent@__:expired 的頻道，用以下配置# notify-keyspace-events Ex## 默認所用的通知被禁用，因為用戶通常不需要該特性，并且該特性會有性能損耗。# 注意如果你不指定至少K或E之一，不會發(fā)送任何事件。notify-keyspace-events ""

==================== Redis配置 - 高級配置 ====================

# 當有大量數(shù)據(jù)時，適合用哈希編碼(這會需要更多的內存)，元素數(shù)量上限不能超過給定限制。# Redis Hash是value內部為一個HashMap，如果該Map的成員數(shù)比較少，則會采用類似一維線性的緊湊格式來存儲該Map, # 即省去了大量指針的內存開銷，如下2個條件任意一個條件超過設置值都會轉換成真正的HashMap，# 當value這個Map內部不超過多少個成員時會采用線性緊湊格式存儲，默認是64,即value內部有64個以下的成員就是使用線性緊湊存儲，超過該值自動轉成真正的HashMap。hash-max-zipmap-entries 512## 當 value這個Map內部的每個成員值長度不超過多少字節(jié)就會采用線性緊湊存儲來節(jié)省空間。hash-max-zipmap-value 64## 與hash-max-zipmap-entries哈希相類似，數(shù)據(jù)元素較少的情況下，可以用另一種方式來編碼從而節(jié)省大量空間。# list數(shù)據(jù)類型多少節(jié)點以下會采用去指針的緊湊存儲格式list-max-ziplist-entries 512## list數(shù)據(jù)類型節(jié)點值大小小于多少字節(jié)會采用緊湊存儲格式list-max-ziplist-value 64## 還有這樣一種特殊編碼的情況：數(shù)據(jù)全是64位無符號整型數(shù)字構成的字符串。# 下面這個配置項就是用來限制這種情況下使用這種編碼的最大上限的。set-max-intset-entries 512 ## 與第一、第二種情況相似，有序序列也可以用一種特別的編碼方式來處理，可節(jié)省大量空間。# 這種編碼只適合長度和元素都符合下面限制的有序序列：zset-max-ziplist-entries 128zset-max-ziplist-value 64 ## 關于HyperLogLog的介紹：http://www.redis.io/topics/data-types-intro#hyperloglogs # HyperLogLog稀疏表示限制設置，如果其值大于16000，則仍然采用稠密表示，因為這時稠密表示更能有效使用內存 # 建議值為3000 hll-sparse-max-bytes 3000 ## 哈希刷新，每100個CPU毫秒會拿出1個毫秒來刷新Redis的主哈希表(頂級鍵值映射表)。# redis所用的哈希表實現(xiàn)(見dict.c)采用延遲哈希刷新機制：你對一個哈希表操作越多，哈希刷新操作就越頻繁；# 反之，如果服務器非常不活躍那么也就是用點內存保存哈希表而已。# 默認是每秒鐘進行10次哈希表刷新，用來刷新字典，然后盡快釋放內存。# 建議：# 如果你對延遲比較在意的話就用 "activerehashing no"，每個請求延遲2毫秒不太好嘛。# 如果你不太在意延遲而希望盡快釋放內存的話就設置 "activerehashing yes"。activerehashing yes ## 客戶端的輸出緩沖區(qū)的限制，可用于強制斷開那些因為某種原因從服務器讀取數(shù)據(jù)的速度不夠快的客戶端，# （一個常見的原因是一個發(fā)布/訂閱客戶端消費消息的速度無法趕上生產它們的速度）## 可以對三種不同的客戶端設置不同的限制：# normal -> 正常客戶端# slave -> slave和 MONITOR 客戶端# pubsub -> 至少訂閱了一個pubsub channel或pattern的客戶端## 下面是每個client-output-buffer-limit語法:# client-output-buffer-limit <class><hard limit> <soft limit> <soft seconds># 一旦達到硬限制客戶端會立即被斷開，或者達到軟限制并持續(xù)達到指定的秒數(shù)（連續(xù)的）。# 例如，如果硬限制為32兆字節(jié)和軟限制為16兆字節(jié)/10秒，客戶端將會立即斷開# 如果輸出緩沖區(qū)的大小達到32兆字節(jié)，或客戶端達到16兆字節(jié)并連續(xù)超過了限制10秒，就將斷開連接。## 默認normal客戶端不做限制，因為他們在不主動請求時不接收數(shù)據(jù)（以推的方式），只有異步客戶端# 可能會出現(xiàn)請求數(shù)據(jù)的速度比它可以讀取的速度快的場景。## pubsub和slave客戶端會有一個默認值，因為訂閱者和slaves以推的方式來接收數(shù)據(jù)## 把硬限制和軟限制都設置為0來禁用該功能client-output-buffer-limit normal 0 0 0client-output-buffer-limit slave 256mb 64mb 60client-output-buffer-limit pubsub 32mb 8mb 60## Redis調用內部函數(shù)來執(zhí)行許多后臺任務，如關閉客戶端超時的連接，清除未被請求過的過期Key等等。## 不是所有的任務都以相同的頻率執(zhí)行，但Redis依照指定的“hz”值來執(zhí)行檢查任務。## 默認情況下，“hz”的被設定為10。提高該值將在Redis空閑時使用更多的CPU時，但同時當有多個key# 同時到期會使Redis的反應更靈敏，以及超時可以更精確地處理。## 范圍是1到500之間，但是值超過100通常不是一個好主意。# 大多數(shù)用戶應該使用10這個默認值，只有在非常低的延遲要求時有必要提高到100。hz 10## 當一個子進程重寫AOF文件時，如果啟用下面的選項，則文件每生成32M數(shù)據(jù)會被同步。為了增量式的# 寫入硬盤并且避免大的延遲高峰這個指令是非常有用的aof-rewrite-incremental-fsync yes

（完畢）

參考： http://blog.csdn.net/thinkercode/article/details/46580871 http://lizhenliang.blog.51cto.com/7876557/1656305

上一篇：Redis筆記7：數(shù)據(jù)類型之有序集合(sorted set)

下一篇：Redis配置文件詳解（生產環(huán)境配置）