一、介紹

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、我們可以使用一主多從的模式等，如下

當然為了高可用我們可以使用哨兵模式Sentinel

 好了我們話不多說，開始我們的redis主從複製配置吧。

二、Redis主從複製

1、環境配置

第一：準備3臺伺服器，一臺master ，兩臺 slave

第二：每臺伺服器安裝redis版本保持一致

安裝教程傳送門：《Redis介紹及部署在CentOS7上（一）》

環境都準備完畢，現在就可以開始配置啦。

2、Redis主從複製配置

第一：進入132 伺服器的redis目錄下

新建一個redis配置檔案，以下內容大家可自行擴充套件，如 持久化等內容。此處檔名 redis-7000.conf

daemonize yes
port 
 
7000
logfile 7000.log
dir ./
requirepass 123
bind 192.168.250.132 127.0.0.1

注意說明：為了安全

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

注意說明：

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

通過以上的日誌分析，我們基本上已經明白redis的主從複製啦。那麼下一篇將會介紹 當redis 掛掉後自動選舉 主redis的哨兵模式Sentinel。

我的部落格即將入駐“雲棲社群”，誠邀技術同仁一同入駐。

asp.net core 交流群：787464275 歡迎加群交流
如果您認為這篇文章還不錯或者有所收穫，您可以點選右下角的【推薦】按鈕精神支援，因為這種支援是我繼續寫作，分享的最大動力！

微信公眾號：歡迎關注                                                 QQ技術交流群： 歡迎加群