Redis基本配置詳解_Redis配置

redis的交易處理

眾所周知，事務是指“一個完整的動作，要麼全部執行，要麼什麼也沒有做”。

在聊redis交易處理之前，要先和大家介紹四個redis指令，即MULTI、EXEC、DISCARD、WATCH。這四個指令構成了redis交易處理的基礎。

1.MULTI用來組裝一個事務；
2.EXEC用來執行一個事務；
3.DISCARD用來取消一個事務；
4.WATCH用來監視一些key，一旦這些key在事務執行之前被改變，則取消事務的執行。

紙上得來終覺淺，我們來看一個MULTI和EXEC的例子：
複製代碼代碼如下:
redis> MULTI //標記事務開始
OK
redis> INCR user_id //多條命令按順序入隊
QUEUED
redis> INCR user_id
QUEUED
redis> INCR user_id
QUEUED
redis> PING
QUEUED
redis> EXEC //執行
1) (integer) 1
2) (integer) 2
3) (integer) 3
4) PONG

在上面的例子中，我們看到了QUEUED的字樣，這表示我們在用MULTI組裝事務時，每一個命令都會進入到記憶體隊列中緩衝起來，如果出現QUEUED則表示我們這個命令成功插入了緩衝隊列，在將來執行EXEC時，這些被QUEUED的命令都會被組裝成一個事務來執行。

對於事務的執行來說，如果redis開啟了AOF持久化的話，那麼一旦事務被成功執行，事務中的命令就會通過write命令一次性寫到磁碟中去，如果在向磁碟中寫的過程中恰好出現斷電、硬體故障等問題，那麼就可能出現只有部分命令進行了AOF持久化，這時AOF檔案就會出現不完整的情況，這時，我們可以使用redis-check-aof工具來修複這一問題，這個工具會將AOF檔案中不完整的資訊移除，確保AOF檔案完整可用。

有關事務，大家經常會遇到的是兩類錯誤：

1.調用EXEC之前的錯誤
2.調用EXEC之後的錯誤

“調用EXEC之前的錯誤”，有可能是由於文法有誤導致的，也可能時由於記憶體不足導致的。只要出現某個命令無法成功寫入緩衝隊列的情況，redis都會進行記錄，在用戶端調用EXEC時，redis會拒絕執行這一事務。（這時2.6.5版本之後的策略。在2.6.5之前的版本中，redis會忽略那些入隊失敗的命令，只執行那些入隊成功的命令）。我們來看一個這樣的例子：
複製代碼代碼如下:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> haha //一個明顯錯誤的指令
(error) ERR unknown command 'haha'
127.0.0.1:6379> ping
QUEUED
127.0.0.1:6379> exec
//redis無情的拒絕了事務的執行，原因是“之前出現了錯誤”
(error) EXECABORT Transaction discarded because of previous errors.

而對於“調用EXEC之後的錯誤”，redis則採取了完全不同的策略，即redis不會理睬這些錯誤，而是繼續向下執行事務中的其他命令。這是因為，對於應用程式層面的錯誤，並不是redis自身需要考慮和處理的問題，所以一個事務中如果某一條命令執行失敗，並不會影響接下來的其他命令的執行。我們也來看一個例子：

複製代碼代碼如下:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 23
QUEUED
//age不是集合，所以如下是一條明顯錯誤的指令
127.0.0.1:6379> sadd age 15 
QUEUED
127.0.0.1:6379> set age 29
QUEUED
127.0.0.1:6379> exec //執行事務時，redis不會理睬第2條指令執行錯誤
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> get age
"29" //可以看出第3條指令被成功執行了

好了，我們來說說最後一個指令“WATCH”，這是一個很好用的指令，它可以幫我們實作類別似於“樂觀鎖”的效果，即CAS（check and set）。

WATCH本身的作用是“監視key是否被改動過”，而且支援同時監視多個key，只要還沒真正觸發事務，WATCH都會盡職盡責的監視，一旦發現某個key被修改了，在執行EXEC時就會返回nil，表示事務無法觸發。
複製代碼代碼如下:
127.0.0.1:6379> set age 23
OK
127.0.0.1:6379> watch age //開始監視age
OK
127.0.0.1:6379> set age 24 //在EXEC之前，age的值被修改了
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 25
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec //觸發EXEC
(nil) //事務無法被執行

redis配置 – 簡介

我們可以在啟動redis-server時指定應該載入的設定檔，方法如下：
複製代碼代碼如下:
$ ./redis-server /path/to/redis.conf

接下來，我們就來講解下redis設定檔的各個配置項的含義，注意，本文是基於redis-2.8.4版本進行講解的。

redis官方提供的redis.conf檔案，足有700+行，其中100多行為有效配置行，另外的600多行為注釋說明。

在設定檔的開頭部分，首先明確了一些度量單位：
複製代碼代碼如下:
# 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設定檔被分成了幾大塊地區，它們分別是：

1.通用（general）
2.快照（snapshotting）
3.複製（replication）
4.安全（security）
5.限制（limits)
6.追加模式（append only mode)
7.LUA指令碼（lua scripting)
8.慢日誌（slow log)
9.事件通知（event notification）

下面我們就來逐一講解。

【教你看懂redis配置 -通用】

預設情況下，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.sock
unixsocketperm 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配置 – 快照

快照，主要涉及的是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傳入一個Null 字元串參數也可以達到相同效果，就像這樣：
複製代碼代碼如下:
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配置 – 複製

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

在主從同步時，可能在這些情況下會有逾時發生：

1.以從redis的角度來看，當有大規模IO傳輸時。
2.以從redis的角度來看，當資料轉送或PING時，主redis逾時
3.以主redis的角度來看，在回複從redis的PING時，從redis逾時

使用者可以設定上述逾時的時限，不過要確保這個時限比repl-ping-slave-period的值要大，否則每次主redis都會認為從redis逾時。
複製代碼代碼如下:
repl-timeout 60

我們可以控制在主從同步時是否禁用TCP_NODELAY。如果開啟TCP_NODELAY，那麼主redis會使用更少的TCP包和更少的頻寬來向從r