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. 配置选项以及启动
设置３个节点，将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集群状态。
这里启动了３个实例: 6379, 6380, 6381.
3. 设置集群节点
这里一般需要基于redis-cli进入命令行参数，然后输入cluster meet的命令，进行cluster的注册：
这里我们从6379这个实例登陆，分别注册6380, 6381两个节点。注册完成后，然后查看集群信息，可以发现其整个集群的信息为３个节点。
4. 创建shell脚本，初始化slots
创建初始化slot的脚本：
>
#!/bin/bash
for i in {1..16383}; do ./src/redis-cli cluster addslots $i; done
在脚本里面总共添加１６３８３个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