Redis高可用之主從複製實踐（四）

時間 2019-11-11

標籤 redis 用之主從複製實踐欄目 Redis 简体版

原文原文鏈接

0、Redis目錄結構

1）Redis介紹及部署在CentOS7上（一）html

2）Redis指令與數據結構（二）redis

3）Redis客戶端鏈接以及持久化數據（三）安全

4）Redis高可用之主從複製實踐（四）服務器

5）Redis高可用之哨兵模式Sentinel配置與啓動（五）微信

6）Redis高可用之集羣配置（六）數據結構

1、介紹

一、Redis的高可用有以下幾個部分組成：併發

第一部分：redis主從複製app

第二部分：Sentinel哨兵模式asp.net

第三部分：集羣部署異步

本篇將介紹第一部分-redis 主從複製。那麼問題來了，爲何須要主從複製呢？

二、爲何須要主從複製呢？

從如下三點說明：

A、redis單機一旦故障，可用經過從服務器上進行恢復數據；

B、redis要達到高可用、高併發，只有單個redis是不夠的，單個redis也就只能支持幾萬的QPS，因此必須以集羣的形式提供服務，而集羣中又以多個主從組成。

C、主從是以多個redis集合在一塊兒，以一個master多個slave爲模式對外提供服務，master主要以寫爲主，slave提供讀，便是讀寫分離的狀況，以讀多寫少爲準。好比電商網站中的商品，讀的多，寫的少。

若是上面三點還不懂，不要緊，我說明一下單機redis 的問題：

A、機器故障

B、容量瓶頸

C、QPS瓶頸

這個也是咱們在互聯網產品中常常會遇到的問題。

三、那麼主從複製的原理是什麼呢？

上面已經說明了爲何須要主從複製，那麼其內部的原理是什麼呢？我在最下面配置的時候也經過了日誌來解釋這一切

主要分爲全量同步和增量同步

A、全量同步

　　Redis全量複製通常發生在Slave初始化階段，這時Slave須要將Master上的全部數據都複製一份。具體步驟以下：

　　1）從服務器鏈接主服務器，發送SYNC命令；

　　2）主服務器接收到SYNC命名後，開始執行BGSAVE命令生成RDB文件並使用緩衝區記錄此後執行的全部寫命令；

　　3）主服務器BGSAVE執行完後，向全部從服務器發送快照文件，並在發送期間繼續記錄被執行的寫命令；

　　4）從服務器收到快照文件後丟棄全部舊數據，載入收到的快照；

　　5）主服務器快照發送完畢後開始向從服務器發送緩衝區中的寫命令；

　　6）從服務器完成對快照的載入，開始接收命令請求，並執行來自主服務器緩衝區的寫命令；

完成上面幾個步驟後就完成了從服務器數據初始化的全部操做，從服務器此時能夠接收來自用戶的讀請求。

B、增量同步

　　Redis增量複製是指Slave初始化後開始正常工做時主服務器發生的寫操做同步到從服務器的過程。

增量複製的過程主要是主服務器每執行一個寫命令就會向從服務器發送相同的寫命令，從服務器接收並執行收到的寫命令。

C、Redis主從同步策略

　　主從剛剛鏈接的時候，進行全量同步；全同步結束後，進行增量同步。固然，若是有須要，slave 在任什麼時候候均可以發起全量同步。redis 策略是，不管如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。

四、主從複製的特性是什麼呢？

1) 一個master能夠有多個slave；

2) 一個slave只能有一個master；

3) 數據流是單向的,master到slave；

4) 主從複製底層依賴與RDB方式進行全量複製。

注意說明：

針對與RDB方式保存有分爲 save 和 bgsave 命令，二者的區別在於save爲同步保存，即存在阻塞；而bgsave爲異步保存，非阻塞。

在上面原理中有給出redis主從複製採用的是bgsave的方式，如若不清楚也能夠看下面log日誌中的內容。

2、Redis主從複製

一、環境配置

第一：準備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上（一）》

環境都準備完畢，如今就能夠開始配置啦。

二、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服務器跟上面的配置一致，只是端口號不同。

配置完畢

第三：啓動13二、13三、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