redis-主从复制

复制

1. Redis 采用异步复制。从 Redis 2.8开始，从服务器会周期性地报告从复制流中处理的数据量。 一个主服务器可以拥有多个从服务器。
2. 从服务器可以接受其他从服务器的连接。除了连接多个从服务器到同一个主服务器，从服务器也可以连接到其他的从服务器，形成图状结构。
3. Redis 的复制在主服务器上是非阻塞的。 这意味着，当一个或多个从服务器执行初始化同步(initial synchronization)时，主服务器能继续处理请求。
4. Redis 的复制在从服务器上也是非阻塞的。
5. redis.conf 中进行了相应配置，也能够继续使用旧版本的数据集处理请求。另外，你还可以配置当复制流宕(dowm)掉的时候，从服务器返回给客户端一个错误。然而，初始化同步结束后，旧的数据集需要被删除，新的数据集需要被载入。在这个简短的窗口期内，从服务器会阻塞到来的连接。
6. 复制可以用来支持可伸缩性，用多个从服务器处理只读查询(例如，繁重的 SORT 操作可以分配到从服务器上)，也可以仅仅作为数据冗余。
7. 可以使用复制来避免主服务器将全部数据集写到磁盘的开销：只需要配置你的主服务器的 redis.conf 来防止保存(所有的” 保存” 指令)，然后连接一个不断复制的从服务器。但是，这种设置下要确保主服务器不会自动重启(阅读下一节获取更多信息)。

主服务器关闭持久化时的安全性(Safety of replication)

当使用了 Redis 的复制时，强烈建议在主服务器上开启持久化，或者，当不可能开启持久化时，例如由于关注延迟，实例应该被配置为避免自动重启。
为了更好的理解为什么关闭了持久化的主服务器被配置为自动重启是很危险的，查看下面的失败模型，数据从主服务器以及其所有从服务器上被清除：

1. 我们设置节点 A 作为主服务器，关闭了持久化，节点 B 和节点 C 从节点 A 复制。
2. A 崩溃了，但是它拥有某个自动重启系统，重启了这个进程。但是，由于持久化是被关闭的，这个节点以空的数据集重启。
3. 节点 B 和节点 C 从空的 A 复制，于是它们完全销毁了他们的数据拷贝。

当 Redis Sentinel 被用于高可用时，主服务器关闭了持久化，并开启了进程重启也是很危险的。例如，主务器非常快速的重启，以至于 Sentinel 没有检测到失败，于是上面描述的失败模型就发生了。

任何时刻数据安全都是很重要的，要禁止主服务器配置为关闭持久化并自动重启。

Redis 复制如何工作(How works)

1. 当你建立一个从服务器，连接时就会发送一个 SYNC 命令。不管是第一次连接上还是重连接上。
2. 然后主服务器开始在后台保存，并且开始缓冲所有新收到的会修改数据集的命令。当后台保存完成以后，主服务器传输数据库文件给从服务器，从服务器将其保存到磁盘上，然后加载到内存中。然后主服务器开始发送缓冲的命令给从服务器。这是通过命令流完成的，和 Redis 的协议是一样的格式。

你可以用 telnet 试试。连上一台正在工作的 Redis 的端口，然后发送 SYNC 命令。你会看到大量的传输，还有主服务器收到的每条命令被重新发送给了 telnet 会话。

当主从链路由于某些原因断开时，从服务器可以自动重连。如果主服务器收到多个并发的从服务器的同步请求，只会执行一个后台保存来服务所有从服务器。

当主服务器和从服务器断开后重连上，总是执行一次完整重同步(full resynchronization)。然而，从 Redis 2.8 以后，可以选择执行部分重同步(partial resynchronization)。

部分重同步(partial resynchronization)

从 Redis 2.8 开始，在复制链接断开后，主服务器和从服务器通常可以继续复制过程，而不需要一次完整的重同步。
这是通过在主服务器上创建一个复制流的内存缓冲区(in-memory backlog)实现的。主服务器和所有从服务器都记录一个复制偏移量(offset)和一个主服务器运行 ID(run id)，当链接断掉时，从服务器会重连接，并且请求主服务器继续复制。假设主服务器的运行 ID 还是一样的，并且指定的偏移量在复制缓冲区中可用，复制会从中断的点继续。如果这两个条件之一不满足，将会执行完整重同步(2.8 版之前的正常行为)。

新的部分重同步特性使用的是内部 PSYNC命令，老的实现采用的是SYNC 命令。注意，Redis 2.8 的从服务器可以检测主服务器是否不支持 PSYNC，然后使用 SYNC 代替。

无盘复制(Diskless replication)

通常，一次完整的重同步需要在磁盘上创建一个 RDB 文件，然后从磁盘重新加载同一个 RDB 来服务从服务器。

由于低速的磁盘，这对主服务器来说是很大压力的操作。Redis 2.8.18 版本是第一个对无盘复制提供试验性支持的版本。在这种设置下，子进程直接通过线路(wire)发送 RDB 文件给从服务器，而不需要使用磁盘作为中间存储。

配置(Configuration)

配置复制简直小菜一碟：只需要添加下面一行到从服务器配置文件：

slaveof  192.168.1.1  6379  

当然，你得把 192.168.1.1 6379 替换成你自己的主服务器 IP 地址(或主机名)和端口。或者，你可以调用 SLAVEOF 命令和主服务器主机，开始与从服务器的一次同步。

有很多参数可以用来调整执行部分重同步主服务器的上的内存复制缓冲区。可以看看 Redis 发布版本中自带的样例文件 redis.conf 以获取更多的信息。

只读从服务器(Read-only slave)

从 Redis 2.6 开始，从服务器支持默认开启的只读模式。这个行为由 redis.conf 文件中的 slave-read-only 选项控制，可以在运行时使用 CONFIG SET 来开启和关闭。

只读从服务器会拒绝所有写命令，所以写入数据到从服务器只会引起错误。这并不意味着，这个特性打算暴露从服务器实例到互联网，或者到网络中不信任的客户端，因为诸如 DEBUG 和 CONFIG 这样的管理命令等仍可用。但是，可以通过在 redis.conf 中使用 rename-command 指令来禁止命令，从而改进只读实例的安全性。

你可能很好奇，为什么需要能够反转只读设置，使得从服务器实例能够成为写操作的目标。尽管这些写入的数据会在从服务器和主服务器重同步时，或者从服务器重启时被丢弃，还是有一些存储一些短暂的数据到可写的从服务器的合理场景。例如，客户端可以存储一些主服务器的可达性信息来调整故障转移(failover)策略。

认证主服务器(Authenticate to a master)

如果你的主服务器通过 requirepass 而有一个密码，很容易配置从服务器在所有同步操作中使用这个密码。

要做到这个，在一个运行的实例上，使用 redis-cli 并键入：

config  set  masterauth    

要永久设置这个，添加这个倒你的配置文件中：

masterauth    

N 个副本才能写(Allow writes only with N attached replicas)

从 Redis 2.8 开始，可以设置 Redis 主服务器在当前至少拥有 N 个从服务器的连接的情况下，才能接受写请求。

然而，由于 Redis 使用异步复制，不能保证从服务器真正收到了一个给定的写请求，于是总是有一个数据丢失的窗口期。

下面是这个特性是如何运作的：

• Redis 从服务器每秒种 ping 主服务器，上报处理完的复制流的数据量。
• Redis 主服务器记录上一次从每一个从服务收到 ping 的时间。
• 用户可以配置最小从服务器数量，每台从服务器拥有一个不大于最大秒数的滞后(lag)。

如果有至少 N 个小于 M 秒滞后的从服务器，写请求才会被接受。

你可能会认为这个像 CAP 理论中较宽松版本的”C”，不能保证指定写的一致性，但是至少数据丢失的时间窗口被限制在一个指定的秒数内。

如果条件不满足，主服务器会返回一个错误，并且不会接受写请求。

这个特性有两个配置参数：

min-slaves-to-write    
min-slaves-max-lag    

请查看随 Redis 源码发布版本自带的 redis.conf 文件获取更多信息。