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

3、总结

一、slave服务器上面的数据都是从master服务器上同步的，一旦master挂掉，则slave服务器没法进行增量同步，假设某项目使用了slave服务器进行写的操做，当master服务器开启后，slave服务器会进行与master服务器进行

全量同步，这样致使原先保存在slave上的数据丢失，固然这个例子是假设，通常slave只当作读的操做。

二、若是master宕机后，如何保证redis还能够正常使用呢？则咱们就须要引入Sentinel进行master的选择啦。

三、经过以上的日志分析，咱们基本上已经明白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技术交流群： 欢迎加群