在上一篇文章中谈了单机的 Redis 部署，你觉得单机部署的架构有什么问题吗？主从复制能够解决全部问题吗？
后文：Linux安装Redis（三）哨兵模式，分析流程和原理，详细图解
但我们还是回到本文的内容吧
本文谈到的内容主要是以下几点：
- 如何部署Redis主从复制（一主二从）
- 一些关于主从的问题模拟和思考
- 主从复制原理和工作流程
前文
所谓主从复制，就是以其中一台机器作为 master，并且以写为主，其他从服务器（Slave）则是以读为主，达到读写分离的效果，以来提高系统性能。从服务器的数据全部从主服务中复制同步而来。
当 master 数据变化的时候，自动将新的数据异步同步到其他Slave数据库
redis 官方文档：redis.io
主从复制它解决了什么问题？
其实这很好说吗，读写分离、容灾备份、数据备份、水平扩容支撑高并发等等，其实也蛮多的，但是也有一些不足之处，后面就知道啦
一、相关命令
其实主从分离是真的很简单，就改几个配置项就完事啦，和单机的没啥区别
也就这一句话，配置从库，不配置主库，从库变更一下配置文件，或者是输入几行命令就可以，主库则不需要动，和单机一样。
关于权限：
- 如果主库设置了密码，则从机需要验证密码
- master 如果配置了 requirepass 参数，需要密码登陆
- 那么slave就要配置masterauth 来设置校验密码，否则的话，master会拒绝slave的访问请求
基本操作命令
info replication: 可以查看复制节点的主从关系和配置信息replicaof 主库IP 主库端口：一般写入redis.conf配置文件内slaveof 主库IP 主库端口：每次与 master 断开之后，都需要重新连接，除非你配置进redis.conf 文件。- 在运行期间修改slave节点的信息，如果该数据库已经是某个主数据库的从数据库，那么会停止和原主数据的同步关系转而和新的主数据库库同步，重新建立联系。
slaveof no one：使当前数据库停止与其他数据库的同步，转为主数据库.
二、部署架构
我有三台虚拟机，分别是
192.168.208.128
192.168.208.129
192.168.208.130
准备部署的架构图为：
三、开始部署
1、前期准备：
三台虚拟机上都已经安装完Redis服务，这点不会可以去考古-->
三台虚拟机能够相互ping通，且开放相关的 redis 服务使用的端口或者是关闭防火墙。
关闭防火墙：
systemctl stop firewalld #三台都要关 或者开发相关的端口
配置主从复制，我们只需要修改从库的配置，不需要修改主机的配置。
replicaof 主库IP 主库端口 ：一般写入redis.conf配置文件内 slaveof 主库IP 主库端口：每次与 master 断开之后，都需要重新连接，除非你配置进redis.conf 文件。 在运行期间修改slave节点的信息，如果该数据库已经是某个主数据库的从数据库，那么会停止和原主数据的同步关系转而和新的主数据库库同步，重新建立联系。 slaveof no one：使当前数据库停止与其他数据库的同步，转为主数据库，自立为王。
2、修改配置文件：
我们重新cp 一份未动过的配置文件，一步一步来看，到底那些要进行配置
补充：从机就比主机多了第十步的一个操作，其余均相同，其他更详细的配置还是需要大家在生产环境中配置，例如aof的开启和关闭，同步时间是多长等等
大致步骤：
1、修改 daemonize 为yes
2、注释掉 bind 127.0.0.1
3、修改 protected-mode 为 no
4、指定 port 端口
其实很多时候在线的 redis 服务并不会开放默认的端口，而是会换成其他不常用的端口，来求得一定的安全性
5、指定工作目录
6、指定 pidfile 文件的名称
可改可不改，知道存在，万一要看了，知道在哪里可以看到
7、指定 logfile 文件名称
我这里指定的是我的地址哈~
8、指定 dump.rdb 文件名称（dbfilename）
9、requirepass 设置密码
主机配到这里就可以啦，下面的这个是从机才需要配置的。
10、配置访问主机的密码 masterauth 、 masterip、masterport
修改完后就是如下：
第二台从机也是一样的配置。
四、启动测试
先启动master，再陆续启动两台slave.
确定主机和从机都起来之后。
我们在主机上set 一个值，我们看有没有复制过去
另外也可以看一下从机的log日志，这边的主机我忘记配了，就没啦~ 感兴趣的话，自己去看一下主机的日志
查看服务器状态：
五、思考问题
你觉得上述这样的架构还存有一些什么问题吗？
1、当主机宕机之后，从机会自动变成主机吗？
- 答案是不会，这里木有人来操作啊~
2、从机宕机之后，再启动是从机还是主机？
- 如果是写入配置的方式，从机宕机后重启还是从机，如果是使用命令的方式，来建立主从服务的话，重启后则是主机。
3、主机宕机之后，从机可不可以成为另一台机器的从机？
- 可以，但需要人工干预，来输入相关命令，让该从机成为其他机器的从机。
4、主机宕机之后，我们可以让剩下的其中一台成为主机吗？
- 可以，但需要人工干预，在客户端执行
slave no one命令
六、薪火相传
如下图部署方式：
是什么意思呢？
就是当主机宕机的时候，192.168.208.129这台从机，在人工干预的情况下可以立马升级为主机，它下面跟随着两台从机，也可以继续提供读服务，而无需重新改向新的主机。
如果是按照之前的方式部署，如果主机宕机了，那么两台从机都只能提供读服务，需要人工干预将其中一台从机升级为主机，再手动将另外一台的从机改从向新的主机进行复制。（注意：如果要改变跟随的主机，是需要将slave的数据全部清除掉，然后再从新跟随的主机，重新开始复制，数据量比较大的情况，需要一定的时间）
配置是一样的，就是一台跟着一台，只是把跟随的主机变更了。
七、反客为主
我们之前就谈到了，如果主机宕机了，我们是可以手动让从机变更为主服务的，发送slave no one即可。
八、主从复制原理和工作流程
借鉴的一张图：
来源 Redis主从复制原理
- slave 第一次启动成功连接到 master 后会发送一个 sync 命令，首次全新连接 master，会自动进行一次完全同步（全量复制），slave自身原有数据会被 master 数据覆盖清除。
- master 节点收到 sync 命令后会开始在后台保存快照（即RDB持久化，主从复制时会触发RDB）同时收集所有接收到的用于修改数据集命令缓存起来，master 节点执行RDB持久化完后，master将rdb快照文件和所有缓存的命令发送到所有slave，以完成一次完全同步。
- 而slave服务在接收到数据库文件数据之后，将其存盘并加载到内存中，从而完成复制初始化。
- 在正常运行的过程中，主从双方要保持通信，主机会向从机发送心跳检测，心跳检测的默认时间为10秒，
repl-ping-replica-period 10 - 增量复制，除去第一次连接是全量复制以外，之后 master 继续将新的所有收集到的修改命令自动依次传给slave，完成同步。
- 从机下线，重连续传；
master会检查backlog里面的offset，master和slave都会保存一个复制的offset还有一个masterId,
offset是保存在backlog中的。master只会把已经复制的offset后面的数据复制给slave，类似断点续传。
缺点
1、复制具有延时性，并且因为所有的写操作都是现在Master 上操作，然后同步更新到 Slave 上，所以从 Master 同步到 Slave 机器上有一定的延迟，当系统很繁忙的时候，延迟问题会更严重，另外就是当 Slave 机器数量变多，复制次数变多也会使这个问题更加严重。
2、当 master 挂了的时候，并不会在 slave 节点中自动选举一个节点成为Master节点，从而导致redis服务只能读而不能写。
同时也意味着出现事故的时候，必须要有人工干预。
后文
如果仔细想想，主从复制的架构其实还是有很多问题的，比如不能够自动的进行故障转移，必须要人工干预，又或者是复制的延迟性等。
但不得不说，部署是极为简单的，机器资源要求也不高，在很多时候还是非常实用的，比如做容灾备份，数据备份等。
对啦，想不如做，看也不如做，感兴趣的话，我还是建议可以抽空试一试~
