一、介绍
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技术交流群： 欢迎加群