多机数据库的实现

1.复制(slaveof命令)

例如，现在有两台redis服务器，地址为127.0.0.1:6379 和 127.0.0.1:6380,现在在6380端口这台机子执行命令:

127.0.0.1:6380>slaveof 127.0.0.1 6379
ok

那么127.0.0.1:6380将成为127.0.0.1:6379的从服务器,而服务器127.0.0.1:6379会成为127.0.0.1:6380的主服务器。

进行复制中的主从服务器双方的数据库将保存相同的数据，概念上将这种现象称为"数据库状态一致",或者简称'一致'。

1.1 旧版复制功能的实现

redis的复制功能分为同步和命令传播两个操作:

(1).同步操作就是将从服务器的数据库状态更新至主服务器当前所处的状态。

(2).命令传播操作用于在主服务器的数据库状态被修改，导致主从服务器的数据库状态出现不一致的时候，让主从状态重新回到一致状态。

同步的具体步骤如下:

1) 从服务器向主服务器发送sync命令

2) 收到sync命令的主服务器执行bgsave命令，在后台生成一个rdb文件，并使用一个缓冲区记录从现在开始执行的所有写命令。

3）当服务器的bgsave命令执行完毕后，主服务器会将rdb文件发送给从服务器，从服务器接受并载入rdb文件，将自己的数据库状态更新到主服务器执行bgsave时的数据库状态

4) 主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新到主服务器当前所在的状态。

命令传播详解：

通过上面的同步操作后，主从服务器的数据库状态达到了一致，但这种一致并不是一成不变的。假如主服务器执行了客户端发送的写命令，那么两者的状态不再一致。为了让主从服务器再次回到一致状态，主服务器需要对从服务器执行命令传播操作:主服务器会将自己执行的写命令，发送给从服务器执行，当从服务器执行了这个命令之后，主从服务器再次回到一致状态。

1.2 旧版复制功能的缺陷

在redis中，主从复制分为 初次复制 和 断线后复制 两种情况。

断线后复制就是 处于命令传播阶段的主从服务器因为网络原因而中断了复制，但是从服务器通过自动重连重新连上了主服务器，并继续复制主服务器。缺陷就在于 旧版复制功能虽然也能让主从服务器回到一致状态，但是效率很低。因为断线后重连，从服务器会向主服务器发送sync命令，重新接收并导入rdb文件，这就很耗时，做了一些无用功，因为rdb文件中很多键的数据从服务器中本来就有。

1.2 新版复制功能的实现

为了解决旧版断线后复制的低效率问题，redis从2.8版本开始，使用PSYNC命令代替原先的sync命令来执行复制时的同步操作。PSYNC命令具有完整重同步和部分重同步两种模式:

完整重同步用于处理初次复制的情况。而部分重同步用于断线后重复制的情况，当从服务器重连上主服务器时，如果条件允许，主服务器可以将从服务器连接断开期间执行的写命令发送给从服务器，从服务器执行后，重新回到一致状态。

1.2.1 部分重同步的实现

部分重同步由下面3个部分组成:

1.主服务器的复制偏移量和从服务器的复制偏移量

2.主服务器的复制积压缓冲区

3.服务器的运行ID

当主服务器在进行命令传播时，它不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区。复制积压缓冲区是主服务器维护的一个固定长度的先进先出(FIFO)队列，默认大小是1MB。所以之前说的如果条件允许就可以理解了，就是指如果从服务器重连后，offset偏移量之后的数据仍然存在于缓冲区中，那么执行部分重同步操作，反之执行完整重同步操作。

2.sentinel

3.集群 

原文地址：https://www.cnblogs.com/juin1058/p/11671873.html