只有光头才能变强
好的，今天我们要上铂金段位了，如果还没经历过青铜和白银和黄金阶段的，可以先去蹭蹭经验再回来：
这篇文章主要讲的是Redis主从复制。因为Redis集群的知识点有点多，所以铂金上分得要好几篇~
文本力求简单讲清每个知识点，希望大家看完能有所收获
一、主从架构 1.1为什么要主从架构Redis也跟关系型数据(MySQL)一样，如果有过多请求还是撑不住的。
因为Redis如果只有一台服务器的话，那随着请求越来越多：
Redis的内存是有限的，可能放不下那么多的数据
单台Redis支持的并发量也是有限的。
万一这台Redis挂了，所有的请求全走关系数据库了，那就更炸了。
显然，出现的上述问题是因为一台Redis服务器不够，所以多搞几台Redis服务器就可以了
为了实现我们服务的高可用性，可以将这几台Redis服务器做成是主从来进行管理
tip:Redis作者已将Master/Slave架构改名为Master/Replica
1.2主从架构的特点下面我们来看看Redis的主从架构特点：
主服务器负责接收写请求
从服务器负责接收读请求
从服务器的数据由主服务器复制过去。主从服务器的数据是一致的
主从架构的好处：
读写分离(主服务器负责写，从服务器负责读)
高可用(某一台从服务器挂了，其他从服务器还能继续接收请求，不影响服务)
处理更多的并发量(每台从服务器都可以接收读请求，读QPS就上去了)
主从架构除了上面的形式，也有下面这种的(只不过用得比较少)：
主从架构的特点之一：主服务器和从服务器的数据是一致的。
因为主服务器是能接收写请求的，主服务器处理完写请求，会做什么来保证主从数据的一致性呢？如果主从服务器断开了，过一阵子才重连，又会怎么处理呢？下面将会了解到这些细节~
在Redis中，用户可以通过执行SALVEOF命令或者设置salveof选项，让一个服务器去复制(replicate)另一个服务器，我们称呼被复制的服务器为主服务器(master)，而对主服务器进行复制的服务器则被称为从服务器(salve)
复制功能分为两个操作：
同步(sync)
将从服务器的数据库状态更新至主服务器的数据库状态
命令传播(command propagate)
主服务器的数据库状态被修改，导致主从服务器的数据库状态不一致，让主从服务器的数据库状态重新回到一致状态。
从服务器对主服务器的同步又可以分为两种情况：
初次同步：从服务器没有复制过任何的主服务器，或者从服务器要复制的主服务器跟上次复制的主服务器不一样。
断线后同步：处于命令传播阶段的主从服务器因为网络原因中断了复制，从服务器通过自动重连重新连接主服务器，并继续复制主服务器
在Redis2.8以前，断线后复制这部分其实缺少的只是部分的数据，但是要让主从服务器重新执行SYNC命令，这样的做法是非常低效的。(因为执行SYNC命令是把所有的数据再次同步，而不是只同步丢失的数据)
接下来我们来详细看看Redis2.8以后复制功能是怎么实现的：
2.1.1复制的前置工作首先我们来看一下前置的工作：
从服务器设置主服务器的IP和端口
建立与主服务器的Socket连接
发送PING命令(检测Socket读写是否正常与主服务器的通信状况)
身份验证(看有没有设置对应的验证配置)
从服务器给主服务器发送端口的信息，主服务器记录监听的端口
前面也提到了，Redis2.8之前，断线后同步会重新执行SYNC命令，这是非常低效的。下面我们来看一下Redis2.8之后是怎么进行同步的。
Redis从2.8版本开始，使用PSYNC命令来替代SYNC命令执行复制时同步的操作。