Redis cluster的配置过程

    当访问量比较大，使用到redis集群的时候，就需要面临一个问题，读写分离。这就意味要么客户端知道主节点是哪个节点，从节点是哪些节点？要么就是，中间加一个代理，来实现主从复制的要求。Redis集群的方案有很多，此处介绍redis官方给出的方案，推荐使用。

    基于分片。一个 Redis cluster集群包含 16384 个哈希槽, 任意一个key都可以通过 CRC16(key) % 16384 这个公式计算出应当属于哪个槽。每个槽应当落在哪个节点上，也是事先定好。这样，进行任一操作时，首先会根据key计算出对应的节点，然后操作相应的节点就可以了。所以说，其实cluster跟单点相比，只是多了一个给key计算sharding值的过程，并没有增加多少复杂度，个人认为完全可以放心使用。像增删节点、重启这些对redis本身的操作，和client端对数据的操作，是两套流程，可以做到互不干扰。关于节点故障，一是有slave，二是即便这一个节点完全挂掉，也只是落在这个节点上的数据不可用，不会有类似"雪崩"这样的问题影响整个集群。数据的恢复之类的逻辑，也与单点完全一致，是独立于集群其他部分的。redis cluster的整个设计是比较简单的，并没有引入太多新问题，大部分操作都可以按照单点的操作流程进行操作。至于cluster最终的易用性，其实很大程度上取决client端的代码可靠性，而jedis现在的代码也已经很完善了，用起来也比较方便。

优点：无中心的P2P Gossip分散式模式，更少的来回次数并降低延迟，自动在多个节点进行分片，不需要第三方软件支持协调机制；缺点：依赖于redis 3,0或更高的版本，没有后台界面，需要智能客户端，Redis客户端必须支持Redis Cluster架构，教Codis有更多的维护升级成本；

集群文件配置：

cluster-enabled：是否启用集群环境，默认注释掉的；

cluster-config-file：cluster集群配置文件，该文件不需要有东西，集群会自己写，但是必须要有该文件，默认注释掉了。该文件，默认放置在etc目录下；

cluster-node-timeout：判断节点是否故障的超时时长，默认被注释；

cluster-slave-validity-factor 进行故障转移时,salve会申请成为master。有时slave会和master失联很久导致数据较旧，这样的slave不应该成为master。这个配置用来判断slave是否和master失联时间过长。

实验：实现redis集群

三台主机，node1，node2，node3；实现redis-cluster；

在三个节点上执行：

vim /etc/redis.conf

bind 0.0.0.0

cluster-enabled yes

cluster-config-file nodes-6379.conf

cluster-node-timeout 15000

cluster-slave-validity-factor 10

systemctl start redis

node1节点：

systemctl start redis

ss -ntl

redis-cli

127.0.0.1:6379> config get cluster-enabled

    (empty list or set)

127.0.0.1:6379> cluster info

    cluster_state:fail        # 集群的状态；

    cluster_slots_assigned:0

    cluster_slots_ok:0

    cluster_slots_pfail:0

    cluster_slots_fail:0

    cluster_known_nodes:1

    cluster_size:0

    cluster_current_epoch:0

    cluster_my_epoch:0

    cluster_stats_messages_sent:0

    cluster_stats_messages_received:0

127.0.0.1:6379> exit

for i in {0..5461};do redis-cli cluster addslots $i;done        # 添加哈希槽；

node2节点：

systemctl restart redis

ss -ntl

for i in {5462..10922};do redis-cli cluster addslots$i;done    # 添加哈希槽；

node3节点：

systemctl restart redis

ss -ntl

for i in {10923..16384};do redis-cli cluster addslots $i;done    # 添加哈希槽

node2节点：

for i in {1..20};do redis-cli set key$i value$i;done        # 添加数据，测试效果；

    OK

    (error) MOVED 4998 192.168.109.7:6379

    (error) MOVED 935 192.168.109.7:6379

    (error) MOVED 13120 192.168.109.6:6379

    OK

    (error) MOVED 4866 192.168.109.7:6379

    ……

node1节点：

redis-cli

127.0.0.1:6379> cluster meet 192.168.109.6

    (error) ERR Wrong CLUSTER subcommand or number of arguments

127.0.0.1:6379> cluster meet 192.168.109.6 6379    # 添加集群；

    OK

127.0.0.1:6379> cluster meet 192.168.109.8 6379    # 添加集群；

    OK

127.0.0.1:6379> cluster info        # 查看集群的状态；

    cluster_state:ok            # 集群配置成功

    cluster_slots_assigned:16384

    cluster_slots_ok:16384

    cluster_slots_pfail:0

    cluster_slots_fail:0    

    cluster_known_nodes:3

    cluster_size:3

    cluster_current_epoch:2

    cluster_my_epoch:2

    cluster_stats_messages_sent:29

    cluster_stats_messages_received:29

127.0.0.1:6379> cluster nodes    # 查看集群的节点；

    b22df3f9965c33375956887de1bf17483fc1d58f 192.168.109.8:6379 master - 0 1513168145410 0 connected 5462-10922

    11e6acb0b53841b276c1ffed1913f6e3d16ee15c 192.168.109.6:6379 master - 0 1513168144401 1 connected 10923-16383

    94b161eea14d5eb7ed99e1f71c79cea980330ae2 192.168.109.7:6379 myself,master - 0 0 2 connected 0-5461

127.0.0.1:6379> get key1    

    (error) MOVED 9189 192.168.109.8:6379        # 在节点1上，查看key1的值，因为该值不在此处存放，所以，node1反馈给客户端，数据的地址。在生产环境中，使用的是智能设备，它会自己去访问，此处没办法模拟。

127.0.0.1:6379> get key2

    (nil)

127.0.0.1:6379> get key3

    (nil)

node2节点：

redis-cli

127.0.0.1:6379> get key1

    "value1"

127.0.0.1:6379> get key2

    (error) MOVED 4998 192.168.109.7:6379

注意：在工作环境中，还需要使用主从备份。此处由于没有多余的机器，没有设置从属节点；可以使用多实例技术。