這篇文章主要介紹redis.conf基本配置項的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！
10年積累的成都網(wǎng)站建設、成都做網(wǎng)站經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有方山免費網(wǎng)站建設讓你可以放心的選擇與我們合作。
Redis的配置項看起來比較復雜，分析之下，其實可以分為幾大類（以redis v2.6.14版本的redis.conf為例）：
1) 基本配置項
2) 持久化（Persistence）相關配置
3) Replication配置
4) Security配置
5) Limit配置
6) SlowLog配置
7) Advanced配置
8) INCLUDES配置
其中，持久化配置及Replication配置對redis來說非常重要，后面單獨說明。
本篇筆記主要介紹其它幾類配置項。
1. 基本配置項
1) daemonize
是否以守護模式啟動，默認為no，配置為yes時以守護模式啟動，這時redis instance會將進程號pid寫入默認文件/var/run/redis.pid
2) pidfile
配置pid文件路徑，默認/var/run/redis.pid，該配置項在以daemonized mode啟動redis時有效
3) port
Redis進程監(jiān)聽的TCP端口，默認為6379，如果配成0，則redis不會再listen TCP socket
4) bind
配置bind網(wǎng)卡，若配為具體ip值，則redis只偵聽來自該網(wǎng)卡的連接。該配置項默認為commented狀態(tài)，表示redis會監(jiān)聽來自該機器所有網(wǎng)卡的連接
5) unixsocket和unixsocketperm
配置unix sock file的路徑和權限，表明redis要偵聽來自指定路徑下的unix socket file的數(shù)據(jù)請求。這些配置項默認是commented的，即redis默認不會偵聽unix socket
6) timeout
配置連接超時時間，單位為秒，超時后redis進程主動斷開連接；若配置為0，則表示redis服務進程不會主動斷開來自client的連接
7) tcp-keepalive
配置redis向client發(fā)送保活ACKs的時間間隔，默認為0，表示不發(fā)送keep-alive報文。
備注：該配置項是新加的，2.6.7版本中沒有，最新的2.6.14有（還沒有調研是哪個版本引入的）。
8) loglevel
配置redis進程的日志level，支持4種：debug/verbose/notice/warning，日志信息的詳細程度遞減，可根據(jù)實際情況做配置
9) logfile
redis輸出日志路徑，默認stdout。若需改為其它目錄（如./log/redis-running.log），則日志文件的父路徑必須事先mkdir出來，否則會啟動失敗
10) sys-log-enable/syslog-ident/syslog-facility
這3個配置項與syslog相關，默認都是commented狀態(tài)。這里不再贅述，感興趣的話，可以在shell terminal中man syslog查看之。
總結：上述基本配置項中，port為必配項，其余項一般情況下保持默認即可。
2. 持久化（Persistence）相關配置
篇幅較多，下篇筆記做詳細說明。update: 參見這里
3. Replication配置
篇幅較多，下下篇筆記做詳細說明。update: 參見這里
4. Security配置
若redis實例可能會接收來自不受自己控制的客戶端的命令時（如來自第三方的訪問），可以考慮啟用密碼保護（即客戶端必須先通過認證（通過AUTH
1) requirepass
指定訪問密碼
2) rename-command
重命名命令。如rename-command CONFIG randomcommand或rename-command CONFIG ""，其中后者會完全禁用CONFIG命令。
注意：Changing the name of commands that are logged into the AOF file or transmitted to slaves may cause problems. 即若某些會寫入aof文件或同步給從庫的命令被rename后，可能會引起問題：aof文件回放時，redis實例未必會識別出被rename后的命令；類似地，master實例中被配置了rename的命令，同步到slave實例執(zhí)行時，后者可能無法識別這些非官方支持的"自定義"命令。
5. Limit配置
1) maxclients
客戶端的并發(fā)連接數(shù)，默認10000。當redis實例無法更改系統(tǒng)fd限制時，會以系統(tǒng)限制數(shù)n減去32作為Redis支持的最大連接數(shù)（減32是因為Redis保留32個fd供內部邏輯使用）。當達到Redis支持的最大連接數(shù)后，新連接會被close，對應的client會收到"max number of clients reached"的出錯提示。
2) maxmemory
配置Redis Server可占用的最大內存值，單位byte。如果達到該閾值，根據(jù)用戶配置的淘汰策略，Redis會嘗試刪除符合淘汰條件的key。假如用戶配置了永不淘汰（noeviction）的策略，則Redis不會刪除現(xiàn)有的key，此時，來自客戶端的所有寫入或排序等需要使用更多內存的命令都會報錯，而讀取命令可以正常執(zhí)行。
在Redis被用來作為LRU緩存時，該配置項會很有用。
特別注意：在主從部署下，master在配置了淘汰策略的前提下，配置maxmemory時，需要配置一個比機器可用物理存儲器數(shù)量小一些的閾值，因為主從同步需要為slave保留output buffer。若master的maxmemory配置成與機器Physical Memory很接近的值，可能會引起master的key全部被淘汰的嚴重后果！
具體的觸發(fā)過程：在Redis Server實際使用的內存達到閾值后，開始根據(jù)淘汰策略刪除master的key，同時會通過DEL命令同步刪除slave的key，此時，master需要申請output buffer用于存放發(fā)往slave的命令，這會使master嘗試使用更多內存，從而加劇內存超限的嚴重程度。于是，master只能通過刪除更多的keys以便嘗試降低內存使用，而這些keys的DELs命令同樣需要同步至slaves，意味著master需要申請更大的output buffer用于存放同步命令或數(shù)據(jù)。典型的"雪崩效應"，最壞的結果是master會把所有的key都刪干凈。
而若maxmemory配置成比機器Physical Memory小一些的值（如配成后者的90%），當Redis實際使用內存達到配置閾值后，開始淘汰key，發(fā)給slave的同步命令存到output buffer，此時Redis實際使用的內存可能會繼續(xù)增長，由于目前系統(tǒng)還有大約10%的存儲器資源可供使用，因此output buffer會從這些free的memory中借用資源（從Redis 2.4開始，master會認為這個增長是暫時的，同步完成后即可釋放內存），從而避免master通過刪除更多的keys為output buffer騰空間。
關于這個問題的更詳細討論以及Redis作者的實現(xiàn)策略，可以參考這里。
總之，要謹記：若系統(tǒng)以主從方式部署且master配置了淘汰策略，那么，master的maxmemory務必要配置一個合理的值（與用戶可以為Redis提供的最大物理內存相比），以避免Redis實際使用的內存達到閾值后發(fā)生所有的key被完全刪除的情況發(fā)生！
3) maxmemory-policy
配置Redis的淘汰策略，默認為volatile-lru。目前支持6種策略：
a. volatile-lru => remove the key with an expire set using an LRU algorithm;
b. allkeys-lru -> remove any key accordingly to the LRU algorithm
c. volatile-random -> remove a random key with an expire set
d. allkeys-random -> remove a random key, any key
e. volatile-ttl -> remove the key with the nearest expire time (minor TTL)
f. noeviction -> don't expire at all, just return an error on write operations
4) maxmemory-samples
配置key淘汰算法運行時的采樣數(shù)，默認為3。之所以存在這個配置項，是由于redis為節(jié)省內存，采用了近似的淘汰算法，這個配置項可以用來調節(jié)淘汰算法的精度：當需要淘汰key時（如內存達到閾值），Redis會在符合淘汰條件（由maxmemory-policy指定）的key set中，隨機采樣n個key并將其中符合LRU的那個key刪掉。默認情況下n取3，如果要提高淘汰算法的精度，n可以調大（代價是增加CPU運算時間）。
6. SlowLog配置
Redis可以記錄處理時間超過某個閾值的慢查詢，這里的處理時間不包括I/O操作（如與客戶端會話的讀/寫時間等）。
注意：由于Redis Server是單線程實現(xiàn)，因此若其中某個查詢命令導致阻塞，會影響到后續(xù)的客戶端請求，因此，線上環(huán)境最好開啟慢查詢記錄以便追蹤問題。
1) slowlog-log-slower-than
指定慢查詢的閾值，單位：微秒。處理時間超過該值的查詢命令，會被記錄到日志中。
2) slowlog-max-len
配置slowlog記錄的最大條數(shù)，大小無限制，但會消耗更多內存。默認128。
7. Advanced配置
1) 內部數(shù)據(jù)結構優(yōu)化的閾值配置
可以配置相應的閾值，Redis據(jù)此判斷其內部實現(xiàn)時是否優(yōu)化相關的數(shù)據(jù)結構。例如：
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
上面的配置指定當ziplist中的key個數(shù)不大于512且最大的value不大于64字節(jié)時，Redis會用一種特殊的更節(jié)省內存的數(shù)據(jù)結構來存儲這些k-v數(shù)據(jù)。
類似的配置還包括list、set、zset等數(shù)據(jù)類型。
2) activerehashing
配置Redis是否主動rehashing，默認yes，意味著Redis每秒會有10次自動rehashing的動作（每100ms會觸發(fā)一次），以便盡可能優(yōu)化內存使用。
注意：Redis采取的是lazy rehashing策略，即越是被頻繁訪問的hash table，Redis針對該表的rehashing也會越頻繁；相反，若某個hash table處于idle狀態(tài)，則針對它的rehashing永遠不會被真正執(zhí)行。
3) output buffer
output buffer是Redis為client分配的緩沖區(qū)（這里的"client"可能是真正的client，也可能是slave或monitor），若為某個客戶端分配的output buffer超過了預留大小，Redis可能會根據(jù)配置策略關閉與該端的連接。
例如，若Redis被用作message queue，訂購消息的consumer處理速度跟不上發(fā)布消息的producer時，就會發(fā)生對應的output buffer超限的情況。
該配置項格式如下：
client-output-buffer-limit
默認的配置如下：
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
8. INCLUDES配置
當機器不只存在1個Redis實例時，這里可以實現(xiàn)每個Redis實例的"個性化"配置，此時，可以將這些實例的共有配置寫到redis.conf中，而個性化的配置寫到由include配置路徑指定的文件中。
配置格式：include /path/to/local.conf
以上是“redis.conf基本配置項的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
重慶分公司
重慶分公司
