# 守護進程模式 # 默認狀況下 redis 不是做爲守護進程運行的,若是你想讓它在後臺運行,你就把它改爲 yes # 當redis做爲守護進程運行的時候,它會寫一個 pid 到 /var/run/redis.pid 文件裏面 daemonize yes # 當redis做爲守護進程運行的時候,它會把 pid 默認寫到 /var/run/redis.pid 文件裏面,可是你能夠在這裏本身制定它的文件位置 pidfile /var/run/redis.pid # 監聽端口號,默認爲 6379,若是你設爲 0 ,redis 將不在 socket 上監放任何客戶端鏈接。 port 6379 # TCP接收隊列長度,受/proc/sys/net/core/somaxconn和tcp_max_syn_backlog這兩個內核參數的影響 # 在高併發的環境下,你須要把這個值調高以免客戶端鏈接緩慢的問題。 tcp-backlog 511 # 一個客戶端空閒多少秒後關閉鏈接(0表明禁用,永不關閉) timeout 0 # 若是非零,則設置SO_KEEPALIVE選項來向空閒鏈接的客戶端發送ACK # 推薦一個合理的值就是60秒 tcp-keepalive 60 # 指定服務器調試等級 # 可能值: # debug (大量信息,對開發/測試有用) # verbose (不少精簡的有用信息,可是不像debug等級那麼多) # notice (適量的信息,基本上是你生產環境中須要的) # warning (只有很重要/嚴重的信息會記錄下來) loglevel notice # 指定日誌文件名和保存位置 logfile "./redis.log" # 設置數據庫個數 # 默認數據庫是 DB 0,你能夠在每一個鏈接上使用 select <dbid> 命令選擇一個不一樣的數據庫,可是 dbid 必須是一個介於 0 到 databasees - 1 之間的值 databases 16 #根據給定的時間間隔和寫入次數將數據保存到磁盤 # 900秒(15分鐘)以後,且至少1次變動 # 300秒(5分鐘)以後,且至少10次變動 # 60秒以後,且至少10000次變動 save 900 1 save 300 10 save 60 10000 # 默認若是開啓RDB快照(至少一條save指令)而且最新的後臺保存失敗,Redis將會中止接受寫操做 # 這將使用戶知道數據沒有正確的持久化到硬盤,不然可能沒人注意到而且形成一些災難 # 若是後臺保存進程從新啓動工做了,redis 也將自動的容許寫操做 stop-writes-on-bgsave-error yes # 當導出到 .rdb 數據庫時是否用LZF壓縮字符串對象,默認都設爲 yes rdbcompression yes # 是否校驗rdb文件,版本5的RDB有一個CRC64算法的校驗和放在了文件的最後。這將使文件格式更加可靠。 rdbchecksum yes # 持久化數據庫的文件名 dbfilename dump.rdb # 工做目錄 # 例如上面的 dbfilename 只指定了文件名,可是它會寫入到這個目錄下。這個配置項必定是個目錄,而不能是文件名 dir ./ # 當master服務設置了密碼保護時,slav服務鏈接master的密碼 masterauth !@#$%^&* # 當一個slave失去和master的鏈接,或者同步正在進行中,slave的行爲能夠有兩種表現: # # 1) 若是 slave-serve-stale-data 設置爲 "yes" (默認值),slave會繼續響應客戶端請求, # 多是正常數據,或者是過期了的數據,也多是還沒得到值的空數據。 # 2) 若是 slave-serve-stale-data 設置爲 "no",slave會回覆"正在從master同步 # (SYNC with master in progress)"來處理各類請求,除了 INFO 和 SLAVEOF 命令。 slave-serve-stale-data yes # 你能夠配置salve實例是否接受寫操做。可寫的slave實例可能對存儲臨時數據比較有用(由於寫入salve的數據在同master同步以後將很容易被刪除) slave-read-only yes # 是否在slave套接字發送SYNC以後禁用 TCP_NODELAY? # 若是你選擇「yes」Redis將使用更少的TCP包和帶寬來向slaves發送數據。可是這將使數據傳輸到slave上有延遲,Linux內核的默認配置會達到40毫秒 # 若是你選擇了 "no" 數據傳輸到salve的延遲將會減小但要使用更多的帶寬 repl-disable-tcp-nodelay no # slave的優先級是一個整數展現在Redis的Info輸出中。若是master再也不正常工做了,哨兵將用它來選擇一個slave提高爲master # 優先級數字小的salve會優先考慮提高爲master,因此例若有三個slave優先級分別爲10,100,25,哨兵將挑選優先級最小數字爲10的slave。 # 0做爲一個特殊的優先級,標識這個slave不能做爲master,因此一個優先級爲0的slave永遠不會被哨兵挑選提高爲master slave-priority 100 # 密碼驗證 # 警告:由於Redis太快了,因此外面的人能夠嘗試每秒150k的密碼來試圖破解密碼。這意味着你須要一個高強度的密碼,不然破解太容易了 requirepass !@#$%^&* # redis實例最大佔用內存,不要用比設置的上限更多的內存。一旦內存使用達到上限,Redis會根據選定的回收策略(參見:maxmemmory-policy)刪除key maxmemory 3gb # 最大內存策略:若是達到內存限制了,Redis如何選擇刪除key。你能夠在下面五個行爲裏選: # volatile-lru -> 根據LRU算法刪除帶有過時時間的key。 # allkeys-lru -> 根據LRU算法刪除任何key。 # volatile-random -> 根據過時設置來隨機刪除key, 具有過時時間的key。 # allkeys->random -> 無差異隨機刪, 任何一個key。 # volatile-ttl -> 根據最近過時時間來刪除(輔以TTL), 這是對於有過時時間的key # noeviction -> 誰也不刪,直接在寫操做時返回錯誤。 maxmemory-policy volatile-lru # 默認狀況下,Redis是異步的把數據導出到磁盤上。這種模式在不少應用裏已經足夠好,但Redis進程 # 出問題或斷電時可能形成一段時間的寫操做丟失(這取決於配置的save指令)。 # # AOF是一種提供了更可靠的替代持久化模式,例如使用默認的數據寫入文件策略(參見後面的配置) # 在遇到像服務器斷電或單寫狀況下Redis自身進程出問題但操做系統仍正常運行等突發事件時,Redis # 能只丟失1秒的寫操做。 # # AOF和RDB持久化能同時啓動而且不會有問題。 # 若是AOF開啓,那麼在啓動時Redis將加載AOF文件,它更能保證數據的可靠性。 appendonly no # aof文件名 appendfilename "appendonly.aof" # fsync() 系統調用告訴操做系統把數據寫到磁盤上,而不是等更多的數據進入輸出緩衝區。 # 有些操做系統會真的把數據立刻刷到磁盤上;有些則會盡快去嘗試這麼作。 # # Redis支持三種不一樣的模式: # # no:不要馬上刷,只有在操做系統須要刷的時候再刷。比較快。 # always:每次寫操做都馬上寫入到aof文件。慢,可是最安全。 # everysec:每秒寫一次。折中方案。 appendfsync everysec # 若是AOF的同步策略設置成 "always" 或者 "everysec",而且後臺的存儲進程(後臺存儲或寫入AOF # 日誌)會產生不少磁盤I/O開銷。某些Linux的配置下會使Redis由於 fsync()系統調用而阻塞好久。 # 注意,目前對這個狀況尚未完美修正,甚至不一樣線程的 fsync() 會阻塞咱們同步的write(2)調用。 # # 爲了緩解這個問題,能夠用下面這個選項。它能夠在 BGSAVE 或 BGREWRITEAOF 處理時阻止主進程進行fsync()。 # # 這就意味着若是有子進程在進行保存操做,那麼Redis就處於"不可同步"的狀態。 # 這其實是說,在最差的狀況下可能會丟掉30秒鐘的日誌數據。(默認Linux設定) # # 若是你有延時問題把這個設置成"yes",不然就保持"no",這是保存持久數據的最安全的方式。 no-appendfsync-on-rewrite yes # 自動重寫AOF文件 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # AOF文件可能在尾部是不完整的(這跟system關閉有問題,尤爲是mount ext4文件系統時 # 沒有加上data=ordered選項。只會發生在os死時,redis本身死不會不完整)。 # 那redis重啓時load進內存的時候就有問題了。 # 發生的時候,能夠選擇redis啓動報錯,而且通知用戶和寫日誌,或者load儘可能多正常的數據。 # 若是aof-load-truncated是yes,會自動發佈一個log給客戶端而後load(默認)。 # 若是是no,用戶必須手動redis-check-aof修復AOF文件才能夠。 # 注意,若是在讀取的過程當中,發現這個aof是損壞的,服務器也是會退出的, # 這個選項僅僅用於當服務器嘗試讀取更多的數據但又找不到相應的數據時。 aof-load-truncated yes # Lua 腳本的最大執行時間,毫秒爲單位 lua-time-limit 5000 # Redis慢查詢日誌能夠記錄超過指定時間的查詢 slowlog-log-slower-than 10000 # 這個長度沒有限制。只是要主要會消耗內存。你能夠經過 SLOWLOG RESET 來回收內存。 slowlog-max-len 128 # redis延時監控系統在運行時會採樣一些操做,以便收集可能致使延時的數據根源。 # 經過 LATENCY命令 能夠打印一些圖樣和獲取一些報告,方便監控 # 這個系統僅僅記錄那個執行時間大於或等於預約時間(毫秒)的操做, # 這個預約時間是經過latency-monitor-threshold配置來指定的, # 當設置爲0時,這個監控系統處於中止狀態 latency-monitor-threshold 0 # Redis能通知 Pub/Sub 客戶端關於鍵空間發生的事件,默認關閉 notify-keyspace-events "" # 當hash只有少許的entry時,而且最大的entry所佔空間沒有超過指定的限制時,會用一種節省內存的 # 數據結構來編碼。能夠經過下面的指令來設定限制 hash-max-ziplist-entries 512 hash-max-ziplist-value 64 # 與hash似,數據元素較少的list,能夠用另外一種方式來編碼從而節省大量空間。 # 這種特殊的方式只有在符合下面限制時才能夠用 list-max-ziplist-entries 512 list-max-ziplist-value 64 # set有一種特殊編碼的狀況:當set數據全是十進制64位有符號整型數字構成的字符串時。 # 下面這個配置項就是用來設置set使用這種編碼來節省內存的最大長度。 set-max-intset-entries 512 # 與hash和list類似,有序集合也能夠用一種特別的編碼方式來節省大量空間。 # 這種編碼只適合長度和元素都小於下面限制的有序集合 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 # HyperLogLog稀疏結構表示字節的限制。該限制包括 # 16個字節的頭。當HyperLogLog使用稀疏結構表示 # 這些限制,它會被轉換成密度表示。 # 值大於16000是徹底沒用的,由於在該點 # 密集的表示是更多的內存效率。 # 建議值是3000左右,以便具備的內存好處, 減小內存的消耗 hll-sparse-max-bytes 3000 # 啓用哈希刷新,每100個CPU毫秒會拿出1個毫秒來刷新Redis的主哈希表(頂級鍵值映射表) activerehashing yes # 客戶端的輸出緩衝區的限制,可用於強制斷開那些由於某種緣由從服務器讀取數據的速度不夠快的客戶端 client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 # 默認狀況下,「hz」的被設定爲10。提升該值將在Redis空閒時使用更多的CPU時,但同時當有多個key # 同時到期會使Redis的反應更靈敏,以及超時能夠更精確地處理 hz 10 # 當一個子進程重寫AOF文件時,若是啓用下面的選項,則文件每生成32M數據會被同步 aof-rewrite-incremental-fsync yes