[[email protected] blog]# egrep -v"#|^$" /application/redis/conf/6379.conf

bind127.0.0.1 #繫結的主機地址，不設定預設將處理所有請求

protected-modeyes # 3.2裡的引數，是否開啟保護模式，預設開啟。要是配置裡沒有指定bind和密碼。開啟該引數後，redis只會本地進行訪問，拒絕外部訪問。要是開啟了密碼   和bind，可以開啟。否  則最好關閉，設定為no

port6379 #指定redis監聽埠

tcp-backlog511 #此引數確定了TCP連線中已完成佇列(完成三次握手之後)的長度， 當然此值必須不大於Linux系統定義的/proc/sys/net/core/somaxconn值，預設是511，而Linux的預設引數值是128。當系統併發量大並且客戶端速度緩慢的時候，可以將這二個引數一起參考設定。該核心引數預設值一般是128，對於負載很大的服務程式來說大大的不夠。一般會將它修改為2048或者更大。在/etc/sysctl.conf中新增:net.core.somaxconn =2048，然後在終端中執行sysctl -p

timeout0 #當 客戶端閒置多長時間後關閉連線，如果指定為0，表示關閉該功能

tcp-keepalive300 #如果設定不為0，就使用配置tcp的SO_KEEPALIVE值，使用keepalive有兩個好處:檢測掛掉的對端。降低中間裝置出問題而導致網路看似連線卻已經與對端埠的問題。在Linux核心中，設定了keepalive，redis會定時給對端傳送ack。檢測到對端關閉需要兩倍的設定值。

daemonizeno #當為yes的時候，以守護程序的模式執行（後臺執行）

supervisedno可以通過upstart和systemd管理Redis守護程序，這個引數是和具體的作業系統相關的

pidfile/var/run/redis_6379.pid #當redis以守護程序方式執行時，預設寫入pid的檔案及路徑

loglevelnotice 日誌級別，要用warning

logfile"" #指定了記錄日誌的檔案。空字串的話，日誌會列印到標準輸出裝置。後臺執行的redis標準輸出是/dev/null

databases16 資料庫的數量，預設使用的資料庫是DB 0。可以通過”SELECT “命令選擇一個db

save900 1 #900秒有一個key變化，就做一個儲存

save300 10 #300秒有10個key變化，就做一個儲存，這裡需要和開發溝通

save60 10000 #60秒有10000個key變化就做一個儲存

stop-writes-on-bgsave-erroryes #在出現錯誤的時候，是不是要停止儲存

rdbcompressionyes使用壓縮rdb檔案，rdb檔案壓縮使用LZF壓縮演算法，yes：壓縮，但是需要一些cpu的消耗。no：不壓縮，需要更多的磁碟空間

rdbchecksumyes是否校驗rdb檔案。從rdb格式的第五個版本開始，在rdb檔案的末尾會帶上CRC64的校驗和。這跟有利於檔案的容錯性，但是在儲存rdb檔案的時候，會有大概10%的效能損耗，所以如果你追求高效能，可以關閉該配置。

dbfilenamedump.rdb rdb檔案的名稱

dir./ 資料目錄，資料庫的寫入會在這個目錄。rdb、aof檔案也會寫在這個目錄

slave-serve-stale-datayes當從庫同主機失去連線或者複製正在進行，從機庫有兩種執行方式：1) 如果slave-serve-stale-data設定為yes(預設設定)，從庫會繼續響應客戶端的請求。2) 如果slave-serve-stale-data設定為no，除去INFO和SLAVOF命令之外的任何請求都會返回一個錯誤”SYNC with master in progress”

slave-read-onlyyes作為從伺服器，預設情況下是隻讀的（yes），可以修改成NO，用於寫（不建議）

repl-diskless-syncno是否使用socket方式複製資料。目前redis複製提供兩種方式，disk和socket。如果新的slave連上來或者重連的slave無法部分同步，就會執行全量同步，master會生成rdb檔案。有2種方式：disk方式是master建立一個新的程序把rdb檔案儲存到磁碟，再把磁碟上的rdb檔案傳遞給slave。socket是master建立一個新的程序，直接把rdb檔案以socket的方式發給slave。disk方式的時候，當一個rdb儲存的過程中，多個slave都能共享這個rdb檔案。socket的方式就的一個個slave順序複製。在磁碟速度緩慢，網速快的情況下推薦用socket方式。

repl-diskless-sync-delay5 diskless複製的延遲時間，防止設定為0。一旦複製開始，節點不會再接收新slave的複製請求直到下一個rdb傳輸。所以最好等待一段時間，等更多的slave連上來。

repl-disable-tcp-nodelayno[gs1] [gs2] 引數，可傳遞yes或者no。預設是no，即使用tcp nodelay。如果master設定了yes來禁止tcp nodelay設定，在把資料複製給slave的時候，會減少包的數量和更小的網路頻寬。但是這也可能帶來資料的延遲。預設我們推薦更小的延遲，但是在資料量傳輸很大的場景下，建議選擇yes。

slave-priority100當master不可用，Sentinel會根據slave的優先順序選舉一個master。最低的優先順序的slave，當選master。而配置成0，永遠不會被選舉。

appendonlyno #預設redis使用的是rdb方式持久化，這種方式在許多應用中已經足夠用了。但是redis如果中途宕機，會導致可能有幾分鐘的資料丟失，根據save來策略進行持久化，Append Only File是另一種持久化方式，可以提供更好的持久化特性。Redis會把每次寫入的資料在接收後都寫入 appendonly.aof 檔案，每次啟動時Redis都會先把這個檔案的資料讀入記憶體裡，先忽略RDB檔案

appendfilename"appendonly.aof" sof檔名

appendfsynceverysec #aof持久化策略的配置

#no表示不執行fsync，由作業系統保證資料同步到磁碟，速度最快。

#always表示每次寫入都執行fsync，以保證資料同步到磁碟。

#everysec表示每秒執行一次fsync，可能會導致丟失這1s資料。

no-appendfsync-on-rewriteno在aof重寫或者寫入rdb檔案的時候，會執行大量IO，此時對於everysec和always的aof模式來說，執行fsync會造成阻塞過長時間，no-appendfsync-on-rewrite欄位設定為預設設定為no。如果對延遲要求很高的應用，這個欄位可以設定為yes，否則還是設定為no，這樣對持久化特性來說這是更安全的選擇。設定為yes表示rewrite期間對新寫操作不fsync,暫時存在記憶體中,等rewrite完成後再寫入，預設為no，建議yes。Linux的預設fsync策略是30秒。可能丟失30秒資料。

auto-aof-rewrite-percentage100 aof自動重寫配置。當目前aof檔案大小超過上一次重寫的aof檔案大小的百分之多少進行重寫，即當aof檔案增長到一定大小的時候Redis能夠呼叫bgrewriteaof對日誌檔案進行重寫。當前AOF檔案大小是上次日誌重寫得到AOF檔案大小的二倍（設定為100）時，自動啟動新的日誌重寫過程。

auto-aof-rewrite-min-size64mb #設定允許重寫的最小aof檔案大小，避免了達到約定百分比但尺寸仍然很小的情況還要重寫

aof-load-truncatedyes#aof檔案可能在尾部是不完整的，當redis啟動的時候，aof檔案的資料被載入記憶體。重啟可能發生在redis所在的主機作業系統宕機後，尤其在ext4檔案系統沒有加上data=ordered選項（redis宕機或者異常終止不會造成尾部不完整現象。）出現這種現象，可以選擇讓redis退出，或者匯入儘可能多的資料。如果選擇的是yes，當截斷的aof檔案被匯入的時候，會自動釋出一個log給客戶端然後load。如果是no，使用者必須手動redis-check-aof修復AOF檔案才可以。

lua-time-limit5000如果達到最大時間限制（毫秒），redis會記個log，然後返回error。當一個指令碼超過了最大時限。只有SCRIPT KILL和SHUTDOWN NOSAVE可以用。第一個可以殺沒有調write命令的東西。要是已經呼叫了write，只能用第二個命令殺。

slowlog-log-slower-than10000 slog log是用來記錄redis執行中執行比較慢的命令耗時。當命令的執行超過了指定時間，就記錄在slow log中，slog log儲存在記憶體中，所以沒有IO操作。

#執行時間比slowlog-log-slower-than大的請求記錄到slowlog裡面，單位是微秒，所以1000000就是1秒。注意，負數時間會禁用慢查詢日誌，而0則會強制記錄所有命令。

slowlog-max-len128慢查詢日誌長度。當一個新的命令被寫進日誌的時候，最老的那個記錄會被刪掉。這個長度沒有限制。只要有足夠的記憶體就行。你可以通過 SLOWLOG RESET 來釋放記憶體。

latency-monitor-threshold0 #延遲監控功能是用來監控redis中執行比較緩慢的一些操作，用LATENCY列印redis例項在跑命令時的耗時圖表。只記錄大於等於下邊設定的值的操作。0的話，就是關閉監視。預設延遲監控功能是關閉的，如果你需要開啟，也可以通過CONFIGSET命令動態設定。

notify-keyspace-events""

#鍵空間通知使得客戶端可以通過訂閱頻道或模式，來接收那些以某種方式改動了Redis 資料集的事件。因為開啟鍵空間通知功能需要消耗一些 CPU ，所以在預設配置下，該功能處於關閉狀態。

#notify-keyspace-events的引數可以是以下字元的任意組合，它指定了伺服器該傳送哪些型別的通知：

##K 鍵空間通知，所有通知以 [email protected]__ 為字首

##E 鍵事件通知，所有通知以 [email protected]__ 為字首

##g DEL 、 EXPIRE 、RENAME 等型別無關的通用命令的通知

##$ 字串命令的通知

##l 列表命令的通知

##s 集合命令的通知

##h 雜湊命令的通知

##z 有序集合命令的通知

##x 過期事件：每當有過期鍵被刪除時傳送

##e 驅逐(evict)事件：每當有鍵因為 maxmemory 政策而被刪除時傳送

##A 引數 g$lshzxe 的別名

#輸入的引數中至少要有一個 K 或者 E，否則的話，不管其餘的引數是什麼，都不會有任何 通知被分發。詳細使用可以參考http://redis.io/topics/notifications

hash-max-ziplist-entries512#資料量小於等於hash-max-ziplist-entries的用ziplist，大於hash-max-ziplist-entries用hash

hash-max-ziplist-value64 #value大小小於等於hash-max-ziplist-value的用ziplist，大於hash-max-ziplist-value用hash。

list-max-ziplist-size-2

# The highestperforming option is usually -2 (8 Kb size) or -1 (4 Kb size),

# but if your use caseis unique, adjust the settings as necessary.

list-compress-depth0

set-max-intset-entries512 #資料量小於等於set-max-intset-entries用iniset，大於set-max-intset-entries用set。

zset-max-ziplist-entries128 #資料量小於等於zset-max-ziplist-entries用ziplist，大於zset-max-ziplist-entries用zset。

zset-max-ziplist-value64 #value大小小於等於zset-max-ziplist-value用ziplist，大於zset-max-ziplist-value用zset。

hll-sparse-max-bytes3000#value大小小於等於hll-sparse-max-bytes使用稀疏資料結構（sparse），大於hll-sparse-max-bytes使用稠密的資料結構（dense）。一個比16000大的value是幾乎沒用的，建議的value大概為3000。如果對CPU要求不高，對空間要求較高的，建議設定到10000左右。

activerehashingyes#Redis將在每100毫秒時使用1毫秒的CPU時間來對redis的hash表進行重新hash，可以降低記憶體的使用。當你的使用場景中，有非常嚴格的實時性需要，不能夠接受Redis時不時的對請求有2毫秒的延遲的話，把這項配置為no。如果沒有這麼嚴格的實時性要求，可以設定為yes，以便能夠儘可能快的釋放記憶體。

client-output-buffer-limitnormal 0 0 0

##對客戶端輸出緩衝進行限制可以強迫那些不從伺服器讀取資料的客戶端斷開連線，用來強制關閉傳輸緩慢的客戶端。

#對於normalclient，第一個0表示取消hard limit，第二個0和第三個0表示取消soft limit，normal client預設取消限制，因為如果沒有尋問，他們是不會接收資料的。

client-output-buffer-limitslave 256mb 64mb 60 #對於slaveclient和MONITER client，如果client-output-buffer一旦超過256mb，又或者超過64mb持續60秒，那麼伺服器就會立即斷開客戶端連線。

client-output-buffer-limitpubsub 32mb 8mb 60 #對於pubsub client，如果client-output-buffer一旦超過32mb，又或者超過8mb持續60秒，那麼伺服器就會立即斷開客戶端連線。

hz10 #redis執行任務的頻率為1s除以hz。

aof-rewrite-incremental-fsyncyes #在aof重寫的時候，如果打開了aof-rewrite-incremental-fsync開關，系統會每32MB執行一次fsync。這對於把檔案寫入磁碟是有幫助的，可以避免過大的延遲峰值。

下面對tcp_nodelay on做一個解釋：

TCP_NODELAY和TCP_CORK基本上控制了包的“Nagle化”，這裡我們主要講TCP_NODELAY.Nagle化在這裡的含義是採用Nagle演算法把較小的包組裝為更大的幀。JohnNagle是Nagle演算法的發明人，後者就是用他的名字來命名的，他在1984年首次用這種方法來嘗試解決福特汽車公司的網路擁塞問題（欲瞭解詳情請參看IETF RFC 896）。他解決的問題就是所謂的silly window syndrome，中文稱“愚蠢視窗症候群”，具體含義是，因為普遍終端應用程式每產生一次擊鍵操作就會發送一個包，而典型情況下一個包會擁有一個位元組的資料載荷以及40個位元組長的包頭，於是產生4000%的過載，很輕易地就能令網路發生擁塞,。Nagle化後來成了一種標準並且立即在因特網上得以實現。它現在已經成為預設配置了，但在我們看來，有些場合下把這一選項關掉也是合乎需要的。

現在讓我們假設某個應用程式發出了一個請求，希望傳送小塊資料，比如sns遊戲中的點選確定按鈕。我們可以選擇立即傳送資料或者等待產生更多的資料然後再一次傳送兩種策略。如果我們馬上傳送資料，那麼互動性的以及客戶/伺服器型的應用程式將極大地受益。例如，當我們正在傳送一個較短的請求並且等候較大的響應時，相關過載與傳輸的資料總量相比就會比較低，而且，如果請求立即發出那麼響應時間也會快一些。以上操作可以通過設定套接字的TCP_NODELAY選項來完成，這樣就禁用了Nagle演算法，在nginx中設定tcp_nodelay on,注意放在http標籤裡。

另外一種情況則需要我們等到資料量達到最大時才通過網路一次傳送全部資料，這種資料傳輸方式有益於大量資料的通訊效能，典型的應用就是檔案伺服器。應用Nagle演算法在這種情況下就會產生問題。但是，如果你正在傳送大量資料，你可以設定TCP_CORK選項禁用Nagle化，其方式正好同TCP_NODELAY相反（TCP_CORK 和 TCP_NODELAY 是互相排斥的）。下面就讓我們仔細分析下其工作原理。

假設應用程式使用sendfile()函式來轉移大量資料（nginx裡可以設定sendfileon)。應用協議通常要求傳送某些資訊來預先解釋資料，這些資訊其實就是報頭內容。典型情況下報頭很小，而且套接字上設定了TCP_NODELAY。有報頭的包將被立即傳輸，在某些情況下（取決於內部的包計數器），因為這個包成功地被對方收到後需要請求對方確認。這樣，大量資料的傳輸就會被推遲而且產生了不必要的網路流量交換。

但是，如果我們在套接字上設定了TCP_CORK（可以比喻為在管道上插入“塞子”）選項，具有報頭的包就會填補大量的資料，所有的資料都根據大小自動地通過包傳輸出去。當資料傳輸完成時，最好取消TCP_CORK選項設定給連線“拔去塞子”以便任一部分的幀都能傳送出去。這同“塞住”網路連線同等重要。

總而言之，如果你肯定能一起傳送多個數據集合（例如HTTP響應的頭和正文），那麼我們建議你設定TCP_CORK選項，這樣在這些資料之間不存在延遲。能極大地有益於WWW、FTP以及檔案伺服器的效能，同時也簡化了你的工作.