以下是关于 Redis 复制功能的几个重要方面: |
| | |
| | +- Redis 使用异步复制。 |
| | + 从 Redis 2.8 开始, |
| | + 从服务器会以每秒一次的频率向主服务器报告复制流(replication stream)的处理进度。 |
| | + |
| | - 一个主服务器可以有多个从服务器。 |
| | |
| | - 不仅主服务器可以有从服务器, |
| @@ -76,8 +80,43 @@ Redis 支持简单且易用的主从复制(master-slave replication)功能 |
| | 就可以处理所有这些从服务器的同步请求。 |
| | |
| | 从服务器可以在主从服务器之间的连接断开时进行自动重连, |
| | -在重连成功之后, |
| | -从服务器需要重新执行一次完整的重同步(resync)操作。 |
| | +在 Redis 2.8 版本之前, |
| | +断线之后重连的从服务器总要执行一次完整重同步(full resynchronization)操作, |
| | +但是从 Redis 2.8 版本开始, |
| | +从服务器可以根据主服务器的情况来选择执行完整重同步还是部分重同步(partial resynchronization)。 |
| | + |
| | + |
| | +部分重同步 |
| | +---------------------------------------- |
| | + |
| | +从 Redis 2.8 开始, |
| | +在网络连接短暂性失效之后, |
| | +主从服务器可以尝试继续执行原有的复制进程(process), |
| | +而不一定要执行完整重同步操作。 |
| | + |
| | +这个特性需要主服务器为被发送的复制流创建一个内存缓冲区(in-memory backlog), |
| | +并且主服务器和所有从服务器之间都记录一个复制偏移量(replication offset)和一个主服务器 ID (master run id), |
| | +当出现网络连接断开时, |
| | +从服务器会重新连接, |
| | +并且向主服务器请求继续执行原来的复制进程: |
| | + |
| | +- 如果从服务器记录的主服务器 ID 和当前要连接的主服务器的 ID 相同, |
| | + 并且从服务器记录的偏移量所指定的数据仍然保存在主服务器的复制流缓冲区里面, |
| | + 那么主服务器会向从服务器发送断线时缺失的那部分数据, |
| | + 然后复制工作可以继续执行。 |
| | + |
| | +- 否则的话, |
| | + 从服务器就要执行完整重同步操作。 |
| | + |
| | +Redis 2.8 的这个部分重同步特性会用到一个新增的 ``PSYNC`` 内部命令, |
| | +而 Redis 2.8 以前的旧版本只有 :ref:`SYNC` 命令, |
| | +不过, |
| | +只要从服务器是 Redis 2.8 或以上的版本, |
| | +它就会根据主服务器的版本来决定到底是使用 ``PSYNC`` 还是 :ref:`SYNC` : |
| | + |
| | +- 如果主服务器是 Redis 2.8 或以上版本,那么从服务器使用 ``PSYNC`` 命令来进行同步。 |
| | + |
| | +- 如果主服务器是 Redis 2.8 之前的版本,那么从服务器使用 :ref:`SYNC` 命令来进行同步。 |
| | |
| | |
| | 配置 |
| @@ -136,7 +175,7 @@ Redis 支持简单且易用的主从复制(master-slave replication)功能 |
| | 从而实现故障转移(failover)策略。 |
| | |
| | |
| | -设置从服务器,让它通过主服务器的身份验证 |
| | +从服务器相关配置 |
| | ----------------------------------------------- |
| | |
| | 如果主服务器通过 ``requirepass`` 选项设置了密码, |
| @@ -156,3 +195,55 @@ Redis 支持简单且易用的主从复制(master-slave replication)功能 |
| | :: |
| | |
| | masterauth <password> |
| | + |
| | +另外还有几个选项, |
| | +它们和主服务器执行部分重同步时所使用的复制流缓冲区有关, |
| | +详细的信息可以参考 Redis 源码中附带的 ``redis.conf`` 示例文件。 |
| | + |
| | + |
| | +主服务器只在有至少 N 个从服务器的情况下,才执行写操作 |
| | +------------------------------------------------------- |
| | + |
| | +从 Redis 2.8 开始, |
| | +为了保证数据的安全性, |
| | +可以通过配置, |
| | +让主服务器只在有至少 N 个当前已连接从服务器的情况下, |
| | +才执行写命令。 |
| | + |
| | +不过, |
| | +因为 Redis 使用异步复制, |
| | +所以主服务器发送的写数据并不一定会被从服务器接收到, |
| | +因此, |
| | +数据丢失的可能性仍然是存在的。 |
| | + |
| | +以下是这个特性的运作原理: |
| | + |
| | +- 从服务器以每秒一次的频率 PING 主服务器一次, |
| | + 并报告复制流的处理情况。 |
| | + |
| | +- 主服务器会记录各个从服务器最后一次向它发送 PING 的时间。 |
| | + |
| | +- 用户可以通过配置, |
| | + 指定网络延迟的最大值 ``min-slaves-max-lag`` , |
| | + 以及执行写操作所需的至少从服务器数量 ``min-slaves-to-write`` 。 |
| | + |
| | +如果至少有 ``min-slaves-to-write`` 个从服务器, |
| | +并且这些服务器的延迟值都少于 ``min-slaves-max-lag`` 秒, |
| | +那么主服务器就会执行客户端请求的写操作。 |
| | + |
| | +你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本: |
| | +尽管不能保证写操作的持久性, |
| | +但起码丢失数据的窗口会被严格限制在指定的秒数中。 |
| | + |
| | +另一方面, |
| | +如果条件达不到 ``min-slaves-to-write`` 和 ``min-slaves-max-lag`` 所指定的条件, |
| | +那么写操作就不会被执行, |
| | +主服务器会向请求执行写操作的客户端返回一个错误。 |
| | + |
| | +以下是这个特性的两个选项和它们所需的参数: |
| | + |
| | +- ``min-slaves-to-write <number of slaves>`` |
| | + |
| | +- ``min-slaves-max-lag <number of seconds>`` |
| | + |
| | +详细的信息可以参考 Redis 源码中附带的 ``redis.conf`` 示例文件。 |