您好,登錄后才能下訂單哦!
這篇文章主要介紹redis.conf基本配置項的示例分析,文中介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們一定要看完!
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進程監聽的TCP端口,默認為6379,如果配成0,則redis不會再listen TCP socket
4) bind
配置bind網卡,若配為具體ip值,則redis只偵聽來自該網卡的連接。該配置項默認為commented狀態,表示redis會監聽來自該機器所有網卡的連接
5) unixsocket和unixsocketperm
配置unix sock file的路徑和權限,表明redis要偵聽來自指定路徑下的unix socket file的數據請求。這些配置項默認是commented的,即redis默認不會偵聽unix socket
6) timeout
配置連接超時時間,單位為秒,超時后redis進程主動斷開連接;若配置為0,則表示redis服務進程不會主動斷開來自client的連接
7) tcp-keepalive
配置redis向client發送保活ACKs的時間間隔,默認為0,表示不發送keep-alive報文。
備注:該配置項是新加的,2.6.7版本中沒有,最新的2.6.14有(還沒有調研是哪個版本引入的)。
8) loglevel
配置redis進程的日志level,支持4種:debug/verbose/notice/warning,日志信息的詳細程度遞減,可根據實際情況做配置
9) logfile
redis輸出日志路徑,默認stdout。若需改為其它目錄(如./log/redis-running.log),則日志文件的父路徑必須事先mkdir出來,否則會啟動失敗
10) sys-log-enable/syslog-ident/syslog-facility
這3個配置項與syslog相關,默認都是commented狀態。這里不再贅述,感興趣的話,可以在shell terminal中man syslog查看之。
總結:上述基本配置項中,port為必配項,其余項一般情況下保持默認即可。
2. 持久化(Persistence)相關配置
篇幅較多,下篇筆記做詳細說明。update: 參見這里
3. Replication配置
篇幅較多,下下篇筆記做詳細說明。update: 參見這里
4. Security配置
若redis實例可能會接收來自不受自己控制的客戶端的命令時(如來自第三方的訪問),可以考慮啟用密碼保護(即客戶端必須先通過認證(通過AUTH <passwd>)才能執行其它命令),也可以通過rename-command來禁用某些會危及Redis正常運行的危險命令。
1) requirepass <passwd>
指定訪問密碼
2) rename-command <normal-cmd> <new-cmd>
重命名命令。如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實例執行時,后者可能無法識別這些非官方支持的"自定義"命令。
5. Limit配置
1) maxclients
客戶端的并發連接數,默認10000。當redis實例無法更改系統fd限制時,會以系統限制數n減去32作為Redis支持的最大連接數(減32是因為Redis保留32個fd供內部邏輯使用)。當達到Redis支持的最大連接數后,新連接會被close,對應的client會收到"max number of clients reached"的出錯提示。
2) maxmemory
配置Redis Server可占用的最大內存值,單位byte。如果達到該閾值,根據用戶配置的淘汰策略,Redis會嘗試刪除符合淘汰條件的key。假如用戶配置了永不淘汰(noeviction)的策略,則Redis不會刪除現有的key,此時,來自客戶端的所有寫入或排序等需要使用更多內存的命令都會報錯,而讀取命令可以正常執行。
在Redis被用來作為LRU緩存時,該配置項會很有用。
特別注意:在主從部署下,master在配置了淘汰策略的前提下,配置maxmemory時,需要配置一個比機器可用物理存儲器數量小一些的閾值,因為主從同步需要為slave保留output buffer。若master的maxmemory配置成與機器Physical Memory很接近的值,可能會引起master的key全部被淘汰的嚴重后果!
具體的觸發過程:在Redis Server實際使用的內存達到閾值后,開始根據淘汰策略刪除master的key,同時會通過DEL命令同步刪除slave的key,此時,master需要申請output buffer用于存放發往slave的命令,這會使master嘗試使用更多內存,從而加劇內存超限的嚴重程度。于是,master只能通過刪除更多的keys以便嘗試降低內存使用,而這些keys的DELs命令同樣需要同步至slaves,意味著master需要申請更大的output buffer用于存放同步命令或數據。典型的"雪崩效應",最壞的結果是master會把所有的key都刪干凈。
而若maxmemory配置成比機器Physical Memory小一些的值(如配成后者的90%),當Redis實際使用內存達到配置閾值后,開始淘汰key,發給slave的同步命令存到output buffer,此時Redis實際使用的內存可能會繼續增長,由于目前系統還有大約10%的存儲器資源可供使用,因此output buffer會從這些free的memory中借用資源(從Redis 2.4開始,master會認為這個增長是暫時的,同步完成后即可釋放內存),從而避免master通過刪除更多的keys為output buffer騰空間。
關于這個問題的更詳細討論以及Redis作者的實現策略,可以參考這里。
總之,要謹記:若系統以主從方式部署且master配置了淘汰策略,那么,master的maxmemory務必要配置一個合理的值(與用戶可以為Redis提供的最大物理內存相比),以避免Redis實際使用的內存達到閾值后發生所有的key被完全刪除的情況發生!
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淘汰算法運行時的采樣數,默認為3。之所以存在這個配置項,是由于redis為節省內存,采用了近似的淘汰算法,這個配置項可以用來調節淘汰算法的精度:當需要淘汰key時(如內存達到閾值),Redis會在符合淘汰條件(由maxmemory-policy指定)的key set中,隨機采樣n個key并將其中符合LRU的那個key刪掉。默認情況下n取3,如果要提高淘汰算法的精度,n可以調大(代價是增加CPU運算時間)。
6. SlowLog配置
Redis可以記錄處理時間超過某個閾值的慢查詢,這里的處理時間不包括I/O操作(如與客戶端會話的讀/寫時間等)。
注意:由于Redis Server是單線程實現,因此若其中某個查詢命令導致阻塞,會影響到后續的客戶端請求,因此,線上環境最好開啟慢查詢記錄以便追蹤問題。
1) slowlog-log-slower-than
指定慢查詢的閾值,單位:微秒。處理時間超過該值的查詢命令,會被記錄到日志中。
2) slowlog-max-len
配置slowlog記錄的最大條數,大小無限制,但會消耗更多內存。默認128。
7. Advanced配置
1) 內部數據結構優化的閾值配置
可以配置相應的閾值,Redis據此判斷其內部實現時是否優化相關的數據結構。例如:
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
上面的配置指定當ziplist中的key個數不大于512且最大的value不大于64字節時,Redis會用一種特殊的更節省內存的數據結構來存儲這些k-v數據。
類似的配置還包括list、set、zset等數據類型。
2) activerehashing
配置Redis是否主動rehashing,默認yes,意味著Redis每秒會有10次自動rehashing的動作(每100ms會觸發一次),以便盡可能優化內存使用。
注意:Redis采取的是lazy rehashing策略,即越是被頻繁訪問的hash table,Redis針對該表的rehashing也會越頻繁;相反,若某個hash table處于idle狀態,則針對它的rehashing永遠不會被真正執行。
3) output buffer
output buffer是Redis為client分配的緩沖區(這里的"client"可能是真正的client,也可能是slave或monitor),若為某個客戶端分配的output buffer超過了預留大小,Redis可能會根據配置策略關閉與該端的連接。
例如,若Redis被用作message queue,訂購消息的consumer處理速度跟不上發布消息的producer時,就會發生對應的output buffer超限的情況。
該配置項格式如下:
client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
<class>:目前支持3種客戶端:1) normal => normal clients; 2) slave clients and MONITOR clients; 3) pubsub => clients subcribed to at least one pubsub channel or pattern
<hard limit>:若output buffer大小超過該值,Redis會立即關閉與對應client的連接
<soft limit> <soft seconds>:若output buffer大小超過soft limit且這種情況的持續時間超過soft seconds,則Redis會關閉與對應client的連接。
默認的配置如下:
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實例時,這里可以實現每個Redis實例的"個性化"配置,此時,可以將這些實例的共有配置寫到redis.conf中,而個性化的配置寫到由include配置路徑指定的文件中。
配置格式:include /path/to/local.conf
以上是“redis.conf基本配置項的示例分析”這篇文章的所有內容,感謝各位的閱讀!希望分享的內容對大家有幫助,更多相關知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。