共计 2846 个字符，预计需要花费 8 分钟才能阅读完成。
1. Redis 的 cluster 集群
在官方文档 Cluster Spec 中，作者详细介绍了 Redis 集群为什么要设计成现在的样子。最核心的目标有三个：
性能：这是 Redis 赖以生存的看家本领，增加集群功能后当然不能对性能产生太大影响，所以 Redis 采取了 P2P 而非 Proxy 方式、异步复制、客户端重定向等设计，而牺牲了部分的一致性、使用性。
可用性：在 Cluster 推出之前，可用性要靠 Sentinel 保证。有了集群之后也自动具有了 Sentinel 的监控和自动 Failover 能力。
水平扩展：集群的最重要能力当然是扩展，文档中称可以线性扩展到 1000 结点。
redis Cluster 集群功能推出已经有一段时间了。在单机版的 Redis 中，每个 Master 之间是没有任何通信的，所以我们一般在 Jedis 客户端或者 Codis 这样的代理中做 Pre-sharding。按照 CAP 理论来说，单机版的 Redis 属于保证 CP(Consistency & Partition-Tolerancy)而牺牲 A(Availability)，也就说 Redis 能够保证所有用户看到相同的数据（一致性，因为 Redis 不自动冗余数据）和网络通信出问题时，暂时隔离开的子系统能继续运行（分区容忍性，因为 Master 之间没有直接关系，不需要通信），但是不保证某些结点故障时，所有请求都能被响应（可用性，某个 Master 结点挂了的话，那么它上面分片的数据就无法访问了）。
有了 Cluster 功能后，Redis 从一个单纯的 NoSQL 内存数据库变成了分布式 NoSQL 数据库，CAP 模型也从 CP 变成了 AP。也就是说，通过自动分片和冗余数据，Redis 具有了真正的分布式能力，某个结点挂了的话，因为数据在其他结点上有备份，所以其他结点顶上来就可以继续提供服务，保证了 Availability。然而，也正因为这一点，Redis 无法保证曾经的强一致性了。这也是 CAP 理论要求的，三者只能取其二。
2. 配置选项以及启动
设置3个节点，将 enable-cluster 设置为 yes, 修改 cluster-config-file nodes-6379.conf，将其设置为不同的文件即可，无需此 nodes 文件存在。
修改 redis.conf 配置文件的内容：
cluster-enabled yes
cluster-config-file nodes-6379.conf
其中 node-6739.conf 并不要求真实存在，只要不同的 redis 实例不相同即可。
然后分别启动各个 redis 的实例，然后查看进程:
从图中可以发现，其中的进程后面都带有 cluster 的字样，标示其为 cluster 集群状态。
这里启动了3个实例: 6379, 6380, 6381.
3. 设置集群节点
这里一般需要基于 redis-cli 进入命令行参数，然后输入 cluster meet 的命令，进行 cluster 的注册：
这里我们从 6379 这个实例登陆，分别注册 6380, 6381 两个节点。注册完成后，然后查看集群信息，可以发现其整个集群的信息为3个节点。
4. 创建 shell 脚本，初始化 slots
创建初始化 slot 的脚本：
>
#!/bin/bash
for i in {1..16383}; do ./src/redis-cli cluster addslots $i; done
在脚本里面总共添加16383个 slot。
修改该脚本的执行权限，执行之，即可获取相应的结果信息。
5. 查看 slots 的内容
cluster slots : 查看 slots 信息
cluster nodes: 查看节点信息
从上面可以整个集群的基本状况。
6. 基于普通模式操作集群/集群模式
基于命令行来查看信息的设置：
redis-cli -p 6739
redis-cli -c -p 6739
从这里可以看懂，在 cluster 模式下与普通模式下的不同，集群模式下客户端可以自动的切换到其他节点。
正常情况下的客户端执行逻辑如下：
7. 安装 ruby 以及 gem 的 redis 组件
各个操作系统的不同，安装方案各有差异，这里以 Ubuntu 的方式来进行。
8. 进行集群的 reshard
src/redis-trib.rb reshard 127.0.0.1:6739
从源节点移动到目标节点
• ./redis-trib.rb reshard 127.0.0.1:6379
• How many slots do you want to move (from 1 to 16384)? 4000 // 输入被迁移的 solt 的数量
• What is the receiving node ID? // 输入目的地节点的 id, 执行第一行命
• Please enter all the source node IDs.// 输入被迁移的槽
• Do you want to proceed with the proposed reshard plan (yes/no)? Yes // 迁移计划确认
如何来确认 reshard 来进行呢？查看命令的日志即可得知：
9. 总结
redis 提供了完整的一套如何进行集群处理的机制，并利用一致性 hash 来更好的处理 redis 的动态调整。
下面关于 Redis 的文章您也可能喜欢，不妨参考下：
Ubuntu 14.04 下 Redis 安装及简单测试 http://www.linuxidc.com/Linux/2014-05/101544.htm
Redis 主从复制基本配置 http://www.linuxidc.com/Linux/2015-03/115610.htm
CentOS 7 下 Redis 的安装与配置 http://www.linuxidc.com/Linux/2017-02/140363.htm
Ubuntu 14.04 安装 Redis 与简单配置 http://www.linuxidc.com/Linux/2017-01/139075.htm
Ubuntu 16.04 环境中安装 PHP7.0 Redis 扩展 http://www.linuxidc.com/Linux/2016-09/135631.htm
Redis 单机 & 集群离线安装部署 http://www.linuxidc.com/Linux/2017-03/141403.htm
CentOS 7.0 安装 Redis 3.2.1 详细过程和使用常见问题 http://www.linuxidc.com/Linux/2016-09/135071.htm
Ubuntu 16.04 环境中安装 PHP7.0 Redis 扩展 http://www.linuxidc.com/Linux/2016-09/135631.htm
Ubuntu 15.10 下 Redis 集群部署文档 http://www.linuxidc.com/Linux/2016-06/132340.htm
Redis 实战 中文 PDF http://www.linuxidc.com/Linux/2016-04/129932.htm
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-07/145463.htm
