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