1. 程式人生 > >redis3.2 最新版本啟動配置檔案redis.conf詳細說明

redis3.2 最新版本啟動配置檔案redis.conf詳細說明

Redis啟動的時候,可以指定配置檔案,如下:

/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf &                                            

Redis.conf檔案內容詳細說明:

# 預設redis不是以後臺程序的方式啟動,如果需要在後臺執行,需要將這個值設定成yes
# 以後臺方式啟動的時候,redis會寫入預設的程序檔案/var/run/redis.pid
daemonize yes
 
# redis啟動的程序路徑
pidfile/var/run/redis.pid
 
# 啟動程序埠號,這裡最好不要使用預設的6379,容易被攻擊
port 7179
 
tcp-backlog 511
 
# 配置redis監聽到的ip地址,可以是一個也可以多個
bind 127.0.0.110.254.3.42
 
# redis的sock路徑
unixsocket/tmp/redis.sock
unixsocketperm 755
 
# 超時時間
timeout 0
 
#指定TCP連線是否為長連線,"偵探"訊號有server端維護。預設為0.表示禁用
tcp-keepalive 0
 
# 日誌級別,log 等級分為4 級,debug,verbose,notice, 和warning。生產環境下一般開啟notice
loglevel notice
 
# 日誌檔案地址
logfile"/usr/local/redis/logs/redis.log"
 
 
 
# 設定資料庫的個數,可以使用SELECT 命令來切換資料庫。預設使用的資料庫是0號庫。預設16個庫
databases 16
 
#RDB方式的持久化是通過快照(snapshotting)完成的,當符合一定條件時Redis會自動將記憶體中的所有資料進行快照並存儲在硬碟上。進行快照的條件可以由使用者在配置檔案中自定義,由兩個引數構成:時間和改動的鍵的個數。當在指定的時間內被更改的鍵的個數大於指定的數值時就會進行快照。RDB是Redis預設採用的持久化方式,在配置檔案中已經預置了3個條件:
save 900 1    # 900秒內有至少1個鍵被更改則進行快照
save 300 10   # 300秒內有至少10個鍵被更改則進行快照
save 60 10000  # 60秒內有至少10000個鍵被更改則進行快照
 
# 持久化資料儲存目錄
dir/usr/local/redis/data
 
 
#當持久化出現錯誤時,是否依然繼續進行工作,是否終止所有的客戶端write請求。預設設定"yes"表示終止,一旦snapshot資料儲存故障,那麼此server為只讀服務。如果為"no",那麼此次snapshot將失敗,但下一次snapshot不會受到影響,不過如果出現故障,資料只能恢復到"最近一個成功點"
stop-writes-on-bgsave-errorno
 
#在進行資料映象備份時,是否啟用rdb檔案壓縮手段,預設為yes。壓縮可能需要額外的cpu開支,不過這能夠有效的減小rdb檔案的大,有利於儲存/備份/傳輸/資料恢復
rdbcompression yes
 
#checksum檔案檢測,讀取寫入的時候rdb檔案checksum,會損失一些效能
rdbchecksum yes
 
#映象備份檔案的檔名,預設為dump.rdb
dbfilename dump.rdb
 
#當主master伺服器掛機或主從複製在進行時,是否依然可以允許客戶訪問可能過期的資料。在"yes"情況下,slave繼續向客戶端提供只讀服務,有可能此時的資料已經過期;在"no"情況下,任何向此server傳送的資料請求服務(包括客戶端和此server的slave)都將被告知"error"
slave-serve-stale-datayes
 
# 如果是slave庫,只允許只讀,不允許修改
slave-read-only yes
 
 
#slave與master的連線,是否禁用TCPnodelay選項。"yes"表示禁用,那麼socket通訊中資料將會以packet方式傳送(packet大小受到socket buffer限制)。可以提高socket通訊的效率(tcp互動次數),但是小資料將會被buffer,不會被立即傳送,對於接受者可能存在延遲。"no"表示開啟tcp nodelay選項,任何資料都會被立即傳送,及時性較好,但是效率較低,建議設為no,在高併發或者主從有大量操作的情況下,設定為yes
repl-disable-tcp-nodelayno
 
 
#適用Sentinel模組(unstable,M-S叢集管理和監控),需要額外的配置檔案支援。slave的權重值,預設100.當master失效後,Sentinel將會從slave列表中找到權重值最低(>0)的slave,並提升為master。如果權重值為0,表示此slave為"觀察者",不參與master選舉
slave-priority 100
 
#限制同時連線的客戶數量。當連線數超過這個值時,redis 將不再接收其他連線請求,客戶端嘗試連線時將收到error 資訊。預設為10000,要考慮系統檔案描述符限制,不宜過大,浪費檔案描述符,具體多少根據具體情況而定
maxclients 10000
 
#redis-cache所能使用的最大記憶體(bytes),預設為0,表示"無限制",最終由OS實體記憶體大小決定(如果實體記憶體不足,有可能會使用swap)。此值儘量不要超過機器的實體記憶體尺寸,從效能和實施的角度考慮,可以為實體記憶體3/4。此配置需要和"maxmemory-policy"配合使用,當redis中記憶體資料達到maxmemory時,觸發"清除策略"。在"記憶體不足"時,任何write操作(比如set,lpush等)都會觸發"清除策略"的執行。在實際環境中,建議redis的所有物理機器的硬體配置保持一致(記憶體一致),同時確保master/slave中"maxmemory""policy"配置一致。
maxmemory 0
 
 
#記憶體過期策略,記憶體不足"時,資料清除策略,預設為"volatile-lru"。
#volatile-lru  ->對"過期集合"中的資料採取LRU(近期最少使用)演算法.如果對key使用"expire"指令指定了過期時間,那麼此key將會被新增到"過期集合"中。將已經過期/LRU的資料優先移除.如果"過期集合"中全部移除仍不能滿足記憶體需求,將OOM.
#allkeys-lru ->對所有的資料,採用LRU演算法
#volatile-random ->對"過期集合"中的資料採取"隨即選取"演算法,並移除選中的K-V,直到"記憶體足夠"為止. 如果如果"過期集合"中全部移除全部移除仍不能滿足,將OOM
#allkeys-random ->對所有的資料,採取"隨機選取"演算法,並移除選中的K-V,直到"記憶體足夠"為止
#volatile-ttl ->對"過期集合"中的資料採取TTL演算法(最小存活時間),移除即將過期的資料.
#noeviction ->不做任何干擾操作,直接返回OOM異常
#另外,如果資料的過期不會對"應用系統"帶來異常,且系統中write操作比較密集,建議採取"allkeys-lru"
maxmemory-policyvolatile-lru
 
# 預設值5,上面LRU和最小TTL策略並非嚴謹的策略,而是大約估算的方式,因此可以選擇取樣值以便檢查
maxmemory-samples 5
 
#預設情況下,redis 會在後臺非同步的把資料庫映象備份到磁碟,但是該備份是非常耗時的,而且備份也不能很頻繁。所以redis 提供了另外一種更加高效的資料庫備份及災難恢復方式。開啟append only 模式之後,redis 會把所接收到的每一次寫操作請求都追加到appendonly.aof 檔案中,當redis 重新啟動時,會從該檔案恢復出之前的狀態。但是這樣會造成appendonly.aof 檔案過大,所以redis 還支援了BGREWRITEAOF 指令,對appendonly.aof 進行重新整理。如果不經常進行資料遷移操作,推薦生產環境下的做法為關閉映象,開啟appendonly.aof,同時可以選擇在訪問較少的時間每天對appendonly.aof 進行重寫一次。
#另外,對master機器,主要負責寫,建議使用AOF,對於slave,主要負責讀,挑選出1-2臺開啟AOF,其餘的建議關閉
appendonly yes
 
#aof檔名字,預設為appendonly.aof
appendfilename"appendonly.aof"
 
# 設定對appendonly.aof 檔案進行同步的頻率。always表示每次有寫操作都進行同步,everysec 表示對寫操作進行累積,每秒同步一次。no不主動fsync,由OS自己來完成。這個需要根據實際業務場景進行配置
appendfsync everysec
 
# 在aof rewrite期間,是否對aof新記錄的append暫緩使用檔案同步策略,主要考慮磁碟IO開支和請求阻塞時間。預設為no,表示"不暫緩",新的aof記錄仍然會被立即同步
no-appendfsync-on-rewriteno
 
#當Aof log增長超過指定比例時,重寫logfile,設定為0表示不自動重寫Aof 日誌,重寫是為了使aof體積保持最小,而確保儲存最完整的資料。
auto-aof-rewrite-percentage100
#觸發aof rewrite的最小檔案尺寸
auto-aof-rewrite-min-size64mb
 
#lua指令碼執行的最大時間,單位毫秒
lua-time-limit 5000
 
 
 
#慢日誌記錄,單位微妙,10000就是10毫秒值,如果操作時間超過此值,將會把command資訊"記錄"起來.(記憶體,非檔案)。其中"操作時間"不包括網路IO開支,只包括請求達到server後進行"記憶體實施"的時間."0"表示記錄全部操作
slowlog-log-slower-than10000
 
#"慢操作日誌"保留的最大條數,"記錄"將會被佇列化,如果超過了此長度,舊記錄將會被移除。可以通過"SLOWLOG<subcommand> args"檢視慢記錄的資訊(SLOWLOG get 10,SLOWLOG reset)
slowlog-max-len 128
notify-keyspace-events""
 
#hash型別的資料結構在編碼上可以使用ziplist和hashtable。ziplist的特點就是檔案儲存(以及記憶體儲存)所需的空間較小,在內容較小時,效能和hashtable幾乎一樣.因此redis對hash型別預設採取ziplist。如果hash中條目的條目個數或者value長度達到閥值,將會被重構為hashtable。
#這個引數指的是ziplist中允許儲存的最大條目個數,,預設為512,建議為128
hash-max-ziplist-entries512
#ziplist中允許條目value值最大位元組數,預設為64,建議為1024
hash-max-ziplist-value64
 
#同上
list-max-ziplist-entries512
list-max-ziplist-value64
 
#intset中允許儲存的最大條目個數,如果達到閥值,intset將會被重構為hashtable
set-max-intset-entries512
 
#zset為有序集合,有2中編碼型別:ziplist,skiplist。因為"排序"將會消耗額外的效能,當zset中資料較多時,將會被重構為skiplist。
zset-max-ziplist-entries128
#zset中允許條目value值最大位元組數,預設為64,建議為1024
zset-max-ziplist-value64
 
 
#是否開啟頂層資料結構的rehash功能,如果記憶體允許,請開啟。rehash能夠很大程度上提高K-V存取的效率
activerehashing yes
 
#客戶端buffer控制。在客戶端與server進行的互動中,每個連線都會與一個buffer關聯,此buffer用來佇列化等待被client接受的響應資訊。如果client不能及時的消費響應資訊,那麼buffer將會被不斷積壓而給server帶來記憶體壓力.如果buffer中積壓的資料達到閥值,將會導致連線被關閉,buffer被移除。
 
#buffer控制型別包括:normal -> 普通連線;slave->與slave之間的連線;pubsub ->pub/sub型別連線,此型別的連線,往往會產生此種問題;因為pub端會密集的釋出訊息,但是sub端可能消費不足.指令格式:client-output-buffer-limit <class> <hard><soft><seconds>",其中hard表示buffer最大值,一旦達到閥值將立即關閉連線;soft表示"容忍值",它和seconds配合,如果buffer值超過soft且持續時間達到了seconds,也將立即關閉連線,如果超過了soft但是在seconds之後,buffer資料小於了soft,連線將會被保留.其中hard和soft都設定為0,則表示禁用buffer控制.通常hard值大於soft.
client-output-buffer-limitnormal 0 0 0
client-output-buffer-limitslave 256mb 64mb 60
client-output-buffer-limitpubsub 32mb 8mb 60
 
 
#Redis server執行後臺任務的頻率,預設為10,此值越大表示redis對"間歇性task"的執行次數越頻繁(次數/秒)。"間歇性task"包括"過期集合"檢測、關閉"空閒超時"的連線等,此值必須大於0且小於500。此值過小就意味著更多的cpu週期消耗,後臺task被輪詢的次數更頻繁。此值過大意味著"記憶體敏感"性較差。建議採用預設值。
hz 10
 
#當一個child在重寫AOF檔案的時候,如果aof-rewrite-incremental-fsync值為yes生效,那麼這個檔案會以每次32M資料的來被同步,這大量新增提交到磁碟是有用的,並且能避免高峰延遲。
aof-rewrite-incremental-fsyncyes


參考文章:http://blog.csdn.net/neubuffer/article/details/17003909