前言
本文转载自 Redis命令参考-功能文档
功能文档
Redis 集群规范
引言
这个文档是正在开发中的 Redis 集群功能的规范（specification）文档， 文档分为两个部分：
- 第一部分介绍目前已经在 unstable 分支中实现了的那些功能。
- 第二部分介绍目前仍未实现的那些功能。
文档各个部分的内容可能会随着集群功能的设计修改而发生改变， 其中， 未实现功能发生修改的几率比已实现功能发生修改的几率要高。
这个规范包含了编写客户端库（client library）所需的全部知识， 不过请注意， 这里列出的一部分细节可能会在未来发生变化。
什么是 Redis 集群？
Redis 集群是一个分布式（distributed）、容错（fault-tolerant）的 Redis 实现， 集群可以使用的功能是普通单机 Redis 所能使用的功能的一个子集（subset）。
Redis 集群中不存在中心（central）节点或者代理（proxy）节点， 集群的其中一个主要设计目标是达到线性可扩展性（linear scalability）。
Redis 集群为了保证一致性（consistency）而牺牲了一部分容错性： 系统会在保证对网络断线（net split）和节点失效（node failure）具有有限（limited）抵抗力的前提下， 尽可能地保持数据的一致性。
Note
集群将节点失效视为网络断线的其中一种特殊情况。
集群的容错功能是通过使用主节点（master）和从节点（slave）两种角色（role）的节点（node）来实现的：
- 主节点和从节点使用完全相同的服务器实现， 它们的功能（functionally）也完全一样， 但从节点通常仅用于替换失效的主节点。
- 不过， 如果不需要保证“先写入，后读取”操作的一致性（read-after-write consistency）， 那么可以使用从节点来执行只读查询。
Redis 集群实现的功能子集
Redis 集群实现了单机 Redis 中， 所有处理单个数据库键的命令。
针对多个数据库键的复杂计算操作， 比如集合的并集操作、合集操作没有被实现， 那些理论上需要使用多个节点的多个数据库键才能完成的命令也没有被实现。
在将来， 用户也许可以通过 MIGRATE COPY 命令， 在集群的计算节点（computation node）中执行针对多个数据库键的只读操作， 但集群本身不会去实现那些需要将多个数据库键在多个节点中移来移去的复杂多键命令。
Redis 集群不像单机 Redis 那样支持多数据库功能， 集群只使用默认的 0 号数据库， 并且不能使用 SELECT index 命令。
Redis 集群协议中的客户端和服务器
Redis 集群中的节点有以下责任：
- 持有键值对数据。
- 记录集群的状态，包括键到正确节点的映射（mapping keys to right nodes）。
- 自动发现其他节点，识别工作不正常的节点，并在有需要时，在从节点中选举出新的主节点。
为了执行以上列出的任务， 集群中的每个节点都与其他节点建立起了“集群连接（cluster bus）”， 该连接是一个 TCP 连接， 使用二进制协议进行通讯。
节点之间使用 Gossip 协议 来进行以下工作：
- 传播（propagate）关于集群的信息，以此来发现新的节点。
- 向其他节点发送 PING 数据包，以此来检查目标节点是否正常运作。
- 在特定事件发生时，发送集群信息。
除此之外， 集群连接还用于在集群中发布或订阅信息。
因为集群节点不能代理（proxy）命令请求， 所以客户端应该在节点返回 -MOVED 或者 -ASK 转向（redirection）错误时， 自行将命令请求转发至其他节点。
因为客户端可以自由地向集群中的任何一个节点发送命令请求， 并可以在有需要时， 根据转向错误所提供的信息， 将命令转发至正确的节点， 所以在理论上来说， 客户端是无须保存集群状态信息的。
不过， 如果客户端可以将键和节点之间的映射信息保存起来， 可以有效地减少可能出现的转向次数， 籍此提升命令执行的效率。
键分布模型
Redis 集群的键空间被分割为 16384 个槽（slot）， 集群的最大节点数量也是 16384 个。
Note
推荐的最大节点数量为 1000 个左右。
每个主节点都负责处理 16384 个哈希槽的其中一部分。
当我们说一个集群处于“稳定”（stable）状态时， 指的是集群没有在执行重配置（reconfiguration）操作， 每个哈希槽都只由一个节点进行处理。
Note
重配置指的是将某个/某些槽从一个节点移动到另一个节点。
Note
一个主节点可以有任意多个从节点， 这些从节点用于在主节点发生网络断线或者节点失效时， 对主节点进行替换。
以下是负责将键映射到槽的算法：
1 | HASH_SLOT = CRC16(key) mod 16384 |
以下是该算法所使用的参数：
- 算法的名称: XMODEM (又称 ZMODEM 或者 CRC-16/ACORN)
- 结果的长度: 16 位
- 多项数（poly）: 1021 (也即是 x16 + x12 + x5 + 1)
- 初始化值: 0000
- 反射输入字节（Reflect Input byte）: False
- 发射输出 CRC （Reflect Output CRC）: False
- 用于 CRC 输出值的异或常量（Xor constant to output CRC）: 0000
- 该算法对于输入 “123456789” 的输出: 31C3
附录 A 中给出了集群所使用的 CRC16 算法的实现。
CRC16 算法所产生的 16 位输出中的 14 位会被用到。
在我们的测试中， CRC16 算法可以很好地将各种不同类型的键平稳地分布到 16384 个槽里面。
集群节点属性
每个节点在集群中都有一个独一无二的 ID ， 该 ID 是一个十六进制表示的 160 位随机数， 在节点第一次启动时由 /dev/urandom 生成。
节点会将它的 ID 保存到配置文件， 只要这个配置文件不被删除， 节点就会一直沿用这个 ID 。
节点 ID 用于标识集群中的每个节点。 一个节点可以改变它的 IP 和端口号， 而不改变节点 ID 。 集群可以自动识别出 IP/端口号的变化， 并将这一信息通过 Gossip 协议广播给其他节点知道。
以下是每个节点都有的关联信息， 并且节点会将这些信息发送给其他节点：
- 节点所使用的 IP 地址和 TCP 端口号。
- 节点的标志（flags）。
- 节点负责处理的哈希槽。
- 节点最近一次使用集群连接发送 PING 数据包（packet）的时间。
- 节点最近一次在回复中接收到 PONG 数据包的时间。
- 集群将该节点标记为下线的时间。
- 该节点的从节点数量。
- 如果该节点是从节点的话，那么它会记录主节点的节点 ID 。 如果这是一个主节点的话，那么主节点 ID 这一栏的值为 0000000 。
以上信息的其中一部分可以通过向集群中的任意节点（主节点或者从节点都可以）发送 CLUSTER NODES 命令来获得。
以下是一个向集群中的主节点发送 CLUSTER NODES 命令的例子， 该集群由三个节点组成：
1 | $ redis-cli cluster nodes |
在上面列出的三行信息中， 从左到右的各个域分别是： 节点 ID ， IP 地址和端口号， 标志（flag）， 最后发送 PING 的时间， 最后接收 PONG 的时间， 连接状态， 节点负责处理的槽。
节点握手（已实现）
节点总是应答（accept）来自集群连接端口的连接请求， 并对接收到的 PING 数据包进行回复， 即使这个 PING 数据包来自不可信的节点。
然而， 除了 PING 之外， 节点会拒绝其他所有并非来自集群节点的数据包。
要让一个节点承认另一个节点同属于一个集群， 只有以下两种方法：
- 一个节点可以通过向另一个节点发送 MEET 信息， 来强制让接收信息的节点承认发送信息的节点为集群中的一份子。 一个节点仅在管理员显式地向它发送 CLUSTER MEET ip port 命令时， 才会向另一个节点发送 MEET 信息。
- 另外， 如果一个可信节点向另一个节点传播第三者节点的信息， 那么接收信息的那个节点也会将第三者节点识别为集群中的一份子。 也即是说， 如果 A 认识 B ， B 认识 C ， 并且 B 向 A 传播关于 C 的信息， 那么 A 也会将 C 识别为集群中的一份子， 并尝试连接 C 。
这意味着如果我们将一个/一些新节点添加到一个集群中， 那么这个/这些新节点最终会和集群中已有的其他所有节点连接起来。
这说明只要管理员使用 CLUSTER MEET 命令显式地指定了可信关系， 集群就可以自动发现其他节点。
这种节点识别机制通过防止不同的 Redis 集群因为 IP 地址变更或者其他网络事件的发生而产生意料之外的联合（mix）， 从而使得集群更具健壮性。
当节点的网络连接断开时， 它会主动连接其他已知的节点。
MOVED 转向
一个 Redis 客户端可以向集群中的任意节点（包括从节点）发送命令请求。 节点会对命令请求进行分析， 如果该命令是集群可以执行的命令， 那么节点会查找这个命令所要处理的键所在的槽。
如果要查找的哈希槽正好就由接收到命令的节点负责处理， 那么节点就直接执行这个命令。
另一方面， 如果所查找的槽不是由该节点处理的话， 节点将查看自身内部所保存的哈希槽到节点 ID 的映射记录， 并向客户端回复一个 MOVED 错误。
以下是一个 MOVED 错误的例子：
1 | GET x |
错误信息包含键 x 所属的哈希槽 3999 ， 以及负责处理这个槽的节点的 IP 和端口号 127.0.0.1:6381 。 客户端需要根据这个 IP 和端口号， 向所属的节点重新发送一次 GET key 命令请求。
注意， 即使客户端在重新发送 GET key 命令之前， 等待了非常久的时间， 以至于集群又再次更改了配置， 使得节点 127.0.0.1:6381 已经不再处理槽 3999 ， 那么当客户端向节点 127.0.0.1:6381 发送 GET key 命令的时候， 节点将再次向客户端返回 MOVED 错误， 指示现在负责处理槽 3999 的节点。
虽然我们用 ID 来标识集群中的节点， 但是为了让客户端的转向操作尽可能地简单， 节点在 MOVED 错误中直接返回目标节点的 IP 和端口号， 而不是目标节点的 ID 。
虽然不是必须的， 但一个客户端应该记录（memorize）下“槽 3999 由节点 127.0.0.1:6381 负责处理“这一信息， 这样当再次有命令需要对槽 3999 执行时， 客户端就可以加快寻找正确节点的速度。
注意， 当集群处于稳定状态时， 所有客户端最终都会保存有一个哈希槽至节点的映射记录（map of hash slots to nodes）， 使得集群非常高效： 客户端可以直接向正确的节点发送命令请求， 无须转向、代理或者其他任何可能发生单点故障（single point failure）的实体（entiy）。
除了 MOVED 转向错误之外， 一个客户端还应该可以处理稍后介绍的 ASK 转向错误。
集群在线重配置（live reconfiguration）
Redis 集群支持在集群运行的过程中添加或者移除节点。
实际上， 节点的添加操作和节点的删除操作可以抽象成同一个操作， 那就是， 将哈希槽从一个节点移动到另一个节点：
- 添加一个新节点到集群， 等于将其他已存在节点的槽移动到一个空白的新节点里面。
- 从集群中移除一个节点， 等于将被移除节点的所有槽移动到集群的其他节点上面去。
因此， 实现 Redis 集群在线重配置的核心就是将槽从一个节点移动到另一个节点的能力。 因为一个哈希槽实际上就是一些键的集合， 所以 Redis 集群在重哈希（rehash）时真正要做的， 就是将一些键从一个节点移动到另一个节点。
要理解 Redis 集群如何将槽从一个节点移动到另一个节点， 我们需要对 CLUSTER 命令的各个子命令进行介绍， 这些命理负责管理集群节点的槽转换表（slots translation table）。
以下是 CLUSTER 命令可用的子命令：
1 | CLUSTER ADDSLOTS slot1 [slot2] ... [slotN] |
最开头的两条命令 ADDSLOTS 和 DELSLOTS 分别用于向节点指派（assign）或者移除节点， 当槽被指派或者移除之后， 节点会将这一信息通过 Gossip 协议传播到整个集群。 ADDSLOTS 命令通常在新创建集群时， 作为一种快速地将各个槽指派给各个节点的手段来使用。
CLUSTER SETSLOT slot NODE node 子命令可以将指定的槽 slot 指派给节点 node 。
至于 CLUSTER SETSLOT slot MIGRATING node 命令和 CLUSTER SETSLOT slot IMPORTING node 命令， 前者用于将给定节点 node 中的槽 slot 迁移出节点， 而后者用于将给定槽 slot 导入到节点 node ：
当一个槽被设置为 MIGRATING 状态时， 原来持有这个槽的节点仍然会继续接受关于这个槽的命令请求， 但只有命令所处理的键仍然存在于节点时， 节点才会处理这个命令请求。
如果命令所使用的键不存在与该节点， 那么节点将向客户端返回一个 -ASK 转向（redirection）错误， 告知客户端， 要将命令请求发送到槽的迁移目标节点。
当一个槽被设置为 IMPORTING 状态时， 节点仅在接收到 ASKING 命令之后， 才会接受关于这个槽的命令请求。
如果客户端没有向节点发送 ASKING 命令， 那么节点会使用 -MOVED 转向错误将命令请求转向至真正负责处理这个槽的节点。
上面关于 MIGRATING 和 IMPORTING 的说明有些难懂， 让我们用一个实际的实例来说明一下。
假设现在， 我们有 A 和 B 两个节点， 并且我们想将槽 8 从节点 A 移动到节点 B ， 于是我们：
- 向节点 B 发送命令 CLUSTER SETSLOT 8 IMPORTING A
- 向节点 A 发送命令 CLUSTER SETSLOT 8 MIGRATING B
每当客户端向其他节点发送关于哈希槽 8 的命令请求时， 这些节点都会向客户端返回指向节点 A 的转向信息：
- 如果命令要处理的键已经存在于槽 8 里面， 那么这个命令将由节点 A 处理。
- 如果命令要处理的键未存在于槽 8 里面（比如说，要向槽添加一个新的键）， 那么这个命令由节点 B 处理。
这种机制将使得节点 A 不再创建关于槽 8 的任何新键。
与此同时， 一个特殊的客户端 redis-trib 以及 Redis 集群配置程序（configuration utility）会将节点 A 中槽 8 里面的键移动到节点 B 。
键的移动操作由以下两个命令执行：
1 | CLUSTER GETKEYSINSLOT slot count |
上面的命令会让节点返回 count 个 slot 槽中的键， 对于命令所返回的每个键， redis-trib 都会向节点 A 发送一条 MIGRATE host port key destination-db timeout [COPY] [REPLACE] 命令， 该命令会将所指定的键原子地（atomic）从节点 A 移动到节点 B （在移动键期间，两个节点都会处于阻塞状态，以免出现竞争条件）。
以下为 MIGRATE host port key destination-db timeout [COPY] [REPLACE] 命令的运作原理：
1 | MIGRATE target_host target_port key target_database id timeout |
执行 MIGRATE host port key destination-db timeout [COPY] [REPLACE] 命令的节点会连接到 target 节点， 并将序列化后的 key 数据发送给 target ， 一旦 target 返回 OK ， 节点就将自己的 key 从数据库中删除。
从一个外部客户端的视角来看， 在某个时间点上， 键 key 要么存在于节点 A ， 要么存在于节点 B ， 但不会同时存在于节点 A 和节点 B 。
因为 Redis 集群只使用 0 号数据库， 所以当 MIGRATE host port key destination-db timeout [COPY] [REPLACE] 命令被用于执行集群操作时， target_database 的值总是 0 。
target_database 参数的存在是为了让 MIGRATE host port key destination-db timeout [COPY] [REPLACE] 命令成为一个通用命令， 从而可以作用于集群以外的其他功能。
我们对 MIGRATE host port key destination-db timeout [COPY] [REPLACE] 命令做了优化， 使得它即使在传输包含多个元素的列表键这样的复杂数据时， 也可以保持高效。
不过， 尽管 MIGRATE host port key destination-db timeout [COPY] [REPLACE] 非常高效， 对一个键非常多、并且键的数据量非常大的集群来说， 集群重配置还是会占用大量的时间， 可能会导致集群没办法适应那些对于响应时间有严格要求的应用程序。
ASK 转向
在之前介绍 MOVED 转向的时候， 我们说除了 MOVED 转向之外， 还有另一种 ASK 转向。
当节点需要让一个客户端长期地（permanently）将针对某个槽的命令请求发送至另一个节点时， 节点向客户端返回 MOVED 转向。
另一方面， 当节点需要让客户端仅仅在下一个命令请求中转向至另一个节点时， 节点向客户端返回 ASK 转向。
比如说， 在我们上一节列举的槽 8 的例子中， 因为槽 8 所包含的各个键分散在节点 A 和节点 B 中， 所以当客户端在节点 A 中没找到某个键时， 它应该转向到节点 B 中去寻找， 但是这种转向应该仅仅影响一次命令查询， 而不是让客户端每次都直接去查找节点 B ： 在节点 A 所持有的属于槽 8 的键没有全部被迁移到节点 B 之前， 客户端应该先访问节点 A ， 然后再访问节点 B 。
因为这种转向只针对 16384 个槽中的其中一个槽， 所以转向对集群造成的性能损耗属于可接受的范围。
因为上述原因， 如果我们要在查找节点 A 之后， 继续查找节点 B ， 那么客户端在向节点 B 发送命令请求之前， 应该先发送一个 ASKING 命令， 否则这个针对带有 IMPORTING 状态的槽的命令请求将被节点 B 拒绝执行。
接收到客户端 ASKING 命令的节点将为客户端设置一个一次性的标志（flag）， 使得客户端可以执行一次针对 IMPORTING 状态的槽的命令请求。
从客户端的角度来看， ASK 转向的完整语义（semantics）如下：
- 如果客户端接收到 ASK 转向， 那么将命令请求的发送对象调整为转向所指定的节点。
- 先发送一个 ASKING 命令，然后再发送真正的命令请求。
- 不必更新客户端所记录的槽 8 至节点的映射： 槽 8 应该仍然映射到节点 A ， 而不是节点 B 。
一旦节点 A 针对槽 8 的迁移工作完成， 节点 A 在再次收到针对槽 8 的命令请求时， 就会向客户端返回 MOVED 转向， 将关于槽 8 的命令请求长期地转向到节点 B 。
注意， 即使客户端出现 Bug ， 过早地将槽 8 映射到了节点 B 上面， 但只要这个客户端不发送 ASKING 命令， 客户端发送命令请求的时候就会遇上 MOVED 错误， 并将它转向回节点 A 。
容错
节点失效检测
以下是节点失效检查的实现方法：
当一个节点向另一个节点发送 PING 命令， 但是目标节点未能在给定的时限内返回 PING 命令的回复时， 那么发送命令的节点会将目标节点标记为 PFAIL （possible failure，可能已失效）。
等待 PING 命令回复的时限称为“节点超时时限（node timeout）”， 是一个节点选项（node-wise setting）。
每次当节点对其他节点发送 PING 命令的时候， 它都会随机地广播三个它所知道的节点的信息， 这些信息里面的其中一项就是说明节点是否已经被标记为 PFAIL 或者 FAIL 。
当节点接收到其他节点发来的信息时， 它会记下那些被其他节点标记为失效的节点。 这称为失效报告（failure report）。
如果节点已经将某个节点标记为 PFAIL ， 并且根据节点所收到的失效报告显式， 集群中的大部分其他主节点也认为那个节点进入了失效状态， 那么节点会将那个失效节点的状态标记为 FAIL 。
一旦某个节点被标记为 FAIL ， 关于这个节点已失效的信息就会被广播到整个集群， 所有接收到这条信息的节点都会将失效节点标记为 FAIL 。
简单来说， 一个节点要将另一个节点标记为失效， 必须先询问其他节点的意见， 并且得到大部分主节点的同意才行。
因为过期的失效报告会被移除， 所以主节点要将某个节点标记为 FAIL 的话， 必须以最近接收到的失效报告作为根据。
在以下两种情况中， 节点的 FAIL 状态会被移除：
如果被标记为 FAIL 的是从节点， 那么当这个节点重新上线时， FAIL 标记就会被移除。
保持（retaning）从节点的 FAIL 状态是没有意义的， 因为它不处理任何槽， 一个从节点是否处于 FAIL 状态， 决定了这个从节点在有需要时能否被提升为主节点。
如果一个主节点被打上 FAIL 标记之后， 经过了节点超时时限的四倍时间， 再加上十秒钟之后， 针对这个主节点的槽的故障转移操作仍未完成， 并且这个主节点已经重新上线的话， 那么移除对这个节点的 FAIL 标记。
在第二种情况中， 如果故障转移未能顺利完成， 并且主节点重新上线， 那么集群就继续使用原来的主节点， 从而免去管理员介入的必要。
集群状态检测（已部分实现）
每当集群发生配置变化时（可能是哈希槽更新，也可能是某个节点进入失效状态）， 集群中的每个节点都会对它所知道的节点进行扫描（scan）。
一旦配置处理完毕， 集群会进入以下两种状态的其中一种：
- FAIL ： 集群不能正常工作。 当集群中有某个节点进入失效状态时， 集群不能处理任何命令请求， 对于每个命令请求， 集群节点都返回错误回复。
- OK ： 集群可以正常工作， 负责处理全部 16384 个槽的节点中， 没有一个节点被标记为 FAIL 状态。
这说明即使集群中只有一部分哈希槽不能正常使用， 整个集群也会停止处理任何命令。
不过节点从出现问题到被标记为 FAIL 状态的这段时间里， 集群仍然会正常运作， 所以集群在某些时候， 仍然有可能只能处理针对 16384 个槽的其中一个子集的命令请求。
以下是集群进入 FAIL 状态的两种情况：
- 至少有一个哈希槽不可用，因为负责处理这个槽的节点进入了 FAIL 状态。
- 集群中的大部分主节点都进入下线状态。当大部分主节点都进入 PFAIL 状态时，集群也会进入 FAIL 状态。
第二个检查是必须的， 因为要将一个节点从 PFAIL 状态改变为 FAIL 状态， 必须要有大部分主节点进行投票表决， 但是， 当集群中的大部分主节点都进入失效状态时， 单凭一个两个节点是没有办法将一个节点标记为 FAIL 状态的。
因此， 有了第二个检查条件， 只要集群中的大部分主节点进入了下线状态， 那么集群就可以在不请求这些主节点的意见下， 将某个节点判断为 FAIL 状态， 从而让整个集群停止处理命令请求。
从节点选举
一旦某个主节点进入 FAIL 状态， 如果这个主节点有一个或多个从节点存在， 那么其中一个从节点会被升级为新的主节点， 而其他从节点则会开始对这个新的主节点进行复制。
新的主节点由已下线主节点属下的所有从节点中自行选举产生， 以下是选举的条件：
- 这个节点是已下线主节点的从节点。
- 已下线主节点负责处理的槽数量非空。
- 从节点的数据被认为是可靠的， 也即是， 主从节点之间的复制连接（replication link）的断线时长不能超过节点超时时限（node timeout）乘以 REDIS_CLUSTER_SLAVE_VALIDITY_MULT 常量得出的积。
如果一个从节点满足了以上的所有条件， 那么这个从节点将向集群中的其他主节点发送授权请求， 询问它们， 是否允许自己（从节点）升级为新的主节点。
如果发送授权请求的从节点满足以下属性， 那么主节点将向从节点返回 FAILOVER_AUTH_GRANTED 授权， 同意从节点的升级要求：
- 发送授权请求的是一个从节点， 并且它所属的主节点处于 FAIL 状态。
- 在已下线主节点的所有从节点中， 这个从节点的节点 ID 在排序中是最小的。
- 这个从节点处于正常的运行状态： 它没有被标记为 FAIL 状态， 也没有被标记为 PFAIL 状态。
一旦某个从节点在给定的时限内得到大部分主节点的授权， 它就会开始执行以下故障转移操作：
- 通过 PONG 数据包（packet）告知其他节点， 这个节点现在是主节点了。
- 通过 PONG 数据包告知其他节点， 这个节点是一个已升级的从节点（promoted slave）。
- 接管（claiming）所有由已下线主节点负责处理的哈希槽。
- 显式地向所有节点广播一个 PONG 数据包， 加速其他节点识别这个节点的进度， 而不是等待定时的 PING / PONG 数据包。
所有其他节点都会根据新的主节点对配置进行相应的更新，特别地：
- 所有被新的主节点接管的槽会被更新。
- 已下线主节点的所有从节点会察觉到 PROMOTED 标志， 并开始对新的主节点进行复制。
- 如果已下线的主节点重新回到上线状态， 那么它会察觉到 PROMOTED 标志， 并将自身调整为现任主节点的从节点。
在集群的生命周期中， 如果一个带有 PROMOTED 标识的主节点因为某些原因转变成了从节点， 那么该节点将丢失它所带有的 PROMOTED 标识。
发布/订阅（已实现，但仍然需要改善）
在一个 Redis 集群中， 客户端可以订阅任意一个节点， 也可以向任意一个节点发送信息， 节点会对客户端所发送的信息进行转发。
在目前的实现中， 节点会将接收到的信息广播至集群中的其他所有节点， 在将来的实现中， 可能会使用 bloom filter 或者其他算法来优化这一操作。
附录 A： CRC16 算法的 ANSI 实现参考
1 | /* |
持久化（persistence）
这篇文章提供了 Redis 持久化的技术性描述， 推荐所有 Redis 用户阅读。
要更广泛地了解 Redis 持久化， 以及这种持久化所保证的耐久性（durability）， 请参考文章 Redis persistence demystified （中文）。
Redis 持久化
Redis 提供了多种不同级别的持久化方式：
- RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
- AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
- Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
- 你甚至可以关闭持久化功能，让数据只在服务器运行时存在。
了解 RDB 持久化和 AOF 持久化之间的异同是非常重要的， 以下几个小节将详细地介绍这这两种持久化功能， 并对它们的相同和不同之处进行说明。
RDB 的优点
- RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
- RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。
- RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
RDB 的缺点
- 如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。
- 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。
AOF 的优点
- 使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。
- AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。
- Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
- AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
AOF 的缺点
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
- 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
- AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH source destination timeout 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。
RDB 和 AOF ，我应该用哪一个？
一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。
如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。
Note
因为以上提到的种种原因， 未来可能会将 AOF 和 RDB 整合成单个持久化模型。 （这是一个长期计划。）
接下来的几个小节将介绍 RDB 和 AOF 的更多细节。
RDB 快照
在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。
你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。
你也可以通过调用 SAVE 或者 BGSAVE ， 手动让 Redis 进行数据集保存操作。
比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集：
1 | save 60 1000 |
这种持久化方式被称为快照（snapshot）。
快照的运作方式
当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：
- Redis 调用 fork() ，同时拥有父进程和子进程。
- 子进程将数据集写入到一个临时 RDB 文件中。
- 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。
只进行追加操作的文件（append-only file，AOF）
快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。
尽管对于某些程序来说， 数据的耐久性并不是最重要的考虑因素， 但是对于那些追求完全耐久能力（full durability）的程序来说， 快照功能就不太适用了。
从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。
你可以通过修改配置文件来打开 AOF 功能：
1 | appendonly yes |
从现在开始， 每当 Redis 执行一个改变数据集的命令时（比如 SET key value [EX seconds] [PX milliseconds] [NX|XX]）， 这个命令就会被追加到 AOF 文件的末尾。
这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。
AOF 重写
因为 AOF 的运作方式是不断地将命令追加到文件的末尾， 所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。
举个例子， 如果你对一个计数器调用了 100 次 INCR key ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录（entry）。
然而在实际上， 只使用一条 SET key value [EX seconds] [PX milliseconds] [NX|XX] 命令已经足以保存计数器的当前值了， 其余 99 条记录实际上都是多余的。
为了处理这种情况， Redis 支持一种有趣的特性： 可以在不打断服务客户端的情况下， 对 AOF 文件进行重建（rebuild）。
执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。
Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令； Redis 2.4 则可以自动触发 AOF 重写， 具体信息请查看 2.4 的示例配置文件。
AOF 的耐久性如何？
你可以配置 Redis 多久才将数据 fsync 到磁盘一次。
有三个选项：
- 每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。
- 每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
- 从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。
推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。
总是 fsync 的策略在实际使用中非常慢， 即使在 Redis 2.0 对相关的程序进行了改进之后仍是如此 —— 频繁调用 fsync 注定了这种策略不可能快得起来。
如果 AOF 文件出错了，怎么办？
服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。
当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：
- 为现有的 AOF 文件创建一个备份。
- 使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。
1
$ redis-check-aof --fix
- （可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。
- 重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。
AOF 的运作方式
AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制。
以下是 AOF 重写的执行步骤：
- Redis 执行 fork() ，现在同时拥有父进程和子进程。
- 子进程开始将新 AOF 文件的内容写入到临时文件。
- 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
- 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
- 搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。
怎么从 RDB 持久化切换到 AOF 持久化
在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：
- 为最新的 dump.rdb 文件创建一个备份。
- 将备份放到一个安全的地方。
- 执行以下两条命令：
1
2
3redis-cli> CONFIG SET appendonly yes
redis-cli> CONFIG SET save "" - 确保命令执行之后，数据库的键的数量没有改变。
- 确保写命令会被正确地追加到 AOF 文件的末尾。
步骤 3 执行的第一条命令开启了 AOF 功能： Redis 会阻塞直到初始 AOF 文件创建完成为止， 之后 Redis 会继续处理命令请求， 并开始将写入命令追加到 AOF 文件末尾。
步骤 3 执行的第二条命令用于关闭 RDB 功能。 这一步是可选的， 如果你愿意的话， 也可以同时使用 RDB 和 AOF 这两种持久化功能。
Note
别忘了在 redis.conf 中打开 AOF 功能！ 否则的话， 服务器重启之后， 之前通过 CONFIG SET 设置的配置就会被遗忘， 程序会按原来的配置来启动服务器。
RDB 和 AOF 之间的相互作用
在版本号大于等于 2.4 的 Redis 中， BGSAVE 执行的过程中， 不可以执行 BGREWRITEAOF 。 反过来说， 在 BGREWRITEAOF 执行的过程中， 也不可以执行 BGSAVE 。
这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。
如果 BGSAVE 正在执行， 并且用户显示地调用 BGREWRITEAOF 命令， 那么服务器将向用户回复一个 OK 状态， 并告知用户， BGREWRITEAOF 已经被预定执行： 一旦 BGSAVE 执行完毕， BGREWRITEAOF 就会正式开始。
当 Redis 启动时， 如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的。
备份 Redis 数据
在阅读这个小节前， 先将下面这句话铭记于心： 一定要备份你的数据库！
磁盘故障， 节点失效， 诸如此类的问题都可能让你的数据消失不见， 不进行备份是非常危险的。
Redis 对于数据备份是非常友好的， 因为你可以在服务器运行的时候对 RDB 文件进行复制： RDB 文件一旦被创建， 就不会进行任何修改。 当服务器要创建一个新的 RDB 文件时， 它先将文件的内容保存在一个临时文件里面， 当临时文件写入完毕时， 程序才使用 rename(2) 原子地用临时文件替换原来的 RDB 文件。
这也就是说， 无论何时， 复制 RDB 文件都是绝对安全的。
以下是我们的建议：
- 创建一个定期任务（cron job）， 每小时将一个 RDB 文件备份到一个文件夹， 并且每天将一个 RDB 文件备份到另一个文件夹。
- 确保快照的备份都带有相应的日期和时间信息， 每次执行定期任务脚本时， 使用 find 命令来删除过期的快照： 比如说， 你可以保留最近 48 小时内的每小时快照， 还可以保留最近一两个月的每日快照。
- 至少每天一次， 将 RDB 备份到你的数据中心之外， 或者至少是备份到你运行 Redis 服务器的物理机器之外。
容灾备份
Redis 的容灾备份基本上就是对数据进行备份， 并将这些备份传送到多个不同的外部数据中心。
容灾备份可以在 Redis 运行并产生快照的主数据中心发生严重的问题时， 仍然让数据处于安全状态。
因为很多 Redis 用户都是创业者， 他们没有大把大把的钱可以浪费， 所以下面介绍的都是一些实用又便宜的容灾备份方法：
- Amazon S3 ，以及其他类似 S3 的服务，是一个构建灾难备份系统的好地方。 最简单的方法就是将你的每小时或者每日 RDB 备份加密并传送到 S3 。 对数据的加密可以通过 gpg -c 命令来完成（对称加密模式）。 记得把你的密码放到几个不同的、安全的地方去（比如你可以把密码复制给你组织里最重要的人物）。 同时使用多个储存服务来保存数据文件，可以提升数据的安全性。
- 传送快照可以使用 SCP 来完成（SSH 的组件）。 以下是简单并且安全的传送方法： 买一个离你的数据中心非常远的 VPS ， 装上 SSH ， 创建一个无口令的 SSH 客户端 key ， 并将这个 key 添加到 VPS 的 authorized_keys 文件中， 这样就可以向这个 VPS 传送快照备份文件了。 为了达到最好的数据安全性，至少要从两个不同的提供商那里各购买一个 VPS 来进行数据容灾备份。
需要注意的是， 这类容灾系统如果没有小心地进行处理的话， 是很容易失效的。
最低限度下， 你应该在文件传送完毕之后， 检查所传送备份文件的体积和原始快照文件的体积是否相同。 如果你使用的是 VPS ， 那么还可以通过比对文件的 SHA1 校验和来确认文件是否传送完整。
另外， 你还需要一个独立的警报系统， 让它在负责传送备份文件的传送器（transfer）失灵时通知你。
发布与订阅（pub/sub）
SUBSCRIBE channel [channel …] 、 UNSUBSCRIBE [channel [channel …]] 和 PUBLISH channel message 三个命令实现了发布与订阅信息泛型（Publish/Subscribe messaging paradigm）， 在这个实现中， 发送者（发送信息的客户端）不是将信息直接发送给特定的接收者（接收信息的客户端）， 而是将信息发送给频道（channel）， 然后由频道将信息转发给所有对这个频道感兴趣的订阅者。
发送者无须知道任何关于订阅者的信息， 而订阅者也无须知道是那个客户端给它发送信息， 它只要关注自己感兴趣的频道即可。
对发布者和订阅者进行解构（decoupling）， 可以极大地提高系统的扩展性（scalability）， 并得到一个更动态的网络拓扑（network topology）。
比如说， 要订阅频道 foo 和 bar ， 客户端可以使用频道名字作为参数来调用 SUBSCRIBE channel [channel …] 命令：
1 | redis> SUBSCRIBE foo bar |
当有客户端发送信息到这些频道时， Redis 会将传入的信息推送到所有订阅这些频道的客户端里面。
正在订阅频道的客户端不应该发送除 SUBSCRIBE channel [channel …] 和 UNSUBSCRIBE [channel [channel …]] 之外的其他命令。 其中， SUBSCRIBE channel [channel …] 可以用于订阅更多频道， 而 UNSUBSCRIBE [channel [channel …]] 则可以用于退订已订阅的一个或多个频道。
SUBSCRIBE channel [channel …] 和 UNSUBSCRIBE [channel [channel …]] 的执行结果会以信息的形式返回， 客户端可以通过分析所接收信息的第一个元素， 从而判断所收到的内容是一条真正的信息， 还是 SUBSCRIBE channel [channel …] 或 UNSUBSCRIBE [channel [channel …]] 命令的操作结果。
信息的格式
频道转发的每条信息都是一条带有三个元素的多条批量回复（multi-bulk reply）。
信息的第一个元素标识了信息的类型：
- subscribe ： 表示当前客户端成功地订阅了信息第二个元素所指示的频道。 而信息的第三个元素则记录了目前客户端已订阅频道的总数。
- unsubscribe ： 表示当前客户端成功地退订了信息第二个元素所指示的频道。 信息的第三个元素记录了客户端目前仍在订阅的频道数量。 当客户端订阅的频道数量降为 0 时， 客户端不再订阅任何频道， 它可以像往常一样， 执行任何 Redis 命令。
- message ： 表示这条信息是由某个客户端执行 PUBLISH channel message 命令所发送的， 真正的信息。 信息的第二个元素是信息来源的频道， 而第三个元素则是信息的内容。
举个例子， 如果客户端执行以下命令：
1 | redis> SUBSCRIBE first second |
那么它将收到以下回复：
1 | 1) "subscribe" |
如果在这时， 另一个客户端执行以下 PUBLISH channel message 命令：
1 | redis> PUBLISH second Hello |
那么之前订阅了 second 频道的客户端将收到以下信息：
1 | 1) "message" |
当订阅者决定退订所有频道时， 它可以执行一个无参数的 UNSUBSCRIBE [channel [channel …]] 命令：
1 | redis> UNSUBSCRIBE |
这个命令将接到以下回复：
1 | 1) "unsubscribe" |
订阅模式
Redis 的发布与订阅实现支持模式匹配（pattern matching）： 客户端可以订阅一个带 * 号的模式， 如果某个/某些频道的名字和这个模式匹配， 那么当有信息发送给这个/这些频道的时候， 客户端也会收到这个/这些频道的信息。
比如说，执行命令
1 | redis> PSUBSCRIBE news.* |
的客户端将收到来自 news.art.figurative 、 news.music.jazz 等频道的信息。
客户端订阅的模式里面可以包含多个 glob 风格的通配符， 比如 * 、 ? 和 […] ， 等等。
执行命令
1 | redis> PUNSUBSCRIBE news.* |
将退订 news.* 模式， 其他已订阅的模式不会被影响。
通过订阅模式接收到的信息， 和通过订阅频道接收到的信息， 这两者的格式不太一样：
- 通过订阅模式而接收到的信息的类型为 pmessage ： 这代表有某个客户端通过 PUBLISH channel message 向某个频道发送了信息， 而这个频道刚好匹配了当前客户端所订阅的某个模式。 信息的第二个元素记录了被匹配的模式， 第三个元素记录了被匹配的频道的名字， 最后一个元素则记录了信息的实际内容。
客户端处理 PSUBSCRIBE pattern [pattern …] 和 PUNSUBSCRIBE [pattern [pattern …]] 返回值的方式， 和客户端处理 SUBSCRIBE channel [channel …] 和 UNSUBSCRIBE [channel [channel …]] 的方式类似： 通过对信息的第一个元素进行分析， 客户端可以判断接收到的信息是一个真正的信息， 还是 PSUBSCRIBE pattern [pattern …] 或 PUNSUBSCRIBE [pattern [pattern …]] 命令的返回值。
通过频道和模式接收同一条信息
如果客户端订阅的多个模式匹配了同一个频道， 或者客户端同时订阅了某个频道、以及匹配这个频道的某个模式， 那么它可能会多次接收到同一条信息。
举个例子， 如果客户端执行了以下命令：
1 | SUBSCRIBE foo |
那么当有信息发送到频道 foo 时， 客户端将收到两条信息： 一条来自频道 foo ，信息类型为 message ； 另一条来自模式 f* ，信息类型为 pmessage 。
订阅总数
在执行 SUBSCRIBE channel [channel …] 、 UNSUBSCRIBE [channel [channel …]] 、 PSUBSCRIBE pattern [pattern …] 和 PUNSUBSCRIBE [pattern [pattern …]] 命令时， 返回结果的最后一个元素是客户端目前仍在订阅的频道和模式总数。
当客户端退订所有频道和模式， 也即是这个总数值下降为 0 的时候， 客户端将退出订阅与发布状态。
编程示例
Pieter Noordhuis 提供了一个使用 EventMachine 和 Redis 编写的 高性能多用户网页聊天软件 ， 这个软件很好地展示了发布与订阅功能的用法。
客户端库实现提示
因为所有接收到的信息都会包含一个信息来源：
- 当信息来自频道时，来源是某个频道；
- 当信息来自模式时，来源是某个模式。
因此， 客户端可以用一个哈希表， 将特定来源和处理该来源的回调函数关联起来。 当有新信息到达时， 程序就可以根据信息的来源， 在 O(1) 复杂度内， 将信息交给正确的回调函数来处理。
Sentinel
Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：
- 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
- 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
- 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。
虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个运行在特殊模式下的 Redis 服务器， 你可以在启动一个普通 Redis 服务器时通过给定 –sentinel 选项来启动 Redis Sentinel 。
Warning
Redis Sentinel 目前仍在开发中， 这个文档的内容可能随着 Sentinel 实现的修改而变更。
Redis Sentinel 兼容 Redis 2.4.16 或以上版本， 推荐使用 Redis 2.8.0 或以上的版本。
获取 Sentinel
目前 Sentinel 系统是 Redis 的 unstable 分支的一部分， 你必须到 Redis 项目的 Github 页面 克隆一份 unstable 分值， 然后通过编译来获得 Sentinel 系统。
Sentinel 程序可以在编译后的 src 文档中发现， 它是一个命名为 redis-sentinel 的程序。
你也可以通过下一节介绍的方法， 让 redis-server 程序运行在 Sentinel 模式之下。
另外， 一个新版本的 Sentinel 已经包含在了 Redis 2.8.0 版本的释出文件中。
启动 Sentinel
对于 redis-sentinel 程序， 你可以用以下命令来启动 Sentinel 系统：
1 | redis-sentinel /path/to/sentinel.conf |
对于 redis-server 程序， 你可以用以下命令来启动一个运行在 Sentinel 模式下的 Redis 服务器：
1 | redis-server /path/to/sentinel.conf --sentinel |
两种方法都可以启动一个 Sentinel 实例。
启动 Sentinel 实例必须指定相应的配置文件， 系统会使用配置文件来保存 Sentinel 的当前状态， 并在 Sentinel 重启时通过载入配置文件来进行状态还原。
如果启动 Sentinel 时没有指定相应的配置文件， 或者指定的配置文件不可写（not writable）， 那么 Sentinel 会拒绝启动。
配置 Sentinel
Redis 源码中包含了一个名为 sentinel.conf 的文件， 这个文件是一个带有详细注释的 Sentinel 配置文件示例。
运行一个 Sentinel 所需的最少配置如下所示：
1 | sentinel monitor mymaster 127.0.0.1 6379 2 |
第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。
不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移， 并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。
换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。
其他选项的基本格式如下：
sentinel <选项的名字> <主服务器的名字> <选项的值>
各个选项的功能如下：
down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。
将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。
如果从服务器被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明）， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。
你可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。
本文档剩余的内容将对 Sentinel 系统的其他选项进行介绍， 示例配置文件 sentinel.conf 也对相关的选项进行了完整的注释。
主观下线和客观下线
前面说过， Redis 的 Sentinel 中关于下线（down）有两个不同的概念：
- 主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
- 客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向它发送 PING 命令的 Sentinel 返回一个有效回复（valid reply）， 那么 Sentinel 就会将这个服务器标记为主观下线。
服务器对 PING 命令的有效回复可以是以下三种回复的其中一种：
- 返回 +PONG 。
- 返回 -LOADING 错误。
- 返回 -MASTERDOWN 错误。
如果服务器返回除以上三种回复之外的其他回复， 又或者在指定时间内没有回复 PING 命令， 那么 Sentinel 认为服务器返回的回复无效（non-valid）。
注意， 一个服务器必须在 master-down-after-milliseconds 毫秒内， 一直返回无效回复才会被 Sentinel 标记为主观下线。
举个例子， 如果 master-down-after-milliseconds 选项的值为 30000 毫秒（30 秒）， 那么只要服务器能在每 29 秒之内返回至少一次有效回复， 这个服务器就仍然会被认为是处于正常状态的。
从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法（strong quorum algorithm）， 而是使用了流言协议： 如果 Sentinel 在给定的时间范围内， 从其他 Sentinel 那里接收到了足够数量的主服务器下线报告， 那么 Sentinel 就会将主服务器的状态从主观下线改变为客观下线。 如果之后其他 Sentinel 不再报告主服务器已下线， 那么客观下线状态就会被移除。
客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。
只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。
每个 Sentinel 都需要定期执行的任务
- 每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。
- 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 那么这个实例会被 Sentinel 标记为主观下线。 一个有效回复可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
- 如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
- 如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel （至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。
- 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO [section] 命令。 当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线主服务器的所有从服务器发送 INFO [section] 命令的频率会从 10 秒一次改为每秒一次。
- 当没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时， 主服务器的主管下线状态就会被移除。
自动发现 Sentinel 和从服务器
一个 Sentinel 可以与其他多个 Sentinel 进行连接， 各个 Sentinel 之间可以互相检查对方的可用性， 并进行信息交换。
你无须为运行的每个 Sentinel 分别设置其他 Sentinel 的地址， 因为 Sentinel 可以通过发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel ， 这一功能是通过向频道 sentinel:hello 发送信息来实现的。
与此类似， 你也不必手动列出主服务器属下的所有从服务器， 因为 Sentinel 可以通过询问主服务器来获得所有从服务器的信息。
- 每个 Sentinel 会以每两秒一次的频率， 通过发布与订阅功能， 向被它监视的所有主服务器和从服务器的 sentinel:hello 频道发送一条信息， 信息中包含了 Sentinel 的 IP 地址、端口号和运行 ID （runid）。
- 每个 Sentinel 都订阅了被它监视的所有主服务器和从服务器的 sentinel:hello 频道， 查找之前未出现过的 sentinel （looking for unknown sentinels）。 当一个 Sentinel 发现一个新的 Sentinel 时， 它会将新的 Sentinel 添加到一个列表中， 这个列表保存了 Sentinel 已知的， 监视同一个主服务器的所有其他 Sentinel 。
- Sentinel 发送的信息中还包括完整的主服务器当前配置（configuration）。 如果一个 Sentinel 包含的主服务器配置比另一个 Sentinel 发送的配置要旧， 那么这个 Sentinel 会立即升级到新配置上。
- 在将一个新 Sentinel 添加到监视主服务器的列表上面之前， Sentinel 会先检查列表中是否已经包含了和要添加的 Sentinel 拥有相同运行 ID 或者相同地址（包括 IP 地址和端口号）的 Sentinel ， 如果是的话， Sentinel 会先移除列表中已有的那些拥有相同运行 ID 或者相同地址的 Sentinel ， 然后再添加新 Sentinel 。
Sentinel API
在默认情况下， Sentinel 使用 TCP 端口 26379 （普通 Redis 服务器使用的是 6379 ）。
Sentinel 接受 Redis 协议格式的命令请求， 所以你可以使用 redis-cli 或者任何其他 Redis 客户端来与 Sentinel 进行通讯。
有两种方式可以和 Sentinel 进行通讯：
- 第一种方法是通过直接发送命令来查询被监视 Redis 服务器的当前状态， 以及 Sentinel 所知道的关于其他 Sentinel 的信息， 诸如此类。
- 另一种方法是使用发布与订阅功能， 通过接收 Sentinel 发送的通知： 当执行故障转移操作， 或者某个被监视的服务器被判断为主观下线或者客观下线时， Sentinel 就会发送相应的信息。
Sentinel 命令
以下列出的是 Sentinel 接受的命令：
- PING ：返回 PONG 。
- SENTINEL masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态。
- SENTINEL slaves <master name> ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态。
- SENTINEL get-master-addr-by-name <master name> ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号。
- SENTINEL reset <pattern> ： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清除主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel 。
- SENTINEL failover <master name> ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移 （不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。
发布与订阅信息
客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器： 你不可以使用 PUBLISH channel message 命令向这个服务器发送信息， 但你可以用 SUBSCRIBE channel [channel …] 命令或者 PSUBSCRIBE pattern [pattern …] 命令， 通过订阅给定的频道来获取相应的事件提醒。
一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。
通过执行 PSUBSCRIBE * 命令可以接收所有事件信息。
以下列出的是客户端可以通过订阅来获得的频道和信息的格式： 第一个英文单词是频道/事件的名字， 其余的是数据的格式。
注意， 当格式中包含 instance details 字样时， 表示频道所返回的信息中包含了以下用于识别目标实例的内容：
1 | <instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port> |
@ 字符之后的内容用于指定主服务器， 这些内容是可选的， 它们仅在 @ 字符之前的内容指定的实例不是主服务器时使用。
- +reset-master <instance details> ：主服务器已被重置。
- +slave <instance details> ：一个新的从服务器已经被 Sentinel 识别并关联。
- +failover-state-reconf-slaves <instance details> ：故障转移状态切换到了 reconf-slaves 状态。
- +failover-detected <instance details> ：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
- +slave-reconf-sent <instance details> ：领头（leader）的 Sentinel 向实例发送了 SLAVEOF host port 命令，为实例设置新的主服务器。
- +slave-reconf-inprog <instance details> ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。
- +slave-reconf-done <instance details> ：从服务器已经成功完成对新主服务器的同步。
- -dup-sentinel <instance details> ：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。
- +sentinel <instance details> ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
- +sdown <instance details> ：给定的实例现在处于主观下线状态。
- -sdown <instance details> ：给定的实例已经不再处于主观下线状态。
- +odown <instance details> ：给定的实例现在处于客观下线状态。
- -odown <instance details> ：给定的实例已经不再处于客观下线状态。
- +new-epoch <instance details> ：当前的纪元（epoch）已经被更新。
- +try-failover <instance details> ：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。
- +elected-leader <instance details> ：赢得指定纪元的选举，可以进行故障迁移操作了。
- +failover-state-select-slave <instance details> ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
- no-good-slave <instance details> ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
- selected-slave <instance details> ：Sentinel 顺利找到适合进行升级的从服务器。
- failover-state-send-slaveof-noone <instance details> ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
- failover-end-for-timeout <instance details> ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。
- failover-end <instance details> ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
- +switch-master <master name> <oldip> <oldport> <newip> <newport> ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
- +tilt ：进入 tilt 模式。
- -tilt ：退出 tilt 模式。
故障转移
一次故障转移操作由以下步骤组成：
- 发现主服务器已经进入客观下线状态。
- 对我们的当前纪元进行自增（详情请参考 Raft leader election ）， 并尝试在这个纪元中当选。
- 如果当选失败， 那么在设定的故障迁移超时时间的两倍之后， 重新尝试当选。 如果当选成功， 那么执行以下步骤。
- 选出一个从服务器，并将它升级为主服务器。
- 向被选中的从服务器发送 SLAVEOF NO ONE 命令，让它转变为主服务器。
- 通过发布与订阅功能， 将更新后的配置传播给所有其他 Sentinel ， 其他 Sentinel 对它们自己的配置进行更新。
- 向已下线主服务器的从服务器发送 SLAVEOF host port 命令， 让它们去复制新的主服务器。
- 当所有从服务器都已经开始复制新的主服务器时， 领头 Sentinel 终止这次故障迁移操作。
Note
每当一个 Redis 实例被重新配置（reconfigured） —— 无论是被设置成主服务器、从服务器、又或者被设置成其他主服务器的从服务器 —— Sentinel 都会向被重新配置的实例发送一个 CONFIG REWRITE 命令， 从而确保这些配置会持久化在硬盘里。
Sentinel 使用以下规则来选择新的主服务器：
- 在失效主服务器属下的从服务器当中， 那些被标记为主观下线、已断线、或者最后一次回复 PING 命令的时间大于五秒钟的从服务器都会被淘汰。
- 在失效主服务器属下的从服务器当中， 那些与失效主服务器连接断开的时长超过 down-after 选项指定的时长十倍的从服务器都会被淘汰。
- 在经历了以上两轮淘汰之后剩下来的从服务器中， 我们选出复制偏移量（replication offset）最大的那个从服务器作为新的主服务器； 如果复制偏移量不可用， 或者从服务器的复制偏移量相同， 那么带有最小运行 ID 的那个从服务器成为新的主服务器。
Sentinel 自动故障迁移的一致性特质
Sentinel 自动故障迁移使用 Raft 算法来选举领头（leader） Sentinel ， 从而确保在一个给定的纪元（epoch）里， 只有一个领头产生。
这表示在同一个纪元中， 不会有两个 Sentinel 同时被选中为领头， 并且各个 Sentinel 在同一个纪元中只会对一个领头进行投票。
更高的配置纪元总是优于较低的纪元， 因此每个 Sentinel 都会主动使用更新的纪元来代替自己的配置。
简单来说， 我们可以将 Sentinel 配置看作是一个带有版本号的状态。 一个状态会以最后写入者胜出（last-write-wins）的方式（也即是，最新的配置总是胜出）传播至所有其他 Sentinel 。
举个例子， 当出现网络分割（network partitions）时， 一个 Sentinel 可能会包含了较旧的配置， 而当这个 Sentinel 接到其他 Sentinel 发来的版本更新的配置时， Sentinel 就会对自己的配置进行更新。
如果要在网络分割出现的情况下仍然保持一致性， 那么应该使用 min-slaves-to-write 选项， 让主服务器在连接的从实例少于给定数量时停止执行写操作， 与此同时， 应该在每个运行 Redis 主服务器或从服务器的机器上运行 Redis Sentinel 进程。
Sentinel 状态的持久化
Sentinel 的状态会被持久化在 Sentinel 配置文件里面。
每当 Sentinel 接收到一个新的配置， 或者当领头 Sentinel 为主服务器创建一个新的配置时， 这个配置会与配置纪元一起被保存到磁盘里面。
这意味着停止和重启 Sentinel 进程都是安全的。
Sentinel 在非故障迁移的情况下对实例进行重新配置
即使没有自动故障迁移操作在进行， Sentinel 总会尝试将当前的配置设置到被监视的实例上面。 特别是：
- 根据当前的配置， 如果一个从服务器被宣告为主服务器， 那么它会代替原有的主服务器， 成为新的主服务器， 并且成为原有主服务器的所有从服务器的复制对象。
- 那些连接了错误主服务器的从服务器会被重新配置， 使得这些从服务器会去复制正确的主服务器。
不过， 在以上这些条件满足之后， Sentinel 在对实例进行重新配置之前仍然会等待一段足够长的时间， 确保可以接收到其他 Sentinel 发来的配置更新， 从而避免自身因为保存了过期的配置而对实例进行了不必要的重新配置。
TILT 模式
Redis Sentinel 严重依赖计算机的时间功能： 比如说， 为了判断一个实例是否可用， Sentinel 会记录这个实例最后一次相应 PING 命令的时间， 并将这个时间和当前时间进行对比， 从而知道这个实例有多长时间没有和 Sentinel 进行任何成功通讯。
不过， 一旦计算机的时间功能出现故障， 或者计算机非常忙碌， 又或者进程因为某些原因而被阻塞时， Sentinel 可能也会跟着出现故障。
TILT 模式是一种特殊的保护模式： 当 Sentinel 发现系统有些不对劲时， Sentinel 就会进入 TILT 模式。
因为 Sentinel 的时间中断器默认每秒执行 10 次， 所以我们预期时间中断器的两次执行之间的间隔为 100 毫秒左右。 Sentinel 的做法是， 记录上一次时间中断器执行时的时间， 并将它和这一次时间中断器执行的时间进行对比：
- 如果两次调用时间之间的差距为负值， 或者非常大（超过 2 秒钟）， 那么 Sentinel 进入 TILT 模式。
- 如果 Sentinel 已经进入 TILT 模式， 那么 Sentinel 延迟退出 TILT 模式的时间。
当 Sentinel 进入 TILT 模式时， 它仍然会继续监视所有目标， 但是：
- 它不再执行任何操作，比如故障转移。
- 当有实例向这个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令时， Sentinel 返回负值： 因为这个 Sentinel 所进行的下线判断已经不再准确。
如果 TILT 可以正常维持 30 秒钟， 那么 Sentinel 退出 TILT 模式。
处理 -BUSY 状态
Warning
该功能尚未实现
当 Lua 脚本的运行时间超过指定时限时， Redis 就会返回 -BUSY 错误。
当出现这种情况时， Sentinel 在尝试执行故障转移操作之前， 会先向服务器发送一个 SCRIPT KILL 命令， 如果服务器正在执行的是一个只读脚本的话， 那么这个脚本就会被杀死， 服务器就会回到正常状态。
Sentinel 的客户端实现
关于 Sentinel 客户端的实现信息可以参考 Sentinel 客户端指引手册 。
集群教程
本文档是 Redis 集群的入门教程， 从用户的角度介绍了设置、测试和操作集群的方法。
本教程不包含晦涩难懂的分布式概念， 也没有像 Redis 集群规范 那样包含 Redis 集群的实现细节， 如果你打算深入地学习 Redis 集群的部署方法， 那么推荐你在阅读完这个教程之后， 再去看一看集群规范。
Redis 集群目前仍处于 Alpha 测试版本， 如果在使用过程中发现任何问题， 请到 Redis 的邮件列表 发贴， 或者到 Redis 的 Github 页面 报告错误。
集群简介
Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施（installation）。
Redis 集群不支持那些需要同时处理多个键的 Redis 命令， 因为执行这些命令需要在多个 Redis 节点之间移动数据， 并且在高负载的情况下， 这些命令将降低 Redis 集群的性能， 并导致不可预测的行为。
Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。
Redis 集群提供了以下两个好处：
- 将数据自动切分（split）到多个节点的能力。
- 当集群中的一部分节点失效或者无法进行通讯时， 仍然可以继续处理命令请求的能力。
Redis 集群数据共享。
Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 数据库中的每个键都属于这 16384 个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
集群中的每个节点负责处理一部分哈希槽。 举个例子， 一个集群可以有三个哈希槽， 其中：
- 节点 A 负责处理 0 号至 5500 号哈希槽。
- 节点 B 负责处理 5501 号至 11000 号哈希槽。
- 节点 C 负责处理 11001 号至 16384 号哈希槽。
这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。 比如说：
- 如果用户将新节点 D 添加到集群中， 那么集群只需要将节点 A 、B 、 C 中的某些槽移动到节点 D 就可以了。
- 与此类似， 如果用户要从集群中移除节点 A ， 那么集群只需要将节点 A 中的所有哈希槽移动到节点 B 和节点 C ， 然后再移除空白（不包含任何哈希槽）的节点 A 就可以了。
因为将一个哈希槽从一个节点移动到另一个节点不会造成节点阻塞， 所以无论是添加新节点还是移除已存在节点， 又或者改变某个节点包含的哈希槽数量， 都不会造成集群下线。
Redis 集群中的主从复制
为了使得集群在一部分节点下线或者无法与集群的大多数（majority）节点进行通讯的情况下， 仍然可以正常运作， Redis 集群对节点使用了主从复制功能： 集群中的每个节点都有 1 个至 N 个复制品（replica）， 其中一个复制品为主节点（master）， 而其余的 N-1 个复制品为从节点（slave）。
在之前列举的节点 A 、B 、C 的例子中， 如果节点 B 下线了， 那么集群将无法正常运行， 因为集群找不到节点来处理 5501 号至 11000 号的哈希槽。
另一方面， 假如在创建集群的时候（或者至少在节点 B 下线之前）， 我们为主节点 B 添加了从节点 B1 ， 那么当主节点 B 下线的时候， 集群就会将 B1 设置为新的主节点， 并让它代替下线的主节点 B ， 继续处理 5501 号至 11000 号的哈希槽， 这样集群就不会因为主节点 B 的下线而无法正常运作了。
不过如果节点 B 和 B1 都下线的话， Redis 集群还是会停止运作。
Redis 集群的一致性保证（guarantee）
Redis 集群不保证数据的强一致性（strong consistency）： 在特定条件下， Redis 集群可能会丢失已经被执行过的写命令。
使用异步复制（asynchronous replication）是 Redis 集群可能会丢失写命令的其中一个原因。 考虑以下这个写命令的例子：
- 客户端向主节点 B 发送一条写命令。
- 主节点 B 执行写命令，并向客户端返回命令回复。
- 主节点 B 将刚刚执行的写命令复制给它的从节点 B1 、 B2 和 B3 。
如你所见， 主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。
Note
如果真的有必要的话， Redis 集群可能会在将来提供同步地（synchronou）执行写命令的方法。
Redis 集群另外一种可能会丢失命令的情况是， 集群出现网络分裂（network partition）， 并且一个客户端与至少包括一个主节点在内的少数（minority）实例被孤立。
举个例子， 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点， 其中 A 、B 、C 为主节点， 而 A1 、B1 、C1 分别为三个主节点的从节点， 另外还有一个客户端 Z1 。
假设集群中发生网络分裂， 那么集群可能会分裂为两方， 大多数（majority）的一方包含节点 A 、C 、A1 、B1 和 C1 ， 而少数（minority）的一方则包含节点 B 和客户端 Z1 。
在网络分裂期间， 主节点 B 仍然会接受 Z1 发送的写命令：
- 如果网络分裂出现的时间很短， 那么集群会继续正常运行；
- 但是， 如果网络分裂出现的时间足够长， 使得大多数一方将从节点 B1 设置为新的主节点， 并使用 B1 来代替原来的主节点 B ， 那么 Z1 发送给主节点 B 的写命令将丢失。
注意， 在网络分裂出现期间， 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选项：
- 对于大多数一方来说， 如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群， 那么集群会将这个主节点视为下线， 并使用从节点来代替这个主节点继续工作。
- 对于少数一方， 如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群， 那么它将停止处理写命令， 并向客户端报告错误。
创建并使用 Redis 集群
Redis 集群由多个运行在集群模式（cluster mode）下的 Redis 实例组成， 实例的集群模式需要通过配置来开启， 开启集群模式的实例将可以使用集群特有的功能和命令。
以下是一个包含了最少选项的集群配置文件示例：
1 | port 7000 |
文件中的 cluster-enabled 选项用于开实例的集群模式， 而 cluster-conf-file 选项则设定了保存节点配置文件的路径， 默认值为 nodes.conf 。
节点配置文件无须人为修改， 它由 Redis 集群在启动时创建， 并在有需要时自动进行更新。
要让集群正常运作至少需要三个主节点， 不过在刚开始试用集群功能时， 强烈建议使用六个节点： 其中三个为主节点， 而其余三个则是各个主节点的从节点。
首先， 让我们进入一个新目录， 并创建六个以端口号为名字的子目录， 稍后我们在将每个目录中运行一个 Redis 实例：
1 | mkdir cluster-test |
在文件夹 7000 至 7005 中， 各创建一个 redis.conf 文件， 文件的内容可以使用上面的示例配置文件， 但记得将配置中的端口号从 7000 改为与文件夹名字相同的号码。
现在， 从 Redis Github 页面 的 unstable 分支中取出最新的 Redis 源码， 编译出可执行文件 redis-server ， 并将文件复制到 cluster-test 文件夹， 然后使用类似以下命令， 在每个标签页中打开一个实例：
1 | cd 7000 |
实例打印的日志显示， 因为 nodes.conf 文件不存在， 所以每个节点都为它自身指定了一个新的 ID ：
1 | [82462] 26 Nov 11:56:55.329 * No cluster configuration found, I'm 97a3a64667477371c4479320d683e4c8db5858b1 |
实例会一直使用同一个 ID ， 从而在集群中保持一个独一无二（unique）的名字。
每个节点都使用 ID 而不是 IP 或者端口号来记录其他节点， 因为 IP 地址和端口号都可能会改变， 而这个独一无二的标识符（identifier）则会在节点的整个生命周期中一直保持不变。
我们将这个标识符称为节点 ID。
创建集群
现在我们已经有了六个正在运行中的 Redis 实例， 接下来我们需要使用这些实例来创建集群， 并为每个节点编写配置文件。
通过使用 Redis 集群命令行工具 redis-trib ， 编写节点配置文件的工作可以非常容易地完成： redis-trib 位于 Redis 源码的 src 文件夹中， 它是一个 Ruby 程序， 这个程序通过向实例发送特殊命令来完成创建新集群， 检查集群， 或者对集群进行重新分片（reshared）等工作。
我们需要执行以下命令来创建集群：
1 | ./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \ |
命令的意义如下：
- 给定 redis-trib.rb 程序的命令是 create ， 这表示我们希望创建一个新的集群。
- 选项 –replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。
- 之后跟着的其他参数则是实例的地址列表， 我们希望程序使用这些地址所指示的实例来创建新集群。
简单来说， 以上命令的意思就是让 redis-trib 程序创建一个包含三个主节点和三个从节点的集群。
接着， redis-trib 会打印出一份预想中的配置给你看， 如果你觉得没问题的话， 就可以输入 yes ， redis-trib 就会将这份配置应用到集群当中：
1 | >>> Creating cluster |
输入 yes 并按下回车确认之后， 集群就会将配置应用到各个节点， 并连接起（join）各个节点 —— 也即是， 让各个节点开始互相通讯：
1 | >>> Nodes configuration updated |
如果一切正常的话， redis-trib 将输出以下信息：
1 | >>> Check for open slots... |
这表示集群中的 16384 个槽都有至少一个主节点在处理， 集群运作正常。
集群的客户端
Redis 集群现阶段的一个问题是客户端实现很少。 以下是一些我知道的实现：
- redis-rb-cluster 是我（@antirez）编写的 Ruby 实现， 用于作为其他实现的参考。 该实现是对 redis-rb 的一个简单包装， 高效地实现了与集群进行通讯所需的最少语义（semantic）。
- redis-py-cluster 看上去是 redis-rb-cluster 的一个 Python 版本， 这个项目有一段时间没有更新了（最后一次提交是在六个月之前）， 不过可以将这个项目用作学习集群的起点。
- 流行的 Predis 曾经对早期的 Redis 集群有过一定的支持， 但我不确定它对集群的支持是否完整， 也不清楚它是否和最新版本的 Redis 集群兼容 （因为新版的 Redis 集群将槽的数量从 4k 改为 16k 了）。
- Redis unstable 分支中的 redis-cli 程序实现了非常基本的集群支持， 可以使用命令 redis-cli -c 来启动。
测试 Redis 集群比较简单的办法就是使用 redis-rb-cluster 或者 redis-cli ， 接下来我们将使用 redis-cli 为例来进行演示：
1 | $ redis-cli -c -p 7000 |
redis-cli 对集群的支持是非常基本的， 所以它总是依靠 Redis 集群节点来将它转向（redirect）至正确的节点。
一个真正的（serious）集群客户端应该做得比这更好： 它应该用缓存记录起哈希槽与节点地址之间的映射（map）， 从而直接将命令发送到正确的节点上面。
这种映射只会在集群的配置出现某些修改时变化， 比如说， 在一次故障转移（failover）之后， 或者系统管理员通过添加节点或移除节点来修改了集群的布局（layout）之后， 诸如此类。
使用 redis-rb-cluster 编写一个示例应用
在展示如何使用集群进行故障转移、重新分片等操作之前， 我们需要创建一个示例应用， 了解一些与 Redis 集群客户端进行交互的基本方法。
在运行示例应用的过程中， 我们会尝试让节点进入失效状态， 又或者开始一次重新分片， 以此来观察 Redis 集群在真实世界运行时的表现， 并且为了让这个示例尽可能地有用， 我们会让这个应用向集群进行写操作。
本节将通过两个示例应用来展示 redis-rb-cluster 的基本用法， 以下是本节的第一个示例应用， 它是一个名为 example.rb 的文件， 包含在redis-rb-cluster 项目里面：
1 | require './cluster' |
这个应用所做的工作非常简单： 它不断地以 foo
如果我们执行这个应用的话， 应用将按顺序执行以下命令：
- SET foo0 0
- SET foo1 1
- SET foo2 2
- 诸如此类。。。
代码中的每个集群操作都使用一个 begin 和 rescue 代码块（block）包裹着， 因为我们希望在代码出错时， 将错误打印到终端上面， 而不希望应用因为异常（exception）而退出。
代码的第七行是代码中第一个有趣的地方， 它创建了一个 Redis 集群对象， 其中创建对象所使用的参数及其意义如下：
- 第一个参数是记录了启动节点的 startup_nodes 列表， 列表中包含了两个集群节点的地址。
- 第二个参数指定了对于集群中的各个不同的节点， Redis 集群对象可以获得（take）的最大连接数 （maximum number of connections this object is allowed to take）。
- 第三个参数 timeout 指定了一个命令在执行多久之后， 才会被看作是执行失败。
记住， 启动列表中并不需要包含所有集群节点的地址， 但这些地址中至少要有一个是有效的（reachable）： 一旦 redis-rb-cluster 成功连接上集群中的某个节点时， 集群节点列表就会被自动更新， 任何真正的（serious）的集群客户端都应该这样做。
现在， 程序创建的 Redis 集群对象实例被保存到 rc 变量里面， 我们可以将这个对象当作普通 Redis 对象实例来使用。
在十一至十九行， 我们先尝试阅读计数器中的值， 如果计数器不存在的话， 我们才将计数器初始化为 0 ： 通过将计数值保存到 Redis 的计数器里面， 我们可以在示例重启之后， 仍然继续之前的执行过程， 而不必每次重启之后都从 foo0 开始重新设置键值对。
为了让程序在集群下线的情况下， 仍然不断地尝试读取计数器的值， 我们将读取操作包含在了一个 while 循环里面， 一般的应用程序并不需要如此小心。
二十一至三十行是程序的主循环， 这个循环负责设置键值对， 并在设置出错时打印错误信息。
程序在主循环的末尾添加了一个 sleep 调用， 让写操作的执行速度变慢， 帮助执行示例的人更容易看清程序的输出。
执行 example.rb 程序将产生以下输出：
1 | ruby ./example.rb |
这个程序并不是十分有趣， 稍后我们就会看到一个更有趣的集群应用示例， 不过在此之前， 让我们先使用这个示例来演示集群的重新分片操作。
对集群进行重新分片
现在， 让我们来试试对集群进行重新分片操作。
在执行重新分片的过程中， 请让你的 example.rb 程序处于运行状态， 这样你就会看到， 重新分片并不会对正在运行的集群程序产生任何影响， 你也可以考虑将 example.rb 中的 sleep 调用删掉， 从而让重新分片操作在近乎真实的写负载下执行。
重新分片操作基本上就是将某些节点上的哈希槽移动到另外一些节点上面， 和创建集群一样， 重新分片也可以使用 redis-trib 程序来执行。
执行以下命令可以开始一次重新分片操作：
1 | $ ./redis-trib.rb reshard 127.0.0.1:7000 |
你只需要指定集群中其中一个节点的地址， redis-trib 就会自动找到集群中的其他节点。
目前 redis-trib 只能在管理员的协助下完成重新分片的工作， 要让 redis-trib 自动将哈希槽从一个节点移动到另一个节点， 目前来说还做不到 （不过实现这个功能并不难）。
执行 redis-trib 的第一步就是设定你打算移动的哈希槽的数量：
1 | $ ./redis-trib.rb reshard 127.0.0.1:7000 |
我们将打算移动的槽数量设置为 1000 个， 如果 example.rb 程序一直运行着的话， 现在 1000 个槽里面应该有不少键了。
除了移动的哈希槽数量之外， redis-trib 还需要知道重新分片的目标（target node）， 也即是， 负责接收这 1000 个哈希槽的节点。
指定目标需要使用节点的 ID ， 而不是 IP 地址和端口。 比如说， 我们打算使用集群的第一个主节点来作为目标， 它的 IP 地址和端口是 127.0.0.1:7000 ， 而节点 ID 则是 9991306f0e50640a5684f1958fd754b38fa034c9 ， 那么我们应该向 redis-trib 提供节点的 ID ：
1 | $ ./redis-trib.rb reshard 127.0.0.1:7000 |
Note
redis-trib 会打印出集群中所有节点的 ID ， 并且我们也可以通过执行以下命令来获得节点的运行 ID ：
1 | $ ./redis-cli -p 7000 cluster nodes | grep myself |
接着， redis-trib 会向你询问重新分片的源节点（source node）， 也即是， 要从哪个节点中取出 1000 个哈希槽， 并将这些槽移动到目标节点上面。
如果我们不打算从特定的节点上取出指定数量的哈希槽， 那么可以向 redis-trib 输入 all ， 这样的话， 集群中的所有主节点都会成为源节点， redis-trib 将从各个源节点中各取出一部分哈希槽， 凑够 1000 个， 然后移动到目标节点上面：
1 | $ ./redis-trib.rb reshard 127.0.0.1:7000 |
输入 all 并按下回车之后， redis-trib 将打印出哈希槽的移动计划， 如果你觉得没问题的话， 就可以输入 yes 并再次按下回车：
1 | $ ./redis-trib.rb reshard 127.0.0.1:7000 |
输入 yes 并使用按下回车之后， redis-trib 就会正式开始执行重新分片操作， 将指定的哈希槽从源节点一个个地移动到目标节点上面：
1 | $ ./redis-trib.rb reshard 127.0.0.1:7000 |
在重新分片的过程中， example.rb 应该可以继续正常运行， 不会出现任何问题。
在重新分片操作执行完毕之后， 可以使用以下命令来检查集群是否正常：
1 | $ ./redis-trib.rb check 127.0.0.1:7000 |
根据检查结果显示， 集群运作正常。
需要注意的就是， 在三个主节点中， 节点 127.0.0.1:7000 包含了 6461 个哈希槽， 而节点 127.0.0.1:7001 和节点 127.0.0.1:7002 都只包含了 4961 个哈希槽， 因为后两者都将自己的 500 个哈希槽移动到了节点 127.0.0.1:7000 。
一个更有趣的示例应用
我们在前面使用的示例程序 example.rb 并不是十分有趣， 因为它只是不断地对集群进行写入， 但并不检查写入结果是否正确。 比如说， 集群可能会错误地将 example.rb 发送的所有 SET key value [EX seconds] [PX milliseconds] [NX|XX] 命令都改成了 SET foo 42 ， 但因为 example.rb 并不检查写入后的值， 所以它不会意识到集群实际上写入的值是错误的。
因为这个原因， redis-rb-cluster 项目包含了一个名为 consistency-test.rb 的示例应用， 这个应用比起 example.rb 有趣得多： 它创建了多个计数器（默认为 1000 个）， 并通过发送 INCR key 命令来增加这些计数器的值。
在增加计数器值的同时， consistency-test.rb 还执行以下操作：
- 每次使用 INCR key 命令更新一个计数器时， 应用会记录下计数器执行 INCR key 命令之后应该有的值。 举个例子， 如果计数器的起始值为 0 ， 而这次是程序第 50 次向它发送 INCR key 命令， 那么计数器的值应该是 50 。
- 在每次发送 INCR key 命令之前， 程序会随机从集群中读取一个计数器的值， 并将它与自己记录的值进行对比， 看两个值是否相同。
换句话说， 这个程序是一个一致性检查器（consistency checker）： 如果集群在执行 INCR key 命令的过程中， 丢失了某条 INCR key 命令， 又或者多执行了某条客户端没有确认到的 INCR key 命令， 那么检查器将察觉到这一点 —— 在前一种情况中， consistency-test.rb 记录的计数器值将比集群记录的计数器值要大； 而在后一种情况中， consistency-test.rb 记录的计数器值将比集群记录的计数器值要小。
运行 consistency-test 程序将产生类似以下的输出：
1 | $ ruby consistency-test.rb |
每行输出都打印了程序执行的读取次数和写入次数， 以及执行操作的过程中因为集群不可用而产生的错误数。
如果程序察觉了不一致的情况出现， 它将在输出行的末尾显式不一致的详细情况。
比如说， 如果我们在 consistency-test.rb 运行的过程中， 手动修改某个计数器的值：
1 | $ redis 127.0.0.1:7000> set key_217 0 |
那么 consistency-test.rb 将向我们报告不一致情况：
1 | (in the other tab I see...) |
在我们修改计数器值的时候， 计数器的正确值是 114 （执行了 114 次 INCR key 命令）， 因为我们将计数器的值设成了 0 ， 所以 consistency-test.rb 会向我们报告说丢失了 114 个 INCR key 命令。
因为这个示例程序具有一致性检查功能， 所以我们用它来测试 Redis 集群的故障转移操作。
故障转移测试
Note
在执行本节操作的过程中， 请一直运行 consistency-test 程序。
要触发一次故障转移， 最简单的办法就是令集群中的某个主节点进入下线状态。
首先用以下命令列出集群中的所有主节点：
1 | $ redis-cli -p 7000 cluster nodes | grep master |
通过命令输出， 我们知道端口号为 7000 、 7001 和 7002 的节点都是主节点， 然后我们可以通过向端口号为 7002 的主节点发送 DEBUG SEGFAULT 命令， 让这个主节点崩溃：
1 | $ redis-cli -p 7002 debug segfault |
现在， 切换到运行着 consistency-test 的标签页， 可以看到， consistency-test 在 7002 下线之后的一段时间里将产生大量的错误警告信息：
1 | 18849 R (0 err) | 18849 W (0 err) | |
从 consistency-test 的这段输出可以看到， 集群在执行故障转移期间， 总共丢失了 578 个读命令和 577 个写命令， 但是并没有产生任何数据不一致。
这听上去可能有点奇怪， 因为在教程的开头我们提到过， Redis 使用的是异步复制， 在执行故障转移期间， 集群可能会丢失写命令。
但是在实际上， 丢失命令的情况并不常见， 因为 Redis 几乎是同时执行将命令回复发送给客户端， 以及将命令复制给从节点这两个操作， 所以实际上造成命令丢失的时间窗口是非常小的。
不过， 尽管出现的几率不高， 但丢失命令的情况还是有可能会出现的， 所以我们对 Redis 集群不能提供强一致性的这一描述仍然是正确的。
现在， 让我们使用 cluster nodes 命令， 查看集群在执行故障转移操作之后， 主从节点的布局情况：
1 | $ redis-cli -p 7000 cluster nodes |
我重启了之前下线的 127.0.0.1:7002 节点， 该节点已经从原来的主节点变成了从节点， 而现在集群中的三个主节点分别是 127.0.0.1:7000 、 127.0.0.1:7001 和 127.0.0.1:7005 ， 其中 127.0.0.1:7005 就是因为 127.0.0.1:7002 下线而变成主节点的。
cluster nodes 命令的输出有点儿复杂， 它的每一行都是由以下信息组成的：
- 节点 ID ：例如 3fc783611028b1707fd65345e763befb36454d73 。
- ip:port ：节点的 IP 地址和端口号， 例如 127.0.0.1:7000 ， 其中 :0 表示的是客户端当前连接的 IP 地址和端口号。
- flags ：节点的角色（例如 master 、 slave 、 myself ）以及状态（例如 fail ，等等）。
- 如果节点是一个从节点的话， 那么跟在 flags 之后的将是主节点的节点 ID ： 例如 127.0.0.1:7002 的主节点的节点 ID 就是 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 。
- 集群最近一次向节点发送 PING 命令之后， 过去了多长时间还没接到回复。
- 节点最近一次返回 PONG 回复的时间。
- 节点的配置纪元（configuration epoch）：详细信息请参考 Redis 集群规范 。
- 本节点的网络连接情况：例如 connected 。
- 节点目前包含的槽：例如 127.0.0.1:7001 目前包含号码为 5960 至 10921 的哈希槽。
添加新节点到集群
根据新添加节点的种类， 我们需要用两种方法来将新节点添加到集群里面：
- 如果要添加的新节点是一个主节点， 那么我们需要创建一个空节点（empty node）， 然后将某些哈希桶移动到这个空节点里面。
- 另一方面， 如果要添加的新节点是一个从节点， 那么我们需要将这个新节点设置为集群中某个节点的复制品（replica）。
本节将对以上两种情况进行介绍， 首先介绍主节点的添加方法， 然后再介绍从节点的添加方法。
无论添加的是那种节点， 第一步要做的总是添加一个空节点。
我们可以继续使用之前启动 127.0.0.1:7000 、 127.0.0.1:7001 等节点的方法， 创建一个端口号为 7006 的新节点， 使用的配置文件也和之前一样， 只是记得要将配置中的端口号改为 7000 。
以下是启动端口号为 7006 的新节点的详细步骤：
- 在终端里创建一个新的标签页。
- 进入 cluster-test 文件夹。
- 创建并进入 7006 文件夹。
- 将 redis.conf 文件复制到 7006 文件夹里面，然后将配置中的端口号选项改为 7006 。
- 使用命令 ../../redis-server redis.conf 启动节点。
如果一切正常， 那么节点应该会正确地启动。
接下来， 执行以下命令， 将这个新节点添加到集群里面：
1 | ./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000 |
命令中的 add-node 表示我们要让 redis-trib 将一个节点添加到集群里面， add-node 之后跟着的是新节点的 IP 地址和端口号， 再之后跟着的是集群中任意一个已存在节点的 IP 地址和端口号， 这里我们使用的是 127.0.0.1:7000 。
通过 cluster nodes 命令， 我们可以确认新节点 127.0.0.1:7006 已经被添加到集群里面了：
1 | redis 127.0.0.1:7006> cluster nodes |
新节点现在已经连接上了集群， 成为集群的一份子， 并且可以对客户端的命令请求进行转向了， 但是和其他主节点相比， 新节点还有两点区别：
- 新节点没有包含任何数据， 因为它没有包含任何哈希桶。
- 尽管新节点没有包含任何哈希桶， 但它仍然是一个主节点， 所以在集群需要将某个从节点升级为新的主节点时， 这个新节点不会被选中。
接下来， 只要使用 redis-trib 程序， 将集群中的某些哈希桶移动到新节点里面， 新节点就会成为真正的主节点了。
因为使用 redis-trib 移动哈希桶的方法在前面已经介绍过， 所以这里就不再重复介绍了。
现在， 让我们来看看， 将一个新节点转变为某个主节点的复制品（也即是从节点）的方法。
举个例子， 如果我们打算让新节点成为 127.0.0.1:7005 的从节点， 那么我们只要用客户端连接上新节点， 然后执行以下命令就可以了：
1 | redis 127.0.0.1:7006> cluster replicate 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e |
其中命令提供的 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 就是主节点 127.0.0.1:7005 的节点 ID 。
执行 cluster replicate 命令之后， 我们可以使用以下命令来确认 127.0.0.1:7006 已经成为了 ID 为 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 的节点的从节点：
1 | $ redis-cli -p 7000 cluster nodes | grep slave | grep 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e |
3c3a0c… 现在有两个从节点， 一个从节点的端口号为 7002 ， 而另一个从节点的端口号为 7006 。
移除一个节点
未完待续。
键空间通知（keyspace notification）
功能概览
键空间通知使得客户端可以通过订阅频道或模式， 来接收那些以某种方式改动了 Redis 数据集的事件。
以下是一些键空间通知发送的事件的例子：
- 所有修改键的命令。
- 所有接收到 LPUSH key value [value …] 命令的键。
- 0 号数据库中所有已过期的键。
事件通过 Redis 的订阅与发布功能（pub/sub）来进行分发， 因此所有支持订阅与发布功能的客户端都可以在无须做任何修改的情况下， 直接使用键空间通知功能。
因为 Redis 目前的订阅与发布功能采取的是发送即忘（fire and forget）策略， 所以如果你的程序需要可靠事件通知（reliable notification of events）， 那么目前的键空间通知可能并不适合你： 当订阅事件的客户端断线时， 它会丢失所有在断线期间分发给它的事件。
未来将会支持更可靠的事件分发， 这种支持可能会通过让订阅与发布功能本身变得更可靠来实现， 也可能会在 Lua 脚本中对消息（message）的订阅与发布进行监听， 从而实现类似将事件推入到列表这样的操作。
事件的类型
对于每个修改数据库的操作，键空间通知都会发送两种不同类型的事件。
比如说，对 0 号数据库的键 mykey 执行 DEL key [key …] 命令时， 系统将分发两条消息， 相当于执行以下两个 PUBLISH channel message 命令：
1 | PUBLISH __keyspace@0__:mykey del |
订阅第一个频道 _keyspace@0_:mykey 可以接收 0 号数据库中所有修改键 mykey 的事件， 而订阅第二个频道 _keyevent@0_:del 则可以接收 0 号数据库中所有执行 del 命令的键。
以 keyspace 为前缀的频道被称为键空间通知（key-space notification）， 而以 keyevent 为前缀的频道则被称为键事件通知（key-event notification）。
当 del mykey 命令执行时：
- 键空间频道的订阅者将接收到被执行的事件的名字，在这个例子中，就是 del 。
- 键事件频道的订阅者将接收到被执行事件的键的名字，在这个例子中，就是 mykey 。
配置
因为开启键空间通知功能需要消耗一些 CPU ， 所以在默认配置下， 该功能处于关闭状态。
可以通过修改 redis.conf 文件， 或者直接使用 CONFIG SET 命令来开启或关闭键空间通知功能：
- 当 notify-keyspace-events 选项的参数为空字符串时，功能关闭。
- 另一方面，当参数不是空字符串时，功能开启。
notify-keyspace-events 的参数可以是以下字符的任意组合， 它指定了服务器该发送哪些类型的通知：
| 字符 | 发送的通知 |
|---|---|
| K | 键空间通知，所有通知以 _keyspace@<db>_ 为前缀 |
| E | 键事件通知，所有通知以 _keyevent@<db>_ 为前缀 |
| g | DEL 、 EXPIRE 、 RENAME 等类型无关的通用命令的通知 |
| $ | 字符串命令的通知 |
| l | 列表命令的通知 |
| s | 集合命令的通知 |
| h | 哈希命令的通知 |
| z | 有序集合命令的通知 |
| x | 过期事件：每当有过期键被删除时发送 |
| e | 驱逐(evict)事件：每当有键因为 maxmemory 政策而被删除时发送 |
| A | 参数 g$lshzxe 的别名 |
输入的参数中至少要有一个 K 或者 E ， 否则的话， 不管其余的参数是什么， 都不会有任何通知被分发。
举个例子， 如果只想订阅键空间中和列表相关的通知， 那么参数就应该设为 Kl ， 诸如此类。
将参数设为字符串 “AKE” 表示发送所有类型的通知。
命令产生的通知
以下列表记录了不同命令所产生的不同通知：
- DEL key [key …] 命令为每个被删除的键产生一个 del 通知。
- RENAME key newkey 产生两个通知：为来源键（source key）产生一个 rename_from 通知，并为目标键（destination key）产生一个 rename_to 通知。
- EXPIRE key seconds 和 EXPIREAT key timestamp 在键被正确设置过期时间时产生一个 expire 通知。当 EXPIREAT key timestamp 设置的时间已经过期，或者 EXPIRE key seconds 传入的时间为负数值时，键被删除，并产生一个 del 通知。
- SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern …]] [ASC | DESC] [ALPHA] [STORE destination] 在命令带有 STORE 参数时产生一个 sortstore 事件。如果 STORE 指示的用于保存排序结果的键已经存在，那么程序还会发送一个 del 事件。
- SET key value [EX seconds] [PX milliseconds] [NX|XX] 以及它的所有变种（SETEX key seconds value 、 SETNX key value 和 GETSET key value）都产生 set 通知。其中 SETEX key seconds value 还会产生 expire 通知。
- MSET key value [key value …] 为每个键产生一个 set 通知。
- SETRANGE key offset value 产生一个 setrange 通知。
- INCR key 、 DECR key 、 INCRBY key increment 和 DECRBY key decrement 都产生 incrby 通知。
- INCRBYFLOAT key increment 产生 incrbyfloat 通知。
- APPEND key value 产生 append 通知。
- LPUSH key value [value …] 和 LPUSHX key value 都产生单个 lpush 通知，即使有多个输入元素时，也是如此。
- RPUSH key value [value …] 和 RPUSHX key value 都产生单个 rpush 通知，即使有多个输入元素时，也是如此。
- RPOP key 产生 rpop 通知。如果被弹出的元素是列表的最后一个元素，那么还会产生一个 del 通知。
- LPOP key 产生 lpop 通知。如果被弹出的元素是列表的最后一个元素，那么还会产生一个 del 通知。
- LINSERT key BEFORE|AFTER pivot value 产生一个 linsert 通知。
- LSET key index value 产生一个 lset 通知。
- LTRIM key start stop 产生一个 ltrim 通知。如果 LTRIM key start stop 执行之后，列表键被清空，那么还会产生一个 del 通知。
- RPOPLPUSH source destination 和 BRPOPLPUSH source destination timeout 产生一个 rpop 通知，以及一个 lpush 通知。两个命令都会保证 rpop 的通知在 lpush 的通知之前分发。如果从键弹出元素之后，被弹出的列表键被清空，那么还会产生一个 del 通知。
- HSET hash field value 、 HSETNX hash field value 和 HMSET 都只产生一个 hset 通知。
- HINCRBY 产生一个 hincrby 通知。
- HINCRBYFLOAT 产生一个 hincrbyfloat 通知。
- HDEL 产生一个 hdel 通知。如果执行 HDEL 之后，哈希键被清空，那么还会产生一个 del 通知。
- SADD key member [member …] 产生一个 sadd 通知，即使有多个输入元素时，也是如此。
- SREM key member [member …] 产生一个 srem 通知，如果执行 SREM key member [member …] 之后，集合键被清空，那么还会产生一个 del 通知。
- SMOVE source destination member 为来源键（source key）产生一个 srem 通知，并为目标键（destination key）产生一个 sadd 事件。
- SPOP key 产生一个 spop 事件。如果执行 SPOP key 之后，集合键被清空，那么还会产生一个 del 通知。
- SINTERSTORE destination key [key …] 、 SUNIONSTORE destination key [key …] 和 SDIFFSTORE destination key [key …] 分别产生 sinterstore 、 sunionostore 和 sdiffstore 三种通知。如果用于保存结果的键已经存在，那么还会产生一个 del 通知。
- ZINCRBY key increment member 产生一个 zincr 通知。（译注：非对称，请注意。）
- ZADD key score member [[score member] [score member] …] 产生一个 zadd 通知，即使有多个输入元素时，也是如此。
- ZREM key member [member …] 产生一个 zrem 通知，即使有多个输入元素时，也是如此。如果执行 ZREM key member [member …] 之后，有序集合键被清空，那么还会产生一个 del 通知。
- ZREMRANGEBYSCORE key min max 产生一个 zrembyscore 通知。（译注：非对称，请注意。）如果用于保存结果的键已经存在，那么还会产生一个 del 通知。
- ZREMRANGEBYRANK key start stop 产生一个 zrembyrank 通知。（译注：非对称，请注意。）如果用于保存结果的键已经存在，那么还会产生一个 del 通知。
- ZINTERSTORE destination numkeys key [key …] [WEIGHTS weight [weight …]] [AGGREGATE SUM|MIN|MAX] 和 ZUNIONSTORE destination numkeys key [key …] [WEIGHTS weight [weight …]] [AGGREGATE SUM|MIN|MAX] 分别产生 zinterstore 和 zunionstore 两种通知。如果用于保存结果的键已经存在，那么还会产生一个 del 通知。
- 每当一个键因为过期而被删除时，产生一个 expired 通知。
- 每当一个键因为 maxmemory 政策而被删除以回收内存时，产生一个 evicted 通知。
Note
所有命令都只在键真的被改动了之后，才会产生通知。
比如说，当 SREM key member [member …] 试图删除不存在于集合的元素时，删除操作会执行失败，因为没有真正的改动键，所以这一操作不会发送通知。
如果对命令所产生的通知有疑问， 最好还是使用以下命令， 自己来验证一下：
1 | $ redis-cli config set notify-keyspace-events KEA |
然后， 只要在其他终端里用 Redis 客户端发送命令， 就可以看到产生的通知了：
1 | "pmessage","__key*__:*","__keyspace@0__:foo","set" |
过期通知的发送时间
Redis 使用以下两种方式删除过期的键：
- 当一个键被访问时，程序会对这个键进行检查，如果键已经过期，那么该键将被删除。
- 底层系统会在后台渐进地查找并删除那些过期的键，从而处理那些已经过期、但是不会被访问到的键。
当过期键被以上两个程序的任意一个发现、 并且将键从数据库中删除时， Redis 会产生一个 expired 通知。
Redis 并不保证生存时间（TTL）变为 0 的键会立即被删除： 如果程序没有访问这个过期键， 或者带有生存时间的键非常多的话， 那么在键的生存时间变为 0 ， 直到键真正被删除这中间， 可能会有一段比较显著的时间间隔。
因此， Redis 产生 expired 通知的时间为过期键被删除的时候， 而不是键的生存时间变为 0 的时候。
通信协议（protocol）
Redis 协议在以下三个目标之间进行折中：
- 易于实现
- 可以高效地被计算机分析（parse）
- 可以很容易地被人类读懂
网络层
客户端和服务器通过 TCP 连接来进行数据交互， 服务器默认的端口号为 6379 。
客户端和服务器发送的命令或数据一律以 \r\n （CRLF）结尾。
请求
Redis 服务器接受命令以及命令的参数。
服务器会在接到命令之后，对命令进行处理，并将命令的回复传送回客户端。
新版统一请求协议
新版统一请求协议在 Redis 1.2 版本中引入， 并最终在 Redis 2.0 版本成为 Redis 服务器通信的标准方式。
你的 Redis 客户端应该按照这个新版协议来进行实现。
在这个协议中， 所有发送至 Redis 服务器的参数都是二进制安全（binary safe）的。
以下是这个协议的一般形式：
1 | *<参数数量> CR LF |
Note
译注：命令本身也作为协议的其中一个参数来发送。
举个例子， 以下是一个命令协议的打印版本：
1 | *3 |
这个命令的实际协议值如下：
1 | "*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n" |
稍后我们会看到， 这种格式除了用作命令请求协议之外， 也用在命令的回复协议中： 这种只有一个参数的回复格式被称为批量回复（Bulk Reply）。
统一协议请求原本是用在回复协议中， 用于将列表的多个项返回给客户端的， 这种回复格式被称为多条批量回复（Multi Bulk Reply）。
一个多条批量回复以 *<argc>\r\n 为前缀， 后跟多条不同的批量回复， 其中 argc 为这些批量回复的数量。
回复
Redis 命令会返回多种不同类型的回复。
通过检查服务器发回数据的第一个字节， 可以确定这个回复是什么类型：
- 状态回复（status reply）的第一个字节是 “+”
- 错误回复（error reply）的第一个字节是 “-“
- 整数回复（integer reply）的第一个字节是 “:”
- 批量回复（bulk reply）的第一个字节是 “$”
- 多条批量回复（multi bulk reply）的第一个字节是 “*”
状态回复
一个状态回复（或者单行回复，single line reply）是一段以 “+” 开始、 “\r\n” 结尾的单行字符串。
以下是一个状态回复的例子：
1 | +OK |
客户端库应该返回 “+” 号之后的所有内容。 比如在在上面的这个例子中， 客户端就应该返回字符串 “OK” 。
状态回复通常由那些不需要返回数据的命令返回，这种回复不是二进制安全的，它也不能包含新行。
状态回复的额外开销非常少，只需要三个字节（开头的 “+” 和结尾的 CRLF）。
错误回复
错误回复和状态回复非常相似， 它们之间的唯一区别是， 错误回复的第一个字节是 “-“ ， 而状态回复的第一个字节是 “+” 。
错误回复只在某些地方出现问题时发送： 比如说， 当用户对不正确的数据类型执行命令， 或者执行一个不存在的命令， 等等。
一个客户端库应该在收到错误回复时产生一个异常。
以下是两个错误回复的例子：
1 | -ERR unknown command 'foobar' |
在 “-“ 之后，直到遇到第一个空格或新行为止，这中间的内容表示所返回错误的类型。
ERR 是一个通用错误，而 WRONGTYPE 则是一个更特定的错误。 一个客户端实现可以为不同类型的错误产生不同类型的异常， 或者提供一种通用的方式， 让调用者可以通过提供字符串形式的错误名来捕捉（trap）不同的错误。
不过这些特性用得并不多， 所以并不是特别重要， 一个受限的（limited）客户端可以通过简单地返回一个逻辑假（false）来表示一个通用的错误条件。
整数回复
整数回复就是一个以 “:” 开头， CRLF 结尾的字符串表示的整数。
比如说， “:0\r\n” 和 “:1000\r\n” 都是整数回复。
返回整数回复的其中两个命令是 INCR key 和 LASTSAVE 。 被返回的整数没有什么特殊的含义， INCR key 返回键的一个自增后的整数值， 而 LASTSAVE 则返回一个 UNIX 时间戳， 返回值的唯一限制是这些数必须能够用 64 位有符号整数表示。
整数回复也被广泛地用于表示逻辑真和逻辑假： 比如 EXISTS key 和 SISMEMBER key member 都用返回值 1 表示真， 0 表示假。
其他一些命令， 比如 SADD key member [member …] 、 SREM key member [member …] 和 SETNX key value ， 只在操作真正被执行了的时候， 才返回 1 ， 否则返回 0 。
以下命令都返回整数回复： SETNX key value 、 DEL key [key …] 、 EXISTS key 、 INCR key 、 INCRBY key increment 、 DECR key 、 DECRBY key decrement 、 DBSIZE 、 LASTSAVE 、 RENAMENX key newkey 、 MOVE key db 、 LLEN key 、 SADD key member [member …] 、 SREM key member [member …] 、 SISMEMBER key member 、 SCARD key 。
批量回复
服务器使用批量回复来返回二进制安全的字符串，字符串的最大长度为 512 MB 。
1 | 客户端：GET mykey |
服务器发送的内容中：
- 第一字节为 “$” 符号
- 接下来跟着的是表示实际回复长度的数字值
- 之后跟着一个 CRLF
- 再后面跟着的是实际回复数据
- 最末尾是另一个 CRLF
对于前面的 GET key 命令，服务器实际发送的内容为：
1 | "$6\r\nfoobar\r\n" |
如果被请求的值不存在， 那么批量回复会将特殊值 -1 用作回复的长度值， 就像这样：
1 | 客户端：GET non-existing-key |
这种回复称为空批量回复（NULL Bulk Reply）。
当请求对象不存在时，客户端应该返回空对象，而不是空字符串： 比如 Ruby 库应该返回 nil ， 而 C 库应该返回 NULL （或者在回复对象中设置一个特殊标志）， 诸如此类。
多条批量回复
像 LRANGE key start stop 这样的命令需要返回多个值， 这一目标可以通过多条批量回复来完成。
多条批量回复是由多个回复组成的数组， 数组中的每个元素都可以是任意类型的回复， 包括多条批量回复本身。
多条批量回复的第一个字节为 “*” ， 后跟一个字符串表示的整数值， 这个值记录了多条批量回复所包含的回复数量， 再后面是一个 CRLF 。
1 | 客户端： LRANGE mylist 0 3 |
在上面的示例中，服务器发送的所有字符串都由 CRLF 结尾。
正如你所见到的那样， 多条批量回复所使用的格式， 和客户端发送命令时使用的统一请求协议的格式一模一样。 它们之间的唯一区别是：
- 统一请求协议只发送批量回复。
- 而服务器应答命令时所发送的多条批量回复，则可以包含任意类型的回复。
以下例子展示了一个多条批量回复， 回复中包含四个整数值， 以及一个二进制安全字符串：
1 | *5\r\n |
在回复的第一行， 服务器发送 *5\r\n ， 表示这个多条批量回复包含 5 条回复， 再后面跟着的则是 5 条回复的正文。
多条批量回复也可以是空白的（empty）， 就像这样：
1 | 客户端： LRANGE nokey 0 1 |
无内容的多条批量回复（null multi bulk reply）也是存在的， 比如当 BLPOP key [key …] timeout 命令的阻塞时间超过最大时限时， 它就返回一个无内容的多条批量回复， 这个回复的计数值为 -1 ：
1 | 客户端： BLPOP key 1 |
客户端库应该区别对待空白多条回复和无内容多条回复： 当 Redis 返回一个无内容多条回复时， 客户端库应该返回一个 null 对象， 而不是一个空数组。
多条批量回复中的空元素
多条批量回复中的元素可以将自身的长度设置为 -1 ， 从而表示该元素不存在， 并且也不是一个空白字符串（empty string）。
当 SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern …]] [ASC | DESC] [ALPHA] [STORE destination] 命令使用 GET pattern 选项对一个不存在的键进行操作时， 就会发生多条批量回复中带有空白元素的情况。
以下例子展示了一个包含空元素的多重批量回复：
1 | 服务器： *3 |
其中， 回复中的第二个元素为空。
对于这个回复， 客户端库应该返回类似于这样的回复：
1 | ["foo", nil, "bar"] |
多命令和流水线
客户端可以通过流水线， 在一次写入操作中发送多个命令：
- 在发送新命令之前， 无须阅读前一个命令的回复。
- 多个命令的回复会在最后一并返回。
内联命令
当你需要和 Redis 服务器进行沟通， 但又找不到 redis-cli ， 而手上只有 telnet 的时候， 你可以通过 Redis 特别为这种情形而设的内联命令格式来发送命令。
以下是一个客户端和服务器使用内联命令来进行交互的例子：
1 | 客户端： PING |
以下另一个返回整数值的内联命令的例子：
1 | 客户端： EXISTS somekey |
因为没有了统一请求协议中的 “*” 项来声明参数的数量， 所以在 telnet 会话输入命令的时候， 必须使用空格来分割各个参数， 服务器在接收到数据之后， 会按空格对用户的输入进行分析（parse）， 并获取其中的命令参数。
高性能 Redis 协议分析器
尽管 Redis 的协议非常利于人类阅读， 定义也很简单， 但这个协议的实现性能仍然可以和二进制协议一样快。
因为 Redis 协议将数据的长度放在数据正文之前， 所以程序无须像 JSON 那样， 为了寻找某个特殊字符而扫描整个 payload ， 也无须对发送至服务器的 payload 进行转义（quote）。
程序可以在对协议文本中的各个字符进行处理的同时， 查找 CR 字符， 并计算出批量回复或多条批量回复的长度， 就像这样：
1 |
|
得到了批量回复或多条批量回复的长度之后， 程序只需调用一次 read 函数， 就可以将回复的正文数据全部读入到内存中， 而无须对这些数据做任何的处理。
在回复最末尾的 CR 和 LF 不作处理，丢弃它们。
Redis 协议的实现性能可以和二进制协议的实现性能相媲美， 并且由于 Redis 协议的简单性， 大部分高级语言都可以轻易地实现这个协议， 这使得客户端软件的 bug 数量大大减少。
复制（Replication）
Redis 支持简单且易用的主从复制（master-slave replication）功能， 该功能可以让从服务器(slave server)成为主服务器(master server)的精确复制品。
以下是关于 Redis 复制功能的几个重要方面：
Redis 使用异步复制。 从 Redis 2.8 开始， 从服务器会以每秒一次的频率向主服务器报告复制流（replication stream）的处理进度。
一个主服务器可以有多个从服务器。
不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器， 多个从服务器之间可以构成一个图状结构。
复制功能不会阻塞主服务器： 即使有一个或多个从服务器正在进行初次同步， 主服务器也可以继续处理命令请求。
复制功能也不会阻塞从服务器： 只要在 redis.conf 文件中进行了相应的设置， 即使从服务器正在进行初次同步， 服务器也可以使用旧版本的数据集来处理命令查询。
不过， 在从服务器删除旧版本数据集并载入新版本数据集的那段时间内， 连接请求会被阻塞。
你还可以配置从服务器， 让它在与主服务器之间的连接断开时， 向客户端发送一个错误。
复制功能可以单纯地用于数据冗余（data redundancy）， 也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）： 比如说， 繁重的 SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern …]] [ASC | DESC] [ALPHA] [STORE destination] 命令可以交给附属节点去运行。
可以通过复制功能来让主服务器免于执行持久化操作： 只要关闭主服务器的持久化功能， 然后由从服务器去执行持久化操作即可。
关闭主服务器持久化时，复制功能的数据安全
当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。 否则的话，由于延迟等问题，部署的服务应该要避免自动拉起。
为了帮助理解主服务器关闭持久化时自动拉起的危险性，参考一下以下会导致主从服务器数据全部丢失的例子：
假设节点A为主服务器，并且关闭了持久化。 并且节点B和节点C从节点A复制数据
节点A崩溃，然后由自动拉起服务重启了节点A. 由于节点A的持久化被关闭了，所以重启之后没有任何数据
节点B和节点C将从节点A复制数据，但是A的数据是空的， 于是就把自身保存的数据副本删除。
在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现Redis的高可用性，也是非常危险的。 因为主服务器可能拉起得非常快，以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流程。
无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动拉起。
复制功能的运作原理
无论是初次连接还是重新连接， 当建立一个从服务器时， 从服务器都将向主服务器发送一个 SYNC 命令。
接到 SYNC 命令的主服务器将开始执行 BGSAVE ， 并在保存操作执行期间， 将所有新执行的写入命令都保存到一个缓冲区里面。
当 BGSAVE 执行完毕后， 主服务器将执行保存操作所得的 .rdb 文件发送给从服务器， 从服务器接收这个 .rdb 文件， 并将文件中的数据载入到内存中。
之后主服务器会以 Redis 命令协议的格式， 将写命令缓冲区中积累的所有内容都发送给从服务器。
你可以通过 telnet 命令来亲自验证这个同步过程： 首先连上一个正在处理命令请求的 Redis 服务器， 然后向它发送 SYNC 命令， 过一阵子， 你将看到 telnet 会话（session）接收到服务器发来的大段数据（.rdb 文件）， 之后还会看到， 所有在服务器执行过的写命令， 都会重新发送到 telnet 会话来。
即使有多个从服务器同时向主服务器发送 SYNC ， 主服务器也只需执行一次 BGSAVE 命令， 就可以处理所有这些从服务器的同步请求。
从服务器可以在主从服务器之间的连接断开时进行自动重连， 在 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 master_run_id offset 内部命令， 而 Redis 2.8 以前的旧版本只有 SYNC 命令， 不过， 只要从服务器是 Redis 2.8 或以上的版本， 它就会根据主服务器的版本来决定到底是使用 PSYNC master_run_id offset 还是 SYNC ：
- 如果主服务器是 Redis 2.8 或以上版本，那么从服务器使用 PSYNC master_run_id offset 命令来进行同步。
- 如果主服务器是 Redis 2.8 之前的版本，那么从服务器使用 SYNC 命令来进行同步。
配置
配置一个从服务器非常简单， 只要在配置文件中增加以下的这一行就可以了：
1 | slaveof 192.168.1.1 6379 |
当然， 你需要将代码中的 192.168.1.1 和 6379 替换成你的主服务器的 IP 和端口号。
另外一种方法是调用 SLAVEOF host port 命令， 输入主服务器的 IP 和端口， 然后同步就会开始：
1 | 127.0.0.1:6379> SLAVEOF 192.168.1.1 10086 |
只读从服务器
从 Redis 2.6 开始， 从服务器支持只读模式， 并且该模式为从服务器的默认模式。
只读模式由 redis.conf 文件中的 slave-read-only 选项控制， 也可以通过 CONFIG SET parameter value 命令来开启或关闭这个模式。
只读从服务器会拒绝执行任何写命令， 所以不会出现因为操作失误而将数据不小心写入到了从服务器的情况。
即使从服务器是只读的， DEBUG 和 CONFIG 等管理式命令仍然是可以使用的， 所以我们还是不应该将服务器暴露给互联网或者任何不可信网络。 不过， 使用 redis.conf 中的命令改名选项， 我们可以通过禁止执行某些命令来提升只读从服务器的安全性。
你可能会感到好奇， 既然从服务器上的写数据会被重同步数据覆盖， 也可能在从服务器重启时丢失， 那么为什么要让一个从服务器变得可写呢？
原因是， 一些不重要的临时数据， 仍然是可以保存在从服务器上面的。 比如说， 客户端可以在从服务器上保存主服务器的可达性（reachability）信息， 从而实现故障转移（failover）策略。
从服务器相关配置
如果主服务器通过 requirepass 选项设置了密码， 那么为了让从服务器的同步操作可以顺利进行， 我们也必须为从服务器进行相应的身份验证设置。
对于一个正在运行的服务器， 可以使用客户端输入以下命令：
1 | config set masterauth <password> |
要永久地设置这个密码， 那么可以将它加入到配置文件中：
1 | 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 示例文件。
事务（transaction）
MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务的基础。
事务可以一次执行多个命令， 并且带有以下两个重要的保证：
事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
EXEC 命令负责触发并执行事务中的所有命令：
- 如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。
- 另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。
当使用 AOF 方式做持久化的时候， Redis 会使用单个 write(2) 命令将事务写入到磁盘中。
然而，如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可能只有部分事务命令会被成功写入到磁盘中。
如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错误。
使用 redis-check-aof 程序可以修复这一问题：它会移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动。
从 2.2 版本开始，Redis 还可以通过乐观锁（optimistic lock）实现 CAS （check-and-set）操作，具体信息请参考文档的后半部分。
用法
MULTI 命令用于开启一个事务，它总是返回 OK 。
MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC 命令被调用时， 所有队列中的命令才会被执行。
另一方面， 通过调用 DISCARD ， 客户端可以清空事务队列， 并放弃执行事务。
以下是一个事务例子， 它原子地增加了 foo 和 bar 两个键的值：
1 | > MULTI |
EXEC 命令的回复是一个数组， 数组中的每个元素都是执行事务中的命令所产生的回复。 其中， 回复元素的先后顺序和命令发送的先后顺序一致。
当客户端处于事务状态时， 所有传入的命令都会返回一个内容为 QUEUED 的状态回复（status reply）， 这些被入队的命令将在 EXEC 命令被调用时执行。
事务中的错误
使用事务时可能会遇上以下两种错误：
- 事务在执行 EXEC 之前，入队的命令可能会出错。比如说，命令可能会产生语法错误（参数数量错误，参数名错误，等等），或者其他更严重的错误，比如内存不足（如果服务器使用 maxmemory 设置了最大内存限制的话）。
- 命令可能在 EXEC 调用之后失败。举个例子，事务中的命令可能处理了错误类型的键，比如将列表命令用在了字符串键上面，诸如此类。
对于发生在 EXEC 执行之前的错误，客户端以前的做法是检查命令入队所得的返回值：如果命令入队时返回 QUEUED ，那么入队成功；否则，就是入队失败。如果有命令在入队时失败，那么大部分客户端都会停止并取消这个事务。
不过，从 Redis 2.6.5 开始，服务器会对命令入队失败的情况进行记录，并在客户端调用 EXEC 命令时，拒绝执行并自动放弃这个事务。
在 Redis 2.6.5 以前， Redis 只执行事务中那些入队成功的命令，而忽略那些入队失败的命令。 而新的处理方式则使得在流水线（pipeline）中包含事务变得简单，因为发送事务和读取事务的回复都只需要和服务器进行一次通讯。
至于那些在 EXEC 命令执行之后所产生的错误， 并没有对它们进行特别处理： 即使事务中有某个/某些命令在执行时产生了错误， 事务中的其他命令仍然会继续执行。
从协议的角度来看这个问题，会更容易理解一些。 以下例子中， LPOP key 命令的执行将出错， 尽管调用它的语法是正确的：
1 | Trying 127.0.0.1... |
EXEC 返回两条批量回复（bulk reply）： 第一条是 OK ，而第二条是 -ERR 。 至于怎样用合适的方法来表示事务中的错误， 则是由客户端自己决定的。
最重要的是记住这样一条， 即使事务中有某条/某些命令执行失败了， 事务队列中的其他命令仍然会继续执行 —— Redis 不会停止执行事务中的命令。
以下例子展示的是另一种情况， 当命令在入队时产生错误， 错误会立即被返回给客户端：
1 | MULTI |
因为调用 INCR key 命令的参数格式不正确， 所以这个 INCR key 命令入队失败。
为什么 Redis 不支持回滚（roll back）
如果你有使用关系式数据库的经验， 那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。
以下是这种做法的优点：
- Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
- 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。
有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR key 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR key ， 回滚是没有办法处理这些情况的。
鉴于没有任何机制能避免程序员自己造成的错误， 并且这类错误通常不会在生产环境中出现， 所以 Redis 选择了更简单、更快速的无回滚方式来处理事务。
放弃事务
当执行 DISCARD 命令时， 事务会被放弃， 事务队列会被清空， 并且客户端会从事务状态中退出：
1 | redis> SET foo 1 |
使用 check-and-set 操作实现乐观锁
WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。
被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回空多条批量回复（null multi-bulk reply）来表示事务已经失败。
举个例子， 假设我们需要原子性地为某个值进行增 1 操作（假设 INCR key 不存在）。
首先我们可能会这样做：
1 | val = GET mykey |
上面的这个实现在只有一个客户端的时候可以执行得很好。 但是， 当多个客户端同时对同一个键进行这样的操作时， 就会产生竞争条件。
举个例子， 如果客户端 A 和 B 都读取了键原来的值， 比如 10 ， 那么两个客户端都会将键的值设为 11 ， 但正确的结果应该是 12 才对。
有了 WATCH ， 我们就可以轻松地解决这类问题了：
1 | WATCH mykey |
使用上面的代码， 如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。
这种形式的锁被称作乐观锁， 它是一种非常强大的锁机制。 并且因为大多数情况下， 不同的客户端会访问不同的键， 碰撞的情况一般都很少， 所以通常并不需要进行重试。
了解 WATCH
WATCH 使得 EXEC 命令需要有条件地执行： 事务只能在所有被监视键都没有被修改的前提下执行， 如果这个前提不能满足的话，事务就不会被执行。
Note
如果你使用 WATCH 监视了一个带过期时间的键， 那么即使这个键过期了， 事务仍然可以正常执行， 关于这方面的详细情况，请看这个帖子： http://code.google.com/p/redis/issues/detail?id=270
WATCH 命令可以被调用多次。 对键的监视从 WATCH 执行之后开始生效， 直到调用 EXEC 为止。
用户还可以在单个 WATCH 命令中监视任意多个键， 就像这样：
1 | redis> WATCH key1 key2 key3 |
当 EXEC 被调用时， 不管事务是否成功执行， 对所有键的监视都会被取消。
另外， 当客户端断开连接时， 该客户端对键的监视也会被取消。
使用无参数的 UNWATCH 命令可以手动取消对所有键的监视。 对于一些需要改动多个键的事务， 有时候程序需要同时对多个键进行加锁， 然后检查这些键的当前值是否符合程序的要求。 当值达不到要求时， 就可以使用 UNWATCH 命令来取消目前对键的监视， 中途放弃这个事务， 并等待事务的下次尝试。
使用 WATCH 实现 ZPOP
WATCH 可以用于创建 Redis 没有内置的原子操作。
举个例子， 以下代码实现了原创的 ZPOP 命令， 它可以原子地弹出有序集合中分值（score）最小的元素：
1 | WATCH zset |
程序只要重复执行这段代码， 直到 EXEC 的返回值不是空多条回复（null multi-bulk reply）即可。
Redis 脚本和事务
从定义上来说， Redis 中的脚本本身就是一种事务， 所以任何在事务里可以完成的事， 在脚本里面也能完成。 并且一般来说， 使用脚本要来得更简单，并且速度更快。
因为脚本功能是 Redis 2.6 才引入的， 而事务功能则更早之前就存在了， 所以 Redis 才会同时存在两种处理事务的方法。
不过我们并不打算在短时间内就移除事务功能， 因为事务提供了一种即使不使用脚本， 也可以避免竞争条件的方法， 而且事务本身的实现并不复杂。
不过在不远的将来， 可能所有用户都会只使用脚本来实现事务也说不定。 如果真的发生这种情况的话， 那么我们将废弃并最终移除事务功能。
