0、Redis目錄結構
1）
Redis介紹及部署在CentOS7上（一）2）
Redis指令與資料結構（二）3）
Redis用戶端連接配接以及持久化資料（三）4）
Redis高可用之主從複制實踐（四）5）
Redis高可用之哨兵模式Sentinel配置與啟動（五）6）Redis高可用之叢集配置（六）
一、介紹
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、那麼主從複制的原理是什麼呢？
上面已經說明了為什麼需要主從複制，那麼其内部的原理是什麼呢？我在最下面配置的時候也通過了日志來解釋這一切
主要分為全量同步和增量同步
A、 全量同步
Redis全量複制一般發生在Slave初始化階段，這時Slave需要将Master上的所有資料都複制一份。具體步驟如下：
1）從伺服器連接配接主伺服器，發送SYNC指令；
2）主伺服器接收到SYNC命名後，開始執行BGSAVE指令生成RDB檔案并使用緩沖區記錄此後執行的所有寫指令；
3）主伺服器BGSAVE執行完後，向所有從伺服器發送快照檔案，并在發送期間繼續記錄被執行的寫指令；
4）從伺服器收到快照檔案後丢棄所有舊資料，載入收到的快照；
5）主伺服器快照發送完畢後開始向從伺服器發送緩沖區中的寫指令；
6）從伺服器完成對快照的載入，開始接收指令請求，并執行來自主伺服器緩沖區的寫指令；
完成上面幾個步驟後就完成了從伺服器資料初始化的所有操作，從伺服器此時可以接收來自使用者的讀請求。
B、增量同步
Redis增量複制是指Slave初始化後開始正常工作時主伺服器發生的寫操作同步到從伺服器的過程。
增量複制的過程主要是主伺服器每執行一個寫指令就會向從伺服器發送相同的寫指令，從伺服器接收并執行收到的寫指令。
C、Redis主從同步政策
主從剛剛連接配接的時候，進行全量同步；全同步結束後，進行增量同步。當然，如果有需要，slave 在任何時候都可以發起全量同步。redis 政策是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。
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版本保持一緻
安裝教程傳送門：《
》
環境都準備完畢，現在就可以開始配置啦。
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 這個檔案中，建議自行配置持久化方式，傳送門
此處文章預計本周五之前釋出；
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 歡迎加群交流
如果您認為這篇文章還不錯或者有所收獲，您可以點選右下角的【推薦】按鈕精神支援，因為這種支援是我繼續寫作，分享的最大動力！
作者：
LouieGuo http://www.cnblogs.com/stulzq聲明：原創部落格請在轉載時保留原文連結或者在文章開頭加上本人部落格位址，如發現錯誤，歡迎批評指正。凡是轉載于本人的文章，不能設定打賞功能，如有特殊需求請與本人聯系！
微信公衆号：歡迎關注 QQ技術交流群： 歡迎加群
