首页手记从零单排学Redis【铂金一】

从零单排学Redis【铂金一】

标签：

Java Redis

前言

只有光头才能变强

好的，今天我们要上铂金段位了，如果还没经历过青铜和白银和黄金阶段的，可以先去蹭蹭经验再回来：

这篇文章主要讲的是Redis主从复制。因为Redis集群的知识点有点多，所以铂金上分得要好几篇~

文本力求简单讲清每个知识点，希望大家看完能有所收获

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

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

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

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

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

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

主从架构的好处：

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

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

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

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

复制功能分为两个操作：

同步(sync)
- 将从服务器的数据库状态更新至主服务器的数据库状态
命令传播(command propagate)
- 主服务器的数据库状态被修改，导致主从服务器的数据库状态不一致，让主从服务器的数据库状态重新回到一致状态。

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

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

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

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

前面也提到了，Redis2.8之前，断线后同步会重新执行SYNC命令，这是非常低效的。下面我们来看一下Redis2.8之后是怎么进行同步的。

Redis从2.8版本开始，使用PSYNC命令来替代SYNC命令执行复制时同步的操作。

PSYNC命令具有完整重同步和部分重同步两种模式(其实就跟上面所说的初次复制和断线后复制差不多个意思)。

下面先来看看完整重同步是怎么实现的：

从服务器向主服务器发送PSYNC命令
收到PSYNC命令的主服务器执行BGSAVE命令，在后台生成一个RDB文件。并用一个缓冲区来记录从现在开始执行的所有写命令。
当主服务器的BGSAVE命令执行完后，将生成的RDB文件发送给从服务器，从服务器接收和载入RBD文件。将自己的数据库状态更新至与主服务器执行BGSAVE命令时的状态。
主服务器将所有缓冲区的写命令发送给从服务器，从服务器执行这些写命令，达到数据最终一致性。