redis分片机制

 所谓的分片其实就是大的数据分红几个小的部分，分别放置存储，对于数据而言无外乎就是读写，读写的基础就是数据的定位，redis利用集群的方式+槽位完成，分片的数据的定位和管理维护。

   Redis 集群是一个能够在多个 Redis 节点之间进行数据共享的设施（installation）。

Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 数据库中的每一个键都属于这 16384 个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪一个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。

1. 槽位分配

集群中的每一个节点负责处理一部分哈希槽。 举个例子， 一个集群能够有三个哈希槽， 其中：

• 节点 A 负责处理 0 号至 5500 号哈希槽。
• 节点 B 负责处理 5501 号至 11000 号哈希槽。
• 节点 C 负责处理 11001 号至 16384 号哈希槽。

这种将哈希槽分布到不一样节点的作法使得用户能够很容易地向集群中添加或者删除节点。 好比说：

• 若是用户将新节点 D 添加到集群中， 那么集群只须要将节点 A 、B 、 C 中的某些槽移动到节点 D 就能够了。
• 与此相似， 若是用户要从集群中移除节点 A ， 那么集群只须要将节点 A 中的全部哈希槽移动到节点 B 和节点 C ， 而后再移除空白（不包含任何哈希槽）的节点 A 就能够了。

由于将一个哈希槽从一个节点移动到另外一个节点不会形成节点阻塞， 因此不管是添加新节点仍是移除已存在节点， 又或者改变某个节点包含的哈希槽数量， 都不会形成集群下线。

  2.高可用性

为了使得集群在一部分节点下线或者没法与集群的大多数（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 集群仍是会中止运做

3.一致性保证(非强一致性)

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

使用异步复制（asynchronous replication）是 Redis 集群可能会丢失写命令的其中一个缘由。 考虑如下这个写命令的例子：

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

如你所见， 主节点对命令的复制工做发生在返回命令回复以后， 由于若是每次处理命令请求都须要等待复制操做完成的话， 那么主节点处理命令请求的速度将极大地下降 —— 咱们必须在性能和一致性之间作出权衡。

4.建立集群(不详说啦，参照个人另外一篇博客)

如今咱们已经有了六个正在运行中的 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 个槽都有至少一个主节点在处理， 集群运做正常。

5.从新分区

如今， 让咱们来试试对集群进行从新分片操做。

在执行从新分片的过程当中， 请让你的 example.rb 程序处于运行状态， 这样你就会看到， 从新分片并不会对正在运行的集群程序产生任何影响， 你也能够考虑将 example.rb 中的 sleep 调用删掉， 从而让从新分片操做在近乎真实的写负载下执行。

从新分片操做基本上就是将某些节点上的哈希槽移动到另一些节点上面， 和建立集群同样， 从新分片也可使用 redis-trib 程序来执行。

执行如下命令能够开始一次从新分片操做：

$ ./redis-trib.rb reshard 127.0.0.1:7000

你只须要指定集群中其中一个节点的地址， redis-trib 就会自动找到集群中的其余节点。

目前 redis-trib 只能在管理员的协助下完成从新分片的工做， 要让 redis-trib 自动将哈希槽从一个节点移动到另外一个节点， 目前来讲还作不到 （不过实现这个功能并不难）。

执行 redis-trib 的第一步就是设定你打算移动的哈希槽的数量：

$ ./redis-trib.rb reshard 127.0.0.1:7000
Connecting to node 127.0.0.1:7000: OK
Connecting to node 127.0.0.1:7002: OK
Connecting to node 127.0.0.1:7005: OK
Connecting to node 127.0.0.1:7001: OK
Connecting to node 127.0.0.1:7003: OK
Connecting to node 127.0.0.1:7004: OK
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000
slots:0-5460 (5461 slots) master
M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002
slots:10922-16383 (5462 slots) master
S: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005
slots: (0 slots) slave
M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001
slots:5461-10921 (5461 slots) master
S: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003
slots: (0 slots) slave
S: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004
slots: (0 slots) slave
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 1000

咱们将打算移动的槽数量设置为 1000 个， 若是 example.rb 程序一直运行着的话， 如今 1000 个槽里面应该有很多键了。

除了移动的哈希槽数量以外， redis-trib 还须要知道从新分片的目标（target node）， 也便是， 负责接收这 1000 个哈希槽的节点。

指定目标须要使用节点的 ID ， 而不是 IP 地址和端口。 好比说， 咱们打算使用集群的第一个主节点来做为目标， 它的 IP 地址和端口是 127.0.0.1:7000 ， 而节点 ID 则是 9991306f0e50640a5684f1958fd754b38fa034c9 ， 那么咱们应该向 redis-trib 提供节点的 ID ：

$ ./redis-trib.rb reshard 127.0.0.1:7000
...
What is the receiving node ID? 9991306f0e50640a5684f1958fd754b38fa034c9

redis-trib 会打印出集群中全部节点的 ID ， 而且咱们也能够经过执行如下命令来得到节点的运行 ID ：

$ ./redis-cli -p 7000 cluster nodes | grep myself
9991306f0e50640a5684f1958fd754b38fa034c9 :0 myself,master - 0 0 0 connected 0-5460

接着， redis-trib 会向你询问从新分片的源节点（source node）， 也便是， 要从哪一个节点中取出 1000 个哈希槽， 并将这些槽移动到目标节点上面。

若是咱们不打算从特定的节点上取出指定数量的哈希槽， 那么能够向 redis-trib 输入 all ， 这样的话， 集群中的全部主节点都会成为源节点， redis-trib 将从各个源节点中各取出一部分哈希槽， 凑够 1000 个， 而后移动到目标节点上面：

$ ./redis-trib.rb reshard 127.0.0.1:7000
...
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1:all

输入 all 并按下回车以后， redis-trib 将打印出哈希槽的移动计划， 若是你以为没问题的话， 就能够输入 yes 并再次按下回车：

$ ./redis-trib.rb reshard 127.0.0.1:7000
...
Moving slot 11421 from 393c6df5eb4b4cec323f0e4ca961c8b256e3460a
Moving slot 11422 from 393c6df5eb4b4cec323f0e4ca961c8b256e3460a
Moving slot 5461 from e68e52cee0550f558b03b342f2f0354d2b8a083b
Moving slot 5469 from e68e52cee0550f558b03b342f2f0354d2b8a083b
...
Moving slot 5959 from e68e52cee0550f558b03b342f2f0354d2b8a083b
Do you want to proceed with the proposed reshard plan (yes/no)? yes

输入 yes 并使用按下回车以后， redis-trib 就会正式开始执行从新分片操做， 将指定的哈希槽从源节点一个个地移动到目标节点上面：

$ ./redis-trib.rb reshard 127.0.0.1:7000
...
Moving slot 5934 from 127.0.0.1:7001 to 127.0.0.1:7000:
Moving slot 5935 from 127.0.0.1:7001 to 127.0.0.1:7000:
Moving slot 5936 from 127.0.0.1:7001 to 127.0.0.1:7000:
Moving slot 5937 from 127.0.0.1:7001 to 127.0.0.1:7000:
...
Moving slot 5959 from 127.0.0.1:7001 to 127.0.0.1:7000:

在从新分片的过程当中， example.rb 应该能够继续正常运行， 不会出现任何问题。

在从新分片操做执行完毕以后， 可使用如下命令来检查集群是否正常：

$ ./redis-trib.rb check 127.0.0.1:7000
Connecting to node 127.0.0.1:7000: OK
Connecting to node 127.0.0.1:7002: OK
Connecting to node 127.0.0.1:7005: OK
Connecting to node 127.0.0.1:7001: OK
Connecting to node 127.0.0.1:7003: OK
Connecting to node 127.0.0.1:7004: OK
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000
slots:0-5959,10922-11422 (6461 slots) master
M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002
slots:11423-16383 (4961 slots) master
S: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005
slots: (0 slots) slave
M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001
slots:5960-10921 (4962 slots) master
S: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003
slots: (0 slots) slave
S: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004
slots: (0 slots) slave
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

根据检查结果显示， 集群运做正常。

须要注意的就是， 在三个主节点中， 节点 127.0.0.1:7000 包含了 6461 个哈希槽， 而节点 127.0.0.1:7001 和节点 127.0.0.1:7002 都只包含了 4961 个哈希槽， 由于后二者都将本身的 500 个哈希槽移动到了节点 127.0.0.1:7000 。

6.添加新的节点(特意放在5以后)

根据新添加节点的种类， 咱们须要用两种方法来将新节点添加到集群里面：

• 若是要添加的新节点是一个主节点， 那么咱们须要建立一个空节点（empty node）， 而后将某些哈希桶移动到这个空节点里面。
• 另外一方面， 若是要添加的新节点是一个从节点， 那么咱们须要将这个新节点设置为集群中某个节点的复制品（replica）。

本节将对以上两种状况进行介绍， 首先介绍主节点的添加方法， 而后再介绍从节点的添加方法。

不管添加的是那种节点， 第一步要作的老是添加一个空节点。

咱们能够继续使用以前启动 127.0.0.1:7000 、 127.0.0.1:7001 等节点的方法， 建立一个端口号为 7006 的新节点， 使用的配置文件也和以前同样， 只是记得要将配置中的端口号改成 7000 。

如下是启动端口号为 7006 的新节点的详细步骤：

1. 在终端里建立一个新的标签页。
2. 进入 cluster-test 文件夹。
3. 建立并进入 7006 文件夹。
4. 将 redis.conf 文件复制到 7006 文件夹里面，而后将配置中的端口号选项改成 7006 。
5. 使用命令 ../../redis-server redis.conf 启动节点。

若是一切正常， 那么节点应该会正确地启动。

接下来， 执行如下命令， 将这个新节点添加到集群里面：

./redis-trib.rb addnode 127.0.0.1:7006 127.0.0.1:7000

命令中的 addnode 表示咱们要让 redis-trib 将一个节点添加到集群里面， addnode 以后跟着的是新节点的 IP 地址和端口号， 再以后跟着的是集群中任意一个已存在节点的 IP 地址和端口号， 这里咱们使用的是 127.0.0.1:7000 。

经过 cluster nodes 命令， 咱们能够确认新节点 127.0.0.1:7006 已经被添加到集群里面了：

redis 127.0.0.1:7006> cluster nodes
3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385543178575 0 connected 5960-10921
3fc783611028b1707fd65345e763befb36454d73 127.0.0.1:7004 slave 3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 0 1385543179583 0 connected
f093c80dde814da99c5cf72a7dd01590792b783b :0 myself,master - 0 0 0 connected
2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385543178072 3 connected
a211e242fc6b22a9427fed61285e85892fa04e08 127.0.0.1:7003 slave 97a3a64667477371c4479320d683e4c8db5858b1 0 1385543178575 0 connected
97a3a64667477371c4479320d683e4c8db5858b1 127.0.0.1:7000 master - 0 1385543179080 0 connected 0-5959 10922-11422
3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7005 master - 0 1385543177568 3 connected 11423-16383

新节点如今已经链接上了集群， 成为集群的一份子， 而且能够对客户端的命令请求进行转向了， 可是和其余主节点相比， 新节点还有两点区别：

• 新节点没有包含任何数据， 由于它没有包含任何哈希桶。
• 尽管新节点没有包含任何哈希桶， 但它仍然是一个主节点， 因此在集群须要将某个从节点升级为新的主节点时， 这个新节点不会被选中。

接下来， 只要使用 redis-trib 程序， 将集群中的某些哈希桶移动到新节点里面， 新节点就会成为真正的主节点了。

由于使用 redis-trib 移动哈希桶的方法在前面已经介绍过， 因此这里就再也不重复介绍了。

如今， 让咱们来看看， 将一个新节点转变为某个主节点的复制品（也便是从节点）的方法。

举个例子， 若是咱们打算让新节点成为 127.0.0.1:7005 的从节点， 那么咱们只要用客户端链接上新节点， 而后执行如下命令就能够了：

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 的节点的从节点：

$ redis-cli -p 7000 cluster nodes | grep slave | grep 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e
f093c80dde814da99c5cf72a7dd01590792b783b 127.0.0.1:7006 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385543617702 3 connected
2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385543617198 3 connected

3c3a0c... 如今有两个从节点， 一个从节点的端口号为 7002 ， 而另外一个从节点的端口号为 7006 。