一、主从架构

1.1为什么要主从架构

Redis也跟关系型数据(MySQL)一样，如果有过多请求还是撑不住的。

                                                   一台Redis撑不住

因为Redis如果只有一台服务器的话，那随着请求越来越多：

• Redis的内存是有限的，可能放不下那么多的数据
• 单台Redis支持的并发量也是有限的。
• 万一这台Redis挂了，所有的请求全走关系数据库了，那就更炸了。

显然，出现的上述问题是因为一台Redis服务器不够，所以多搞几台Redis服务器就可以了

                                             多搞几台Redis服务器

为了实现我们服务的高可用性，可以将这几台Redis服务器做成是主从来进行管理

                                                            主从架构

tip:Redis作者已将Master/Slave架构改名为Master/Replica

1.2主从架构的特点

下面我们来看看Redis的主从架构特点：

• 主服务器负责接收写请求
• 从服务器负责接收读请求
• 从服务器的数据由主服务器复制过去。主从服务器的数据是一致的

                                                        主从架构特点

主从架构的好处：

• 读写分离(主服务器负责写，从服务器负责读)
• 高可用(某一台从服务器挂了，其他从服务器还能继续接收请求，不影响服务)
• 处理更多的并发量(每台从服务器都可以接收读请求，读QPS就上去了)

主从架构除了上面的形式，也有下面这种的(只不过用得比较少)：

                                               从服务器又挂着从服务器

二、复制功能

主从架构的特点之一：主服务器和从服务器的数据是一致的。

因为主服务器是能接收写请求的，主服务器处理完写请求，会做什么来保证主从数据的一致性呢？如果主从服务器断开了，过一阵子才重连，又会怎么处理呢？下面将会了解到这些细节~

在Redis中，用户可以通过执行SALVEOF命令或者设置salveof选项，让一个服务器去复制(replicate)另一个服务器，我们称呼被复制的服务器为主服务器(master)，而对主服务器进行复制的服务器则被称为从服务器(salve)

                                                                 复制

2.1复制功能的具体实现

复制功能分为两个操作：

• 同步(sync)

• 将从服务器的数据库状态更新至主服务器的数据库状态

• 命令传播(command propagate)

• 主服务器的数据库状态被修改，导致主从服务器的数据库状态不一致，让主从服务器的数据库状态重新回到一致状态。

                                                        主从数据一致性

从服务器对主服务器的同步又可以分为两种情况：

• 初次同步：从服务器没有复制过任何的主服务器，或者从服务器要复制的主服务器跟上次复制的主服务器不一样。
• 断线后同步：处于命令传播阶段的主从服务器因为网络原因中断了复制，从服务器通过自动重连重新连接主服务器，并继续复制主服务器

在Redis2.8以前，断线后复制这部分其实缺少的只是部分的数据，但是要让主从服务器重新执行SYNC命令，这样的做法是非常低效的。(因为执行SYNC命令是把所有的数据再次同步，而不是只同步丢失的数据)

接下来我们来详细看看Redis2.8以后复制功能是怎么实现的：

2.1.1复制的前置工作

首先我们来看一下前置的工作：

• 从服务器设置主服务器的IP和端口
• 建立与主服务器的Socket连接
• 发送PING命令(检测Socket读写是否正常与主服务器的通信状况)
• 身份验证(看有没有设置对应的验证配置)
• 从服务器给主服务器发送端口的信息，主服务器记录监听的端口