redis.conf部分配置詳解

# 啟動redis，顯示載入配置redis.conf
# ./redis-server /path/to/redis.conf

# 停止redis
# redis-cli -h IP -p PORT shutdown

# 可以包含一個或多個其他配置檔案，如果多個redis伺服器存在標準配置模板，但是每隔redis伺服器可能有個性化的配置
# include /path/to/local.conf
# include /path/to/other.conf

# 這個地方網上存在許多誤解，bind的是網路介面。對於一個redis伺服器來說可以有一個或者多個網絡卡。比如伺服器上有兩個網絡卡：bind 192.168.1.100 192.168.1.101，如果bind bind 192.168.1.100，則只有該網絡卡地址接受外部請求，如果不繫結，則兩個網絡卡都接受請求
 

# bind 192.168.1.100 192.168.1.101
# bind 127.0.0.1 ::1

# 監聽埠號，預設為6379，如果為0監聽任連線
port 6379

# TCP連線中已完成佇列的長度
tcp-backlog 511

#客戶端和Redis服務端的連線超時時間，預設為0表示永不超時
timeout 0

# 服務端週期性時間（單位秒）驗證客戶端是否處在健康狀態，避免服務端一直阻塞
tcp-keepalive 300

# Redis以後臺守護程序形式啟動
daemonize yes

# 配置PID檔案路徑，當redis以守護程序啟動時，它會把PID預設寫到 /var/redis/run/redis_6379.pid檔案裡面
 

pidfile "/var/run/redis_6379.pid"

#Redis日誌級別：debug，verbose，notice，warning，級別一次遞增
loglevel notice

#日誌檔案路徑及名稱
logfile ""

Redis持久化

為了能夠重用Redis資料，或者防止系統故障，我們需要將Redis中的資料寫入到磁碟空間中，即持久化。 Redis提供了兩種不同的持久化方法可以將資料儲存在磁碟中，一種叫快照（RDB），另一種叫只追加檔案（AOF）。

RDB方式

Redis通過建立快照的方式獲取某一時刻Redis中所有資料的副本。使用者可以針對該快照進行各種操作，比如：將快照複製到其他伺服器從而完成Redis的主從複製，或者將快照留在原地，伺服器重啟的時候重用資料。 根據配置檔案，可以手動設定Redis快照名及路徑：

# RDB檔名
dbfilename "dump.rdb"
# RDB檔案和AOF檔案路徑
dir "/usr/local/var/db/redis"

Redis建立快照主要有以下幾種方式： * （1）客戶端直接通過命令BGSAVE或者SAVE來建立一個快照

• BGSAVE是通過redis呼叫fork來建立一個子程序，然後子程序負責將快照寫入磁碟，而父程序仍然繼續處理命令。
• SAVE是在沒有足夠的記憶體空間去執行BGSAVE或者無所謂等待的時候。執行SAVE命令過程中，redis不在響應任何其他命令。 2 （2）在redis.conf中設定save配置選項（應用開發中比較常用）

# 當在規定的時間內，Redis發生了寫操作的個數滿足條件，會觸發發生BGSAVE命令。
# save <seconds> <changes>
# 當用戶設定了多個save的選項配置，只要其中任一條滿足，Redis都會觸發一次BGSAVE操作，比如：900秒之內至少一次寫操作、300秒之內至少發生10次寫操作、60秒之內發生至少10000次寫操作都會觸發發生快照操作
save 900 1
save 300 10
save 60 10000

(3) 當Redis通過shutdown命令關閉伺服器請求時，會執行SAVE命令建立一個快照，如果使用kill -9 PID將不會建立快照。 (4) 主從同步，這個將在下面一小節講解。 注意：

在只使用快照持久化來報錯資料時，如果系統崩潰或者強殺，使用者將會丟失最近一次生成快照之後更改的所有資料。因此如果應用程式對於兩次快照間丟失的資料可接受，利用快照就是一個很好的方式，但是往往一些系統對於丟失幾分鐘的資料都不可接受，比如高頻的電子商務系統。

此外，如果Redis儲存的資料量長達數十G的時候，沒執行一次快照需要花費大量時間，嚴重影響到伺服器的效能。

因此，針對上述的問題，可以使用AOF方式來持久化資料。

AOF方式

在執行寫命令時，AOF持久化會將執行的寫命令也寫到AOF檔案的末尾，以此來記錄資料的變化。換句話說，將AOF檔案中包含的內容重新執行一遍，就可以回覆AOF檔案所記錄的資料集。 在Redis.conf配置中設定如下：

# redis預設關閉AOF機制，可以將no改成yes實現AOF持久化
appendonly no
# AOF檔案
appendfilename "appendonly.aof"
# AOF持久化同步頻率，always表示每個Redis寫命令都要同步fsync寫入到磁碟中，但是這種方式會嚴重降低redis的速度；everysec表示每秒執行一次同步fsync，顯示的將多個寫命令同步到磁碟中；no表示讓作業系統來決定應該何時進行同步fsync，Linux系統往往可能30秒才會執行一次
# appendfsync always
appendfsync everysec
# appendfsync no

# 在日誌進行BGREWRITEAOF時，如果設定為yes表示新寫操作不進行同步fsync，只是暫存在緩衝區裡，避免造成磁碟IO操作衝突，等重寫完成後在寫入。redis中預設為no  
no-appendfsync-on-rewrite no   
# 當前AOF檔案大小是上次日誌重寫時的AOF檔案大小兩倍時，發生BGREWRITEAOF操作。  
auto-aof-rewrite-percentage 100  
#當前AOF檔案執行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由於檔案尺寸較小導致頻繁的BGREWRITEAOF。  
auto-aof-rewrite-min-size 64mb  
# Redis再恢復時，忽略最後一條可能存在問題的指令(因為最後一條指令可能存在問題，比如寫一半時突然斷電了)
aof-load-truncated yes
#Redis4.0新增RDB-AOF混合持久化格式，在開啟了這個功能之後，AOF重寫產生的檔案將同時包含RDB格式的內容和AOF格式的內容，其中RDB格式的內容用於記錄已有的資料，而AOF格式的記憶體則用於記錄最近發生了變化的資料，這樣Redis就可以同時兼有RDB持久化和AOF持久化的優點（既能夠快速地生成重寫檔案，也能夠在出現問題時，快速地載入資料）。
aof-use-rdb-preamble no

RDB與AOF同時開啟 預設先載入AOF的配置檔案，因此需要根據具體情況使用，4.0+的可以使用RDB-AOF混合持久化格式

Redis複製

本部分只介紹主從同步的簡單實現，並利用哨兵機制實現高可用，不介紹叢集Cluster無中心的方式（放在後面的部落格中詳解）。

Redis主從複製 在Redis中實現主從複製比較簡單，只需要修改slave伺服器的redis.conf中的slaveof。下面利用一個具體的例項展示主從同步。

主從複製示例 環境如下： MacOS，Redis版本4.0.2 master伺服器：127.0.0.1 6379 slave伺服器：127.0.0.1 6399

配置slave伺服器：

# 設定master伺服器IP和埠
slaveof 127.0.0.1 6379 
# slave是否只讀，從伺服器負責讀操作，主伺服器負責寫操作，從而實現讀寫分離
slave-read-only yes

分別按照順序啟動mater(redis-server redis.conf)和slave(redis-server redis2.conf) 在master中新增元素 這裡寫圖片描述 在slave伺服器中可以獲得元素 這裡寫圖片描述

主從複製如何互動 下面來研究下slave伺服器和master伺服器間是如何建立起主從同步機制的。 這裡寫圖片描述

Slave服務啟動，主動連線Master，併發送SYNC命令，請求初始化同步 Master收到SYNC後，執行BGSAVE命令生成RDB檔案，並快取該時間段內的寫命令 Master完成RDB檔案後，將其傳送給所有Slave伺服器， Slave伺服器接收到RDB檔案後，刪除記憶體中舊的快取資料，並裝載RDB檔案 Master在傳送完RDB後，即刻向所有Slave伺服器傳送快取中的寫命令 至此初始化完成，後續進行增量同步 上述主從複製模式鏈是非常脆弱的，一旦Master伺服器發生宕機，會導致無法向redis中讀取或者寫入資料，高可用性極差。 下篇部落格研究如何搭建Redis高可用叢集環境。