redis3集群
redis集群节点需要两个TCP端口：
1. 6379端口默认给client提供服务，所有需要访问集群的client和其他集群节点都要能访问（集群节点作为键迁移）
2. 16379作为集群通信端口，节点到节点的通信的二进制通道（用于节点失效检测、配置更新、故障迁移认证），注意这个端口总是提供服务端口+10000
redis集群的主从模型
防止一台故障集群故障，master故障可以使slave提升为master，继续提供服务
一个master可以有N个slave
redis集群数据一致性
主从同步的问题：
由于主从没有通告机制，所以客户写到master之后再同步给slave，slave不会向master通告是否slave是否同步OK，这样在客户写给master之后，master挂了（数据写入了master），挂了之后数据不能同步到slave，这样slave提升到master之后，写入的数据就丢失了。
主从同步复制：
通过WAIT命令支持同步写机制。会导致写性能降低。即使使用同步写也存在数据一致性的问题：
Z1
A----
A1
B----
B1
C----
C1
Z1（客户端）和B在一个网络区域，剩余在一个区域。当两个区域的网络中断，中断很快恢复时，集群将正常运行。当中断时间足够长时，B1被提升为master，Z1写入B的数据就会丢失。注意，Z1能写入B的数量为maximum window：时间足够长的话，有多数master节点的区域选举了一个slave为master，在少数区域的所有主节点将禁止写入。
这个超时的时间是redis集群非常重要的一个配置：
node timeout。
node timeout超时后，某个主节点被视为失效，可以被其slave接替为master。类似的，少数区域内的其他主节点进入错误状态，停止接收写入。（主节点的个数是确定的，每个区域可以计算出当前区域是少数节点还是多数节点，这是网络分割为两个部分的情况，多余两个部分可能会出现所有区域都算作少数节点吧）
redis集群配置参数
cluster-enabled yes开启redis集群。no不开启集群。
cluster-config-file 注意，这个配置文件用户不可编辑，redis集群节点在有更改时自动更新。文件中列出集群中的其他节点的状态、持久变量等。该文件重写和刷新表面接收到某些消息。
cluster-node-timeout redis集群节点可以中断的最大时长，没有配置被视为节点失败。在指定时间内master节点不可达的话，slave将接替master。这个参数控制redis集群其他重要的属性。尤其是，各节点在指定时间内不可达多数主节点区域的话，将会停止接收请求。
cluster-slave-validity-factor 如果设置为0，slave将总是尝试接管master，而不管master和slave之间中断的时长。如果为正，最大中断时长=node timeout时长*该参数提供的因子，并且如果该节点为slave，如果master连接中断大于指定时长，它将不会启动故障切换
（有些slave可能与master断开一段时间了，导致数据过于陈旧，避免这些slave接替master）。例如，node timeout设置为5秒，validity factor设置为10，slave与master连接中断大于50秒，slave将不会尝试去接替master。注意，在一个主节点失败后如果没有可以接替master的slave，非0的值将导致redis集群不可用。在这种情况下，只有原来的master重新加入集群才可以恢复集群。
cluster-migration-barrier master连接的slave的数量大于该值，slave才能够迁移到
孤立的master
cluster-require-full-coverage 默认情况下，集群全部的slot有节点负责，集群状态才ok，才能提供服务，设置为no，可以在slot没有全部分配的时候提供服务。
不建议打开该配置，会造成分区的时候，小分区的master一直在接受写请求，而造成很长时间数据不一致。
配置：
[root@ELK-REDIS-01 redis]# /root/redis-3.2.8/src/redis-trib.rb create --replicas 1 10.78.90.23:7000 10.78.90.23:7001 10.78.90.23:7002 10.78.90.27:7010 10.78.90.27:7011 10.78.90.27:7012
>>> Creating cluster
>>> Performing hash slots allocation on 6 nodes...
Using 3 masters:
10.78.90.27:7010
10.78.90.23:7000
10.78.90.27:7011
Adding replica 10.78.90.23:7001 to 10.78.90.27:7010
Adding replica 10.78.90.27:7012 to 10.78.90.23:7000
Adding replica 10.78.90.23:7002 to 10.78.90.27:7011
M: 431729f8dfabbbcdd92604d8c3e2ded9bc15d9d1 10.78.90.23:7000
slots:5461-10922 (5462 slots) master
S: e482230c845ce9fb07e56406b81952d23832b24d 10.78.90.23:7001
replicates 014840be3287f291bd5e946f9fa98f4db7616497
S: f2d2de4b14e7c67f1b8e056c77c8439a75725bd9 10.78.90.23:7002
replicates 982fbf13e4fa86e2786c96f4403d790b18c93bba
M: 014840be3287f291bd5e946f9fa98f4db7616497 10.78.90.27:7010
slots:0-5460 (5461 slots) master
M: 982fbf13e4fa86e2786c96f4403d790b18c93bba 10.78.90.27:7011
slots:10923-16383 (5461 slots) master
S: 5c7691a0f2212f7b7236f83e05e408deb15a8a7c 10.78.90.27:7012
replicates 431729f8dfabbbcdd92604d8c3e2ded9bc15d9d1
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join...
>>> Performing Cluster Check (using node 10.78.90.23:7000)
M: 431729f8dfabbbcdd92604d8c3e2ded9bc15d9d1 10.78.90.23:7000
slots:5461-10922 (5462 slots) master
1 additional replica(s)
M: 014840be3287f291bd5e946f9fa98f4db7616497 10.78.90.27:7010
slots:0-5460 (5461 slots) master
1 additional replica(s)
S: 5c7691a0f2212f7b7236f83e05e408deb15a8a7c 10.78.90.27:7012
slots: (0 slots) slave
replicates 431729f8dfabbbcdd92604d8c3e2ded9bc15d9d1
S: f2d2de4b14e7c67f1b8e056c77c8439a75725bd9 10.78.90.23:7002
slots: (0 slots) slave
replicates 982fbf13e4fa86e2786c96f4403d790b18c93bba
S: e482230c845ce9fb07e56406b81952d23832b24d 10.78.90.23:7001
slots: (0 slots) slave
replicates 014840be3287f291bd5e946f9fa98f4db7616497
M: 982fbf13e4fa86e2786c96f4403d790b18c93bba 10.78.90.27:7011
slots:10923-16383 (5461 slots) master
1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
[root@ELK-REDIS-01 redis]#
[root@ELK-REDIS-02 redis]# /root/redis-3.2.8/src/redis-trib.rb check 127.0.0.1:7010
>>> Performing Cluster Check (using node 127.0.0.1:7010)
M: 014840be3287f291bd5e946f9fa98f4db7616497 127.0.0.1:7010
slots:0-5460 (5461 slots) master
1 additional replica(s)
M: 431729f8dfabbbcdd92604d8c3e2ded9bc15d9d1 10.78.90.23:7000
slots:10922-16383 (5462 slots) master
1 additional replica(s)
S: f2d2de4b14e7c67f1b8e056c77c8439a75725bd9 10.78.90.23:7002
slots: (0 slots) slave
replicates 431729f8dfabbbcdd92604d8c3e2ded9bc15d9d1
S: e482230c845ce9fb07e56406b81952d23832b24d 10.78.90.23:7001
slots: (0 slots) slave
replicates 982fbf13e4fa86e2786c96f4403d790b18c93bba
S: 5c7691a0f2212f7b7236f83e05e408deb15a8a7c 10.78.90.27:7012
slots: (0 slots) slave
replicates 014840be3287f291bd5e946f9fa98f4db7616497
M: 982fbf13e4fa86e2786c96f4403d790b18c93bba 10.78.90.27:7011
slots:5461-10921 (5461 slots) master
1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
[root@ELK-REDIS-02 redis]#
[root@ELK-REDIS-02 redis]# /root/redis-3.2.8/src/redis-trib.rb reshard 127.0.0.1:7010
...
[root@ELK-REDIS-02 redis]#
[root@ELK-REDIS-02 redis-rb-cluster-master]# redis-cli -p 7011 cluster nodes
431729f8dfabbbcdd92604d8c3e2ded9bc15d9d1 10.78.90.23:7000 master - 0 1489811750635 8 connected 10922-16383
f2d2de4b14e7c67f1b8e056c77c8439a75725bd9 10.78.90.23:7002 slave 431729f8dfabbbcdd92604d8c3e2ded9bc15d9d1 0 1489811752037 8 connected
014840be3287f291bd5e946f9fa98f4db7616497 10.78.90.27:7010 master,fail - 1489811272393 1489811270389 9 disconnected
e482230c845ce9fb07e56406b81952d23832b24d 10.78.90.23:7001 slave 982fbf13e4fa86e2786c96f4403d790b18c93bba 0 1489811750535 10 connected
982fbf13e4fa86e2786c96f4403d790b18c93bba 10.78.90.27:7011 myself,master - 0 0 10 connected 5461-10921
5c7691a0f2212f7b7236f83e05e408deb15a8a7c 10.78.90.27:7012 master - 0 1489811751537 11 connected 0-5460
[root@ELK-REDIS-02 redis-rb-cluster-master]#
重新分配slot
redis-trib.rb reshard 127.0.0.1:7000
手动failover
有时强制故障切换实际上没有错误的master很有用。例如为了更新redis中的一个master进程，将master切换到slave将会对可用性影响降到最低。
使用CLUSTER FAILOVER命令做强制故障转移，必须在要迁移的master的某个slave上做。
手动failover比实际master故障转移要特别和更安全，通过确保新的master同步所有旧的master的数据，来避免数据丢失。
客户如果连接到将要故障转移的master上时将停止。同时，master发送replication offset到slave，slave等待replication offset到达。当replication offset到达，开始故障转移，老的master通知配置切换。当客户阻塞在老master时，将被重定向到新的master。
添加新节点
新增节点过程，为master时，增加一个新的空节点，将一些数据移到空节点。为slave时，设置为某个已知节点的slave。
两种方式都会展示，首先展示master。
两种情形第一步都是新增一个空节点。
新增一个节点，配置除了端口号，其他都一样
redis-trib.rb add-node 127.0.0.1:7003 127.0.0.1:7000
第一个参数为新节点，第二个参数已有节点
redis-trib.rb只是发送CLUSTER MEET消息给集群，也可以手动做。但是redis-trib在操作之前会做集群状态检测，即使你知道内部如何工作，应该始终使用redis-trib来操作。
注意，由于节点已经连接到集群，所以可以正确重定向客户的查询，并可以集群通信。
但是有两点和其他master不同：
1.没有数据，因为没有分配slot
2.因为是没有分配slot的master，所以不参加选举。
现在可以使用redis-trib的reshard获取slot了。
添加slave节点
有两种方式。
1.redis-trib.rb add-node --slave 127.0.0.1:7013 127.0.0.1:7010
没有指定是哪个master的slave的话，会自动作作为缺少slave的master的slave
2.redis-trib.rb add-node --slave [--master-id master_id] 127.0.0.1:7013 127.0.0.1:7010
指定slave为特定的master的slave。
手动方式为特定的master添加slave：新建一个新node为空的master，使用CLUSTER REPLICATE命令转变为slave。如果节点作为slave添加，想换个master，用这种方法也可以。
redis 127.0.0.1:7013> CLUSTER REPLICATE xxxxx(master_id)
移除节点
redis-trib del-node 127.0.0.1:7000
第一个参数为集群中某个节点，第二个参数为要移除的节点的id
也可以这样移除master节点，不过master必须为空。
或者可以手动故障转移，角色变为slave时删除。
slave迁移
如果有replicas migration，当一个master没有slave时，有多个slave的master将会自动迁移一个slave给那个master。
replicas migration简短的说：
1.在某时刻，集群将会从有最多slave的master上迁移一个slave给孤立的master
2.在某个master上挂多些slave可以触发这个机制，防止孤立master出现。
3.有个配置项控制slave迁移 cluster-migration-barrier（master连接的slave的数量大于该值，slave才能够迁移到孤立的master）。
集群中更新节点
更新slave，仅仅需要关闭节点，用新版本重新启动。如果客户使用分布式读，并且使用了更新的slave，可以重连去访问其他的可用的slave。
更新master比slave复杂，推荐的更新过程：
1. 使用CLUSTER FAILOVER手动触发故障转移，（master中的一个slave提升为新master，旧master变为slave）
2. 等待master变为slave
3. 更新slave
4. 再手动触发故障转移，slave提升为master
直到所有的节点都被更新。