Redis的配置主要放置在redis.conf，可以通過修改配置文件實現Redis許多特性，比如複製，持久化，集羣等。
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）在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 noRDB與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高可用集羣環境。