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

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

你可能感兴趣的:(Redis cluster的配置过程)