redis經常使用配置參數詳解

Redis 支持不少的參數，但都有默認值。
daemonize
默認狀況下， redis 不是在後臺運行的，若是須要在後臺運行，把該項的值更改成 yes。

pidfile
當 Redis 在後臺運行的時候， Redis 默認會把 pid 文件放在/var/run/redis.pid，你能夠配
置到其餘地址。當運行多個 redis 服務時，須要指定不一樣的 pid 文件和端口

bind
指定 Redis 只接收來自於該 IP 地址的請求，若是不進行設置，那麼將處理全部請求，在
生產環境中最好設置該項

port
監聽端口，默認爲 6379

timeout
設置客戶端鏈接時的超時時間，單位爲秒。當客戶端在這段時間內沒有發出任何指令，
那麼關閉該鏈接

loglevel
log 等級分爲 4 級， debug, verbose, notice, 和 warning。生產環境下通常開啓 notice

logfile
配置 log 文件地址，默認使用標準輸出，即打印在命令行終端的窗口上

databases
設置數據庫的個數，可使用 SELECT <dbid>命令來切換數據庫。默認使用的數據庫是 0

save
設置 Redis 進行數據庫鏡像的頻率。
if(在 60 秒以內有 10000 個 keys 發生變化時){
進行鏡像備份
}else if(在 300 秒以內有 10 個 keys 發生了變化){
進行鏡像備份
}else if(在 900 秒以內有 1 個 keys 發生了變化){
進行鏡像備份
}

rdbcompression
在進行鏡像備份時，是否進行壓縮

dbfilename
鏡像備份文件的文件名

dir
數據庫鏡像備份的文件放置的路徑。這裏的路徑跟文件名要分開配置是由於 Redis 在進行備份時，先會將當前數據庫的狀態寫入到一個臨時文件中，等備份完成時，再把該該
臨時文件替換爲上面所指定的文件，而這裏的臨時文件和上面所配置的備份文件都會放
在這個指定的路徑當中

slaveof
設置該數據庫爲其餘數據庫的從數據庫

masterauth
當主數據庫鏈接須要密碼驗證時，在這裏指定

requirepass
設置客戶端鏈接後進行任何其餘指定前須要使用的密碼。警告：由於 redis 速度至關快，
因此在一臺比較好的服務器下，一個外部的用戶能夠在一秒鐘進行 150K 次的密碼嘗試，
這意味着你須要指定很是很是強大的密碼來防止暴力破解。

maxclients
限制同時鏈接的客戶數量。當鏈接數超過這個值時， redis 將再也不接收其餘鏈接請求，
客戶端嘗試鏈接時將收到 error 信息。

maxmemory
設置 redis 可以使用的最大內存。當內存滿了的時候，若是還接收到 set 命令， redis 將
先嚐試剔除設置過 expire 信息的 key，而無論該 key 的過時時間尚未到達。在刪除時，
將按照過時時間進行刪除，最先將要被過時的 key 將最早被刪除。若是帶有 expire 信息
的 key 都刪光了，那麼將返回錯誤。這樣， redis 將再也不接收寫請求，只接收 get 請求。
maxmemory 的設置比較適合於把 redis 看成於相似 memcached 的緩存來使用。

appendonly
默認狀況下， redis 會在後臺異步的把數據庫鏡像備份到磁盤，可是該備份是很是耗時
的，並且備份也不能很頻繁，若是發生諸如拉閘限電、拔插頭等情況，那麼將形成比較
大範圍的數據丟失。因此 redis 提供了另一種更加高效的數據庫備份及災難恢復方式。
開啓 append only 模式以後， redis 會把所接收到的每一次寫操做請求都追加到
appendonly.aof 文件中，當 redis 從新啓動時，會從該文件恢復出以前的狀態。可是這樣
會形成 appendonly.aof 文件過大，因此 redis 還支持了 BGREWRITEAOF 指令，對
appendonly.aof 進行從新整理。因此我認爲推薦生產環境下的作法爲關閉鏡像，開啓
appendonly.aof，同時能夠選擇在訪問較少的時間天天對 appendonly.aof 進行重寫一次。

appendfsync
設置對 appendonly.aof 文件進行同步的頻率。 always 表示每次有寫操做都進行同步，
everysec 表示對寫操做進行累積，每秒同步一次。這個須要根據實際業務場景進行配置

vm-enabled
是否開啓虛擬內存支持。由於 redis 是一個內存數據庫，並且當內存滿的時候，沒法接
收新的寫請求，因此在 redis 2.0 中，提供了虛擬內存的支持。可是須要注意的是， redis
中，全部的 key 都會放在內存中，在內存不夠時，只會把 value 值放入交換區。這樣保
證了雖然使用虛擬內存，但性能基本不受影響，同時，你須要注意的是你要把
vm-max-memory 設置到足夠來放下你的全部的 key

vm-swap-file
設置虛擬內存的交換文件路徑

vm-max-memory
這裏設置開啓虛擬內存以後， redis 將使用的最大物理內存的大小。默認爲 0， redis 將
把他全部的能放到交換文件的都放到交換文件中，以儘可能少的使用物理內存。在生產環
境下，須要根據實際狀況設置該值，最好不要使用默認的 0

vm-page-size
設置虛擬內存的頁大小，若是你的 value 值比較大，好比說你要在 value 中放置博客、
新聞之類的全部文章內容，就設大一點，若是要放置的都是很小的內容，那就設小一點。

vm-pages
設置交換文件的總的 page 數量， 須要注意的是， page table 信息會放在物理內存中，每
8 個 page 就會佔據 RAM 中的 1 個 byte。總的虛擬內存大小 ＝ vm-page-size * vm-pages

vm-max-threads
設置 VM IO 同時使用的線程數量。由於在進行內存交換時，對數據有編碼和解碼的過
程，因此儘管 IO 設備在硬件上本上不能支持不少的併發讀寫，可是仍是若是你所保存
的 vlaue 值比較大，將該值設大一些，仍是可以提高性能的

glueoutputbuf
把小的輸出緩存放在一塊兒，以便可以在一個 TCP packet 中爲客戶端發送多個響應，具體
原理和真實效果我不是很清楚。因此根據註釋，你不是很肯定的時候就設置成 yes

hash-max-zipmap-entries
在 redis 2.0 中引入了 hash 數據結構。當 hash 中包含超過指定元素個數而且最大的元素
沒有超過臨界時， hash 將以一種特殊的編碼方式（大大減小內存使用）來存儲，這裏
能夠設置這兩個臨界值

activerehashing 開啓以後， redis 將在每 100 毫秒時使用 1 毫秒的 CPU 時間來對 redis 的 hash 表進行從新 hash，能夠下降內存的使用。當你的使用場景中，有很是嚴格的實時性須要，不能夠接受 Redis 時不時的對請求有 2 毫秒的延遲的話，把這項配置爲 no。若是沒有這麼嚴 格的實時性要求，能夠設置爲 yes，以便可以儘量快的釋放內存