| 服務器 | IP |
|---|---|
| redis服務器160（主） | 192.168.1.210 |
| redis服務器170（從） | 192.168.1.220 |
一、主從服務器安裝redis服務
參考博客：https://blog.csdn.net/renfeigui0/article/details/103182585
二、主從服務器同步配置（需密碼認證）
1、主redis服務器210，修改redis.conf配置文件，在下圖所示位置添加“requirepass 1111”，即設置密碼爲“1111”。redis-cli客戶端訪問時需要密碼認證，如下圖。
find / -name redis.conf
vi /usr/local/redis/redis.conf
2、從redis服務器220，修改redis.conf配置文件，在下圖所示位置添加"replicaof 主redisIP 主redis端口"和“masterauth 1111”，如下圖。
find / -name redis.conf
vi /usr/local/redis/redis.conf
三、主從服務器同步測試
1、主redis服務器210重啓redis服務，啓動redis本地客戶端。
pkill redis
netstat -anp |grep redis
/usr/local/redis/src/redis-server /usr/local/redis/redis.conf
/usr/local/redis/src/redis-cli
2、從redis服務器220重啓redis服務，啓動redis本地客戶端。
/usr/local/redis/src/redis-cli -p 6379 shutdown
/usr/local/redis/src/redis-server /usr/local/redis/redis.conf
/usr/local/redis/src/redis-cli
3、主redis服務器210通過客戶端查看信息，提示需要密碼認證，輸入命令“auth 1111”，可以查看信息角色：master，連接的slaves主機數量，slave主機信息等。
info replication
auth 1111
info replication
4、從redis服務器220通過客戶端可以查看角色：slave，連接的master主機IP、端口，master主機的連接狀態等。up表示主從已連接，可以同步。
info replication
5、主redis服務器210，修改key的值。
set key 77777777
6、從redis服務器220也可查到同樣的值，證明同步正常工作。
get key
四、主從複製同步必要性
-
雖然redis有持久化機制，但是有時redis服務器重啓也會丟失數據，因爲redis重啓後會將硬盤中的數據恢復到內存中。但是當redis服務器的硬盤損壞了，可能就會導致數據丟失。如果通過redis的主從複製就能很好的避免這種單點故障。
-
當主redis數據庫有兩個從redis服務器，即使其中一臺服務器宕機，其他兩臺服務器照樣可以正常工作。主從redis保持實時同步，當主redis寫入數據時，通過主從複製機制會將數據複製到兩個從redis服務器上。
-
只有一個主redis，但可以有多個從redis。主從複製不會阻塞主redis，在同步數據時，主redis可以繼續處理客戶端的請求。
五、主從同步複製過程說明
1、slave服務啓動後主動建立和master服務的聯繫，發送sync同步命令。
2、master啓動一個後臺進程將數據鏡像保存到rdb文件中，此時如果生成rdb文件過程中存在寫數據操作，將會導致rdb文件和當前master數據不一致，所以此時master主進程會開始收集寫命令並緩存起來。
3、master發送rdb文件給slave。
4、slave將rdb文件保存在磁盤中，加載到內存中恢復。
5、master把寫命令的緩存轉發給slave。後續master收到的寫命令會通過之前建立的連接發送給slave，當主從連接斷開時slave會自動重新建立連接。如果master同時收到多個slave發來的sync命令時，只啓動一個進程寫數據鏡像，發送給多個slave。
6、redis2.8之前slave每次同步會從master複製全部數據，如果首次同步當然沒問題。但是如果slave停止工作，再次啓動時可能只有少量數據不同步，這時slave又要從master複製全部數據，這樣性能肯定沒有隻複製那一小部分未同步的數據快。
7、redis2.8之後使用部分複製機制，當slave連接master時，主動發送psync命令，slave提供master的runid（機器標示，隨機生成）和offset（數據偏移量），master驗證rundi和offset是否有效，如果master驗證runid未通過，則slave進行全同步（首次同步），驗證通過則說明slave曾與master同步過，此時根據offset同步部分數據即可。
六、持久化方式
redis提供了兩種數據備份的方式rdb和aof。
| 持久化方式 | rdb | aof |
|---|---|---|
| 默認狀態 | 默認開啓；把redis.conf中所有的save註釋即可關閉 | 默認關閉，在redis.conf中設爲 appendonly yes即是開啓了aof； |
| 同步機制 | 滿足條件觸發同步，即可以指定某個時間內發生多少個命令時進行同步 | 每秒同步或者每次發生命令後同步 |
| 存儲內容 | 存儲的是Redis裏具體的值 | 存儲的是執行更新操作的命令 |
| 存儲文件的路徑 | 根據dir以及dbfilenname來指定路徑和具體的文件名 | 根據dir以及appendfilename來指定具體的路徑和文件名 |
| 優點 | 存儲數據文件時會進行壓縮，文件體積比aof小；在恢復的時候速度比aof快；非常適合備份用。 | aof策略的備份機制是每秒或者每發生寫操作的時候都會同步，因此即使服務器故障，最多隻會丟失1秒的數據；aof存儲的是redis命令，並且是直接追加到aof文件後面，因此每次備份的時候只要添加新的數據進去就可以了；如果aof文件比較大了，那麼Redis會進行重寫，只保留最小的命令集合。 |
| 缺點 | rdb在滿足觸發條件纔會觸發同步機制，rdb在同步的時候都重新保存整個Redis中的數據，在這種情況下，一旦服務器故障，會造成這段時間的數據丟失；在數據保存進rdb的時候，redis會fork出一個子進程用來同步，在數據量比較大的時候，可能非常耗時。 | aof文件因爲沒有壓縮，因此比rdb體積大；aof是在每秒或者每次寫操作都進行備份，因此如果併發量比較大，效率可能會有點慢；aof文件因爲存儲的是命令，因此在災難恢復的時候Redis會重新運行aof中的命令，因此恢復速度比不上rdb。 |
| rdb持久化參數 | 介紹 |
|---|---|
| save 900 1 | 900秒和至少1個鍵改變纔會被保存 |
| save 300 10 | 300秒和至少10個鍵改變纔會被保存 |
| save 60 10000 | 60秒和至少10000個鍵改變纔會被保存 |
| stop-writes-on-bgsave-error yes | 錯誤發生時停止寫入 |
| rdbcompression yes | 啓用壓縮 |
| rdbchecksum yes | 檢驗 |
| dbfilename dump.rdb | rdb文件名 |
| dir /var/lib/redis | rdb文件保存路徑 |
| AOF持久化參數 | 說明 |
|---|---|
| appendonly no | 不啓用aof持久化。若啓動aof持久化，只要修改爲appendonly yes即可。 |
| auto-aof-rewrite-percentage 100 | 當aof文件的大小增張了指定比例的時候，執行一次重寫操作。 |
| auto-aof-rewrite-min-size 64mb | 設定aof文件重寫操作最小值。 |
| appendfilename “appendonly.aof” | aof持久化信息保存在哪個文件中。 |
| appendfsync always | 一旦執行了操作，會立刻將操作的語句記錄到aof文件中。 |
| appendfsync everysec | 每秒向aof文件進行一次寫入操作。 |
| appendfsync no | 不主動向aof執行寫入操作，由系統自行判斷何時向磁盤執行寫入操作。 |