Redis集群搭建实战：3主 3从 模式
0、准备工作 A、在虚拟机上准备三台CentOS 7系统，IP分别为172.22.13.77,172.22.13.78,172.22.13.79(不清楚的，可以参考另外一个博文 “搭建VMware和CentOS”) B、下载、安装redis5.x版本
1、创建目录（以172.22.13.77这台服务器为例）
在/usr/local下创建redis/redis-cluster两个目录，并在redis-cluster目录下建两个以端口命名的目录8001和8004
2、拷贝配置文件
将安装redis时最原始的配置文件redis.conf分别拷贝到8001和8004两个目录下
3、修改配置文件
8001和8004两个目录下的配置文件修改如下配置
（1）daemonize yes （在后台运行redis）
（2）port 8001（分别对每个机器的端口号进行设置）
（3）dir /usr/local/redis-cluster/8001/（指定数据文件存放位置，必须要指定不同的目录位置，不然会丢失数据），这个目录必须要先建好
（4）cluster-enabled yes（启动集群模式）
（5）cluster-config-file nodes-8001.conf（集群节点信息文件，这里800x最好和port对应上）
（6）cluster-node-timeout 5000
(7) bind 127.0.0.1 -->改为连接的主机IP bind 172.22.13.77
(8) protected-mode no （关闭保护模式）
(9) appendonly yes
(10) pidfile "/var/run/redis_8001.pid" (redis_800*,改为对应的端口)
(11) 注释掉 replicaof 主从复制相关的信息 生产环境需要加密码
(12) requirepass zhuge (设置redis访问密码)
(13) masterauth zhuge (设置集群节点间访问密码，跟上面一致)
4、关闭防火墙
systemctl stop firewalld # 临时关闭防火墙
systemctl disable firewalld # 禁止开机启动
5、启动redis服务
/usr/local/software/redis-5.0.3/src/redis-server /usr/local/redis/redis-cluster/8001/redis.conf
6、验证服务是否以集群模式启动成功
ps -ef |grep redis
成功图示
7、分配主从关系
-a 后面跟的是设置的访问密码
--cluster-replicas 后面跟的 1，表示一个主节点下面分配一个从节点，如果不加 --cluster-replicas 1这个命令，执行完，6台实例都是主节点
/usr/local/software/redis-5.0.3/src/redis-cli -a zhuge --cluster create --cluster-replicas 1 172.22.13.77:8001 172.22.13.78:8002 172.22.13.79:8003 172.22.13.77:8004 172.22.13.78:8005 172.22.13.79:8006
8、验证集群
在任意一个服务器上用客户端命令连接
连接 ： /usr/local/software/redis‐5.0.3/src/redis‐cli ‐a zhuge ‐c ‐h 172.22.13.78 ‐p 8002
验证 ： cluster info（查看集群信息）、cluster nodes（查看节点列表） 
至此，集群3主3从模式搭建成功！
集群相关原理总结
一、集群原理
Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。 当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。
槽位定位算法
Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。 HASH_SLOT = CRC16(key) mod 16384
二、集群选举原理
当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程， 其过程如下：
1.slave发现自己的master变为FAIL
2.将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST 信息
3.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack
4.尝试failover的slave收集master返回的FAILOVER_AUTH_ACK
5.slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)
6.slave广播Pong消息通知其他集群节点。 从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保我们等待FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票
•延迟计算公式： DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms •SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下，持有最新数据的slave将会首先发起选举（理论上）
来源：oschina
链接：https://my.oschina.net/xiaomiaonevergiveup/blog/4705603