0、Redis目錄結構
5）Redis高可用之哨兵模式Sentinel配置與啟動（五）
一、介紹
1、Redis的高可用有如下幾個部分組成：
第一部分：redis主從復制
第二部分：Sentinel哨兵模式
第三部分：集群部署
本篇將介紹第一部分-redis 主從復制。那么問題來了，為什么需要主從復制呢？
2、為什么需要主從復制呢？
從以下三點說明：
A、redis單機一旦故障，可用通過從服務器上進行恢復數據；
B、redis要達到高可用、高並發，只有單個redis是不夠的，單個redis也就只能支持幾萬的QPS，所以必須以集群的形式提供服務，而集群中又以多個主從組成。
C、主從是以多個redis集合在一起，以一個master多個slave為模式對外提供服務，master主要以寫為主，slave提供讀，即是讀寫分離的情況，以讀多寫少為准。比如電商網站中的商品，讀的多，寫的少。
如果上面三點還不懂，沒關系，我說明一下 單機redis 的問題：
A、機器故障
B、容量瓶頸
C、QPS瓶頸
這個也是我們在互聯網產品中經常會遇到的問題。
3、那么主從復制的原理是什么呢？
上面已經說明了為什么需要主從復制，那么其內部的原理是什么呢？我在最下面配置的時候也通過了日志來解釋這一切
主要分為全量同步和增量同步
4、主從復制的特性是什么呢？
1) 一個master可以有多個slave；
2) 一個slave只能有一個master；
3) 數據流是單向的,master到slave；
4) 主從復制底層依賴與RDB方式進行全量復制。
注意說明：
針對與RDB方式保存有分為 save 和 bgsave 命令，兩者的區別在於save為同步保存，即存在阻塞；而bgsave為異步保存，非阻塞。
在上面原理中有給出redis主從復制采用的是bgsave的方式，如若不清楚也可以看下面log日志中的內容。
二、Redis主從復制
1、環境配置
第一：准備3台服務器，一台master ，兩台 slave
| 主機說明 | 主機IP | 端口 |
| master | 192.168.250.132
|
7000 |
| slave | 192.168.250.133 | 7001 |
| slave | 192.168.250.134 |
7002 |
第二：每台服務器安裝redis版本保持一致
安裝教程傳送門：《Redis介紹及部署在CentOS7上（一）》
環境都准備完畢，現在就可以開始配置啦。
2、Redis主從復制配置
第一：進入132 服務器的redis目錄下
新建一個redis配置文件，以下內容大家可自行擴展，這邊說明一點就是數據持久化我這邊采用AOF，這也是官方推薦的，效率高，而且持久化是必須的，如果沒有持久化則數據容易丟失。如果想了解redis的持久化，可以看我另外一篇文章《Redis客戶端連接及持久化配置（三）》。
文件名 redis-7000.conf
daemonize yes port 7000 logfile 7000.log dir ./ requirepass 123
masterauth 123 # 132服務器配置masterauth作用主要是為了后期sentinel引入后重新選舉master並且7000端口redis重新加入主從復制時必備的，否則會出現權限不足 bind 192.168.250.132 127.0.0.1
# AOF 數據持久化 appendonly yes appendfilename aof-7000.aof appendfsync everysec no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
注意說明：為了安全
A、需要設置密碼，密碼必須復雜；
B、設置bind 的IP地址，此IP為redis服務器IP以及本地127，如果沒有設置 127，會出現無法啟動問題，沒有設置服務器IP會出現slave服務器無法連接master服務器。
第二：進入 133和134的服務器的redis目錄下
新建redis配置文件, 133服務器為 redis-7001.conf ,134 服務器為redis-7002.conf
port 7001 daemonize yes logfile 7001.log dir ./ requirepass 123 slaveof 192.168.250.132 7000 masterauth 123 bind 192.168.250.133 127.0.0.1 # AOF 數據持久化 appendonly yes appendfilename aof-7001.aof appendfsync everysec no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
注意說明：
A、slaveof 后面綁定的是master 服務器IP 和端口
B、需要設置master的密碼，否則在連接的時候會報 權限不足
C、設置slave 服務器的密碼強烈建議與master服務器上的密碼一致，因為這樣在后面的哨兵模式自動選出主服務器有很大的幫助，否則會報錯。
D、134服務器跟上面的配置一致，只是端口號不一樣。
配置完畢
第三：啟動132、133、134的redis
./src/redis-server redis-7000.conf
./src/redis-server redis-7001.conf
./src/redis-server redis-7002.conf
我們來通過日志分析一下，redis主從復制啟動的過程是怎么樣的吧。
我們從132master服務器的 7000.log 日志來進行講解。
說明：建議大家自行操作然后對照着下面的說明，有助於大家理解。
A、132啟動，然后133redis啟動會開始請求與133redis進行連接與數據同步，當134啟動也會進行數據同步；
B、並且同步的數據會默認保存在 dump.rdb 這個文件中，建議自行配置持久化方式，傳送門《Redis客戶端連接及持久化配置（三）》此處文章預計本周五之前發布；
C、然后 把134 redis 關閉，又重新啟動，然后132master服務器redis 關閉有啟動的一系列操作。
==================132redis啟動================================================
103398:C 08 Jan 2019 17:42:20.481 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 103398:C 08 Jan 2019 17:42:20.481 # Redis version=5.0.2, bits=64, commit=00000000, modified=0, pid=103398, just started 103398:C 08 Jan 2019 17:42:20.481 # Configuration loaded 103399:M 08 Jan 2019 17:42:20.482 * Increased maximum number of open files to 10032 (it was originally set to 1024). 103399:M 08 Jan 2019 17:42:20.483 * Running mode=standalone, port=7000. 103399:M 08 Jan 2019 17:42:20.483 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 103399:M 08 Jan 2019 17:42:20.483 # Server initialized 103399:M 08 Jan 2019 17:42:20.483 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. 103399:M 08 Jan 2019 17:42:20.483 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled. 103399:M 08 Jan 2019 17:42:20.483 * Ready to accept connections ==================133redis啟動開始請求同步======================================
103399:M 08 Jan 2019 17:44:56.213 * Replica 192.168.250.133:7001 asks for synchronization 103399:M 08 Jan 2019 17:44:56.213 * Full resync requested by replica 192.168.250.133:7001 # 主從復制 默認 RDB 持久化 103399:M 08 Jan 2019 17:44:56.213 * Starting BGSAVE for SYNC with target: disk 103399:M 08 Jan 2019 17:44:56.214 * Background saving started by pid 103768
103768:C 08 Jan 2019 17:44:56.216 * DB saved on disk 103768:C 08 Jan 2019 17:44:56.216 * RDB: 4 MB of memory used by copy-on-write 103399:M 08 Jan 2019 17:44:56.299 * Background saving terminated with success # 133 redis 數據同步成功 103399:M 08 Jan 2019 17:44:56.299 * Synchronization with replica 192.168.250.133:7001 succeeded ==================134redis啟動開始請求同步=======================================
103399:M 08 Jan 2019 17:45:25.389 * Replica 192.168.250.134:7002 asks for synchronization 103399:M 08 Jan 2019 17:45:25.389 * Full resync requested by replica 192.168.250.134:7002 # 主從復制 默認 RDB 持久化 103399:M 08 Jan 2019 17:45:25.389 * Starting BGSAVE for SYNC with target: disk 103399:M 08 Jan 2019 17:45:25.390 * Background saving started by pid 103858
103858:C 08 Jan 2019 17:45:25.391 * DB saved on disk 103858:C 08 Jan 2019 17:45:25.392 * RDB: 4 MB of memory used by copy-on-write 103399:M 08 Jan 2019 17:45:25.402 * Background saving terminated with success # 133 redis 數據同步成功 103399:M 08 Jan 2019 17:45:25.402 * Synchronization with replica 192.168.250.134:7002 succeeded ==================134redis關閉日志===============================================
103399:M 08 Jan 2019 17:51:13.850 # Connection with replica 192.168.250.134:7002 lost. ==================134redis重新啟動日志============================================
103399:M 08 Jan 2019 17:52:28.885 * Replica 192.168.250.134:7002 asks for synchronization 103399:M 08 Jan 2019 17:52:28.885 * Partial resynchronization request from 192.168.250.134:7002 accepted. Sending 588 bytes of backlog starting from offset 43. ==================132redis強制關閉================================================
103399:M 08 Jan 2019 17:54:06.369 # User requested shutdown... 103399:M 08 Jan 2019 17:54:06.369 * Removing the pid file. 103399:M 08 Jan 2019 17:54:06.369 # Redis is now ready to exit, bye bye... ==================132redis 主服務器再次上線，同步數據以及連接slave服務器===============
105223:M 08 Jan 2019 17:54:47.189 * Background saving terminated with success 105223:M 08 Jan 2019 17:54:47.189 * Synchronization with replica 192.168.250.133:7001 succeeded 105223:M 08 Jan 2019 17:54:47.807 * Replica 192.168.250.134:7002 asks for synchronization 105223:M 08 Jan 2019 17:54:47.807 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'd0ff33789382fccfe621d9ad03c26cc545bda3fa', my replication IDs are '00591a20c6cafe8f906632746d514e99213ee121' and '0000000000000000000000000000000000000000') 105223:M 08 Jan 2019 17:54:47.807 * Starting BGSAVE for SYNC with target: disk 105223:M 08 Jan 2019 17:54:47.808 * Background saving started by pid 105229
105229:C 08 Jan 2019 17:54:47.809 * DB saved on disk 105229:C 08 Jan 2019 17:54:47.809 * RDB: 4 MB of memory used by copy-on-write 105223:M 08 Jan 2019 17:54:47.894 * Background saving terminated with success 105223:M 08 Jan 2019 17:54:47.894 * Synchronization with replica 192.168.250.134:7002 succeeded
三、總結
1、slave服務器上面的數據都是從master服務器上同步的，一旦master掛掉，則slave服務器無法進行增量同步，假設某項目使用了slave服務器進行寫的操作，當master服務器開啟后，slave服務器會進行與master服務器進行
全量同步，這樣導致原先保存在slave上的數據丟失，當然這個例子是假設，一般slave只當做讀的操作。
2、如果master宕機后，如何保證redis還可以正常使用呢？則我們就需要引入Sentinel進行master的選擇啦。
3、通過以上的日志分析，我們基本上已經明白redis的主從復制啦。那么下一篇將會介紹 當redis 掛掉后自動選舉 主redis的哨兵模式Sentinel。
參考文章：
《Redis主從復制原理總結》：https://www.cnblogs.com/kevingrace/p/5685332.html
《Redis主從復制原理》：https://www.cnblogs.com/hepingqingfeng/p/7263782.html
asp.net core 交流群：787464275 歡迎加群交流
如果您認為這篇文章還不錯或者有所收獲，您可以點擊右下角的【推薦】按鈕精神支持，因為這種支持是我繼續寫作，分享的最大動力！
微信公眾號：歡迎關注 QQ技術交流群： 歡迎加群
