Redis高可用之主从复制实践（四）

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版本保持一致

安装教程传送门：《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 欢迎加群交流
如果您认为这篇文章还不错或者有所收获，您可以点击右下角的【推荐】按钮精神支持，因为这种支持是我继续写作，分享的最大动力！

作者：LouieGuo

声明：原创博客请在转载时保留原文链接或者在文章开头加上本人博客地址，如发现错误，欢迎批评指正。凡是转载于本人的文章，不能设置打赏功能，如有特殊需求请与本人联系！

微信公众号：欢迎关注                                                 QQ技术交流群： 欢迎加群