本文摘抄自大鵬redis教程
我們可以在啟動redis-server時指定應該加載的配置文件，方法如下：
$ ./redis-server /path/to/redis.conf
在配置文件的開頭部分，首先明確了一些度量單位：
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
可以看出，redis配置中對單位的大小寫不敏感，1GB、1Gb和1gB都是相同的。由此也說明，redis只支持bytes，不支持bit單位。
redis支持“主配置文件中引入外部配置文件”，很像C/C++中的include指令，比如：
include /path/to/other.conf
如果你看過redis的配置文件，會發現還是很有條理的。redis配置文件被分成了幾大塊區域，它們分別是：
- 通用（general）
- 快照（snapshotting）
- 復制（replication）
- 安全（security）
- 限制（limits)
- 追加模式（append only mode)
- LUA腳本（lua scripting)
- 慢日志（slow log)
- 事件通知（event notification）
下面我們就來逐一講解。
通用
默認情況下，redis并不是以daemon形式來運行的。通過daemonize配置項可以控制redis的運行形式，如果改為yes，那么redis就會以daemon形式運行：
daemonize no
當以daemon形式運行時，redis會生成一個pid文件，默認會生成在/var/run/redis.pid。當然，你可以通過pidfile來指定pid文件生成的位置，比如：
pidfile /path/to/redis.pid
默認情況下，redis會響應本機所有可用網卡的連接請求。當然，redis允許你通過bind配置項來指定要綁定的IP，比如：
bind 192.168.1.2 10.8.4.2
redis的默認服務端口是6379，你可以通過port配置項來修改。如果端口設置為0的話，redis便不會監聽端口了。
port 6379
有些同學會問“如果redis不監聽端口，還怎么與外界通信呢”，其實redis還支持通過unix socket方式來接收請求。可以通過unixsocket配置項來指定unix socket文件的路徑，并通過unixsocketperm來指定文件的權限。
unixsocket /tmp/redis.sockunixsocketperm 755
當一個redis-client一直沒有請求發向server端，那么server端有權主動關閉這個連接，可以通過timeout來設置“空閑超時時限”，0表示永不關閉。
timeout 0
TCP連接保活策略，可以通過tcp-keepalive配置項來進行設置，單位為秒，假如設置為60秒，則server端會每60秒向連接空閑的客戶端發起一次ACK請求，以檢查客戶端是否已經掛掉，對于無響應的客戶端則會關閉其連接。所以關閉一個連接最長需要120秒的時間。如果設置為0，則不會進行保活檢測。
tcp-keepalive 0
redis支持通過loglevel配置項設置日志等級，共分四級，即debug、verbose、notice、warning。
loglevel notice
redis也支持通過logfile配置項來設置日志文件的生成位置。如果設置為空字符串，則redis會將日志輸出到標準輸出。假如你在daemon情況下將日志設置為輸出到標準輸出，則日志會被寫到/dev/null中。
logfile ""
如果希望日志打印到syslog中，也很容易，通過syslog-enabled來控制。另外，syslog-ident還可以讓你指定syslog里的日志標志，比如：
syslog-ident redis
而且還支持指定syslog設備，值可以是USER或LOCAL0-LOCAL7。具體可以參考syslog服務本身的用法。
syslog-facility local0
對于redis來說，可以設置其數據庫的總數量，假如你希望一個redis包含16個數據庫，那么設置如下：
databases 16
這16個數據庫的編號將是0到15。默認的數據庫是編號為0的數據庫。用戶可以使用select <DBid>來選擇相應的數據庫。
快照
快照，主要涉及的是redis的RDB持久化相關的配置，我們來一起看一看。
我們可以用如下的指令來讓數據保存到磁盤上，即控制RDB快照功能：
save <seconds> <changes>
舉例來說：
save 900 1 //表示每15分鐘且至少有1個key改變，就觸發一次持久化
save 300 10 //表示每5分鐘且至少有10個key改變，就觸發一次持久化
save 60 10000 //表示每60秒至少有10000個key改變，就觸發一次持久化
如果你想禁用RDB持久化的策略，只要不設置任何save指令就可以，或者給save傳入一個空字符串參數也可以達到相同效果，就像這樣：
save ""
如果用戶開啟了RDB快照功能，那么在redis持久化數據到磁盤時如果出現失敗，默認情況下，redis會停止接受所有的寫請求。這樣做的好處在于可以讓用戶很明確的知道內存中的數據和磁盤上的數據已經存在不一致了。如果redis不顧這種不一致，一意孤行的繼續接收寫請求，就可能會引起一些災難性的后果。
如果下一次RDB持久化成功，redis會自動恢復接受寫請求。
當然，如果你不在乎這種數據不一致或者有其他的手段發現和控制這種不一致的話，你完全可以關閉這個功能，以便在快照寫入失敗時，也能確保redis繼續接受新的寫請求。配置項如下：
stop-writes-on-bgsave-error yes
對于存儲到磁盤中的快照，可以設置是否進行壓縮存儲。如果是的話，redis會采用LZF算法進行壓縮。如果你不想消耗CPU來進行壓縮的話，可以設置為關閉此功能，但是存儲在磁盤上的快照會比較大。
rdbcompression yes
在存儲快照后，我們還可以讓redis使用CRC64算法來進行數據校驗，但是這樣做會增加大約10%的性能消耗，如果你希望獲取到最大的性能提升，可以關閉此功能。
rdbchecksum yes
我們還可以設置快照文件的名稱，默認是這樣配置的：
dbfilename dump.rdb
最后，你還可以設置這個快照文件存放的路徑。比如默認設置就是當前文件夾：
dir ./
復制
redis提供了主從同步功能。
通過slaveof配置項可以控制某一個redis作為另一個redis的從服務器，通過指定IP和端口來定位到主redis的位置。一般情況下，我們會建議用戶為從redis設置一個不同頻率的快照持久化的周期，或者為從redis配置一個不同的服務端口等等。
slaveof <masterip> <masterport>
如果主redis設置了驗證密碼的話（使用requirepass來設置），則在從redis的配置中要使用masterauth來設置校驗密碼，否則的話，主redis會拒絕從redis的訪問請求。
masterauth <master-password>
當從redis失去了與主redis的連接，或者主從同步正在進行中時，redis該如何處理外部發來的訪問請求呢？這里，從redis可以有兩種選擇：
第一種選擇：如果slave-serve-stale-data設置為yes（默認），則從redis仍會繼續響應客戶端的讀寫請求。
第二種選擇：如果slave-serve-stale-data設置為no，則從redis會對客戶端的請求返回“SYNC with master in progress”，當然也有例外，當客戶端發來INFO請求和SLAVEOF請求，從redis還是會進行處理。
你可以控制一個從redis是否可以接受寫請求。將數據直接寫入從redis，一般只適用于那些生命周期非常短的數據，因為在主從同步時，這些臨時數據就會被清理掉。自從redis2.6版本之后，默認從redis為只讀。
slave-read-only yes
只讀的從redis并不適合直接暴露給不可信的客戶端。為了盡量降低風險，可以使用rename-command指令來將一些可能有破壞力的命令重命名，避免外部直接調用。比如：
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
從redis會周期性的向主redis發出PING包。你可以通過repl_ping_slave_period指令來控制其周期。默認是10秒。
repl-ping-slave-period 10
在主從同步時，可能在這些情況下會有超時發生：
以從redis的角度來看，當有大規模IO傳輸時。
以從redis的角度來看，當數據傳輸或PING時，主redis超時
以主redis的角度來看，在回復從redis的PING時，從redis超時
用戶可以設置上述超時的時限，不過要確保這個時限比repl-ping-slave-period的值要大，否則每次主redis都會認為從redis超時。
repl-timeout 60
我們可以控制在主從同步時是否禁用TCP_NODELAY。如果開啟TCP_NODELAY，那么主redis會使用更少的TCP包和更少的帶寬來向從redis傳輸數據。但是這可能會增加一些同步的延遲，大概會達到40毫秒左右。如果你關閉了TCP_NODELAY，那么數據同步的延遲時間會降低，但是會消耗更多的帶寬。
repl-disable-tcp-nodelay no
我們還可以設置同步隊列長度。隊列長度（backlog)是主redis中的一個緩沖區，在與從redis斷開連接期間，主redis會用這個緩沖區來緩存應該發給從redis的數據。這樣的話，當從redis重新連接上之后，就不必重新全量同步數據，只需要同步這部分增量數據即可。
repl-backlog-size 1mb
如果主redis等了一段時間之后，還是無法連接到從redis，那么緩沖隊列中的數據將被清理掉。我們可以設置主redis要等待的時間長度。如果設置為0，則表示永遠不清理。默認是1個小時。
repl-backlog-ttl 3600
我們可以給眾多的從redis設置優先級，在主redis持續工作不正常的情況，優先級高的從redis將會升級為主redis。而編號越小，優先級越高。比如一個主redis有三個從redis，優先級編號分別為10、100、25，那么編號為10的從redis將會被首先選中升級為主redis。當優先級被設置為0時，這個從redis將永遠也不會被選中。默認的優先級為100。
slave-priority 100
假如主redis發現有超過M個從redis的連接延時大于N秒，那么主redis就停止接受外來的寫請求。這是因為從redis一般會每秒鐘都向主redis發出PING，而主redis會記錄每一個從redis最近一次發來PING的時間點，所以主redis能夠了解每一個從redis的運行情況。
min-slaves-to-write 3
min-slaves-max-lag 10
上面這個例子表示，假如有大于等于3個從redis的連接延遲大于10秒，那么主redis就不再接受外部的寫請求。上述兩個配置中有一個被置為0，則這個特性將被關閉。默認情況下min-slaves-to-write為0，而min-slaves-max-lag為10。
安全
我們可以要求redis客戶端在向redis-server發送請求之前，先進行密碼驗證。當你的redis-server處于一個不太可信的網絡環境中時，相信你會用上這個功能。由于redis性能非常高，所以每秒鐘可以完成多達15萬次的密碼嘗試，所以你最好設置一個足夠復雜的密碼，否則很容易被黑客破解。
requirepass zhimakaimen
這里我們通過requirepass將密碼設置成“芝麻開門”。
redis允許我們對redis指令進行更名，比如將一些比較危險的命令改個名字，避免被誤執行。比如可以把CONFIG命令改成一個很復雜的名字，這樣可以避免外部的調用，同時還可以滿足內部調用的需要：
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c89
我們甚至可以禁用掉CONFIG命令，那就是把CONFIG的名字改成一個空字符串：
rename-command CONFIG ""
但需要注意的是，如果你使用AOF方式進行數據持久化，或者需要與從redis進行通信，那么更改指令的名字可能會引起一些問題。
限制
我們可以設置redis同時可以與多少個客戶端進行連接。默認情況下為10000個客戶端。當你無法設置進程文件句柄限制時，redis會設置為當前的文件句柄限制值減去32，因為redis會為自身內部處理邏輯留一些句柄出來。
如果達到了此限制，redis則會拒絕新的連接請求，并且向這些連接請求方發出“max number of clients reached”以作回應。
maxclients 10000
我們甚至可以設置redis可以使用的內存量。一旦到達內存使用上限，redis將會試圖移除內部數據，移除規則可以通過maxmemory-policy來指定。
如果redis無法根據移除規則來移除內存中的數據，或者我們設置了“不允許移除”，那么redis則會針對那些需要申請內存的指令返回錯誤信息，比如SET、LPUSH等。但是對于無內存申請的指令，仍然會正常響應，比如GET等。
maxmemory <bytes>
需要注意的一點是，如果你的redis是主redis（說明你的redis有從redis），那么在設置內存使用上限時，需要在系統中留出一些內存空間給同步隊列緩存，只有在你設置的是“不移除”的情況下，才不用考慮這個因素。
對于內存移除規則來說，redis提供了多達6種的移除規則。他們是：
volatile-lru：使用LRU算法移除過期集合中的key
allkeys-lru：使用LRU算法移除key
volatile-random：在過期集合中移除隨機的key
allkeys-random：移除隨機的key
volatile-ttl：移除那些TTL值最小的key，即那些最近才過期的key。
noeviction：不進行移除。針對寫操作，只是返回錯誤信息。
```
無論使用上述哪一種移除規則，如果沒有合適的key可以移除的話，redis都會針對寫請求返回錯誤信息。
```
maxmemory-policy volatile-lru
```
LRU算法和最小TTL算法都并非是精確的算法，而是估算值。所以你可以設置樣本的大小。假如redis默認會檢查三個key并選擇其中LRU的那個，那么你可以改變這個key樣本的數量。
####追加模式
默認情況下，redis會異步的將數據持久化到磁盤。這種模式在大部分應用程序中已被驗證是很有效的，但是在一些問題發生時，比如斷電，則這種機制可能會導致數分鐘的寫請求丟失。
如博文上半部分中介紹的，追加文件（Append Only File）是一種更好的保持數據一致性的方式。即使當服務器斷電時，也僅會有1秒鐘的寫請求丟失，當redis進程出現問題且操作系統運行正常時，甚至只會丟失一條寫請求。
我們建議大家，AOF機制和RDB機制可以同時使用，不會有任何沖突。
```
appendonly no
```
我們還可以設置aof文件的名稱：
```
appendfilename "appendonly.aof"
```
fsync()調用，用來告訴操作系統立即將緩存的指令寫入磁盤。一些操作系統會“立即”進行，而另外一些操作系統則會“盡快”進行。
redis支持三種不同的模式：
* no：不調用fsync()。而是讓操作系統自行決定sync的時間。這種模式下，redis的性能會最快。
* always：在每次寫請求后都調用fsync()。這種模式下，redis會相對較慢，但數據最安全。
* everysec：每秒鐘調用一次fsync()。這是性能和安全的折衷。
```
appendfsync everysec
```
當fsync方式設置為always或everysec時，如果后臺持久化進程需要執行一個很大的磁盤IO操作，那么redis可能會在fsync()調用時卡住。目前尚未修復這個問題，這是因為即使我們在另一個新的線程中去執行fsync()，也會阻塞住同步寫調用。
為了緩解這個問題，我們可以使用下面的配置項，這樣的話，當BGSAVE或BGWRITEAOF運行時，fsync()在主進程中的調用會被阻止。這意味著當另一路進程正在對AOF文件進行重構時，redis的持久化功能就失效了，就好像我們設置了“appendsync none”一樣。如果你的redis有時延問題，那么請將下面的選項設置為yes。否則請保持no，因為這是保證數據完整性的最安全的選擇。
```
no-appendfsync-on-rewrite no
```
我們允許redis自動重寫aof。當aof增長到一定規模時，redis會隱式調用BGREWRITEAOF來重寫log文件，以縮減文件體積。
redis是這樣工作的：redis會記錄上次重寫時的aof大小。假如redis自啟動至今還沒有進行過重寫，那么啟動時aof文件的大小會被作為基準值。這個基準值會和當前的aof大小進行比較。如果當前aof大小超出所設置的增長比例，則會觸發重寫。另外，你還需要設置一個最小大小，是為了防止在aof很小時就觸發重寫。
```
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
```
如果設置auto-aof-rewrite-percentage為0，則會關閉此重寫功能。