主从复制

Redis 支持简单且易用的主从复制（master-slave replication）功能以下是关于 Redis 复制功能的几个重要方面：

Redis 使用异步复制。从 Redis 2.8 开始，从服务器会以每秒一次的频率向主服务器报告复制流的处理进度。
一个主服务器可以有多个从服务器。
不仅主服务器可以有从服务器，从服务器也可以有自己的从服务器，多个从服务器之间可以构成一个图状结构。
复制功能不会阻塞主服务器：即使有一个或多个从服务器正在进行初次同步，主服务器也可以继续处理命令请求。
复制功能也不会阻塞从服务器：只要在 redis.conf 文件中进行了相应的设置，即使从服务器正在进行初次同步，服务器也可以使用旧版本的数据集来处理命令查询。

不过，在从服务器删除旧版本数据集并载入新版本数据集的那段时间内，连接请求会被阻塞。

你还可以配置从服务器，让它在与主服务器之间的连接断开时，向客户端发送一个错误。

复制功能可以单纯地用于数据冗余，也可以通过让多个从服务器处理只读命令请求来提升扩展性如常用的读写分离。写操作在主服务器上执行，读操作在从服务器。redis 默认也是这么配置的，从服务器默认只支持读操作。

可以通过复制功能来让主服务器免于执行持久化操作：只要关闭主服务器的持久化功能，然后由从服务器去执行持久化操作即可。

复制功能的运作原理

无论是初次连接还是重新连接，当建立一个从服务器时，从服务器都将向主服务器发送一个 SYNC 命令。
接到 SYNC 命令的主服务器将开始执行 BGSAVE ，并在保存操作执行期间，将所有新执行的写入命令都保存到一个缓冲区里面。
当 BGSAVE 执行完毕后，主服务器将执行保存操作所得的 .rdb 文件发送给从服务器，从服务器接收这个 .rdb 文件，并将文件中的数据载入到内存中。
之后主服务器会以 Redis 命令协议的格式，将写命令缓冲区中积累的所有内容都发送给从服务器。

即使有多个从服务器同时向主服务器发送 SYNC ，主服务器也只需执行一次 BGSAVE 命令，就可以处理所有这些从服务器的同步请求。

从服务器可以在主从服务器之间的连接断开时进行自动重连，在 Redis 2.8 版本之前，断线之后重连的从服务器总要执行一次完整重同步操作，但是从 Redis 2.8 版本开始，从服务器可以根据主服务器的情况来选择执行完整重同步还是部分重同步。

部分重同步

从 Redis 2.8 开始，在网络连接短暂性失效之后，主从服务器可以尝试继续执行原有的复制进程，而不一定要执行完整重同步操作。

这个特性需要主服务器为被发送的复制流创建一个内存缓冲区，并且主服务器和所有从服务器之间都记录一个复制偏移量和一个主服务器 ID，当出现网络连接断开时，从服务器会重新连接，并且向主服务器请求继续执行原来的复制进程：

如果从服务器记录的主服务器 ID 和当前要连接的主服务器的 ID 相同，并且从服务器记录的偏移量所指定的数据仍然保存在主服务器的复制流缓冲区里面，那么主服务器会向从服务器发送断线时缺失的那部分数据，然后复制工作可以继续执行。

否则的话，从服务器就要执行完整重同步操作。

Redis 2.8 的这个部分重同步特性会用到一个新增的 PSYNC 内部命令，而 Redis 2.8 以前的旧版本只有 SYNC 命令，不过，只要从服务器是 Redis 2.8 或以上的版本，它就会根据主服务器的版本来决定到底是使用 PSYNC 还是 SYNC ：

如果主服务器是 Redis 2.8 或以上版本，那么从服务器使用 PSYNC 命令来进行同步。

如果主服务器是 Redis 2.8 之前的版本，那么从服务器使用 SYNC 命令来进行同步。

主从结构配置

配置一个从服务器非常简单，只要在配置文件中增加以下的这一行就可以了：

slaveof 192.168.1.1 6379

当然，你需要将代码中的 192.168.1.1 和 6379 替换成你的主服务器的 IP 和端口号。

另外一种方法是调用 SLAVEOF 命令，输入主服务器的 IP 和端口，然后同步就会开始：

127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK

只读从服务器

从 Redis 2.6 开始，从服务器支持只读模式，并且该模式为从服务器的默认模式。

只读模式由 redis.conf 文件中的 slave-read-only 选项控制，也可以通过 CONFIG SET 命令来开启或关闭这个模式。

只读从服务器会拒绝执行任何写命令，所以不会出现因为操作失误而将数据不小心写入到了从服务器的情况。

从服务器其它配置

如果主服务器通过 requirepass 选项设置了密码，那么为了让从服务器的同步操作可以顺利进行，我们也必须为从服务器进行相应的身份验证设置。

对于一个正在运行的服务器，可以使用客户端输入以下命令：

config set masterauth

要永久地设置这个密码，那么可以将它加入到配置文件中：

masterauth youpassword

至少 N 个从服务器连接的情况下，才执行写操作

从 Redis 2.8 开始，为了保证数据的安全性，可以通过配置，让主服务器只在有至少 N 个当前已连接从服务器的情况下，才执行写命令，为的是保证写入的内容会成功的传输到从机上。

不过，因为 Redis 使用异步复制，所以主服务器发送的写数据并不一定会被从服务器接收到，因此，数据丢失的可能性仍然是存在的。

以下是这个特性的运作原理：

从服务器以每秒一次的频率 PING 主服务器一次，并报告复制流的处理情况。
主服务器会记录各个从服务器最后一次向它发送 PING 的时间。
用户可以通过配置，指定网络延迟的最大值 min-slaves-max-lag ，以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。
如果至少有 min-slaves-to-write 个从服务器，并且这些服务器的延迟值都少于 min-slaves-max-lag 秒，那么主服务器就会执行客户端请求的写操作。
如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件，那么写操作就不会被执行，主服务器会向请求执行写操作的客户端返回一个错误。

实践

主库只RDB备份，从机AOF 从机 read-only

若主机挂了，不要直接重启；会把从机的AOF覆盖

info commandstats/config resetstat 查看所有命令的统计信息，后面是重置统计
redis-cli -h localhost -p 6379 client list | grep -v "omem=0" 快速找到引起阻塞的

命令删除大的列表时的阻塞–不直接删除这种大的集合，而是将他们重命名然后后台跑一个删除进程慢慢删

用 scan 代替 key*，孩子一次扫描过多的key 可以按主-从-从结构。这样主机挂后，第一从机直接升为主机就行了。

集群

Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施。

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 集群中的主从复制

为了使得集群在一部分节点下线或者无法与集群的大多数节点进行通讯的情况下，仍然可以正常运作， 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 集群的一致性保证

Redis 集群不保证数据的强一致性（strong consistency）：在特定条件下， Redis 集群可能会丢失已经被执行过的写命令。

使用异步复制（asynchronous replication）是 Redis 集群可能会丢失写命令的其中一个原因。

考虑以下这个写命令的例子：

客户端向主节点 B 发送一条写命令。
主节点 B 执行写命令，并向客户端返回命令回复。
主节点 B 将刚刚执行的写命令复制给它的从节点 B1 、 B2 和 B3 。

主节点对命令的复制工作发生在返回命令回复之后，因为如果每次处理命令请求都需要等待复制操作完成的话，那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。

Redis 集群另外一种可能会丢失命令的情况,如下例:

假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点，其中 A 、B 、C 为主节点，而 A1 、B1 、C1 分别为三个主节点的从节点，另外还有一个客户端 Z1 。

假设集群中发生网络分裂，那么集群可能会分裂为两方，大多数（majority）的一方包含节点 A 、C 、A1 、B1 和 C1 ，而少数（minority）的一方则包含节点 B 和客户端 Z1 。这时候分裂的两方是互相不通的，即：A、C 等会认为 B 已经下线，且客户端 Z1 只能和 B 连通。

在网络分裂期间，主节点 B 仍然会接受 Z1 发送的写命令：

如果网络分裂出现的时间很短，那么集群会继续正常运行；

但是，如果网络分裂出现的时间足够长，使得大多数一方将从节点 B1 设置为新的主节点，并使用 B1 来代替原来的主节点 B ，那么 Z1 发送给主节点 B 的写命令将丢失。

注意，在网络分裂出现期间，客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的，这一时间限制称为节点超时时间（node timeout），是 Redis 集群的一个重要的配置选项：

对于大多数一方来说，如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群，那么集群会将这个主节点视为下线，并使用从节点来代替这个主节点继续工作。

对于少数一方，如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群，那么它将停止处理写命令，并向客户端报告错误。

创建并使用 Redis 集群

Redis 集群由多个运行在集群模式（cluster mode）下的 Redis 实例组成，实例的集群模式需要通过配置来开启，开启集群模式的实例将可以使用集群特有的功能和命令。

以下是一个包含了最少选项的集群配置文件示例：

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

文件中的 cluster-enabled 选项用于开实例的集群模式，而 cluster-conf-file 选项则设定了保存节点配置文件的路径，默认值为 nodes.conf 。

节点配置文件无须人为修改，它由 Redis 集群在启动时创建，并在有需要时自动进行更新。

要让集群正常运作至少需要三个主节点，不过在刚开始试用集群功能时，强烈建议使用六个节点：其中三个为主节点，而其余三个则是各个主节点的从节点。

首先，让我们进入一个新目录，并创建六个以端口号为名字的子目录，稍后我们在将每个目录中运行一个 Redis 实例：

mkdir cluster-test
cd cluster-test
mkdir 7000 7001 7002 7003 7004 7005

在文件夹 7000 至 7005 中，各创建一个 redis.conf 文件，文件的内容可以使用上面的示例配置文件，但记得将配置中的端口号从 7000 改为与文件夹名字相同的号码。

现在，从 Redis Github 页面的 unstable 分支中取出最新的 Redis 源码，编译出可执行文件 redis-server ，并将文件复制到 cluster-test 文件夹，然后使用类似以下命令，在每个标签页中打开一个实例：

cd 7000
../redis-server ./redis.conf

实例打印的日志显示，因为 nodes.conf 文件不存在，所以每个节点都为它自身指定了一个新的 ID ：

[82462] 26 Nov 11:56:55.329 * No cluster configuration found, I'm 97a3a64667477371c4479320d683e4c8db5858b1

实例会一直使用同一个 ID ，从而在集群中保持一个独一无二的名字。

每个节点都使用 ID 而不是 IP 或者端口号来记录其他节点，因为 IP 地址和端口号都可能会改变，而这个独一无二的标识符（identifier）则会在节点的整个生命周期中一直保持不变。

我们将这个标识符称为节点 ID。

创建集群

现在我们已经有了六个正在运行中的 Redis 实例，接下来我们需要使用这些实例来创建集群，并为每个节点编写配置文件。

通过使用 Redis 集群命令行工具 redis-trib ，编写节点配置文件的工作可以非常容易地完成： redis-trib 位于 Redis 源码的 src 文件夹中，它是一个 Ruby 程序，这个程序通过向实例发送特殊命令来完成创建新集群，检查集群，或者对集群进行重新分片（reshared）等工作。

我们需要执行以下命令来创建集群：

./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

命令的意义如下：

给定 redis-trib.rb 程序的命令是 create ，这表示我们希望创建一个新的集群。
选项 –replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。
之后跟着的其他参数则是实例的地址列表，我们希望程序使用这些地址所指示的实例来创建新集群。

简单来说，以上命令的意思就是让 redis-trib 程序创建一个包含三个主节点和三个从节点的集群。

接着， redis-trib 会打印出一份预想中的配置给你看，如果你觉得没问题的话，就可以输入 yes ， redis-trib 就会将这份配置应用到集群当中：

>>> Creating cluster
Connecting to node 127.0.0.1:7000: OK
Connecting to node 127.0.0.1:7001: OK
Connecting to node 127.0.0.1:7002: OK
Connecting to node 127.0.0.1:7003: OK
Connecting to node 127.0.0.1:7004: OK
Connecting to node 127.0.0.1:7005: OK
>>> Performing hash slots allocation on 6 nodes...
Using 3 masters:
127.0.0.1:7000
127.0.0.1:7001
127.0.0.1:7002
127.0.0.1:7000 replica #1 is 127.0.0.1:7003
127.0.0.1:7001 replica #1 is 127.0.0.1:7004
127.0.0.1:7002 replica #1 is 127.0.0.1:7005
M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000
slots:0-5460 (5461 slots) master
M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001
slots:5461-10921 (5461 slots) master
M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002
slots:10922-16383 (5462 slots) master
S: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003
S: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004
S: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005
Can I set the above configuration? (type 'yes' to accept): yes

输入 yes 并按下回车确认之后，集群就会将配置应用到各个节点，并连接起（join）各个节点 —— 也即是，让各个节点开始互相通讯：

>>> Nodes configuration updated
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join...
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000
slots:0-5460 (5461 slots) master
M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001
slots:5461-10921 (5461 slots) master
M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002
slots:10922-16383 (5462 slots) master
M: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003
slots: (0 slots) master
M: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004
slots: (0 slots) master
M: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005
slots: (0 slots) master
[OK] All nodes agree about slots configuration.

如果一切正常的话， redis-trib 将输出以下信息：

>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

这表示集群中的 16384 个槽都有至少一个主节点在处理，集群运作正常。

集群客户端

Redis 集群现阶段的一个问题是客户端实现很少。以下是一些我知道的实现：

redis-rb-cluster 是作者编写的 Ruby 实现，用于作为其他实现的参考。该实现是对 redis-rb 的一个简单包装，高效地实现了与集群进行通讯所需的最少语义。

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 为例来进行演示：

$ redis-cli -c -p 7000
redis 127.0.0.1:7000> set foo bar
-> Redirected to slot [12182] located at 127.0.0.1:7002
OK

redis 127.0.0.1:7002> set hello world
-> Redirected to slot [866] located at 127.0.0.1:7000
OK

redis 127.0.0.1:7000> get foo
-> Redirected to slot [12182] located at 127.0.0.1:7002
"bar"

redis 127.0.0.1:7000> get hello
-> Redirected to slot [866] located at 127.0.0.1:7000
"world"

redis-cli 对集群的支持是非常基本的，所以它总是依靠 Redis 集群节点来将它转向（redirect）至正确的节点。

一个真正的集群客户端应该做得比这更好：它应该用缓存记录起哈希槽与节点地址之间的映射（map），从而直接将命令发送到正确的节点上面。

这种映射只会在集群的配置出现某些修改时变化, 比如在一次故障转移之后，或者系统管理员通过添加节点或移除节点来修改了集群的布局之后，诸如此类。

Redis主从/集群